Skip to main content

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

86 replies [Last post]
mijzcx
Offline
Joined: 2004-09-11
Points: 0

Hello Java Community,

As a Java Developer, my concern to Java Language future is this.

I would like to ask your vote and opinion on this?

Target: java language.

Traditionally we wrote:

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()

My Proposal:

public static void main( String[] args )
{
string
{
The quick brown
Fox jumps over
The lazy dog.
} vstat1, vstat2;

System.out.println( vstat1 + " " + vstat2 );

} // main()

Projected benefit:
1. Easy to cut and paste especially for sql statements
run-checks.
2. Easy to read.
3. Less typing, no quotes and plus sign.
4. Look! Is it it easy, what do you think?

Yes, i am aware of phython multiline string.
http://docs.python.org/tut/node5.html#SECTION005120000000000000000

As To My Proposal: (Fig1)

public static void main( String[] args )
{
string
{
The quick brown
Fox jumps over
The lazy dog.
} vstat1, vstat2;

System.out.println( vstat1 + " " + vstat2 );

} // main()

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.

In My Humble Opinion,

-Melvin

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
jwenting
Offline
Joined: 2003-12-02
Points: 0

> 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.

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

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...

great idea means it's worth following it, investigating impacts, evaluating possibilities....

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)

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

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)

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

> 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 ".

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

Hi,

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.

Regards,
-Melvin

kcpeppe
Offline
Joined: 2003-06-15
Points: 0

> we could write
> [code]
> String sql = "
> select a,b,c
> from mytable
> where id=1
> ";
> [/code]

>
> the only thing we need is fix the parser so that it
> allows multiline literals.

SQL statement is represented as a String but... it is *not* a String. Maybe it makes sense to add a literial form for SQLStatement. Something along the lines of an XML literial form.

- Kirk

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

> just a quick idea:
> do you all gyus realize that this can be much
> simpler?
>
> instead of
>
> [code]String sql
> = "select a, b, c "
> + "from mytable "
> + "where id=1";
> [/code]
> we could write
> [code]
> String sql = "
> select a,b,c
> from mytable
> where id=1
> ";
> [/code]
> there is no need for any fancy syntax like string
> {...} or @" ... "@
>
> the only thing we need is fix the parser so that it
> allows multiline literals.

Yes, BUT, " requires that all \ characters be doubled. @" would parse all characters as they are. That is a big difference.

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

> 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.)

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

> > 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:

@1"this is a complex string containing "@ and anything"1@

tackline
Offline
Joined: 2003-06-19
Points: 0

> 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 <%. Perhaps interpolation could added using a <%= ... %> syntax.

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

> > 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 <%. Perhaps
> interpolation could added using a <%= ... %> syntax.

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

sse
Offline
Joined: 2006-01-16
Points: 0

+1 for this.

delimiters.

no in-between "no-decision". we need it.

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

While I was wondering if someone already file a similar case, I found out this one:

Add support for verbatim string literals. Dated JUN-21-2001.
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4472509

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.

Please support this "syntactic sugar".

tackline
Offline
Joined: 2003-06-19
Points: 0

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).

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

I have yet another solution to this problem. We could have embedded resources in Java files, like the following:

[pre]
@Resource("SQL_FETCH_CUSTOMER_BY_ID", String)
SELECT *
FROM Customer
WHERE Id = ?
-END:SQL_FETCH_CUSTOMER_BY_ID

public class App {
public static void main(String[] args) {
System.out.println(@Resource("SQL_FETCH_CUSTOMER_BY_ID"));
}
}
[/pre]

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.

kcpeppe
Offline
Joined: 2003-06-15
Points: 0

> > > 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!

Cheers,
Kirk

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

> > 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.

firefight
Offline
Joined: 2006-05-05
Points: 0

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.

[code]
return String.format(statement, "Enlightend");
[/code]

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

> 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.

firefight
Offline
Joined: 2006-05-05
Points: 0

> > 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.

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

>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.

leouser
Offline
Joined: 2005-12-12
Points: 0

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

leouser

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

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.

fak
Offline
Joined: 2004-11-18
Points: 0

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.

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

> 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?

There already is such an IDE available: IntelliJ IDEA.

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

> > 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?

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

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.

mernst
Offline
Joined: 2005-02-19
Points: 0

> Perhaps some of this features already exist, and I don't
know :)

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)

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

This sounds better than my last proposal, except that I would like to have several strings in one resource file:

