The "string" here in (Fig1) is a keyword. There shall be distinction between a
String class and a keyword "string" for multiline code presentation.
Inside the brackets is a "message" presented as wordwrap of a long line
message synonymous to message string we traditionally wrote in one line. Resulting to a
long one line output message. The vstat1, and vstat2 variables are String variables
that automatically gets the message assigned.

This I endorsed as a solution to our traditional way of string multiline
presentation - as we all know that it stinks specially on SQL construct
or to some of our embbedded scripting in respect.

Embedded Scripting is a delicate part in programming. One miss or error
in spelling is a big distraction. IDEs are neutral to this string
presentations. This are all treated as raw, same way may it be a script
language embbeded or just a mere "quick brown fox".
We are (The Java Community especially at the DAO side) all
aware that scripts should be tested first before we embbed.

Outside file resources only offer another clumsiness on scripting
side. On one side we would not allow somebody an end user to alter our scripting, a
good example is SQLs. The aim is this, scriptings should be
easy enough to copy and paste from java source to executable scratch pad of the
scripting language of choice. Like for example for MySQL, I need to run first my
console mysql> or any SQL Manager Application and copy paste it to my console
in order to get an assurance that my scripts would run smoothly.
Now in debugging I am already confident that it is not my scripts
who are making some nuisance.

Traditionally we wrote: (Fig2)

public static void main( String[] args )
{
String vstat1, vstat2;

vstat1 = "The quick brown " +
"Fox jumps over " +
"The lazy dog. ";

vstat2 = vstat1;

System.out.println( vstat1 + " " + vstat2);
} // main()

In Fig2 traditionally we wrote like that. In debugging DAO, I first run a notepad or something;
transfer the strings into it; cleanup the quotes and plus signs; then copy and paste it
to the console or sql manager apps; then modify if theres some wringkles; then from
the notepad copy paste again to my java code; then add again a "quotes and a plus sign"
or aStringBuilder.append("again"); aStringBuilder.append("and again and so on"); - just
to envision this good practice. What a worst isnt it?

For embedded xml, yeah you can define also with this kind of construct
(Fig3 below). But not XML embedded language as part of Java language in which
I don't agree, for it will only cause Language Pollution or Confusion. Now vxml1(Fig3 below)
you can now use it like any other strings. And finally (Java)
with its "string" as keyword, Java should be distinct from other language,
especially C# were string and String means the same thing. Isn't it?

(Fig3)

string {
<?xml version="1.0"?>

Some thing like that.

} vxml1;

Sqlj in Oracle and DB2 #sql keyword already has this kind of concept,
but only concentrate to sql construct. You pre-compile first to sqlj
compiler then to javac so to say. As to my concern, I have this strong vibe
that there have been impluse already from the Java Community on kind of
problem I address. As I base this on my experience in programming particularly
in embedding scripting languages; making us like chasing cats and dogs in
debugging stage. Me, particular to SQL Scripting in DAO part.

> Suggestion for @" has an expansion, so that you could
> have any digits between @ and " characters, and those
> digits must be repeated in the end. So you could
> easily have "@ in the string itself:
>
> @1"this is a complex string containing "@ and
> anything"1@

yugh, gross indeed.
Just learn to use the system you have rather than trying to subvert it into something disgusting.
What's so hard about \" that you need to replace it with "@ anyway?

The more "proposals" like this I see the more scared I get for the future of the language if and when Sun releases the language specs to the open source sharks.
All of these idioteries will immediately find their way into the core language, utterly destroying it.

e.g. you can minimize the need for escaping in literals where escape sequence of the underlying language (regular expressions, for instance) conflicts with java escaping. for multiline literals, it completely eliminates
" + "

it think it is a good idea, although the proposal is quite ugly. its potential is great...

it does not neccessarily means it gets immediately into the language...

i guess sun will try to protect java from unreasonable forking while still providing kind of opensource licensing... yes, most likely many forks will be created but most of them will be just an academical research... (which is not bad)

1) great idea because it *mostly* eliminates the need for escaping (i.e. you are capable to write most of the literals withoyut any escape sequences - you are able to define terminator that does not conflict with anything)

