Skip to main content

What Do you Think? A Proposal to Java Language For String

86 replies [Last post]

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
tackline
Offline
Joined: 2003-06-19
Points: 0

$ is a valid identifier.

kidxml
Offline
Joined: 2005-03-10
Points: 0

+1

To support raw string in java will be great.
something like "@" in c# or (r'rawstring') in python are valuable. It always make something like regex more readable.

dog
Offline
Joined: 2003-08-22
Points: 0

In general I'm opposed to most proposals for language changes. But this one I think would be useful.

I believe the PHP syntax for this is somewhat like:

END_MARKER>>>
here is some raw
text like SQL or something
END_MARKER

The cool thing is that you can use anything as a marker. I kindof like this. It is useful. If you can parameterize it it would be good too.

Obvious applications: SQL code, message formatting, large text, etc..

javakiddy
Offline
Joined: 2004-01-23
Points: 0

For what it's worth, I tend to stick SQL and lengthy regex's into properties files (which support multi line entries) and read them into a program using java.util.Properties .

This allows some degree of flexibility to change/enhance external data and database formats without needing to re-compile/re-issue the binary. If it turns out there's a bug (an actual example being when one of my apps failed to account for Microsoft smart quotes in a regular expression) I can issue an update by simple sending out a properties file, rather than an entire Jar file.

fuerte
Offline
Joined: 2004-11-22
Points: 0

> For what it's worth, I tend to stick SQL and lengthy
> regex's into properties files (which support multi
> line entries) and read them into a program using
> java.util.Properties .

I tested this using NetBeans. It works and is an acceptable solution to this problem. Here is my sql.xml:
[pre]

Id bigint primary key generated always as identity,
Name varchar(128),
Modified timestamp not null default current timestamp
)]]>


[/pre]
And here is the code snippet:
[pre]
Properties sqlProps = new Properties();
FileInputStream in = new FileInputStream("src/derbytest/sql.xml");
sqlProps.loadFromXML(in);
in.close();
String createTableCustomer = sqlProps.getProperty("CreateTableCustomer");
String createIndexPK_Customer = sqlProps.getProperty("CreateIndexPK_Customer");
[/pre]
An annotation helper to this would be great, to get the string into .class at compile time, so that there would be no runtime penalty (and what if the sql.xml is inside jar):
[pre]
@Property("src/derbytest/sql.xml", "CreateTableCustomer")
String createTableCustomer;
@Property("src/derbytest/sql.xml", "CreateIndexPK_Customer")
String createIndexPK_Customer;
[/pre]
Also xml CDATA sections are a bit confusing, NetBeans editor does not have any structured editing capabilities, it has to be done manually.

sjasja
Offline
Joined: 2004-08-15
Points: 0

> An annotation helper to this would be great,
> to get the string into .class at compile time,
> so that there would be no runtime penalty

My somewhat obsolete laptop PC can fetch 20,000,000 items from a HashMap per second. So in one second it can fetch so many SQL statements that actually executing them will take 22 hours (4 ms/statement which is what "select sysdate from dual" took when I last measured it.) So probably not the most important thing to spend time worrying about, performance-wise.

fuerte
Offline
Joined: 2004-11-22
Points: 0

> > An annotation helper to this would be great,
> > to get the string into .class at compile time,
> > so that there would be no runtime penalty
>
> My somewhat obsolete laptop PC can fetch 20,000,000
> items from a HashMap per second. So in one second it
> can fetch so many SQL statements that actually
> executing them will take 22 hours (4 ms/statement
> which is what "select sysdate from dual" took when I
> last measured it.) So probably not the most important
> thing to spend time worrying about, performance-wise.

Yes but how do you get the property file if it has been packed into jar? The code below does not work anymore, does it?
[pre]
Properties sqlProps = new Properties();
FileInputStream in = new FileInputStream("src/derbytest/sql.xml");
sqlProps.loadFromXML(in);
in.close();
[/pre]
Also having the string at compile time removes one possibility for error, if there is a typo in property key name.

