RE: generic type support

[Øyvind Harboe <oyvind dot harboe at zylin dot com>]

> 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