JDK8 - bypassing the building of the images

[Magnus Ihse Bursie]

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.

Strictly speaking, it is not necessary. However, we have to strike a 
balance between doing too much and doing to little in every build step. 
If we do too much, we spend more time than necessary for most users. If 
we do too little, we end up with tons of build targets, making it 
impossible to parallelize the build, and for the user to know what each 
target does.

Our goal was that the default build should give a way to run the java 
launcher, and nothing more than this. Compiled jars are not neccessary 
for this, since you can run the launcher directly with the classes as-is 
on disk.

/Magnus

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