sjasja
Offline
Joined: 2004-08-15
Points: 0

This is getting a bit too detailed and programming-tutorial-y for this forum but anyway:

> Yes but how do you get the property file if it has been packed into jar?

getClass().getResource(). Google should find examples.

Although, whenever I have my sysadmin hat on, I prefer configuration files outside jars so I don't have to do silly unzipping to see them. Server platforms (Unix) have a perfectly good file system for storing files and text processing tools for dealing with them. YMMV.

> Also having the string at compile time removes one possibility
> for error, if there is a typo in property key name.

Sure. As there is a possibility of having a typo in the SQL string, wherever it is stored, or in an annotation parameter. So let's be careful out there. I have written various strings in program code that refer to external objects, e.g. redirect to a JSP page with a specific name. Can't say I recall having had any major trouble with typos. Fairly basic testing should reveal them quickly anyway (three cheers to jUnit!). So can't see myself losing much sleep over that.

I prefer to write simple SQL strings in Strings, and complex ones usually go naturally in stored procedures. I doubt typing " and + characters to split a string is a measurable percentage of a software project. YMMV.

fuerte
Offline
Joined: 2004-11-22
Points: 0

> This is getting a bit too detailed and
> programming-tutorial-y for this forum but anyway:

We are discussing if we should have multi-line strings or not...

> > Yes but how do you get the property file if it has
> been packed into jar?
>
> getClass().getResource(). Google should find
> examples.

The following works if it is in jar or not:
[pre]
Properties sqlProps = new Properties();
InputStream in = getClass().getResourceAsStream("/derbytest/sql.xml");
sqlProps.loadFromXML(in);
in.close();
[/pre]
I think that this is an acceptable solution to multi-line strings. Of course @" "@ would be better and easier in many ways.

> I prefer to write simple SQL strings in Strings, and
> complex ones usually go naturally in stored
> procedures.

Agree.

> I doubt typing " and + characters to
> split a string is a measurable percentage of a
> software project. YMMV.

I hate \n" + ", it feels like Visual Basic, which I have done enough.

@" "@ would make life easier, and it would be trivial to implement, so why not? Also it would help regular expressions.

ahalsey
Offline
Joined: 2005-06-15
Points: 0

> @" "@ would make life easier, and it would be trivial to implement, so why not? Also it would help regular expressions.

I agree. Java's poor support for string literals is one of the reasons why Java has a lousy reputation for text processing applications.

Yesterday I was porting a small app from Ruby to Java. Everytime I encountered a regular expression I needed to litter the regexp with a bunch of backslash escapes, to the extent that the Java version was virtually unreadable compared to the Ruby version.

Why?

When I took a Programming Languages course in college, the text book said that readability is a desireable quality of a programming language. Do the designers of Java think otherwise?

I don't think Java programmers are a bunch of masochists. I know I'm not. Java must continue to evolve, both through inovation and borrowing good ideas from other languages. Otherwise, its user base will move on to the growing number of alternatives.

soupdragon
Offline
Joined: 2006-01-07
Points: 0

> When I took a Programming Languages course in
> college, the text book said that readability is a
> desireable quality of a programming language. Do the
> designers of Java think otherwise?

I've done a fair bit of Perl, with quite a few multi-line strings. My opinion is that, while it's convenient for cut and paste etc., it's the very opposite of readable in the context of language syntax. It's just not so instantly apparent what's code and what's literal.

To my mind the answer is better handling of String literals by the IDEs.

On the other hand, I do take the point about regexp. Regexps were not used in early versions of Java, but they are increasingly valuable. I think you could make a better case for a regexp literal type, as used in JavaScript. It could, in fact, generate a Pattern value rather than a String value. A "/" delimiter isn't, AFAIKS, a big problem for the syntax (since "/" isn't a valid start of a primary expression).

