String literals in Java

[Harri Pesonen]

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

Simple. Just like Java builds on C++ and Visual Basic, C# and VB.NET
build on Java. Java took the best features from C++ and Visual Basic:

* C++: classes and general syntax
* VB: ease of development, virtual machine, no freeing of objects, COM,
UI components

Java added garbage collection, JIT compiling and a reasonably good
library (Java Platform API). Since then many of the original library
features have been deprecated and replaced with new versions, and whole
new APIs have been added to fix the problems in the original ones:

AWT => Swing
IO => NIO
Date => Calendar

C# and .NET platform have been designed to have the best features from
Java, without the burden of deprecated API or language features. Java
1.5 proves that C# is/was ahead of Java in many ways. .NET platform
performs better than Java in Windows, because it uses native Win32 UI
features, while Swing suffers from bugs and incompabilities and is slower.

C# has "using" statement that makes sure that the resource is freed
(disposed) correctly.

In C# "switch" statement works with strings.

C# has structs for creating new primitive types.

Did I mention that C# has verbatim strings, which are good for regular
expressions and multi-line SQL statements...

I could go on, but C# is simply superior to Java (in Win32). I hope that
Java gets better, Java 1.5 sounds very promising.

Harri

 

[Roedy Green]

Why would anyone want that Java is not improved?

It is not a matter of whether people want it improved, it is a matter
of whether they consider you proposal an improvement, or worth the
hassle of learning yet another syntax wrinkle. There is value to
simplicity. Most of my ideas for improvements are documented in
http://mindprod.com/jgloss/bali.html

So far the only ones Sun have implemented are enum and extended for
over collections (using somewhat different syntax that I suggested.)

C# however, has implemented a number of them.

 

[Roedy Green]

Ask anybody that does SQL development. Also adding verbatim string to
java compiler would be trivial.

These should perhaps be added to IDEs and SCIDs and leave the base
language alone.


see http://mindprod.com/projects/scid.html

 

[Chris Smith]

C# and .NET platform have been designed to have the best features from
Java, without the burden of deprecated API or language features. Java
1.5 proves that C# is/was ahead of Java in many ways.

Yes, you're right that C# is/was ahead of Java in many ways. It was
just the ludicrous extension of that as a way to prove that *everything*
in C# is better than Java that was ridiculous. We all understand by now
that you like these "literal" strings from C#. (At least, those of us
who aren't completely oblivious do...). I, on the other hand, consider
them an incomplete attempt to complicate the language so as to avoid a
relatively painless problem. And yes, I do JDBC programming with SQL
strings all the time.

I could go on, but C# is simply superior to Java (in Win32). I hope that
Java gets better, Java 1.5 sounds very promising.

It's really not that simple. Specifically, C# suffers from the
disadvantage that it's really a rather complex language with a lot more
gotchas to look out for than Java; a lot more situations where it's
rather non-obvious what's going on. It represents a language that's a
lot heavier on the syntactic sugar than Java is. Essentially, it comes
from a considerably different language design philosophy.

Hopefully, Java 1.5 takes those genuinely good ideas from C# that are
really compatible with its language design, but still remains its own
language with its own advantages. It looks like that balance is largely
happening (although I'd be pushing for leaving out a few more things
like the new for loop syntax and static imports). Obviously, some
people in charge have more of a vision for what Java should be than
simply trying to make it as much like C# as possible.

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

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Tony Morris]

Java is harder than Python in many ways. On the other hand, Java has

code completion and compile time type checking.

Umm ... what ? Java does not have "code completion".
A very strange statement to make, I might add.

string "replace" function that works as expected.

It has done since 1.2.

Stick to Python

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

 

[Chris Smith]

It has done since 1.2.

Mmm? As far as I can tell, this is not wrong. Java has had
String.replace(char, char) since the beginning (well before 1.2), but
String.replace(String, String) is new in 1.5.

1.4 added replaceAll(String, String) and replaceFirst(String, String),
but they indeed don't work as expected given the use of regular
expressions... and that makes them suitable for only a small subset of
the cases where 1.5's replace(String, String) is useful [namely, where
the pattern and replacement text are both known at compile time].

I'm interested where you got 1.2 from.

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

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Chris Uppal]

Why would anyone want that Java is not improved?

I /certainly/ want Java to be improved. But this proposal isn't an improvement
in my book.

Java 1.5 focuses on
"Ease of Development". It does it by taking many things from C#:

A poor place to look, in my not particularly knowledgeably opinion.

There are lots of things that I'd like to see changed; messing around with
syntax to make an easy tasks imperceptibly easier is not on the list.


Just to put my money where my mouth is (iyswim), here are a few of the things
/I'd/ like to see (but don't expect that I ever shall).

* Rules for interfaces relaxed so that a method can satisfy an interface if it
is at least as visible as the interface rather than being required to be
public.

