java version "1.3.1"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1-b24)
Java HotSpot(TM) Client VM (build 1.3.1-b24, mixed mode)

The current syntax for string literals, as stated in the JLS, has many
practical limitations:

A) String literals that contain many occurances of the '\' character must use
superfluous escaping. Examples of this limitation are:
1) Regular expressions
2) Path syntaxes that use '\' as a path separator, eg. Win32 file paths.

B) String literals cannot contain line breaks. Often the author of the Java
source file would like to add structure, by using whitespace, to the String
literal without breaking the meaning. For instance:

1) Storing a SQL query as a String literal. Using the current version of the
Java Language, the source file author can either put the whole SQL statement in
one line, or break the statement in separate chunks:

String qry =
"SELECT a.name, b.number" +
"FROM table a, table b" +
"WHERE a.id = b.id" +
"ORDER BY name";

The above example is small, but bigger queries quickly start to require a lot
of tab,",+ typing.


Feature Request Proposal

A vertabim string literal would have the following properties:
1) All characters are treaded vertabim, that is, they are not escaped.
1a) Character, hexadecimal and Unicode escape sequences are not processed.
1b) The only character with a special meaning is the tail quote, indicating the
end of the vertabim string literal.
2) A vertabim string may span multiple lines, only ending when the end quote
delimiter is encountered.
3) A vertabim string literal is indicated by a '@' character immediately before
the opening quote: String re = @"\(\d{1,3}\D{1,3)";

  To summarize, I propose adding vertabim String literals as formulated in the C#
Language Specification[1] submitted to the ECMA, paragraph 9.3.4.5.
A similar enhancement is proposed for the next version of ECMAScript (v4).

A number of examples follow to summarize the proposed syntax, and show the
advantage of vertabim string literals.


Examples
(string literal, result string in comment)

String a = "hello, world";                      // hello, world
String b = @"hello, world";                     // hello, world

String c = "hello \t world";                    // hello 	 world
String d = @"hello \t world";                   // hello \t world

String e = "Joe said \"Hello\" to me";		// Joe said "Hello"
String f = @"Joe said ""Hello"" to me";         // Joe said "Hello"

String g = "\\\\server\\share\\file.txt";	// \\server\share\file.txt
String h = @"\\server\share\file.txt";		// \\server\share\file.txt

// A simple query, much more easily separated over multiple lines.
// Also note that indenting is made much easier for these type of text.

String qry = @"
   SELECT
     a.name, b.number
   FROM
     User a, Data b
   WHERE
     a.name = "James"
      AND
     a.id = b.id
";

// A simple regular expression, without the need for erroneous escaping:

String RE = new RE(@"\D{1,3}\S{1,3};");
(Review ID: 126782) 
======================================================================

None
======================================================================

This is yet another request for a syntactic sugar to save some user from
typing. It's not worth it.

  xxxxx@xxxxx   2001-06-28

Alas, it appears the Bug Database anonymizer ate all "at" 
signs in my report. (To test, this is a small HTML encoded 
string: @"/

Here is a repost of the original RFE, hopefully without the 
replaces @'s:

------------------------------------------------------------

The current syntax for string literals, as stated in the 
JLS, has many practical limitations:

A) String literals that contain many occurances of the '\' 
character must use superfluous escaping. Examples of this 
limitation are:

1) Regular expressions
2) Path syntaxes that use '\' as a path separator, eg. 
Win32 file paths.
B) String literals cannot contain line breaks. Often the 
author of the Java source file would like to add structure, 
by using whitespace, to the String literal without breaking 
the meaning. For instance:

1) Storing a SQL query as a String literal. Using the 
current version of the Java Language, the source file 
author can either put the whole SQL statement in one line, 
or break the statement in separate chunks:

String qry =
"SELECT a.name, b.number" +
"FROM table a, table b" +
"WHERE a.id = b.id" +
"ORDER BY name";

The above example is small, but bigger queries quickly 
start to require a lot of tab,",+ typing.

** Feature Request Proposal **

A vertabim string literal would have the following 
properties:
1) All characters are treaded vertabim, that is, they are 
not escaped.
1a) Character, hexadecimal and Unicode escape sequences are 
not processed.
1b) The only character with a special meaning is the tail 
quote, indicating the end of the vertabim string literal.
2) A vertabim string may span multiple lines, only ending 
when the end quote delimiter is encountered.
3) A vertabim string literal is indicated by a '@' 
character immediately before the opening quote:
String re = @"\(\d{1,3}\D{1,3)";

To summarize, I propose adding vertabim String literals as 
formulated in the C# Language Specification[1] submitted to 
the ECMA, paragraph 9.3.4.5.
A similar enhancement is proposed for the next version of 
ECMAScript (v4).