2) however, you still need means for escaping because not everything can or is allowed to be written without it (suppose you want to keep your source code plain ASCII)

> 1) great idea because it *mostly* eliminates the need
> for escaping (i.e. you are capable to write most of
> the literals withoyut any escape sequences - you are
> able to define terminator that does not conflict with
> anything)

Exactly.

> 2) however, you still need means for escaping because
> not everything can or is allowed to be written
> without it (suppose you want to keep your source code
> plain ASCII)

I think that @" should be used just for these cases, where we have SQL statements or regular expressions, which are plain ASCII (or ANSI or UTF8). There should be no need to use escaping. If you want escaping, then use the regular ".

What I did for a while is that I resort to learn a new (scripting) language to compensate this deficiency. Not only language but languages that support this lacks - like phython (jython), ruby (jruby) and groovy. I like to think this concern as a blessing (forces me seeing other languages in different perspective like ruby) as this scripts alleviates me somehow in terms of this absence. But even though joining the twos, deep inside I still feel that this is still something missing, leads me back to U-turn.

This is a language issue (Sun holds java), I'll leave it to the experts. What this forums.java.net is setup to? Suggestion? Anyway the suggestions are up there now, the concept is there been implemented by other languages. Now, I don't care if it is JDK 6 or 7 or anything or nothing, its up to the experts to any form of progress concerning to this. It's up to them to listen or don't for any reason or some other grounds anyway.

> > Yes, BUT, " requires that all \ characters be
> > doubled. @" would parse all characters as they
> are.
> > That is a big difference.
>
> you STILL need some form of escaping, you can't just
> give it up...
>
> e.g. how would you enter "@ in your string? you use
> escape sequence. once you have any escape sequences,
> you need to escape the escape character itself :-)
>
> what I would agree with, is that we need means to
> redefine escape character per literal (i think there
> already is some thread about this on this site).
>
> (e.g. this would be very useful for regexp where RE
> escaping conflicts with java escaping (\b\t\\ ==
> "\\b\\t\\\\") and makes some more regexps almost
> unreadable.)

Suggestion for @" has an expansion, so that you could have any digits between @ and " characters, and those digits must be repeated in the end. So you could easily have "@ in the string itself:

> Suggestion for @" has an expansion, so that you could
> have any digits between @ and " characters, and those
> digits must be repeated in the end. So you could
> easily have "@ in the string itself:

That's gross.

If it's to be done, I suggest opening the multiline string with %> and closing with syntax.

> > Suggestion for @" has an expansion, so that you
> could
> > have any digits between @ and " characters, and
> those
> > digits must be repeated in the end. So you could
> > easily have "@ in the string itself:
>
> That's gross.
>
> If it's to be done, I suggest opening the multiline
> string with %> and closing with
> interpolation could added using a syntax.

%> is no better than @" and it would be confusing or impossible in JSP pages.

Though it was posted as a BUG, with a bug_id 4472509, instead of RFE, for those "YEA" I think it would be helpful to support this one. I don't know if anyone, anybody (expert group) had pushed this already to JSR.

Putting code inside property files does not magically make it not code. In order to be willing to replace code in configuration files, you should be willing to replace code.

SQL DML code is intimately involved with the code that calls it. If you add a field, you will need to alter both the SQL and the Java that reads/writes it. If you have Oracle SQL using CONNECT BY PRIOR, porting to another database will require more than just changing the SQL.

Working with the results of this kind of sloppy thinking is a pain. Instead of all the relevant code at the same place in the same file, it's spread over two files (at least).

Or something similar. I'm sure that you could have a better syntax, but the idea is there:
* Multi-line strings and other complex data embedded into Java source file, and compiled into .class.
* We could have different types, even byte[] binary data encoded in hex or base64.
* This solves the problem of indentation, because the @Resource definition would always be outside of class, in the beginning of line.
* @Resource definitions could in the beginning or end of file.

> > > 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.
> >
> > Sorry, I am referring to this reaction.
>
> Exactly. I just can't understand why so many Java
> people oppose EVERY change

What I'm seeing is that people are coming to Java and then looking to program in the language that they are coming from when many of these features are found in the language, just in different forms. People need to take a bit of time to learn the langauge (beyond syntax).

