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: Feedback on JRELite efforts
Date Mon, 31 Mar 2008 21:54:27 GMT


----- Original Message ----- 
From: "Egor Pasko" <egor.pasko@gmail.com>
To: <dev@harmony.apache.org>
Sent: Saturday, March 22, 2008 9:52 PM
Subject: Re: Feedback on JRELite efforts


> On the 0x40F day of Apache Harmony Johnny Kewl wrote:
>> Thought you would be interested to know that our efforts to turn J2SE
>> into a "click and go" Java failed miserably :)
>>
>> I think that any JRE that sets up for speed "immediately" will never be 
>> lite.
>> It loads everything under the sun, in an effort to be instantly fast.
>> I think its still possible but not with "that" machine.
>>
>> I been digging around trying to find good articles on JVM design so I can 
>> understand the
>> design parameters. Anyone know of good links, please yell.
>>
>> Even been doing things like simulating Java's dependencies, so I can see 
>> what an application
>> "actually needs".
>> Did some very rough analysis on a simple AWT app against sun J2SE...
>> ie analysed dependencies, then wrote some software to extract every class 
>> "actually used".
>> And the idea seems to pan out... for example from the one test I did the 
>> classes used
>> came to around 1600... is that unbelievable or what (a simple app)...
>> .... BUT compressed its 2 megs ... and that aint bad at all.
>>
>> I see there are a frew JSR's in this area so people are thinking about 
>> it, but they seem
>> to be wrongly approaching it from a package view, installer view, not 
>> what the JRE is actually needing.
>> ie there is a big difference between thinking XERCES and XALAN package, 
>> and what the JRE actually takes
>> from it... the yada blah conversation that we already had... ie the JRE 
>> as installer blah blah.
>>
>> I think this is beeeeeg, and I see you have student projects on the go, I 
>> think a ** JRE Engine analyser **
>> (if not done already) would be an amazing project.
>> IE, show the analyser an application... it tells you, all the JRE classes 
>> used, the size, the native component, and lists the dependency diags.
>> The way I did it was very primative and very slow... but its an 
>> interesting area.
>
> Yes, interesting.
> This is a part of GSoC harmony-tools-1 idea (BundleTool)
>
> There is a proprietary ahead-of-time compiler to produce small native
> execuables limited to only the classes used. Examples of several such
> applications:
>
> http://www.excelsior-usa.com/java-download-size.html

Yes, thanks, nice link and clever package, just the sort of thing Java 
needs.
I think it fits a user niche nicely, quick starting, "contained" native 
package - from Java
Clever manipulation of JIT, I imagine... nice lateral thinking stuff.

>
> In short: GUI <10MB, noGUI <5MB.
>
> AFAIR, you would not call those packages lite. Given that the whole
> JRE is about 20MB download ..

Yes, what I have in mind doesnt work like the above link, it would still be 
Java with this idea.
I'm not sure at all if it will work... I just keep thinking that Suns Java 
embedded is 5 megs
The lite down load 7 megs, and a full JRE 15 megs.... so I think that a 
naked JRE without classes
must be around 3 megs and then the rest can be paired off with required 
functionality.
Like AWT plus its Native paired off component, and fonts....

At this stage its more of a wish for a "click and go" java.
I actually dont know what "GSoC harmony-tools-1" is ;)
But yes I get the idea of the above tool (link), and how it derives from the 
nature of a JRE.
Anyway thanks Egor... at this stage just a few idea's we playing with.

== POJO APPLICATION SERVER (API server released) ==
BTW we have released the 1.0.6 version of the POJO Application Server (PAS)
The native delivery is very experimental but seems to work.
Even though the PAS can deliver applications to remote machines very 
efficiently, and
even though it can now also deliver native "JNI" extensions... this stuff is 
all very
much "application level", ie the native delivery is to say incorporate a 
cool mutimedia player
for an app... its not delivering Java itself... thus our further interest in 
the area.
Currently applications do not have to be on remote machines, we having a 
good look at
whether we can find a way to have absolutely 'nothing' on the remote 
machines to start with.
(click and go). Thats the maybe impossible idea... but for some reason my 
gutt tells me
its possible.
BTW... PAS does not work on Harmony yet... I know... shoot me ;)
We are thinking about it ;)

Thanks...

> -- 
> Egor Pasko
>
> 


Mime
View raw message