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

[Alan Bateman]

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. I spoke with Jon G on this topic the other 
> day and we didn't come up with any really good reasons why they need 
> to be built with the boot JDK. Historically they were upstream 
> repositories so they were usually based on a backrev JDK anyway, so 
> there was no real need for them to use the latest features. Also, 
> using the boot JDK was probably an incidental outcome of the way the 
> old build system was put together. (Old-timers lurking -- or not :-) 
> -- on this list will certainly know better than me.) The new build 
> system does the same, since one of its requirements is that it 
> slavishly match the output of the old build system.
>
> In principle I don't see any reason why these libraries couldn't be 
> built with the current JDK instead of the boot JDK. This might be a 
> fairly large restructuring of the build system, though.
>
My understanding is that the new build is just following the old build 
(a while back, I did ask about the same issue and I remember Kelly or 
someone pointing out that the new build had to follow the same build 
sequence as the old in order to generate equivalent bits). Although 
you're anxious to get the README updates then it is a great topic and 
now might be a great time to discuss it.

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).

As least for the CORBA APIs then we've already done significant 
refactoring to support modularization and it might not be big job to 
move the CORBA dependencies into the corba repo. That said, CORBA is 
mostly just bug fixes these days so there isn't a queue at the door to 
use new language features or APIs. On the other hand there is still a 
case to building it with the newly built jdk because of sun.* and other 
implementation mess. We have several examples in the last year where 
building the corba repository with the boot JDK has been a problem (a 
duplicate shared secrets mechanism had to be added for example).

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.

-Alan.