Feedback on JRELite efforts

[Johnny Kewl <jo...@kewlstuff.co.za>]

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.

I think coders would look at it and go... do we really need to load JMX, and sockets and XML parsers, just to run System.out, why?

Anyway... thats as far as we got, although we did manage do turn the POJO server we working on into an API server, and it works damn well.
Will be in next release... will drop a note here when out so anyone interested can see how delivering API to remote machines works.

Conclusion J2SE is a "heavy" speed freak... ha ha, I hope Harmony doesnt emulate that pattern.
It must "build up" to being a speed freak ;)

Any article links on JVM design much appreciated.
I'm not even in IT, and this gets me excited ;)

--------------------------------------------------------------------------
HARBOR: http://coolharbor.100free.com/index.htm
The most powerful application server on earth.
The only real POJO Application Server.
Making the Java dream come true.
Making Gates - Number 2
---------------------------------------------------------------------------

Re: Feedback on JRELite efforts

[Tim Ellison <t....@gmail.com>]

Johnny Kewl wrote:
> == POJO APPLICATION SERVER (API server released) ==
> BTW we have released the 1.0.6 version of the POJO Application Server (PAS)
<snip>
> BTW... PAS does not work on Harmony yet... I know... shoot me ;)
> We are thinking about it ;)

Why does it not work on Harmony?  Any bugs to report?

Regards,
Tim

Re: Feedback on JRELite efforts

[Johnny Kewl <jo...@kewlstuff.co.za>]

----- Original Message ----- 
From: "Egor Pasko" <eg...@gmail.com>
To: <de...@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
>
> 

Re: Feedback on JRELite efforts

[Egor Pasko <eg...@gmail.com>]

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

In short: GUI <10MB, noGUI <5MB.

AFAIR, you would not call those packages lite. Given that the whole
JRE is about 20MB download ..

-- 
Egor Pasko