JDK8 - bypassing the building of the images

[Naoto Sato]

On 9/16/13 1:03 AM, Erik Joelsson wrote:
>
> On 2013-09-13 18:38, Naoto Sato wrote:
>> Hi Erik,
>>
>> Is there any reason that those jars *have to* be created in "images"
>> build? localedata.jar is also in the same boat, and it's even more
>> difficult for incremental build, since those locales are loaded as
>> extensions with ServiceLoader.
>>
> No, it could be moved to the jdk target just as the crypto jars have
> been due to loading issues with having those classes in the classes
> directory. I'm not familiar with the ServiceLoader and extensions. In
> what situations is this a problem?

Sorry, I take those ServiceLoader/Extensions back, but the way to load 
locales depends on the existence of "localedata.jar" which allows the 
JRE to correctly return supported locales (incl. compact profiles). 
However as Magnus replied before, if the goal for the default jdk build 
is just to build the runnable launcher, this is not required.

Naoto

>
> /Erik
>> Naoto
>>
>> On 9/12/13 11:54 PM, Erik Joelsson wrote:
>>> Unfortunately rt.jar is part of the images build. The fastest turnaround
>>> incremental builds for your usecase is currently reached by doing this:
>>>
>>> make jdk-only JDK_FILTER="javax/swing javax/accessibility java/beans"
>>>
>>> You don't get an rt.jar, but you can run the exploded image directly
>>> from <outputdir>/bin/java and most things should work.
>>>
>>> /Erik
>>>
>>> On 2013-09-12 19:51, Pete Brunet wrote:
>>>> I made some changes for debugging in jdk8.  jdk ran for 9.5 min and
>>>> images for a little over 13 min.  I'm currently changing code in
>>>> javax.swing, javax.accessibility, and java.beans.  All those live in
>>>> rt.jar so it would be nice to be able to copy a newly built rt.jar
>>>> to an
>>>> existing image without having to rebuild the images.  However, I didn't
>>>> find rt.jar in the jdk tree.  Does it exist; maybe I just missed it?
>>>>
>>>> I know those are long build times but after trying lots of things I
>>>> haven't had any success in getting to the low build times others
>>>> experience.  A new SSD should arrive today so hopefully that will be
>>>> running by tomorrow.  I'll report the results of that in another
>>>> thread.  So maybe I won't care about build times after that but I
>>>> suspect there are others on the list also suffering from long build
>>>> times who would be interested in the answer to the above question.
>>>>
>>>> Pete
>>>
>>
>