Now for this problem, String literials are... string literials... However I do think that it would be nice if String literials were not bounded by the EOL so that you could avoid things such as

Sting someString = "blah blah blah" +
"yeah yeah yeah";

It could be as simple as

String someString = "blah blah blah
yeah yeah yeah";

FYI, the compiler will optimize away the + operator.

>
> Why did they implement annotations in JDK5 then? It
> is just syntactic sugar, to catch up with C#.

You should read Dr. Heinz (Javaspecialist) on the subject of the new language features. These things come with some very interesting penalties. Many of these penalties were well known before they were released. Are we resistant to change? I think not.. yet when I can show a room of more then 600 developers a single trivial piece of code that looks very reasonable and not a *single* one of these developers can tell you what it does..... I'll take the name fossil with pride if I'm against change like that!

> > Exactly. I just can't understand why so many Java
> > people oppose EVERY change
>
> What I'm seeing is that people are coming to Java and
> then looking to program in the language that they are
> coming from when many of these features are found in
> the language, just in different forms. People need to
> take a bit of time to learn the langauge (beyond
> syntax).
>
indeed, that seems to be the vast majority of "Java must be changed to do XXXXX" cases (maybe all of them, I don't know enough languages to make that assertion).

> Now for this problem, String literials are... string
> literials... However I do think that it would be nice
> if String literials were not bounded by the EOL so
> that you could avoid things such as
>
> Sting someString = "blah blah blah" +
> "yeah yeah yeah";
>
> It could be as simple as
>
> String someString = "blah blah blah
> yeah yeah yeah";
>
> FYI, the compiler will optimize away the + operator.
>
Problem is, how would your example be interpreted?
I'd expect it to keep any line ends and whitespace included in the literal (after all, it's a literal), but apparently you want it to strip whitespace and line ends.

But that would make it impossible to split on whitespace that needs to be maintained, forcing me to split for example "the big brown fox jumped over the tall white fence" halfway through "jumped" instead of on whitespace which is a more logical location.

The Python method of triple quotes for multi-line strings works well. I'm working on a project right now with lots of long SQL statements, and this feature would greatly increase readability.

[code]
String statement = """
This is a multi-line
string, with indents
You are %s!
Wow!
""";
[/code]

The whitespace before the column of the first line would be ignored so that it would be equivalent to this:
[code]
"This is a multi-line\nstring, with indents\n You are %s\nWow!"
[/code]
The syntax doesn't breaking any backward compatibility because """ is currenly not a valid token sequence in Java.

It would also work well with the printf functionality
new with Java5 to insert dynamic values.

> The whitespace before the column of the first line
> would be ignored

So it would be a syntax error if there are characters to the left of the indentation? Maybe not though. It would be difficult to copy+paste text from some other application. So, would they be ignored or not, that is the question.

> > The whitespace before the column of the first line
> > would be ignored
>
> So it would be a syntax error if there are characters
> to the left of the indentation? Maybe not though. It
> would be difficult to copy+paste text from some other
> application. So, would they be ignored or not, that
> is the question.

It would start and the leftmost column of any line in the string. Tabs vs. spaces would have to be worked out, that may have to be a syntax error, or 4 spaces/tab could be assumed.

Although it's the permanent readability of the code I'm concerned about, copy & paste from another application would be at least as easy as the other proposed solutions:

All you do is copy & paste, then select block of text and press tab, etc.

I am intruiged by the idea of and IDE solution. I looked at making an Eclipse plugin, but I don't think it's possible with that framework. Pity, as it wouldn't involve the (necessary) bureaucracy of making javac solution.

>Why did they implement annotations in JDK5 then? It is just
> syntactic sugar, to catch up with C#.

Principally, I should think, for the benefit of EJB-3 and similar persistence managers.

But annotations, and generics, are considerably more than syntactic sugar. They enable you to do stuff that you couldn't do without them. Also annotations open up the possibility of doing stuff that would otherwise require language extensions.

I think one way to help the discusion is to get someone to create a patch for the proposal in the collaboration project and then we can experience it in real life. Talking and theorising is ok, but it can help expedite things when there is something real to play with. People may fall in love with it. You may decide you hate it and want to express it in a different way. Maybe string should be expressed as String, for example. :D

