harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Egor Pasko <egor.pa...@gmail.com>
Subject Re: JRE Lite
Date Mon, 03 Mar 2008 08:12:49 GMT
On the 0x3FC day of Apache Harmony Johnny Kewl wrote:
> ----- Original Message ----- 
> From: "Tim Ellison" <t.p.ellison@gmail.com>
> To: <dev@harmony.apache.org>
> 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


Mime
View raw message