Btw, Java bytecodes and Java VM are both misnomers. There are no Java VM but just VM produced by Sun, IBM, MSFT, Mono or whatever vendor, plus multiple compilers targeting particular VMs. Naming everything (language and VM) “Java” was just a marketing ploy by Sun.

In .NET universe, there are virtual machines (produced by MSFT or Mono), there are core libraries, and there are multiple (20+ last time I checked) compilers produced by various vendors. Everything from Assembly to Perl.

Myclass output = obj. methcall(arg1,
arg2,
arg3);

That is, args alligned vertically.

SomeLongClassName output = someLongObjectName.methodCall(argument1,
argument2,
argument3);

Backslashing multi-line statements? Insanely less readable.

Require braces for multiline statements — Braces create compound statements by grouping the contained staements. You want to require them in cases where there is only one contained statement? Trivially helpful as a coding style but the existing definition of a “statement” is consistent. Emacs auto-indent catches any such coding errors easily.

switch-case statements — I disagree. A trivial change, but it would undermine a lot of existing, well-thought-out code.

switch types — I’m neutral on this one. (But how about allowing non-booleans as if-arguments? What’s wrong with C-style rules?)

Ban tabs — I agree. Emacs auto-tabs for the java-mode, but allows untabification for saved code.

Multiline string literals — Does this dovetail with your multiline issue? I think the current way (literal “\n”) is clearer. Perhaps it would help to introduce some new kind of bracketing for your multi-line Strings. BTW you seem to be missing some backslashes and a closing parenthesis in your examples.

1. Multi-line string literals. What is the problem with implementing “if you find an unescaped-double-quote-character then everything up to the next unescaped-double-quote-character is one String literal”? Graphical IDEs will color the text appropriately so that you can see what is in your string literal.

2. Allowing any Object to work as a switch case. There could be two variants:
a) the current int-based version for ints and enums, and
b) a generified Object-based version using equals for Objects.

3. Making “final” the default extensibility option. I pair this with making “private” the default visibilty. In other words, you cannot see it or alter it unless I explicitly allow it. This is at odds with Gili (”turn-around time between my request and his next release usually ranges into months”) but the other developer has to maintain the integrity of their code for all users and “just say no” is the most conservative default.

try {
blah
}
catch(ThisException, ThatException, MyException, YourException as Exception){
blah;
}
catch(Exception e) {
}

The VM:
Since the JVM is now a multi-language thing, lets call it VM. In general it has gotten up to a good speed by now, but it is still a memmory hawk beyond anything else in the industry. SUN must have half a dusin marketing departments, consistancy please, now you adopted JSE 6.0 do not refer to it as java.version 1.6.0 - and no, you can not call it Java 2.

The Syntax:
As proposed by this blog entry, there are so many nifty things that could be done by thinking a little rather than copying the construct from C++. A lot less verbosity thanks, and more dynamic/flexible such that we can program into the language (idioms), not just on the language (patterns).

The API:
By far the worst. Date is broken, Calandar which was suppose to fix this is also broken and so are 100+ more general purpose classes. There’s really too much wrong here that I get a headache from thinking about it.
[/RANT ON]

1)I love it!!! - especially the multi-line strings. This is by far my biggest pet peeve w/ the Java syntax. Creating long string literals in java feels like I’m trudging through mud.

2)I’m all for UTF-8, But let’s actually *use* unicode. Take multi-line strings for example. Why not delimit them w/ the  ¶Pilcrow Sign (aka “paragraph” symbol). That would be more succinct and also save programmers from escaping double quotes all the time.

That’s just the tip of the iceberg. How about using the actual math glyphs instead of the operator literals we use now? Or using the box-printing characters for formatting comments? There’s tons of opportunities to improve readability by using symbols that are more descriptive and tie to real-world concepts.