harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Johnny Kewl" <j...@kewlstuff.co.za>
Subject JRE Lite
Date Sat, 01 Mar 2008 22:11:40 GMT
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
If it needs a Comic font and UTF module... it fetches it, just enuf to get that application
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;)
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message