@Resource("/com/company/package/sql.xlm", "FETCH_CUSTOMER_BY ID")
final String fetchCustomerById;

@Resource("/com/company/package/sql.xlm", "FETCH_CUSTOMER_BY_NAME")
final String fetchCustomerByName;

Or something.

dound
Offline
Joined: 2006-06-06
Points: 0

>> 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)

Well, you could create your own class with this clean syntax to do this.

Overall though, I think the proposed change is a good idea, though I prefer the C# @"sdsad" delineation to the braces {}.

sse
Offline
Joined: 2006-01-16
Points: 0

+111

Multi-line broken SQL language, make them far much less readable, and not seing them as the would be typed, make us less capable of identifying errors in SQL syntax or in the statement.

And i just talk about the first time you code it. When it comes to maintain it, it is the same nightmare.

This is very odd for us, the way SQL statements have to be maintained.

And SQL is sometimes where most tricky and time consuming errors/problems happen.

Finally the ability to type them as they would be in "SQL Editor Tool" will make
- copy and paste from SQL Tool easy
- copy and paste from Java code to SQL tool, for testing purpose, much easier

This ought to be, current situation is odd. really.

And this is not theoretical, this is every day nightmare that must be resolved.

Regards

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

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

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.

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

> 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.

Or if you use /* and */ it can happen as well.

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

>
> 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 <[CDATA[ ]]> 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.

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

> > > 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.

Yes.

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

>
> 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).

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

> 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.

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

> > 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#.

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

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).

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

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.

disciple285
Offline
Joined: 2005-07-15
Points: 0

I think a way of entering non-excaped strings would be a great boon.

And also some added String class enhancements so that one does not need to import apache.commons.stringutils!

firefight
Offline
Joined: 2006-05-05
Points: 0

I think this it's now clear that long strings are never going to be added to the parser. For one, no-one can agree on syntax. Sadly, it reminds of those debates about where to put the {.

Our best bet as a community for getting results would be to add IDE support for them. Something like an inner window that that converts what is displayed to the usual "" + "" + "" convention.

As much as I'd like to see it, it also doesn't pass the "Great-not-good" requirement for language additions.

disciple285
Offline
Joined: 2005-07-15
Points: 0

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.

plethora
Offline
Joined: 2005-06-30
Points: 0

Funny to read this thread now.

I submitted the referenced Bugparade RFE, +/- 5 years ago. It got refused real quick :-) Those were the days that anything remotely C#/MS-inspired was 'not done (you may remember the lawsuits).

Today, IntelliJ take most of the pain await of course.

I still remember Gosling preaching that C# delegates were the devil, now we have a nice mess with runtime-generated CGLIB classes to get the same effect.

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

just a quick idea:
do you all gyus realize that this can be much simpler?

instead of

[code]String sql
= "select a, b, c "
+ "from mytable "
+ "where id=1";
[/code]
we could write
[code]
String sql = "
select a,b,c
from mytable
where id=1
";
[/code]
there is no need for any fancy syntax like string {...} or @" ... "@

the only thing we need is fix the parser so that it allows multiline literals.

ilazarte
Offline
Joined: 2005-11-28
Points: 0

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.

hlovatt
Offline
Joined: 2003-11-18
Points: 0

I think there is a Sun proposal to add XML literals to Java. As I recall the syntax is something like:
[pre]
String s = @Book {
@Author { Fred Bloggs }
@Title { Foo Bar }
}
[/pre]
This XML syntax would probably cover most uses of multi-line literals via a translation from XML into what ever format. The chosen Sun format is structured with {} and therefore compatibility with normal Java source code is better.

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

> I think there is a Sun proposal to add XML literals
> to Java. As I recall the syntax is something like:
> [pre]
> String s = @Book {
> @Author { Fred Bloggs }
> @Title { Foo Bar }
> }
> [/pre]
> This XML syntax would probably cover most uses of
> multi-line literals via a translation from XML into
> what ever format. The chosen Sun format is structured
> with {} and therefore compatibility with normal Java
> source code is better.

But how do add CDATA section into this XML? I think that this would be good for XML perhaps but not for general multi-line string case (SQL, JavaScript, etc).

hlovatt
Offline
Joined: 2003-11-18
Points: 0

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.

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

I agree with fuerte but instead of @" "@ i suggest

$"
The quick
Brown Fox
Jumps over
The Lazy Dog.
"$;

Because @ already used in annotation. While the $ not yet.