Yes, Java should be simple enough but not simplest. Itâ€™s not Java who is a monster; it is our bloated codes that do if we donâ€™t follow sound OO coding practices and principles. A bad artist is a bad artist â€“ they say.

Now, those simple scripts that are effectively part of the code, like simple SQL SELECT statement - which wonâ€™t vary between databases or any scripting statements that are used only once, should be easy enough to test and elegant to read for maintainability reason â€“ the multi-line proposal comes to picture.

And to those properties that are adjustable, should be outside file â€“ as resources. Be it an xml format, properties format, or any format you wish to parse. There is the regex package anyway.

The candidates for outside file are internationalization string bundles, variable configuration adjustments, declarative GUIs, and some minors that you allow your user to customize, like color, width, height properties or something... But, for the parts that are restricted and vulnerable, it should be part of the code.

And speaking of annotation, for the sake of argument, back in J2EE EJB 1 and 2 (BMP and CMP) days, it was tedious to code for a simple business logic with 3 (the PK, Stubs and Skeletons) supporting java files and an XML descriptor file. If you imagine yourself coding a project with 500+ tables, it was horrible back then. In spite of this, Xdoclet an open-source project came to the rescue; to save you from typing, defining only to one file, and I think it was the perfect time annotation was adopted out of necessity of that bloated J2EE EJBs back then. You could feel how proud those J2EE developers before (I am one of those), seems they donâ€™t even want to touch the SQL side of scripting. And from that on, the community realizes that there is a need to adjust, as you see now in EJB3 as well as Java 1.5. So what was the side effect? Some developers started to develop trauma, and hesitant about change. Some wants to continue to live in the darker side. But some wants to emerge from their egg shells.

As I am lucky to be with in this J-neration as compared to those ABaCus programmers who have no JCP ago, for me, Java should look professional and it should look professional.

â€œAdopt their Good[s] Discard the Bad[s] and if Nothing to Adopt, Invent Good[s] or Do Nothingâ€ â€“ itâ€™s kind of like that principle.

Historically, Java has relied more on tools than on clever language features. So I think many people will agree with me on this post.

Many people on this thread argumented that multiline strings would ease the cut and paste of string literals from other editors. Isn't it time for those nice and huge IDEs to have a special shortcut to automatically format the input of a paste operation into a string literal, automatically scaping the special characters and adding plus signs and doing the indentation? For example, instead of doing a Crtl+v on Eclipse, do a Crtl+Shift+v, and the IDE will do de job for you. Or perhaps automatically detect that you have de carret placed inside a string literal, and automatically do de formating: type "", place de carret between the apostrophes and paste it. Hover the mouse cursor over this strings literals, and the IDE could popup a simple dialog box, for you to edit the string without having to worry about scaping characters or break lines. Perhaps some of this features already exist, and I don't know :)

Such new features language can indeed be nice, but we need to let the idea mature, we need to continue thinking about them for a while, before we embrace or discard it.

> Historically, Java has relied more on tools than on
> clever language features. So I think many people will
> agree with me on this post.

I would phrase it different: Because of the Java's clear language design, there occured more powerful tools than for other languages. I do not know of any other language which has comparable tools available (e.g. regarding refactoring). That's a big PLUS for Java.

> Isn't it time for those
> nice and huge IDEs to have a special shortcut to
> automatically format the input of a paste operation
> into a string literal, automatically scaping the
> special characters and adding plus signs and doing
> the indentation?

> > Isn't it time for those
> > nice and huge IDEs to have a special shortcut to
> > automatically format the input of a paste
> operation
> > into a string literal, automatically scaping the
> > special characters and adding plus signs and doing
> > the indentation?
>
> There already is such an IDE available: IntelliJ IDEA.

Does it display the string formatted correctly or does it show the raw Java string expression? Does it support copying the string back to other editor?

Yeah, in the event where there is no multi-line string implementation yet, smart IDEs would be a help or some clever ideas out of our resourcefulness. Thatâ€™s the only best patch, in the meantime.