nullpointer
Offline
Joined: 2005-04-10
Points: 0

All string resources must be out of java code!!!
Java is not a script language!

jwenting
Offline
Joined: 2003-12-02
Points: 0

> All string resources must be out of java code!!!
> Java is not a script language!

well said, especially very long strings which are almost always things like status messages and SQL queries which should always be externalised.
i18n and changing database requirements dictate that.

In my experience anyone needing long string constants in his source has a an architecture problem.

Anyone needing copious amounts of annotations has one of those as well...

tchangu
Offline
Joined: 2004-03-05
Points: 0

The quotes and + pretty much clutters the DAO code. Larger SQLs are very difficult to read due to this cluttering. I think Mustang should incorporate some of the good features from C# - Like the free form text as well as ability to extend String class.

devittof
Offline
Joined: 2005-10-23
Points: 0

Something you don't have to forget is that String is not modifiable, so if you have a lot of lines like these

String stat = "insert into xy;"
+ "insert into xy; "
+ "insert into xy; "
+ "insert into xy; "
...

your app can get slow at runtime!

mthornton
Offline
Joined: 2003-06-10
Points: 0

> Something you don't have to forget is that String is
> not modifiable, so if you have a lot of lines like
> these
>
> String stat = "insert into xy;"
> + "insert into xy; "
> + "insert into xy; "
> + "insert into xy; "
> ...
>
> your app can get slow at runtime!

No it doesn't run slow, the compiler concatenates the strings at compile time.

mijzcx
Offline
Joined: 2004-09-11
Points: 0

Yeah, I found out also similar to your syntax. The C# way.

static void Main(string[] args)
{
string hello = @"
The Quick Brown
Fox Jumps Over
The Lazy Dog
";

Console.WriteLine(hello);
} // Main()

which is nice.

fuerte
Offline
Joined: 2004-11-22
Points: 0

@" and "@ would make it possible to have embedded " characters as well. In some language this is extended so that you can have arbitrary characters between @ and " so that you can have any string literal, for example:

@a"this makes it possible to have "@ in the string literal"a@

jwenting
Offline
Joined: 2003-12-02
Points: 0

-10

Why the heck do so many people want change for the sake of change.
Learn to use the tools at your disposal rather than force the world into your frame of mind.

fuerte
Offline
Joined: 2004-11-22
Points: 0

Usually people want to do things easily. It is much easier to copy-paste a SQL string to

@"SELECT *
FROM Customer
WHERE Id = 123"@

than write the following manually:

"SELECT *\nFROM\tCustomer\nWHERE\tId = 123"

and it is also much easier to read the first version later.

Easier to write and easier to read, so better, not?

sjasja
Offline
Joined: 2004-08-15
Points: 0

> "SELECT *\nFROM\tCustomer\nWHERE\tId = 123"

You can improve the readability of this by splitting it into lines and using string concatenation. Also by using spaces instead of \n and \t.

Maybe something like this:
[pre]
String sql =
"select * " +
"from customer " +
"where id = ?";
[/pre]
Out of a, say, six man month project, how many days do you lose if you have to type it like that? Is the typing of extra two quotes and a + sign a significant source of schedule slippage in your typical projects?

Ugly kludge for a teeny weeny insignificant improvement...

fuerte
Offline
Joined: 2004-11-22
Points: 0

But it is better to have the original line feeds and tabs preserved, so that the SQL is formatted correctly when later viewed in log files or SQL monitor.

You just need to approve that multi-line string literals would be a good thing, and the current Java string literals are very primitive and make code ugly and coding unnecessary difficult.

olsonje
Offline
Joined: 2005-08-10
Points: 0

I would personally agree on the sake of SQL being easier with a multi-line string setup as does makes it easier to read, snag out and test, and verify versus a broken up string. Its one of the things I _love_ about Python, but I don't like any way its being proposed in this thread. If it happens someday, cool... If not, then I can keep going without lossing sleep over it, but thats my thoughts.

