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