Ideally, it does something like you write to it and you could just lick your thumb to erase it. Some kind of a normal raw procedure of copy-paste; back-and-forth from editor-to-editor (fat-or-thin editor application); or even mark-from || paste-to the console without any special editorâ€™s effects or tricks. Hopefully by the next JDK release â€œmulti-line string in pure formâ€ would be here to stay.

Indeed. IDEA supports pasting into a string literal with auto escaping. Also, if you press return in a string literal, it'll add \n"+ and start with a new literal in the next line. So much for that.

Nonetheless I would appreciate an effort to make this nicer in the language. I would actually propose to make resource references and access first class in Java, checked by the compiler and linked by the VM, just not within the .java file, but in a separate one.

I'd imagine something like:

@Resource("/com/company/package/stylesheet.xsl")
final String xsl;

@Resource would be a standard annotation equivalent to the ".class" keyword today. When encountered, the compiler would look for a resource /com/company/package/stylesheet.xsl and copy it to the classpath. The resource reference would be stored in the constant pool. Just like the .class reference, it would be resolved and loaded by the VM on class-load time. Just like with class references, a resource reference without a path would be resolved relative to your imports:

import com.company.stylesheets.*;

@Resource("atom2html.xsl")
String stylesheet;

You could support String, byte[], InputStream and Reader (the last two without IOException would be nice).

Benefit: compile and link-time checking that would make resources as comfortable as literals.
Drawback: potentially a tendency to have more entries in your jars with possible performance implications (resources.jar was just extracted from rt.jar in Mustang, for example)

> Increasingly I'm coming to think that long String
> constants, SQL, messages etc., really ought to be in
> config files rather than source.

Okay, if there would be a clean syntax to fetch a SQL string from a config file, like

@config.sql(FETCH_CUSTOMER_BY_ID)

and if there was a standard config file format in Java that would also have an editor, WHERE YOU COULD ACTUALLY HAVE MULTI-LINE STRINGS.

> As I said in the other thread, the problem with
> multi-line string syntax (other than not resting
> comfortably with indentation control etc.) is that
> when you make a typo it can silently swallow code.

>
> Okay, if there would be a clean syntax to fetch a SQL
> string from a config file, like
>
> @config.sql(FETCH_CUSTOMER_BY_ID)
>

Well, how is that so much better than a single method call? I think extended syntax needs consisderably more justification.

> and if there was a standard config file format in
> Java that would also have an editor, WHERE YOU COULD
> ACTUALLY HAVE MULTI-LINE STRINGS.
>

I'm tempted to say there is - XML. My latest program has it's SQL in sections. In a largest program writing a moderately complicated config load class is worthwhile, to my mind.

> > As I said in the other thread, the problem with
> > multi-line string syntax (other than not resting
> > comfortably with indentation control etc.) is that
> > when you make a typo it can silently swallow code.
>
> Or if you use /* and */ it can happen as well.

Granted, but it's one more opportunity for problems. I've done a fair bit of Perl with multi-line strings. In my opinion it's an ugly syntax. For a start it completely distrupts the indentation scheme. Indentation is important in making code comprehensible.

Meanwhile Netbeans, no doubt and increasingly widespread function, will automatically fold java string literals for you; if you hit return inside a string literal it generates the " + ".

On the other hand it [i]is[/i] a nuisance when you're cutting and pasting between source and, say, TOAD.

> > > As I said in the other thread, the problem with
> > > multi-line string syntax (other than not resting
> > > comfortably with indentation control etc.) is
> that
> > > when you make a typo it can silently swallow
> code.
> >
> > Or if you use /* and */ it can happen as well.
>
> Granted, but it's one more opportunity for problems.
> I've done a fair bit of Perl with multi-line strings.
> In my opinion it's an ugly syntax. For a start it
> completely distrupts the indentation scheme.
> Indentation is important in making code
> comprehensible.
>
> Meanwhile Netbeans, no doubt and increasingly
> widespread function, will automatically fold java
> string literals for you; if you hit return inside a
> string literal it generates the " + ".

If Netbeans would show the multiline string literals in place, maybe like in a text box, where you could easily edit, copy+paste, and see the text formatted, and still save the string into file in Java-compatible format (using multiple lines and "+"), then it would solve this problem as well.

But it would be much easier to add this new @" "@ syntax to the language than implement the above to every IDE.