fuerte
Offline
Joined: 2004-11-22
Points: 0

Okay, what is your proposal then?

"""SELECT *
FROM Customer
WHERE Id = 123"""

That would be OK too.

fuerte
Offline
Joined: 2004-11-22
Points: 0

Not bad. Any fix for the current String literals is more than welcome. A fix that handles both SQL and regular expressions (no need to double every \ character).

My proposal was simply

@"any text here
even line feeds
or tabs or backslashes \ no problem"@

so @" in the beginning and "@ in the end.

brucechapman
Offline
Joined: 2004-03-18
Points: 0

For those that want to play with something ...

https://rapt.dev.java.net/nonav/docs/api/index.html?net/java/dev/rapt/pr...

For info on using it see

https://rapt.dev.java.net/nonav/docs/api/index.html?overview-summary.html

line breaks are resolved to the line.separator value at runtime, which is something no-one has discussed in this thread yet.

Bruce

fuerte
Offline
Joined: 2004-11-22
Points: 0

> For those that want to play with something ...
>
> https://rapt.dev.java.net/nonav/docs/api/index.html?ne
> t/java/dev/rapt/proposed/generators/LongString.html

I would be happy with this, even though I didn't quite understand it. It would solve the problem of indentation as well, because white space + * would be stripped off from the beginning of line.

> For info on using it see
>
> https://rapt.dev.java.net/nonav/docs/api/index.html?ov
> erview-summary.html
>
> line breaks are resolved to the line.separator value
> at runtime, which is something no-one has discussed
> in this thread yet.

Because it does not matter much if it is \n or \r\n or \r because it is just white space in SQL, and in many other cases as well.

mijzcx
Offline
Joined: 2004-09-11
Points: 0

again syntactics yes, syntactics.

I think the "import static" is a big non-sense in Java IMHO. Why'd they approved this crap and why not "multi-string" instead!

As its usability and practice, I wonder how many Java Programmers take advantage on this! Take a look on "Static Imports" area http://www.sitepoint.com/article/introducing-java-5 . Does this promotes productivity or chaos.

patrikbeno
Offline
Joined: 2004-10-11
Points: 0

Man, I love static imports :-) I use them intentively.

And since static imports are explicitly specified in imports section, there is no ambiguity or chaos...

I just love it, when properly used, it decreases overall verbosity and improves readability of the code.

mijzcx
Offline
Joined: 2004-09-11
Points: 0

Why'd I say non-sense?

>>>> Because its just a redundant

---------------------------------------------
This
---------------------------------------------
import static System.out;

public class NewClass{

public static void main( String[] args ) {
out.println( "Hello" );
}
}

----------------------------------------------
Same as
----------------------------------------------
public class NewClass {
public static PrintStream out = System.out;

public static void main( String[] args ) {
out.println( "Hello" );
}
}

a. What problem does it practically trying to solve why it is endorsed?
b. What problem of productivity does that solution addresses?
c. Before the 'static import', do we have problem with readability of declaring static variables inside the class and using it? - same, it also decreases verbosity.

>>>> Because it is prone to pollute the code and slowly adds confusion.

Try to ask before using this feature,
Does this VERBOSITY BUSTER helps me after a month or two?

But one thing I surely knows of, yes it adds quiz value to Java Certification Exam.
------------------------------------------------
A - class file
------------------------------------------------
package staticImport;

public class A {
public static int AMBIGUOUS_INT = 1;
}
------------------------------------------------
B - class file
------------------------------------------------
package staticImport;

import static staticImport.A.AMBIGUOUS_INT;

public class B {
private static final int AMBIGUOUS_INT = 2;

public static void main( String[] args ) {
System.out.println( AMBIGUOUS_INT );
}
}
------------------------------------------------

Put it this way, you are setting at your workbench try to figure out your next big java5 project. At fresh you gathered your team, plan-design- and ready now to implement. And the members are so excited! You can tell them by the expressions of their faces. Why? Maybe, because of this marvelous new feature. You can't blame them, they've been on horrors of java < 5 'declaring static variables inside the class'.

