On the 0x3FC day of Apache Harmony Johnny Kewl wrote: > ----- Original Message ----- > From: "Tim Ellison" <[EMAIL PROTECTED]> > To: <[email protected]> > Sent: Sunday, March 02, 2008 9:02 PM > Subject: Re: JRE Lite > > > > Your ideas sound quite reasonable to me. I bet you are surprised > > about how much code is run just to invoke main(String[]) in a Java > > program, but I see your idea. > > > > If you get it working we'd be delighted to create you a branch! > > Heres to hoping it pans out, I do realize that this burger may be > bigger than my bite ;) > Expect a lot of questions in the beginning, if it starts to work as a > rough prototype > I'll yell. > You would also have to consider carefully who sponsors the project, > what lic it > should have, and whether or not it should have a harmonious sounding name. > As you know most OS projects are marketing statements with very little > unpaid community. > This one would have to be a real community driven effort, even at > ownership level.... I think. > ... worth thinking about I think ;) > I'm going to need all the help I can get... thanks
OK. So, the project is to make a tiny-self-downloadable-almost-java? So, just to make sure, the TODO is like: * divide JSE in small packages * make an easily set-up server infrastructure for package hosting and mirroring (torrent?) * tweak classloader to download packages if they are not available on the system * make things work :) Sorry for my dummy question, I am just having major difficulties reading through your verbosity level ;) > > Regards, > > Tim > > > > Johnny Kewl wrote: > >> 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;) > > > > -- Egor Pasko
