String literals in Java

H

Harri Pesonen

I'm new to Java and find Java string literals a bit limited. In C/C++ it
is possible to concatenate string literals by doing "ab" "cde", and in
Python it is possible to have raw strings like r"C:\Windows" where \
does not need to be doubled (good for regular expressions as well).
Python also has multi-line strings like """
SELECT *
FROM COMPANY
WHERE NAME LIKE 'MIC%'
""" which is good for SQL, for example. All these are missing from Java.
Has this been discussed, and are any improvements coming in Java 1.5
(which has a lot of other good features that make programming a lot
easier like auto-boxing of primitive types)?

Harri
 
R

Ryan Stewart

Harri Pesonen said:
I'm new to Java and find Java string literals a bit limited. In C/C++ it
is possible to concatenate string literals by doing "ab" "cde", and in
"ab" + "cde"
Python it is possible to have raw strings like r"C:\Windows" where \
does not need to be doubled (good for regular expressions as well).
Then how do you get a " in a raw string? It could be useful, but I feel it
would be an unnecessary complication.
Python also has multi-line strings like """
SELECT *
FROM COMPANY
WHERE NAME LIKE 'MIC%'
""" which is good for SQL, for example. All these are missing from Java.
String sql = "SELECT * "
+ "FROM company "
+ "WHERE name LIKE 'MIC%'";
 
H

Harri Pesonen

Ryan said:
"ab" + "cde"

"ab" "cde" is better, because it would happen in compile time.
Then how do you get a " in a raw string? It could be useful, but I feel it
would be an unnecessary complication.

It was introduced in Python just for regular expressions I believe. It
is not fun to write s.replaceAll("\\\\", "\\\\\\\\") in Java either.

String sql = "SELECT * "
+ "FROM company "
+ "WHERE name LIKE 'MIC%'";

Yeah, but if you have written a big SQL statement in Query Analyzer, and
just want to copy it to Java sources, you have to add all these extra
concatenation operators and string terminators. Not fun. And, the
resulting string does not have line feeds (in your example). You have to
add \n in the end of each line to get the same string.

Harri
 
C

Carl Howells

Harri said:
"ab" "cde" is better, because it would happen in compile time.

First, unless you're doing it in a loop, it's just not very important.

Second, it does happen at compile time, as long as all the pieces being
concatenated are literals.
 
R

Ryan Stewart

Carl Howells said:
First, unless you're doing it in a loop, it's just not very important.

Second, it does happen at compile time, as long as all the pieces being
concatenated are literals.

Besides which, if they're just literals, wouldn't you rather write "abcde"
anyway?
 
T

Tony Morris

First, unless you're doing it in a loop, it's just not very important.
Second, it does happen at compile time, as long as all the pieces being
concatenated are literals.

Second, it does happen at compile time, as long as all the pieces being
concatenated are "compile-time constants".

final char c = 'h';
// c is compile-time constant, but not literal
String s = c + "ello";

--
Tony Morris
(BInfTech, Cert 3 I.T.)
Software Engineer
(2003 VTR1000F)
Sun Certified Programmer for the Java 2 Platform (1.4)
Sun Certified Developer for the Java 2 Platform
 
R

Ryan Stewart

Harri Pesonen said:
It was introduced in Python just for regular expressions I believe. It
is not fun to write s.replaceAll("\\\\", "\\\\\\\\") in Java either.
I'll agree with you there :)
Yeah, but if you have written a big SQL statement in Query Analyzer, and
just want to copy it to Java sources, you have to add all these extra
concatenation operators and string terminators. Not fun. And, the
resulting string does not have line feeds (in your example). You have to
add \n in the end of each line to get the same string.
Some IDE's will do the multiline concatenation stuff for you, and what would
you want with newlines in SQL?
 
R

Roedy Green

