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

Erik Joelsson erik.joelsson at oracle.com
Wed Jun 19 08:01:45 UTC 2013

On 2013-06-19 03:10, Stuart Marks wrote:
> -- 
> I have half a mind to look at the Configure changes myself in my spare 
> time (ha!), but I have no spare time, and I don't have the expertise 
> in this area anyway. So anyone is welcome to pick this up. In 
> principle it should be fairly simple, and I think it's fairly 
> important. This isn't the first time someone's been bitten by having 
> the wrong boot JDK version, and it won't be the last.
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.
> 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.


More information about the build-dev mailing list