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.