IDE solution would be better in one way at least: It could solve the indentation problem.

> On the other hand it [i]is[/i] a nuisance when you're
> cutting and pasting between source and, say, TOAD.

>
> But it would be much easier to add this new @" "@
> syntax to the language than implement the above to
> every IDE.
>

On the contrary, changes in language syntax, to my mind, need [i]far[/i] more justification. New ideas and tools introduced into one IDE seem to spread pretty quickly to the others. That's the value of the open source approach.

I was thinking that a "paste as string literal" would make a useful addition to IDEs (in fact I may consider writing one for Netbeans) but you're right to suggest that a popup-editor would be more powerful (if substantially more effort to write).

> > 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.
>
> Sorry, I am referring to this reaction.

Exactly. I just can't understand why so many Java people oppose EVERY change, be it so trivial as this multi-line string literal, which would not hurt anyone. It seems that Java people are a bunch of fossils, compared to other languages like C# and Python, which are evolving with good speed.

The official comment to this is that "this is just syntactic sugar to save some people from typing". It seems that people developing Java are sadists, they want to make us suffer. :-)

Why did they implement annotations in JDK5 then? It is just syntactic sugar, to catch up with C#.

annotations were indeed implemented for marketing reasons only, there's no technical reason to have them, they don't add zip.
I'm getting ever more disenchanted with the direction Java is taking, away from a powerful but simple language and towards a massive bloated monster.
Every fault C++ designers made is being replicated by the JCP (except so far operator overloading but that can't be far in the future).

Well... what a nice reaction, Thank you. But, put it this way, the reality is that Java our tool is constantly evolving, take a look around, the community is getting bigger and bigger, the library APIs as well as at language level keeps mutating for better, improving in x-y-z sideways, just to cope up with the demands of reality and to face the more and more challenges waiting ahead. If you take a closer look, Java evolved from other languages shortcomings and if Java will stop adopting change in practical and technical battles, then it will eventually left behind and loose its developerâ€™s mind-shares attractiveness. My intention is not to cloud the flowing river. The point is that, for now as I see, Java lacks â€œmultiline stringâ€ support. And the reality is â€“ Embedded Scripting (ES) demands it. One situation were it is necessary to have this, is that, it is more convenient especially when you are debugging others ES, like DAO codes. Trust me, those SB.appends and plus signs are messy you know. Lets be open-minded, C# has this comfy feature and itâ€™s not bad to be envious, the only bad one it is because itâ€™s C#? Or maybe because itâ€™s from Microsoft?! Politically speakingâ€¦ :-) Well, looking at the bright side of the race, I have this itch to persuade you especially to the language side of JCommunity in resonant to this deficiency I addressed.

P.S. As to those opposing, kindly please explain further the reason why â€œit should notâ€ in convincing form.

I don't see why Netbeans couldn't add this feature.
It would be very handy to have IDE support for Strings, especially ones for regular expressions where it hard to extract the escaped stuff from the text.

An editor popup could be created to show a text input window for long string ... something as simple looking as notepad.

It's amazing how stubborn the deciding body is that we dont have multi-line strings already. Most every other platform/language has them. Of course we've all written the stupid xml reader or text reader that gets the configuration string, but it's just plain need that is driving this, not some innate desire to ruin the code base with hardcoded constants.

Unless they're about to make it such that we dont hardcode ANY string constant in our code, give us easy multi-line strings. Just stop with the questions and give it to us.

I think the general idea is that you would use a translator from XML to what ever you wanted. The translator would typically be in XSLT. EG assuming a long string translator:
[pre]
String s = @longString {
SELECT *
FROM Customer
WHERE Id = 123
};
longStringXSLT.process( s, ... );
[/pre]
Or if you had a more structured SQL translator then maybe something like:
[pre]
int id = 123;
String s = @SQL {
@SELECT {
*
@FROM { Customer }
@WHERE { @Id { @{ id } } }
}
};
SQLXSLT.process( s, ... );
[/pre]
There is also a syntax for introducing variable values into the strings created using the XML notation. See @SQL example above.

PS I am going from memory as to the exact syntax. But I think you will get Sun's drift. Something similar is in the language Scala - I think this is where they got the idea.