""" which is good for SQL, for example. All these are missing from Java.
Has this been discussed, and are any improvements coming in Java 1.5
(which has a lot of other good features that make programming a lot

You can create any literal you want in Java. See
http://mindprod.com/jgloss/literals.html


Concatenation needs explicit +. Two literals are combined at compile
time, so there is no speed penalty for the split.

The biggest pain are in regexes where literal \ must be encoded as
\\\\

Sun generally refuses to add sugar to the language -- short forms that
generate the same code as long hand. The relented slightly with the
new for loops. Perhaps other like short hand Listeners will come,
then maybe the sort of things you want. I would not hold by breath.

I think you will get them via scids rather than language evolution.

See http://mindprod.com/jgloss/scid.html
 
L

Liz

maybe there are some other languages like lisp and ada and such
that have features you like too........
maybe java is just too hard for you......
 
H

Harri Pesonen

Ryan said:
Some IDE's will do the multiline concatenation stuff for you, and what would
you want with newlines in SQL?

It is nice to have SQL formatted in readable form, in all phases: Query
Analyzer, Java source, Profiler, log file. """ is raw string as well, so
that \ does not need to be doubled, and it can contain tab characters as
well. It would be really great for database development. Of course, if
you have some data-aware control/component, you can write the SQL there.
But unfortunately you can't do it in Java.

You said that some IDEs will do the multiline concatenation? Which ones
and how? Not NetBeans? Still if IDE has some tool to make the
concatenation, then the SQL does not remain in readable form anymore,
but this would be better than nothing.

Harri
 
H

Harri Pesonen

Hehe, right, lisp...

Java is harder than Python in many ways. On the other hand, Java has
code completion and compile time type checking. And fortunately Java 1.5
has great improvements like primitive type auto-boxing and finally a
string "replace" function that works as expected.

Harri
 
R

Ryan Stewart

Harri Pesonen said:
It is nice to have SQL formatted in readable form, in all phases: Query
Analyzer, Java source, Profiler, log file. """ is raw string as well, so
that \ does not need to be doubled, and it can contain tab characters as
well. It would be really great for database development. Of course, if
you have some data-aware control/component, you can write the SQL there.
But unfortunately you can't do it in Java.
True, but at least all it takes is a simple System.out.println or log.debug
to see if your SQL is correct.
You said that some IDEs will do the multiline concatenation? Which ones
and how? Not NetBeans? Still if IDE has some tool to make the
concatenation, then the SQL does not remain in readable form anymore,
but this would be better than nothing.
I've been mainly using NetBeans for several months, and am not aware of the
option for that. I think IntelliJ does, but it's not free. In JDeveloper, if
there's not an option for it, you can create a code template for it.
 
H

Harri Pesonen

Ryan said:
True, but at least all it takes is a simple System.out.println or log.debug
to see if your SQL is correct.

I have to correct myself. In Python, """ can have escape sequences like
any normal string. Only r" has limited escape sequences:

"When an "r" or "R" prefix is present, a character following a backslash
is included in the string without change, and all backslashes are left
in the string. For example, the string literal r"\n" consists of two
characters: a backslash and a lowercase "n". String quotes can be
escaped with a backslash, but the backslash remains in the string; for
example, r"\"" is a valid string literal consisting of two characters: a
backslash and a double quote; r"\" is not a valid string literal (even a
raw string cannot end in an odd number of backslashes). Specifically, a
raw string cannot end in a single backslash (since the backslash would
escape the following quote character). Note also that a single backslash
followed by a newline is interpreted as those two characters as part of
the string, not as a line continuation."

So r" string can have " in it. Also:

"When an "r" or "R" prefix is used in conjunction with a "u" or "U"
prefix, then the \uXXXX escape sequence is processed while all other
backslashes are left in the string. For example, the string literal
ur"\u0062\n" consists of three Unicode characters: `LATIN SMALL LETTER
B', `REVERSE SOLIDUS', and `LATIN SMALL LETTER N'. Backslashes can be
escaped with a preceding backslash; however, both remain in the string.
As a result, \uXXXX escape sequences are only recognized when there are
an odd number of backslashes. "