Its time to implement, then next morning comes (with a confident smile)... start to code... then next morning start to code again and again, without questioning the multi-line string - 'why this feature instead of this feature' in java5 improvements. But anyway, you are happy, they are happy, it saves the day (coding the embedded scripts, the regex, the dao-sql, the xmls, the texts) - still keep telling at their selves, "See we're the best, we go deep into strings escape character, double quotes and plus sign", and still proud!

Lets turn back. Normally as the days goes along, your codes gets more and more. Afterwards - you've finished on time fortunately (with your static import team). Surprise! a loud voice broke the silence. Out of feeling of completeness... someone in your team jumps and shouts with joy, "Yes! What a feature, it decreases verbosity!". Another one cries out loud, "It helps us finish our project on time!". But out of 10 members 1 realizes why not multiline-string instead, keep quiet with a bow head - and reminisced, anyway the project is finished.

Finally, as the months or two goes by, no problem seen so far. Then you start a new fresh project. Ooch! When suddenly (1)someone, somebody else discovered a creepy bug crawling mysteriously! (2)Then another next one, post a new features(willing to buy your working time on time).

Now it is debugging time! It is maintenance time! ...Team! Ready... Start scratching your head and meet your old code friends and start jotting your new years resolution!

Conclusion? I'm afraid on the part of readability. I think its confusability feature as the time of judgement comes. That's why IMHO, I say non-sense as compares to multiline-string feature except for the other features added. But still the keyword is still "be careful" as it applies to every endeavors and setups of using.

patrikbeno
Offline
Joined: 2004-10-11
Points: 0

sorry, but it's so funny seen so many lines about nothing... just entertaining lines with almost no argument...

well, this is wrong thread to take this any further...

importing statically System.out is just a bad example, suppose you have an enum with 30 items (fields) and you use them all intensively in other class (some parsing stuff or alike). write some code like this with and without static import and you'll understand...

IDE will quickly tell you where statically imported method or field comes from, exactly the same way we are already used to with ordinarily imported classes...

i think that static import is designed consistently enough to be productive

[b]please note[/b], that the same arguments you used against static imports apply also to

- imports at all (static all not, you can import first.SomeClass and second.SomeClass)
- class loading (multiple classes with the same name, incompatible at runtime)

conclusion :-)

static import is safe and can be helpful. more important risks and dangers are elsewhere...

mijzcx
Offline
Joined: 2004-09-11
Points: 0

> sorry, but it's so funny seen so many lines about nothing... just entertaining lines with almost no argument...
> well, this is wrong thread to take this any further...
I don't think so, perhaps maybe entertaining.
I am not going to argue you on this - I agree this is the wrong thread. I am just trying to give an insight of 'instead'.

> importing statically System.out is just a bad example, suppose you have an enum with 30 items (fields) and you use them all
> intensively in other class (some parsing stuff or alike). write some code like this with and without static import and you'll understand...
I can use MyEnum.ONE...MyEnum.THIRTY its clearer this way.
If you have two enum with identical items - it will clash, still you resort to conventional way.
Worst still, the compiler won't halt on identical field name; one declared as 'import static' and the other one declared as 'public static' inside the class.
I have no idea on some IDE, but in netbeans it won't give you a warning/error signal.

> IDE will quickly tell you where statically imported method or field comes from, exactly the same
> way we are already used to with ordinarily imported classes...
Yes I know, in netbeans it does.

> i think that static import is designed consistently enough to be productive
> please note, that the same arguments you used against static imports apply also to
I am still not convinced.

Here is mine to picture.
>>>>>>>>>>>> dependents [start] <<<<<<<<<<<<<
---------------------------------------------
File: EnumOf30 package importstatic2.penum
---------------------------------------------
package importstatic2.penum;

