Hi, Alexey, thanks for the link. I don't think the distribution size is the biggest JRE problem for client applications. Anyway even without Kernel distribution RE JRE is only 15MB which is substantially smaller than .NET framework redistributable. With the Kernel distribution it's only 3MB about 2x Flash Player size :)
JRE's three biggest problems I think are slow startup, large footprint and GC pauses. The footprint problem is generally solved by data sharing between JVM instances. The GC pauses can be helped by using incremental or concurrent GC. The startup time tougher problem. It's almost unrelated to the ditribution size as only the used classes are loaded. But it's governed by the class parsing and no-opt JIT/interpreter overhead. It's possible to make JRE startup to be more lean and mean. But the real answer here is excluding the classloading and JIT phase from startup altogether at least for frequently used components. The good news are that most of the frequently used classes for small applications are located in class libraries. RE JRE as I remember already can precompile rt.jar and use that fact. .NET has a signed binary module cache and the application installer can compile the model AOT and place it to cache. The bbiggest problems of AOT compiled module caching are class versioning and security. I think it's possible to implement such mechanism for Java using Jar files as an atomic modules for AOT caching. In this case the Jar signature would be used for module versioning and ensuring the binary code is unmodified. We already made some experiments and caching on individual method level doesn't give any performance boost due to class loading and signing overhead. Thanks. Sergey. 2008/4/28 Alexey Petrenko <[EMAIL PROTECTED]>: > > http://java.sun.com/developer/technicalArticles/javase/java6u10/index.html#kernel >
