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