public enum EnumOf30 {

ONE, TWO, THREE, FOUR, FIVE, SIX, SEVEN, EIGHT, NINE, TEN,
ELEVEN, TWELVE, THIRTEEN, FOURTEEN, FIFTEEN, SIXTEEN, SEVENTEEN, EIGHTEEN, NINETEEN, TWENTY,
TWENTY_ONE, TWENTY_TWO, TWENTY_THREE, TWENTY_FOUR, TWENTY_FIVE, TWENTY_SIX, TWENTY_SEVEN, TWENTY_EIGHT, TWENTY_NINE, THIRTY

}

---------------------------------------------
File: EnumOf30 package importstatic2.penum2
---------------------------------------------
package importstatic2.penum2;

public enum EnumOf30 {

FOREVER, NEVER
}

---------------------------------------------
File: EnumOfSame30 package importstatic2.penum2
---------------------------------------------
package importstatic2.penum2;

public enum EnumOfSame30 {
ONE, TWO, THREE, FOUR, FIVE, SIX, SEVEN, EIGHT, NINE, TEN,
ELEVEN, TWELVE, THIRTEEN, FOURTHEEN, FIFTEEN, SIXTEEN, SEVENTEEN, EIGHTEEN, NINETEEN, TWENTY,
TWENTY_ONE, TWENTY_TWO, TWENTY_THREE, TWENTY_FOUR, TWENTY_FIVE, TWENTY_SIX, TWENTY_SEVEN, TWENTY_EIGHT, TWENTY_NINE, THIRTY
}

---------------------------------------------
File: ClassSameName package importstatic2.samename
---------------------------------------------
package importstatic2.samename;

public class ClassSameName {

public static void doLikeThis() {
System.out.println( "doLikeThis" );
}

}

---------------------------------------------
File: ClassSameName package importstatic2.samename.with
---------------------------------------------
package importstatic2.samename.with;

public class ClassSameName {

public static void doLikeThat() {
System.out.println( "doLikeThat" );
}

}
>>>>>>>>>>>>>> dependent [end] <<<<<<<<<<<<<<<

> - imports at all (static all not, you can import first.SomeClass and second.SomeClass)
> - class loading (multiple classes with the same name, incompatible at runtime)

---------------------------------------------
File: ClassThatUseStaticImportForEnumOf30 Using static import - Modern Way?
---------------------------------------------
package importstatic2;

import static importstatic2.penum.EnumOf30.*;
import static importstatic2.penum2.EnumOf30.*;
//import static importstatic2.penum2.EnumOfSame30.*; // clashes

import static importstatic2.samename.ClassSameName.*; // incompatible at runtime?
import static importstatic2.samename.with.ClassSameName.*; // incompatible at runtime?

public class ClassThatUseStaticImportForEnumOf30 {

public static int ONE = 1; // compiler wont halt about ambiguity

public static void main( String[] args ) {
System.out.println( ONE );
System.out.println( FOREVER );

doLikeThis(); // Any idea where this came from? scenario: I am on the console mode, I can't use Eclipse or Netbeans
doLikeThat(); // I am on dark age using vi or some editor say tinkering my jnode operating system.

}

}

---------------------------------------------
File: ClassThatDoesNotUseStaticImportForEnumOf30 Compares to Conventional Way: Does not use static import
---------------------------------------------
package importstatic2;

import importstatic2.penum.EnumOf30; // clearer

public class ClassThatDoesNotUseStaticImportForEnumOf30 {

public static void main( String[] args ) {
System.out.println( EnumOf30.ONE ); // clearer
}

}

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

> conclusion :)
Maybe its personal preference.

> static import is safe and can be helpful. more important risks and dangers are elsewhere...
1st stmt, I disagree. 2nd stmt, yes I agree. Again, personal preferences. I don't think this is a breakthrough :( back to the main topic.

patrikbeno
Offline
Joined: 2004-10-11
Points: 0

> I can use MyEnum.ONE...MyEnum.THIRTY its clearer this
> way.