* The built-in type char expanded to 32 bits (not quite as radical a change as
it sounds, since chars are mostly handled internally as 32-bit anyway).

* String refactored to allow physical storage of character-sequence data in
UTF-8, UCS-2, UTF-16, or UTF-32 (and, perhaps, other formats too).

* NoSuchMethodException to be specified to record the values of the parameters
to the method call. (And similarly for assigns to non-existent fields.)

* Find some way of removing the clutter of from mis-designed API left over from
Java's early days.

* Deprecate wait(), and notify[All]() (and, perhaps, even "synchronized") and
replace them with something that doesn't require the brains of a Turing or a
Von Newman to get right. The new APIs in 1.5 are a step in the right
direction here.

* Retrofit arrays with a common superclass(es) other than Object, and make them
act as proper Collections. Allowing array syntax for "real" Collections is
probably a worthwhile bit of sugar.

* Deprecate /anonymous/ inner classes, which I think experience has shown to be
badly obfuscating.

* ...but add proper closures.

* Since they've insisted on cluttering-up the language with so many frivolous
constructs that it's not reasonable to expect ordinary skilled programmers to
be able to do any real meta-programming, there should be support for it at the
language definition level.

* Using fixed-width arithmetic with silent wrap-around /by default/ is an
engineering disaster. Such low-level arithmetic should be /available/ as an
optimisation to advanced programmers who can deal with the implications, but
there's no way it should ever have been the default.

* I'd like to remove generics before they even appear, and instead focus on
trying to /reduce/ the amount of early, static, analysis that the Java compiler
imposes on the JVM semantics.

* I'd /really/ like to get rid of the non-OO mess we currently have with
"constructors" and "static methods", but that's too much even to dream of, I
suppose... If we can't have that then at least allow constructors to inherit.

*** stuff for the JVM rather than Java-the-language ***

* The JVM developers to stop thinking of modifying a class definitions as a
mere
debugging aid, and make it work properly, at full speed, and be non-optional.

* The JVM developers to implement their /own/ spec for re-starting JVM
instances within one process (and ideally allow more than one).

* Add a way to discover all instances of a class at runtime. Should be
reasonably fast too. (NB: /not/ a debugging feature)

* Similarly, add a way to discover all effervescences to an object at runtime.

In short: concentrate on making stuff /simpler/ and more /general/, not on
trying to out-Perl Perl.

-- chris

 

[Harri Pesonen]

Umm ... what ? Java does not have "code completion".
A very strange statement to make, I might add.

It is impossible to have a decent code completion in Python, because the
language is so dynamic. Java is so strictly type defined that code
completion is always possible.

Harri

 

[Harri Pesonen]

There are lots of things that I'd like to see changed; messing around with
syntax to make an easy tasks imperceptibly easier is not on the list.


Just to put my money where my mouth is (iyswim), here are a few of the things
/I'd/ like to see (but don't expect that I ever shall).

* Rules for interfaces relaxed so that a method can satisfy an interface if it
is at least as visible as the interface rather than being required to be
public.

* The built-in type char expanded to 32 bits (not quite as radical a change as
it sounds, since chars are mostly handled internally as 32-bit anyway).

* String refactored to allow physical storage of character-sequence data in
UTF-8, UCS-2, UTF-16, or UTF-32 (and, perhaps, other formats too).

* NoSuchMethodException to be specified to record the values of the parameters
to the method call. (And similarly for assigns to non-existent fields.)

* Find some way of removing the clutter of from mis-designed API left over from
Java's early days.

This would be good for beginner Java programmers like me. NetBeans tells
that the method is deprecated in code completion if I recall correctly.

* Deprecate wait(), and notify[All]() (and, perhaps, even "synchronized") and
replace them with something that doesn't require the brains of a Turing or a
Von Newman to get right. The new APIs in 1.5 are a step in the right
direction here.

* Retrofit arrays with a common superclass(es) other than Object, and make them
act as proper Collections. Allowing array syntax for "real" Collections is
probably a worthwhile bit of sugar.

* Deprecate /anonymous/ inner classes, which I think experience has shown to be
badly obfuscating.

* ...but add proper closures.

* Since they've insisted on cluttering-up the language with so many frivolous
constructs that it's not reasonable to expect ordinary skilled programmers to
be able to do any real meta-programming, there should be support for it at the
language definition level.

* Using fixed-width arithmetic with silent wrap-around /by default/ is an
engineering disaster. Such low-level arithmetic should be /available/ as an
optimisation to advanced programmers who can deal with the implications, but
there's no way it should ever have been the default.

* I'd like to remove generics before they even appear, and instead focus on
trying to /reduce/ the amount of early, static, analysis that the Java compiler
imposes on the JVM semantics.

* I'd /really/ like to get rid of the non-OO mess we currently have with
"constructors" and "static methods", but that's too much even to dream of, I
suppose... If we can't have that then at least allow constructors to inherit.

