Andrew John Hughes wrote:
On Wed, 2004-06-30 at 23:28, David Holmes wrote:
Andrew Hughes wrote:
The hardest thing would seem to be the generics (Java's templates -- is
it or me or does it seem strange that Java 1.5/5.0 is basically bringing
back in lots of C++ features, mainly as a result of C# having them?).
It's you :) Java has had generics on the cards for a long time - too long,
but that's another story - since before C# existed. C# didn't define
generics initially either - have they added it yet? Java Generics is nothing
like C++ templates except for the <> syntax. You could say that a key goal
for Java generics was to NOT provide something like C++ templates. :)
From what I was reading recently, the new C# has generics. I wasn't
aware how different generics were from templates -- I suppose that's
what comes from rushing in before I know better. Templates are a pain,
so hopefully generics will be better.
As far as actually using Java goes, the re-appearance of enums will be
the nicest addition, mainly because the lack of them has been a pain
since I started using Java, and had to emulate them with constants.
Boxing/unboxing will also be nice to avoid the use of the wrapper
classes, but I'll think we'll see side effects with the same thing going
on behind the scenes. Most of these things are partly a result of C#, I
think, because its had these since word go. I never understand why
enums weren't carried across, anyway.
Java's Enum are stronger than the ones in C. If you define two
different Enumerations E1 and E2 with
certain constants you cannot define a variable of E1 and set it to a
value of E2. In C this would not be a
problem.
This is similar to way Java treats Arrays.
Generics are added to a lot of the core classes, notably java.util's
collections. Would adding this mean that compilers and code would need
to be 1.5 ready?
In principle because generics are based on type erasure, they are primarily
a compile-time concept. So code that uses generics that is compiled with a
1.5 compiler may be runnable on a non-1.5 JVM. That said, some of the
information is stored in the extensions to the class file format for
run-time introspection (don't know the details of what you can and can't do
here). So compiling with generics tends to produce class files that won't be
understood by non-1.5 supporting VM's. I suspect you would need a compiler
that knows how to compile generics whilst producing a non-1.5 specific class
file.
I think there are a few issues here. If Classpath starts using
generics, compilers will need to support generics as they are prevalent
in some of the most basic classes. This has already been noted. What
is probably a more long term effect (and one I imagine Sun has already
considered at great length) is that this is likely to break both binary
and source compatibility, something which hasn't happened as far as I
recall, in Java's history. Even the old AWT event model was maintained
from 1.0 to 1.1. Later releases have added more and more code to the
library (Swing, better 2D graphics and printing, XML, SSL, etc.), making
more and more code for us to rewrite. However, I think the only
language addition has been the 1.4 assert facility (which personally
I've never even used). How will pre-1.5 code work with generics, etc?
>From flicking through the docs for 1.5 beta 2, enums are also being used
in the core classes, so I imagine some methods will return them
(Thread's state is now done this way). It will be interested to see
what breaks. This is also a issue for Classpath, of course, because
most of the library is more complex stuff building on top of these
things.
Generics do not break binary compatibility - basically they are 'just'
syntactical sugar. Its the
compiler doing all the hard work - at runtime it is not possible to
tell anything about a type
variable (this might change in a later version). Remember that you can
develop with "-source 1.4"
with Java 1.5 (err 5.0 :P )
Btw: the assert statement is familiar from C but its better in Java
too: By default assert statements in Code
are deactivated and cannot be activated later at runtime (except if you
reload the class). That means the JIT
compiler can rip of that code and it never gets executed (like
expensive checks). Thats fine. If your application
does something unexpected you can run it again with -ea (enable
assertions) and with a little luck you can see
that something uses a method without providing the method's
preconditions.
cu
Robert Schuster
|