A number of examples follow to summarize the proposed 
syntax, and show the advantage of vertabim string literals.

Examples
(string literal, result string in comment)

String a = "hello, world";               // hello, world
String b = @"hello, world";              // hello, world

String c = "hello \t world";             // hello world
String d = @"hello \t world";            // hello \t world

String e = "Joe said \"Hello\" to me";
// Joe said "Hello" to me
String f = @"Joe said "Hello"" to me";
// Joe said "Hello" to me

String g = "\\\\server\\share\\file.txt";
// \\server\share\file.txt
String h = @"\\server\share\file.txt";
// \\server\share\file.txt

// A simple query, much more easily separated over multiple 
lines.
// Also note that indenting is made much easier for these 
type of text.

String qry = @"
   SELECT
     a.name, b.number
   FROM
     User a, Data b
   WHERE
     a.name = "James"
      AND
     a.id = b.id
";

// A simple regular expression, without the need for 
erroneous escaping:

String RE = new RE(@"\D{1,3}\S{1,3};");

-----------------------------------------------------------
For the C# Language Specification, look at:
http://devresource.hp.com/devresource/Docs/TechPapers/CLIand
CSharp/CLIandCSharpMirror.html

(Another test: @"')

As for the evaluation comments: I agree.

Of course it's syntactic sugar. But is that so bad, since 
it only requires a small parser change? And the goal is 
*not* to type LESS, it's to type in a cleaner way, that's 
easier to read...

Why should we take the 20+ years old C-style literals 
syntax as a given? Why not improve a bit?

I agree that this is a worthwhile change.  I can't tell Sun 
how many times I've screwed up code due to not double-
backslashing properly!

I agree with the Evaluation, completely. This is truly
pointless syntactic sugar, unless you're coming directly
from the C# or Visual Basic world without ever having worked
in any other language, and escape sequences are just too
hard for you to comprehend..  (In which case, many other
Java features would be, too..)

How many other C# syntactic sugars would you like to see in
Java, then?

shankar.unni,

I see you commentted on WED APR 28 10:44 A.M. 
2004. At that time, i suppose Tiger already went beta.

Should I list every thing coming from C# but in Tiger 
here? 

They are not all syntactic sugars, but much more 
significant than just syntactic sugars if they are not.

This is much more important than just syntactic sugar. Currently it is impossible to copy a SQL statement from Query Analyzer directly into Java sources. Python has """ for multi-line literal strings. Similar thing is needed in Java as well. It is ridiculous to have to add +" into beginning and \n" into end of each SQL statement line, to keep the original formatting. And even this is not enough, tab characters need to be preserved as well. Java is much like Visual Basic in this regard.

I need to be able to copy a SQL statement directly from Query Analyzer into Java sources, keep all formatting, tabs and line feeds, so that the SQL statement is intact and readable when I see it in Profiler or log file.

And this new multi-line string literal should take backspaces as they are, not as escape sequences.

Christopher Barber wrote in newsgroup:
"in the Curl language, simple verbatime strings look like |"abc"|, but you can add an arbitrary tag as well:  |foo"abc"foo|, or you can specify the number of characters in the string, as in |3"abc"3|.  The latter form is useful for machine generated code."

This sounds very good to me. I suggest that Java add @"abc"@ verbatim strings with the extensions described above. This way there is no need to double " characters either.

When doing anything with SQL I'd choose C# over VB.Net because of this feature. I hope people wouldn't
choose C# over Java because of the lack of multiline string literals. 

It's a lot easier to copy and past that sql example into a sql editor and run it to check it's working. There are many applications where it is appropriate to use multiline string literals - they are not always bad, and as such the developers should be given a chance to use their own judgement.

The C# syntax is simply superior.   Since java is constantly changing, why not change it in this way too.  Its totally backward compatible, and its better.  C# has set a syntax, so simply copy it.

On the other hand, stay with a bad format, because that is obviously a good thing to do.  Who needs progress.

A workaround for the regular expressions, for instance, is to swap / and \
before compiling.  You almost certainly send it to another method to compile,
so might as well insert your own to do the switch.

As for the evaluation, I don

+1 vote against the idea that this is not worth it

where other languages have built-in domain-specific syntax for doing things, java often has libraries that take the concise representation of information as strings

if these strings necessarily include characters that are normally processed by the compiler then things get messy and this enhancement request would fix that

I vote for multiline string language enhancement. Sometimes it can lead to better readability of code. 

No matter whether it will be @"..." syntax or python style """...""". 

On my opinion syntax such a sugar   can sometimes lead to better readability of code.

It is a vital requirement. Reason - programmers write ugly SQLs and often one has to pan code. Situation gets more aggravated when in maintenance people write additional SQL elements in any  order and making the code even more ugly.

Verbatim literal would help in writing neat embedded SQLs and maintenance of SQL code would be easy. Majority of commercial Java uses JDBC heavily and Java Community would gain by this syntax enhancement.

Often stand alone SQL standards are not respected by Java programmers and this is a very unfortunate reality in the Java world.

I vote for VERBATIM LTERAL.

lets remove the new looping construct from java 1.5, you know, the one with the : in the middle.  Not needed, pure sugar in my opinion.

In fact, this whole notion of writing in text is pure crap, sugar if you ask me.  We all really know that all this verbose text (like for, while, import) is pure 100% crap sugar.

Opcodes baby.  Think about it.  More concise, more precise, less sugar.

-- Andrew

This goes well beyond SQL and regular expressions.
It affects traditional command line programs as well.

 String usage = q{Usage:  java whatever [options] [file]
      options:
          -a = whavever
          -b = whatever
};

Though I must say the C#  '@"' convention is pretty ugly; since quotation marks are pretty common in text.

How about something like Perl's   q{} so that you can choose the quoting character that interferes least with your text like q~whatever~;

        

What is so bad about syntactic sugar?

The bottom line is that it would improve readability and maintainability in any application, which saves time in the long run.

Imagine how nice it would be if you could write a regular expression without all of the back slashes.

Imagine how nice it would be if you could embed sql, xml, html, or what ever by simply cutting and pasting from another editor and not having to add a bunch of ‘+’ and ’/’ characters.  

What would be the bad side of implementing this?

Plz Save us from "// HELL"  when using Regax,
again C# owns it, and it work fine on C#, as it is workable, why not absorb the good features from C# ?

i hope to see python style """...""" multiline string in Mustang.
nowadays scripting is popular and this feature will be more important.

Could someone from Sun please comment with something more than "this is syntactic sugar."

Coding long SQL statements or chunk of XML or HTML in Java is clumsy, cumbersome, and error prone -- e.g., don't forget to include a space at the end or beginning of each line!  The need to surround lines with quotes and intervening +'s also makes the code less readable.

Several changes in 1.5 make Java friendlier and are welcome changes.  Support for multiline strings would be a nice addition to the list.

Could someone from Sun please comment with something more than "this is syntactic sugar."

Coding long SQL statements or chunk of XML or HTML in Java is clumsy, cumbersome, and error prone -- e.g., don't forget to include a space at the end or beginning of each line!  The need to surround lines with quotes and intervening +'s also makes the code less readable.

Several changes in 1.5 make Java friendlier and are welcome changes.  Support for multiline strings would be a nice addition to the list.

More opinions...

http://forums.java.net/jive/thread.jspa?threadID=2522&start=0&tstart=0

C# @" " is not a solution, because " is very common in SQL statements. @" "@ would solve this problem. Or Python """ """.

I disklike multi -line literalls

1) Because they mess up a programs indentation structure.

2) Because of the danger of an incorrect terminator swallowing any amount of code, potentially without resulting in an error message and, likely, with an error message on the wrong line.

I think there's a case for a special literal syntax for regualar expressions, in effect a regular expression literal with a Pattern value.

The usual / .. / syntax should work.

As to editting long String literals I think this is best done by an IDE editor tool designed for the purpose. Such an editor could tranfer literal values into a mutli-line text box and back, allowing cut and paste.

I can see 2 requests here.  
1) multiple line string support in java without + and "
2) to take plain text format input without using esacpe characters

I think (1) is definitely a must.  This is so limited that even C supports some sort of multiple line with printf( ).

For (2), to save users from typing might not be bad at all when you have a lot to type.   And more readable in java when you are working on the following,
- XML
- SQL
- multi line string
- regex
- any text with \ or "

I'll add my vote for adding this "syntactic sugar".  Arguments have already been given that summarize my position.

This is desperately needed. 
IDEs like Eclipse help write multiline literals using the current syntax. Why does this feature exist in the IDE? If such a feature exists and is used then that might indicate  something is wrong with the current syntax. We don't need IDE help to do a lot of things, why do we need it here? 

I agree that this would be a very useful enhancement, making the intent of regular expression statements FAR clearer.  I also think that a system that allows you to specify the quoting character would be helpful for verbatim text.

It seems very aloof for sun to thumb its nose at syntactic sugar.  Frankly, I find the brevity of C/C++ descendants syntactic sugar compared to BASIC descendants.  AND I LIKE THE SUGAR.  

This enhancement should be evaluated on its merits, rather than simply denigrating it with a label.  Would it provide advantages -- I think it has been made clear in previous posts, and by other modern languages that it would add something worthwhile.  Would it cause potential problems?  That question needs to be answered and weighed against the benefit.  Just calling it syntactic sugar scores no points in a real debate.

I think that this is a much needed addition
to javac. I have used python's string handling
- it is quite nice. """ denotes a multi-line string
r" denotes a raw string. r""" denotes a multiline
raw string. With the javac source code been
released under GPL licence, one can play with
the syntax and get multi-line parsing into javac
quite easily - see http://peter-reilly.blogspot.com/2006/11/multiline-strings-in-java-part-2.html

This request is important for both ease of development and readability.  Those against it are purist morons.

I think this is a must feature. I would like to use Groovy like scripting embedded into my Java classes and use them for OR mapping  tasks because they don't have a strict type system. Do other computations in Java. However, a small problem with the code is that it becomes so cluttered because of excessive ""'s and + 's.

Every try to generate dynamic javascript code in Java? It is hideous. Allowing multiline string literals would solve this problem and cleanup many common tasks. Of the following which would you rather debug?

"<script language=\"JavaScript\" type=\"text/javascript\">\n" +
		    "//<!--\n" +
		    "document.onkeypress = stopRKey;\n" +
		    "function stopRKey(event) {\n" +
			"var event = (event) ? event : ((event) ? event : null);\n" +
			"var node = (event.target) ? event.target : ((event.srcElement) ? event.srcElement : null);\n" +
			"if ((event.keyCode == 13) && (node.type==\"text\")) {\n" +
			"    return false;\n" +
			"}\n" +
			"}\n" +
			"//-->\n" +
			"</script>\n"

OR

return @"<script language=\"JavaScript\" type=\"text/javascript\">
		    //<!--
		    document.onkeypress = stopRKey;
		    function stopRKey(event) {
			var event = (event) ? event : ((event) ? event : null);
			var node = (event.target) ? event.target : ((event.srcElement) ? event.srcElement : null);
			if ((event.keyCode == 13) && (node.type==\"text\")) {
			    return false;
			}
			}
			//-->
			</script>";

Please add this "syntactic sugar", it makes sql code very unreadable.

You are very dismissive of "syntactic sugar" considering the whole text based language is "syntactic sugar". You would have to program in bytecodes to avoid the sugar.

The writing and maintainence of regexp, sql, scripting, and dynamic javascript would all benefit from this.   Anything that significantly improves the readability of code is worthwhile.  This would - not necessarily for all programs.  I would guess that the original evaluator of this RFE never had to maintain complex sql queries or generate dynamic javacsript literals of any significance.

Whats the status on this? It's a pain in the ass to maintain SQL code in java without this. Syntactic sugar is not a bad thing, hurry up already!!

how about status of this bug?

"Syntatic sugar" is a non-argument! Let's get real: virtually everything in a high-level language is syntatic sugar.

* Certainly, comments are *pure* sugar, only there to make the code easier to understand. 
* You only need one loop: `while` (or `goto`). 
* You could probably write at least half of the standard Java libraries yourself.
* Generics are arguably sugar (or maybe salt): they're optional and basically compiled away!
* Concatenation operators are sugar: it's just an alias for StringBuilder.
* Synchronized methods are sugar: you can get the monitor yourself.

Most of these exist to save typing and/or make your code clearer. We could have standard patterns for all of them, just as we do for multi-line strings. But, as it's been said, patterns are really just kludges for language weaknesses. A good language doesn't try to solve every problem, but the comments are evidence that this is a substantial and common issue. 

There can be no real argument that adding this syntax wouldn't make a lot of code easier to read, modify and write. There is also no real argument that this change is complicated or makes the language harder to learn or parse/compile. As far as I'm concerned, a "syntatic sugar" argument is a knee-jerk response from someone who doesn't have any real perspective on this issue. If you don't like multi-line strings, don't use them! I see a real benefit and no down side!

In sql programs this 'syntactic sugar' is very helpfull, I'll say more: it is desired.

Readability is most important from a maintenance point of view. It's not just more convenient but leads to more reliable software. So it is a pity that the evaluator dismisses it as syntactic sugar.

The most time I have problems with the escaped strings in Java is with unreadable regular expressions.

I hope this feature will be added. I'm not exactly sure how much influence the voting has but I added my vote to this RFE.

After spending some years in C# world and now coming back to Java this is one the biggest things I miss. 

It's all about readability. We're coding for humans to read not for machines. You need to be expressive with your code and minimize the effort it takes for the next person to understand the code.  

When you are dynamically generating some HTML and JS, trying to make sense of that HTML with '+' and quotes all over the place is virtually impossible. 

So to me this is not a nice thing to have, it is a necessity. 

Please put this feature asap. Thanks

Python has it, so don't be obsolette. 

Once again, I find myself wishing that the bug parade allowed you to cast votes against an RFE.

Please do not add this "feature".

"It's not worth it."  You have no idea how painful it is not to have this.

After developing in C# for a couple of years and coming back, it's painful to see that this is'nt supported in Java yet. Please support this, Java needs it.