RFR: 8016780: (xs) README-builds.html misses crucial requirement on bootstrap JDK

[Stuart Marks]

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
>