[concurrency-interest] Why not J2SE 5?

Osvaldo Pinali Doederlein osvaldo@visionnaire.com.br
Tue, 07 Dec 2004 10:02:01 -0300


David Holmes wrote:
> Osvaldo writes:
>>Then why two switches, sourge & target?  A single switch would do it.
> Historically the target and source values have not been tied - in
> fact -source came much later than -target. With the later releases you are
> forced to keep them upwardly compatible:
>   -source 1.4 requires -target 1.4+
>   -source 1.5 requires -target 1.5+
> but source 1.3 does not require -target 1.3+

I haven't noticed this recent change... perhaps because I've been using
only Eclipse since 1.0, and its compiler is much more flexible on this:
I can easily setup a project for J2SE1.4 compliance, but with source
compatibility at 1.3 and classfile compatibility to 1.1, and independent
of this, chose whether identifiers named 'assert' (and now, 'enum') are
flagged as errors, warnings or ignored... not to mention other details,
like inlining finally blocks to avoid JSR (mandatory only in J2SE 5.0).
Only under J2SE5.0 compliance, I see that not even Eclipse allows me to
output 1.4-compatible classfiles; but I hope this may change (people
behind projects like RetroWeaver could certainly "fix" this...).

> I work on a system which requires -target 1.1 hence we can't use new source
> features from 1.4 or 1.5.

Try Eclipse's compiler.  Even if you prefer another IDE, you can just
use its compiler.  There's no stand-alone distribution (yet), but it's
easy to extract it from the SDK; for example, the latest Tomcat (5.5.x)
bundles Eclipse's compiler (a 900Kb common/lib/jasper-compiler-jdt.jar).
Check also ftp://sources.redhat.com/pub/rhug/ecj, that's the stand-alone
Eclipse compiler that was compiled to native code (Linux/x86) with gcj,
but unfortunately this is not updated since July 2003.  So you probably
want to follow these instructions:

http://dev.eclipse.org/viewcvs/index.cgi/~checkout~/jdt-core-home/howto/batch%20compile/batchCompile.html

Except for Eclipse-specific options like its multitude of line-style
warnings, the switches are similar to javac, so it should be easy to
update your ant buildfiles or similar.

Another option: http://www-124.ibm.com/developerworks/opensource/jikes/
This compiler is also more flexible than javac, in -source/-target.
It happily accepts -source 1.4 -target 1.3, for example.

> Other people who haven't migrated to asserts yet might use source 1.3 but
> allow the default target 1.5

That was a huge problem for me a few years ago, when I really wanted to
use asserts in a critical software component that must be compatible
down to J2SE1.2 at that time (and 1.3 still today).  I had to resort to
a complicated Ant script that would create a copy of the source code,
filtering out all lines of code containing assert statements, and then
compile that code with lesser -source/-target options.  Only recently I
discovered that jikes offers a wonderful switch ("--assert" or "+a")
that makes the compiler discard completely the assert statements, so
I can compile that unmodifiable source to older J2SE's.  WAY cool...
Essential feature if you ask me.  I only wish Eclipse could do the same.

It's clear that there's a huge demand from developers for a smoother
compatibility path between versions of the J2SE.  Eclipse and Jikes are
the only alternative compilers that I have investigated, and both of
them are nicer than javac in this respect -- I wonder if others, like
gcj, have similar compatibility features.

Gregg Wonderly wrote:
 > The standing issue is that a specification would have to exist for
 > this version of Java, or Sun would be breaking the rules in a way
 > similar to what Microsoft went to court over.  So, the reality is
 > that it can't be done "easily", and the benefits, while seemingly
 > strong, would only, in the end, slow adoption.

I don't think the specification is a big issue, as long a Sun doesn't
make these features default.  Use extended ("-X...") switches to enable
these options, and declare them unsupported, and all is well. Microsoft
was wrong here because they enbled extensions by default, not to mention
other very incompatible practices like removing entire APIs, or adding
new public methods to standard APIs.  And Sun wouldn't be inventing new
language features, they would just be making available some features of
modern J2SEs (all blessed by JCP specs) in non-standard circumstances
(supporting older JREs, and in some cases supported partially, e.g. if
assert statements are accepted but handled as no-ops, or if enums are
compiled in a way that requires an extension jar in the bootclasspath
and lacks on-the-wire serialization compatiblity with J2SE5.0). The only
important thing is passing the JCK -- and Eclipse's compiler does it,
so the JCK for javac does not forbid these careful extensions.

A+
Osvaldo

-- 
-----------------------------------------------------------------------
Osvaldo Pinali Doederlein                   Visionnaire Informática S/A
osvaldo@visionnaire.com.br                http://www.visionnaire.com.br
Arquiteto de Tecnologia                          +55 (41) 337-1000 #223