clearer, yes, and preferred, yes, unless you need to decrease redundant verbosity without sacrifying clarity... static imports give you the tool...

> If you have two enum with identical items - it will
> clash, still you resort to conventional way.

that's it, they will clash the same way regular imports do... and you resolve this just like you do when using javax.jms.MessageListener and mymessaging.MessageListener in the same class... one of them is fully qualified...

what's wrong with that?

> Worst still, the compiler won't halt on identical
> field name; one declared as 'import static' and the
> other one declared as 'public static' inside the
> class.

that's because locally defined fields are by design visible without importing and therefore they are preferred to any imports, static or not...
the same applies to nested classes, try it.

this is totally consistent behaviour and static imports just conform, they do not introduce anything new...

> import static importstatic2.penum.EnumOf30.*;
> import static importstatic2.penum2.EnumOf30.*;
> //import static importstatic2.penum2.EnumOfSame30.*;
> // clashes

first of all, wildcard import is the way to hell, fight against this one, they cause much more damage than static imports ...

second, compiler prefers explicit (named) imports to wildcards...

[code]
enum Color { RED, GREEN, BLUE; }
enum Color2 { RED, GREEN, BLUE; }

...

import static Color.RED;
import static Color2.*;

...

Object red = RED; // no conflict, using Color.RED;
[/code]

but there will be conflict if you wildcard import both of them...
again, what's wrong with that?

> public static int ONE = 1; // compiler wont halt
> halt about ambiguity

because there is no ambiguity, locally visible type/variable overrides any import (static or not)...
(see above)

> doLikeThis(); // Any idea where this came
> his came from? scenario: I am on the console mode, I
> can't use Eclipse or Netbeans

i don't buy this...

if you want to argument like this, you can safely go ahead and
- fight against imports altogether and use only fully qualified names
- attack inheritance and polymorphism
- etc

because in console mode and VI, you are totally LOST anyway, and the bigger code base is the worse. static imports do not change this a lot..

convinced? wanna continue?
you may start a new thread for this, I might join you there for a while :-)

But I think I said enough...

/peace/

mijzcx
Offline
Joined: 2004-09-11
Points: 0

./peace/ accepted. I gave up :)

In case others would like to spend with this topic, I made a neighboring thread dedicated to this. Let us hear from others opinion.

>because in console mode and VI, you are totally LOST anyway, and the bigger code base is the worse. static imports do not change this a lot..
My answer of concern continues here: http://forums.java.net/jive/thread.jspa?threadID=16171 What Do you Think? "import static" vetoed or voted?

BTW, I have no idea how to indent my code snippets. I hate it, its something of a kind messy here when I copy-paste. My apology. NEED LITTLE HELP :(

brucechapman
Offline
Joined: 2004-03-18
Points: 0

> BTW, I have no idea how to indent my code snippets. I
> hate it, its something of a kind messy here when I
> copy-paste. My apology. NEED LITTLE HELP :(

[code]interface bar {
public static crud();
}[/code]

Was achieved by wrapping in [[b][/b]code] and [[b][/b]/code] tags. And to get the [ in the previous sentence without it being interpreted as a code tag I used [[[b][/b]b][[b][/b]/b] if you are interested. Then I applied that recursively to write the sentence prior to this one, which looks much 'orribler in the editor than you are seeing :)

Bruce

fuerte
Offline
Joined: 2004-11-22
Points: 0

To get back to the subject, what do you think about the following:
http://java.sun.com/developer/technicalArticles/J2EE/injection/

It has a nice example how we can have multi-line strings:
[code]
private @Resource String welcomeMessage;

public class HelloWorld extends HttpServlet {

public void doGet(HttpServletRequest request,
HttpServletResponse response)
throws ServletException, IOException {
PrintWriter out = response.getWriter();
out.println(welcomeMessage);
}


welcomeMessage
java.lang.String
Hello World from env-entry!

[/code]