On 6/19/13 1:01 AM, Erik Joelsson wrote:
Currently, configure checks that the found boot jdk is 7 or 8. Do we really
want to actively prevent using 8 all together? I could agree to printing a big
warning in the summary at the end of configure to discourage it, but I do
believe it necessary to have the ability to build with 8 for tracking down
certain bugs.
Right. This is mainly about preventing mistakes, such as a run of configure
that picks up a JDK 8 that might happen to be in one's path, or someone who's
not aware of the rule I just clarified in the README. :-)
But of course it should be possible to configure JDK 8 as the boot for JDK 8 if
necessary.
I'm not sure a warning is sufficient. To paraphrase Kelly's message from
earlier,
Rule #1 Nobody pays attention to any warnings
Rule #2 When things go wrong, claim that you didn't see the warning
I looked in boot-jdk.m4 and I see that it disallows JDK 6 entirely (makes
sense) and allows 7 and 8. Maybe it could disallow JDK 8 by default, unless an
additional option is provided (like Max suggested).
Of course, all of these numbers will need to be rolled forward when we get to
JDK 9.
s'marks
Regarding the rearrangement of corba/jaxp/jaxws to use the fresh JDK instead
of the boot JDK. At least we know they build, because the boot cycle build
builds them successfully. (At least, I think it does.) Now, I don't think the
artifacts produced from a boot cycle build are actually tested or are
delivered anywhere in a bundle. So, while it seems quite unlikely, some bugs
could have been introduced by building with a newer JDK version.
Now ... circular dependencies ... urk ... I *knew* there was something that
would make this complicated. Well, maybe these will need to be refactored
away somehow. Or maybe some kind of GenStubs technique can be used to deal
with the circularity.
You introduced yet another point as well, which is the relationship between
the repository organization and the build structure. As I understand things,
each repository has its own build support and builds in a separate step from
the others. In principle I think that the repository structure ought to be
orthogonal to the build structure. At least, if we move to a more modular
build structure, that shouldn't imply that we need to have each module in its
own repository. In fact I'd like to see fewer repositories. To me, the only
compelling reason to have a separate repo is if the source code in it is a
snapshot of an upstream source base -- as seems to be the case for jaxws.
Having all the stuff in fewer repos makes it easier to bisect to find
failures, and it reduces the need for careful management of coordinated,
cross-repo changes.
My preferred solution would be to fold in the repos that aren't upstream
projects into jdk and just have them compile with the rest there. I much like
the idea of reducing the number of repos. If that isn't possible, we can just
add those source directories to the main javac invocation in jdk too.
/Erik