"In triple-quoted strings, unescaped newlines and quotes are allowed
(and are retained), except that three unescaped quotes in a row
terminate the string. (A ``quote'' is the character used to open the
string, i.e. either ' or ".)"

All this is a bit confusing compared to how C# handles this:

"A verbatim string literal consists of an @ character followed by a
double-quote character, zero or more characters, and a closing
double-quote character. A simple example is @"hello". In a verbatim
string literal, the characters between the delimiters are interpreted
verbatim, the only exception being a quote-escape-sequence. In
particular, simple escape sequences and hexadecimal and Unicode escape
sequences are not processed in verbatim string literals. A verbatim
string literal may span multiple lines."

This sounds good, except that " has to be doubled. The ideal Java
verbatim string would be something like:

String s = @"can have anything here,
including line feeds, file paths like:
C:\Windows
even tabulators. How to embed " then? Simple, the terminating " must
have @ after it."@;

This way the only string sequence that is now allowed is the closing "@.

Perhaps there could be better terminators, like {"How about this then?"}
or <"And this?">. There are also a couple of characters that are not
normally used: ´Would this be cool?´ `Probably not.`

Harri
 
R

Roedy Green

Perhaps there could be better terminators, like {"How about this then?"}
or <"And this?">. There are also a couple of characters that are not
normally used: ´Would this be cool?´ `Probably not.`

The generic solution would be to allow you to choose the terminator:
e.g.
@$abc$

That still does not deal with the problem of embedded escapes.

I'm running into this problem with macros. I don't want to fool with
quoting accidentally embedded terminators, so I have allowed a variety
of enclosers.
 
H

Harri Pesonen

Chris said:
The problem with Sun's RFE system is that there doesn't seem to be a way to
vote /against/ things.

Why would anyone want that Java is not improved? Java 1.5 focuses on
"Ease of Development". It does it by taking many things from C#:

* auto-boxing of primitives
* metadata (attributes)
* enumerated types
* Enhanced for Loop (foreach)
* formatted output (String.Format)
* Varargs (parameter arrays)

Verbatim string literals is one thing that is still missing.

Harri
 
C

Chris Smith

Harri said:
Why would anyone want that Java is not improved?

Circular answer. The word "improved" implies that the change is for the
better. Obviously, Chris doesn't think so. Not thinking so is a
reasonable opinion. Unbounded increases in the complexity of a language
definition will kill the language. Every change has to be weighed
against the increase in language complexity. This change doesn't add
too awfully much complexity, but it doesn't provide much benefit either.
Java 1.5 focuses on
"Ease of Development". It does it by taking many things from C#:

And hence everything from C# is good by default? Go write code in C#,
then.

--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation
 
H

Harri Pesonen

Chris said:
Circular answer. The word "improved" implies that the change is for the
better. Obviously, Chris doesn't think so. Not thinking so is a
reasonable opinion. Unbounded increases in the complexity of a language
definition will kill the language. Every change has to be weighed
against the increase in language complexity. This change doesn't add
too awfully much complexity, but it doesn't provide much benefit either.

Ask anybody that does SQL development. Also adding verbatim string to
java compiler would be trivial.
And hence everything from C# is good by default? Go write code in C#,
then.

C# is technically better than Java, because it is a next generation
product. Now Java tries to catch up. If C# and .NET were available on
every major platform (Win, Linux, Mac) for free, and if there were free
development systems (like NetBeans), I would be using C#. As it is, Java
is better for multiplatform development, and it is free, so there is no
choice (unfortunately).

Harri
 
J

Jim Cochrane

C# is technically better than Java, because

When I read this I thought: "Oh, good - I don't know much about C#, maybe
I'll learn something about why it may be better than Java." But then I
read this: "it is a next generation product." and thought: "How
disappointing - He does not really give a reason, but just uses an
essentially meaningless phrase. He doesn't even give any kind of
definition for 'next generation product', which might have at least given
some sense of why C# is technically better than Java."

I guess I didn't learn anything after all. :)
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,900
Latest member
Nell636132

Latest Threads

Top