TIm... you right too much in one topic so split... You know when you discovering something, its not a science, its exploration, and I havent even got the dev env going yet so still very low on the learning curve... but this is what I'm thinking..
The basic JRE engine must be completely plugable... dynamic loading as you call it. At a quick glance the really big components are things like the JIT compiler, The fonts, all the "base" classes and the Unicode... I think its a unicode module. Now here is what I'm thinking... the JRE gets stripped right down... So for example it looks for JIT but if it cant find it is doesnt crash. Then instead of making users download... there is a Harmony site and on this site, are all the fonts, all the classes... optional UTF modules etc etc. The initial download is just a bootstrap... it can either be downloaded or included with the software... If it needs a Comic font and UTF module... it fetches it, just enuf to get that application running. So if the users runs a series of small applications they all very quick installs, but the JRE is growing... So by the time the user installs a heavy application, the JRE will probably do it all. In this scheme there is also no concept of versioning... if a class is loaded that needs a new JRE lite module it will just happen.... the user is hassle free. So there is still a installation server somewhere.... but the user doesnt even have to know about it. That kind of dynamic loading means the JRE must fit together like a jigsaw puzzle.. For example the first run of an application may run without JIT, but the JRE's background loader starts to pull it down... the next run will be fast.... The reason I asked about the interchangability is because if one has a small engine that can get only what it has to... then that gets very interesting. For example, if a machine already has classpaths all over the place.... and a JavaLite hits the machine.... it gets only what it needs, ie it gets a few core classes, maybe a few fonts, maybe its own multimedia engine.... but it does not have to get anything else... it does not have to tell the users to setup xerces again... it see's wots on the machine already and uses it... so theres the compatability side... the creativity side is that the Java application downloaded, may also be able to suck down a native module, or custom class modules that do stuff like play Flash Video... now thats a JRE ;) So... when I get going I'm going to break Harmony into tini weenie pieces.... ha ha. In this model, one does not even care about classes.... its just that engine that must be able to discover and use whats there, or pull it from a installation server. Apps have the choice of using there own JRE Lite... or the systems JRE ;) but I think if that JRELite is small enuf... it will go out with every application. Installers will use that... for sure, it makes life very easy. ... so thats the idea... whether it will pan out, and the idea is possible, I dont know... I cant see why not.... Some application will be unlucky... they internationalized the developer has gone mad with XML, use JPA, JMX, JWhatever... and yes that apps JRE will have to build itself up to 10 megs before it will run... but a game using JNI and doing its own drawing will probably run on a 500k JRE Developers will very quickly learn what make the JRE take a big hit.... I think thats a good thing, all the technology is there but depending on what system they targeting.... they will design accordingly, possibly using property files instead of XML parsing... So... once I get going thats my hobby for the next 4 months ;) If it works... you'll have to make another SVN fork;)
