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

[Stuart Marks]

On 6/18/13 2:25 AM, Alan Bateman wrote:
> On 18/06/2013 08:42, Stuart Marks wrote:
>> 4) Could jaxp, jaxws, and corba be built with the current JDK, not the boot
>> JDK? Sure, probably.[...]
>>
> My understanding is that the new build is just following the old build[...]
>
> As least for the jaxws repository then I don't see any reason that it has to be
> built by the boot JDK. I actually don't see any reason why it needs to be
> rt.jar either, it could be built to jaxws.jar and dropped into the extensions
> directory (but that's another matter). That said, even if the jaxws repository
> was built later then it's unlikely that code there will start making use of new
> language features or APIs. That is because it's really an upstream project that
> still creates standalone releases to run on jdk7.
>
> The corba and jaxp are trickier because there are circular dependencies. These
> circular dependencies arises because we have a few places in the jdk repository
> that need to parse XML and there are few cases where CORBA APIs are used (the
> JMX remote API supports IIOP, and the JNDI CosNaming provider are two).
> [...]
> The jaxp repository is a clear case where we should be able to new new language
> features and APIs. Aside from the build then the only thing holding things back
> is periodically calls to keep the jdk7u and jdk8 code in sync. I don't know how
> long that can last and we will need to break from the past at some point.
>
> So I think this is a great topic to discuss. I think it has to be discussed in
> the context of where the repositories are going with modules. For the JDK
> modularization then we've long talked about restructuring the source code so
> that it's organized by modules, we didn't get to considering whether this would
> have an impact on the repositories. I think it's also worth discussing whether
> the "compilation unit" is the code in a single repository or whether the code
> in multiple repositories could be compiled together. The other extreme is where
> we get to the point where individual modules can be compiled on their own.

OK, I've pushed the change to README-builds.html.

I've filed an RFE that proposes changes to Configure to do version checking:

   http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8016918

Brad W filed a bug to cover changes in the way jaxp, jaxws, and corba are built:

   http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8016909

[links won't work until the externally-facing bug database is refreshed]

--

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.

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.

s'marks