generic type support

Wed Feb 19 22:10:00 GMT 2003

> Teaching gcj to invisibly run jikes and then read the 
> resulting bytecode would be an interesting project.

My main concern about GCJ doing source compilation is that it
is going to be "outflanked", i.e. it is a lot of work to create
an up to date frontend. It is easier for GCJ to keep up with "only"
changes to the bytecode standard.
On the horizon:
- Generics
- AspectJ
- Other?
I'm not clear on what the design goals for GCJ is, but my
vote is for deployment: Java could get a bigger bite out of 
the desktop, if applications didn't have to drag along the JRE with
all its hickups. Painless JRE deployment is still a couple of years
off.
I support side by side installation of my program using GCJ(unzip
old and new version to two seperate directories, done!).
The only safe way I have found to deploy my app is to include the
JRE in each side-by-side installation(using e.g. InstallAnywhere).
Performance as a design goal for GCJ?
Development efforts aside, I believe that a JIT compiler could 
be made to outdo any source level static compiler. 
I haven't seen any uncompromising efforts on JIT compiler performance: 
e.g. any of the JITs with vectorisiation support yet(MMX, SSE, 3D Now!, etc.)?
(The bytecode is probably not an ideal starting point, but...). Microsofts 
.Net has a JIT which can be configured to do its compilation install 
time(they have a global cache of compiled code).
There a couple of other motivations that I know of:
- anti reverse engineering
- reduced memory footprint(executable sharing between processes)
Øyvind