rt.jar put on a Proguard diet losses 26 MB

[Jeff Palmer]

On Dec 17, 2012, at 7:58 AM, macosx-port-dev-request at openjdk.java.net wrote:

> From: Michael Hall <mik3hall at gmail.com>
> Subject: Re: rt.jar put on a Proguard diet losses 26 MB
> Date: December 16, 2012 7:09:42 PM EST
> To: macosx-port-dev OS X <macosx-port-dev at openjdk.java.net>
> 
> 
> On Dec 16, 2012, at 5:33 PM, Jeff Palmer wrote:
>> 
>> 
>> You could also get a similar effect, but write it out as separate jars, one for your app & rt. jar.  Both of these would not allow the user of your application to replace the library & have it still work.  Licensing issue if someone wants to make a scene.
> 
> JWS on OS X is supposed to use the Internet Plugin 'shared' JRE as far as I know with no options for embedding or pointing to your own. I'm not sure what shortcuts do. If they create a more or less standalone application bundle you could maybe embed your own JRE there. But I'm just not sure this would work  real easily the way JWS is set up on OS X.

It might have gotten lost from the original note, these are experiments I am doing to look for a replacement to JWS some time in the future.  I want my own JRE with no regression gotchas that could spring from a new JRE.  It would be trimmed of un-needed stuff from rt. jar, and built for direct install using the app bundler for mac http://java.net/projects/appbundler , and some as yet unknown tool for windows.

The bundle would also have a library I use, HSQLDB, and never need to change.  It is overkill for my needs as it is.  

The actual application is stored in a signed jar file on an SSL capable http server.  Call it impl.jar.

The main() code that is put in the bundle, attempts to download impl.jar via https, if it is newer than the one already there, otherwise 304.  The new file is quarantined until the modulus & exponent  of the certificate of every entry in the jar matches that which main() has been hard coded to look for.  JarFile & JarEntry classes do all the heavy lifting.  The class loader is then sub-classed with impl.jar added in the path (still working on this part; J2SE is different from Android), then launch the implMain() using reflection.

I already have a 15 KB Android app, which acts as a stub, that gets an impl.apk.  It works really good.  It is < 150 lines.  Coordinated server-desktop-android updates make the development & deployment cycles much easier.

JWS is a process of stuff strung together, with too many options, like nest able jnlp's.  Options that are implemented at runtime.  This is not really great for reliability.  The time to be flexible is at the media creation stage, not here.

JWS has to launch a JRE that's available on each machine.  Here the JRE is already running & can never change.  There is exactly ONE thing to get & cache.  JWS has a whole cache database for resources.  When over the past have you heard of having to clear your cache to fix some problem?

No more directions on your web pages to go to Oracle to install a JRE.  The javascript which does the automation of the JRE install creates as many problems as it solves with all the different browser behaviors. 

I feel by massively reducing the options, being already inside a running JRE that is both fixed and private, and leveraging app bundling tools available for non-updateable apps, that I can do a better job than JWS.  Do not want sound ungrateful for what has been provided for me, but comments I have seen about JWS maybe not being in Java 9 was all I needed to go on the hunt to something better.

Jeff Palmer
WhatIf Squared LLC