harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Johnny Kewl" <j...@kewlstuff.co.za>
Subject Re: JRE Lite
Date Tue, 04 Mar 2008 01:23:53 GMT
----- Original Message ----- 
From: "Egor Pasko" <egor.pasko@gmail.com>
To: <dev@harmony.apache.org>
Sent: Monday, March 03, 2008 2:54 PM
Subject: Re: JRE Lite


> On the 0x3FC day of Apache Harmony Johnny Kewl wrote:
>> ----- Original Message ----- 
>> From: "Egor Pasko" <egor.pasko@gmail.com>
>> To: <dev@harmony.apache.org>
>> Sent: Monday, March 03, 2008 10:12 AM
>> Subject: Re: JRE Lite
>>
>>
>> > 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 :)
>>
>> More or less yes... but I dont think it will be easy, possibly not
>> even doable.
>>
>>
>> I think size and speed tradeoffs, and the intelligence required will
>> make it really
>> interesting... if we get there a lot of fun.
>
> How about a bit of somewhat easier stuff?
>
> shell> java-intaller install --all-deps swing
>
> (where, 'swing' is the package name)
>
> I.e. get basic JVM, then control which packages to install by hand. No
> pain. The only weird thing is that to deliver a Java app one must
> provide it with list of dependencies. But this is rather common and
> convenient in open source world.

A JRE is already selecting what an application needs to run, and does it a 
lot better than a human.
An application actually uses much less than its "bundle".
Also as a developer you do not know what is on the users machine already....
If the last application used Swing... this application will not need to get 
it again ;)

Its a very simple concept actually... if you see the whole JRE as 100%
I think most applications on use 10%
Heavy applications 60%

But with every run, the usage drops off exponentially...

If app A  used 20% when it runs on its own.
And another app B uses 25% when it runs on its own.

Then first App run = 20%
Second App run 5%

A developer cant control that because the JRE is a learning system....

But it also means this... have you ever wondered why multimedia and video 
are not packed with Java...
Its because if it not main stream or popular... Java has a thud factor 
problem.
In a scheme like this... the JRE engine could be a 1000 gigs...
It doesnt matter, the app only uses what it needs.... and now...
USB support...
Video Editing, Streaming...
Companies that woudnt even look at Java would add in Flash players...
Medical companies could add in special Hospital stuff.... the API would be 
endless...

Java just for business is boring... this would make a Java for the world...

The PANIC Harmony sub-project would be the busiest open source project on 
the web... I think ;)
I think its a way to turn the guru's loose and let them change the world 
:)... make it a whole lot better.

So make java deliverable.... and the sun will really shine ;)

>> Java currently is a pain to deliver... can we take that away, and why
>> hasnt anyone done
>> that yet.... is wots on my mind.
>>
>> or... you got a 50k application, but dont even bother trying to send
>> it via email, or contemplate
>> the user starting it froma browser.... because there is a big lump of
>> concrete attached to it.
>> Its like making a ferrari and towing a truck... more verbosity ;)
>>
>> > 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
>> >
>> >
>>
>>
>
> -- 
> Egor Pasko
>
> 


Mime
View raw message