*** stuff for the JVM rather than Java-the-language ***

* The JVM developers to stop thinking of modifying a class definitions as a
mere
debugging aid, and make it work properly, at full speed, and be non-optional.

* The JVM developers to implement their /own/ spec for re-starting JVM
instances within one process (and ideally allow more than one).

* Add a way to discover all instances of a class at runtime. Should be
reasonably fast too. (NB: /not/ a debugging feature)

* Similarly, add a way to discover all effervescences to an object at runtime.

In short: concentrate on making stuff /simpler/ and more /general/, not on
trying to out-Perl Perl.

Hehe, I have such a simple wish compared to yours... and as I said, I am
pretty happy with the improvements in Java 1.5.

Harri

 

[Christopher Barber]

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

Yes, for example, 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.

 

[Harri Pesonen]

Yes, for example, 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.

Okay, so this has been decided then. Someone post this to Sun now.

But, it should be @"abc"@ in Java I guess, because C# has @"abc" and
they did not pick @ by accident.

Harri

 

[Mohun Biswas]

Just to put my money where my mouth is (iyswim), here are a few of the things
/I'd/ like to see (but don't expect that I ever shall).

Somewhere on the net there's an article called something like "Ten (?)
Reasons Why We Need Java 3" which overlaps to some degree with your
wishlist. The basic point of it is that, as Harri says, Java is still
encumbered by a few mistaken design decisions made early on and that ten
years later it's time to correct them in a modern new language. Worth
reading though controversial (and of course it triggered significant
flameage then which need not be repeated now).

 

[Timo Kinnunen]

I don't think that C# has generic types.

C# also has preprocessor directives #if #endif and so on. It would be
great to be able to do #if DEBUG in Java as well.

I do that quite successfully in Java today. I have the following:

public static final boolean DEBUG = true;
public static void debug(String s) { if(DEBUG) System.out.println(s); }

and in every class I want to debug I have:

private static final boolean debug = MainClass.DEBUG && true;
private static void debug(String s) {
if(debug) MainClass.debug("id: " + s);
}

and I call them like this:

if(debug) debug("some debugging here");

The end result is that I can enable/disable my debug outputs on a per class
basis or altogether. When I want to create a release version, I set the
flag to false, Sun's javac strips away the actual method calls and the
obfuscator (ProGuard) removes those now unused debug methods. All this with
Java's type safety.

C# also has unsigned integer types. One thing I don't understand: Why
both C# and Java have signed integer (32 bit) as array index and array
length, while the index or length can't ever be negative? It is just a
waste of one bit in C#.

Things are quite a bit simpler when the difference of two array indices can
be negative.

 

[Harri Pesonen]

Harri,
I do a lot of SQL development with java, and i don't see why you need to do
what you are doing.

How do you copy multi-line SQL statement into Java sources then?

also as it stands you are going to get yourself into a lot of problems, doing
what you are doing , the way you are doing it.

What do you mean?

Harri

 

[Harri Pesonen]

That is a retrograde step. Java has a better way of achieving this.

Okay, how? I'm new to Java you see.

Harri

 

[Harri Pesonen]

you can do

if ( Config.DEBUG )
{
...
}

The debug code will not be included in the class file if you set


public static final boolean DEBUG = false;

But this DEBUG = false is in the Java sources, right? I don't want to
change sources for debug/release build.

Harri

 

[Harri Pesonen]

I do that quite successfully in Java today. I have the following:

public static final boolean DEBUG = true;
public static void debug(String s) { if(DEBUG) System.out.println(s); }

That's exactly how I did it as well, but I was hoping for a better way.
Changing the source code is not as clean as it could be, because the
file modification date and file changes all the time.

Harri

 

[Ryan Stewart]

System.out.println(s); }

That's exactly how I did it as well, but I was hoping for a better way.
Changing the source code is not as clean as it could be, because the
file modification date and file changes all the time.

So put it in a different file:

public class Debug {
public static final boolean DEBUG = true;
public static final boolean LOG = true;
// Whatever else you want to be able to turn on and off.
}

That's essentially how it's done in C, right?

 

[Chris Smith]

That's exactly how I did it as well, but I was hoping for a better way.
Changing the source code is not as clean as it could be, because the
file modification date and file changes all the time.

You're welcome to write files to both enable and disable debugging,
having both declare the same class name, and then include only one of
them in the build depending on what you want.

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

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Mark Thornton]

But this DEBUG = false is in the Java sources, right? I don't want to
change sources for debug/release build.

Harri

The value of Config.DEBUG can also be computed at runtime. This means
that the byte code is still present, but the JIT will remove the
unreachable code when it is compiled to native. As result your debug
code has negligible runtime cost (the time spent by the JIT eliminating
it), but you can easily turn it back on whenever you like --- even in
delivered code.

Mark Thornton