rt.jar put on a Proguard diet losses 26 MB

[Michael Hall]

On Dec 17, 2012, at 4:10 PM, Jeff Palmer wrote:

> 
> 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.

I remember this from the start but thought you were planning on using some other jre with JWS.

> 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.

I think I was seeing that to accomplish some things having them in a separate jnlp is required to do the task, not an unnecessary feature.
> 
> 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?

Automatically getting updating runtimes were for a long time the usual situation on OS X. Being current was usually where you wanted to be if possible. I have heard of cache problems but haven't had to resort to it too much myself in my jws use. Which hasn't been much but I am using it for a couple app's at this time.

> 
> 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.

I hadn't heard about JWS going away. Thats not good news. Sort of like Jigsaw delayed until 9. Although I guess the development version is available ongoing along with Java 8? If you plan on tailoring the jre that would be what is provided for this is my understanding. The JRE that is used for JWS is I think somewhat stripped down. No command line related, etc. There are  others far more knowledgable on this. It sort of seems like you are re-inventing some wheels though. 

Michael Hall

trz nio.2 for OS X http://www195.pair.com/mik3hall/index.html#trz

HalfPipe Java 6/7 shell app http://www195.pair.com/mik3hall/index.html#halfpipe

AppConverter convert Apple jvm to openjdk apps http://www195.pair.com/mik3hall/index.html#appconverter