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
