On 19:27 Wed 09 Mar , Phil Race wrote:
> Andrew,
>
> Whilst almost everything you wrote is something I agree with (like getting
> jcheck out there, not adding additional build tools/complexity), the one
> thing I quite like right now comes up here I'd like to keep is the
> separate repos.
> Its not just hotspot, but I've been working on JDK for a long time now,
> since before there was a hotspot and last year I built hotspot for the
> first time,
> and even then only because I was working on the VS2010 compiler upgrade.
>
> So I like that hotspot and jaxp/jaxws can be pre-built and pulled from an
> import JDK in a way that doesn't slow down my builds, bloat the source
> I need to pull via hg etc etc.
>
Well HotSpot is one thing I think works well as a separate repository.
It allows us to have a stable branch for OpenJDK6 for example. The only
real thing that stops it being independent is the servicability agent,
which, IME, would be better held in the JDK. That would also mean that
the existing rules for building java classes could be used, rather than
reinventing it all in the HotSpot makefiles as at present.
Likewise, I think langtools works as a separate entity. The other three
(corba, jaxp, jaxws) only really exist separately because no-one on the
OpenJDK project takes care of them. JAXP and JAXWS get irregular build
drops, but I don't think I've seen anything more than build fixes for
CORBA. They would be less work if maintaining in the JDK directory
as they'd share the build infrastructure. They are hardly huge (unlike
HotSpot vs. JDK) and there are dependencies between the JDK and these.
I probably should provide some context. During this week, I've been
looking at getting OpenJDK bootstrapping well when OpenJDK is not the
bootstrap JDK (i.e. sun.* and com.sun.* classes are not available).
To cut a long story short, it's a week later and I'm still only at
HotSpot. So far, I've found dependencies in all but JAXP that mean
that the build has to be patched to reference other repositories
(mainly JDK but also langtools in one case). JAXWS has to be able to
find com.sun.net.httpserver, annotation/javadoc classes and the JAXP
classes, while CORBA needs the sun.tools stuff and HotSpot needs
com.sun.jdi for the servicability agent.
Now you may think this isn't relevant and expect people to just use
OpenJDK to build. Well, this also becomes a problem if one of these
APIs changes. You're building stuff in CORBA, JAXWS and HotSpot against
a different API than the one they will eventually run against, hiding
issues which could be exposed at build time until run time.
I've already run across one place where this is true. HotSpot builds
the servicability agent with -source 1.4 -target 1.4. Why? Because
of incompatibilies between its implementation and the com.sun.jdi
interfaces which require Comparable<T> not Comparable.
> Maybe this doesn't matter to people who want to pull a full forest but
> its great for those working on specific components. Which I believe is
> most developers.
>
It's hard to generalise, especially with an open source project. These
mailing lists show that there will be quite a few newbies who follow
the build guides and try downloading the entire forest. As was mentioned
elsewhere in this discussion, the tarballs would be better for this
scenario as you don't really need the repos unless you're going to create
a patch (and even then, there are ways to do that without them).
My concern isn't the pull, but simply what makes best sense in terms
of maintenance, both of the code and the build system. Having independent
repositories also means duplicate build code and cross-repo dependencies.
With HotSpot and langtools it makes sense as you have independent entities
(the VM and javac et. al.). I don't think it makes sense with code that
has to then be imported into the JDK build.
> -phil.
>
>
> On 3/9/2011 4:48 PM, Dr Andrew John Hughes wrote:
> > On 18:32 Tue 08 Mar , Kelly O'Hair wrote:
> >> First, if we talk about the mercurial forests, it has nothing to do with
> >> the Mercurial Forest Extension.
> >> What we really have is a set of nested repositories, sometimes called our
> >> "forest" of repositories.
> >>
> >> This email is just about the actual layout of the repositories for jdk8.
> >>
> >> The initial thinking at this time is that the openjdk8 open forest will
> >> look very much like openjdk7:
> >>
> >> openjdk8/
> >> corba/
> >> jaxp/
> >> jaxws/
> >> jdk/
> >> hotspot/
> >> langtools/
> >>
> >> 7 repositories total. Cloned from the openjdk7 repos so we will have all
> >> the openjdk7 history in the openjdk8 repositories.
> >>
> >> Just for discussion sake, not that you can see what is behind the closed
> >> curtains, we are considering changing
> >> the closed overlay a little, from the current jdk7 (bold is a closed repo):
> >>
> >> jdk7/
> >> corba/
> >> deploy/
> >> jaxp/
> >> jaxws/
> >> jdk/
> >> src/closed/
> >> test/closed
> >> make/closed/
> >> hotspot/
> >> src/closed/
> >> test/closed
> >> install/
> >> langtools/
> >> pubs/
> >>
> >> To something a little simplier like:
> >>
> >> jdk8/
> >> corba/
> >> deploy/
> >> jaxp/
> >> jaxws/
> >> jdk/
> >> closed/{src,test,make}
> >> hotspot/
> >> closed/{src,test,make}
> >> install/
> >> langtools/
> >> pubs/
> >>
> >> The existence of these closed repos should not be a surprise, and it
> >> should have no impact on the openjdk itself.
> >> We are just trying to consolidate and have fewer repositories. Just
> >> thought it might be of interest.
> >>
> > Not surprised. Also don't really care where you put them as I don't seem
> > to have them either way ;-)
> >
> > What I would ask is do the projects get this as well? Specifially, I'd
> > like an icedtea/jdk8 at the same time please.
> >
> >> But back to the openjdk8 forest.
> >>
> >> Other ideas were considered:
> >> * Folding jaxp/jaxws into the root or jdk8/jdk repo
> > Sounds good. jdk8/jdk would make more sense as jaxws depends on some
> > classes that are in the jdk
> > tree (com.sun.net.httpserver) and we could then get rid of the Ant junk.
> > It would be good to have
> > the code there too so we can once again track changes. The recent security
> > issue was a nightmare
> > due to the unavailability of the source code.
> >
> >> * Separating out the jdk demos from the jdk repo to a separate "demos"
> >> repository
> > Makes sense. Having an option to disable them would be a good first step.
> >
> >> * Separating out the client (awt/swing/etc) code from the jdk repo into
> >> a separate repo
> > Why would we want to do this? IME, there are lots of interdependencies
> > with the other code and
> > this would make the build a nightmare.
> >
> >> * Updating the corba sources changing it to an ant build
> > Please, no! These Ant builds are already a nightmare and an order of
> > magniture harder to debug than
> > the Makefiles. Why you want to require a build system that requires an
> > entire JDK setup (possibly
> > bringing another into the mix beyond the bootstrap JDK) is beyond me.
> >
> > What would make much more sense is to just add corba into the jdk tree. It
> > actually requires sun.tools
> > classes to compile rmic anyway so it would make much more sense there.
> >
> > Hey, I'd just make it all one repository as they all interdepend on each
> > other, but the HotSpot folks
> > probably wouldn't like that... ;-) Moving the HotSpot servicability agent
> > into the JDK, where the
> > interfaces it uses lives, might be a good idea though. I'm currently
> > working on a patch which fixes
> > up a mismatch between the HotSpot SA implementation and the interfaces in
> > the JDK which has existed
> > for who knows how long (it's certainly in OpenJDK6)...
> >
> >> None of this seemed urgent to do out of the gate, or delay getting a
> >> preliminary jdk8 layout defined.
> >>
> > No, I agree with that. Splitting off OpenJDK8 already seems overdue.
> >
> >> I know there is some interest in pulling the actual jaxp/jaxws sources
> >> back into their repos, that will
> >> be discussed separately, we have multiple issues with that, but I am well
> >> aware of the pains that the
> >> source drop zip files have created.
> >>
> > The problem is less technical and more social; there is no obvious way to
> > interact with the JAXP and JAXWS
> > side of things. We just get these zips of code with no idea of what
> > changes are in there or why.
> >
> > Basically, they shouldn't work either like they do now or did before, but
> > like everything else in OpenJDK
> > with visible commits. Hey, maybe we could even have some mailing list
> > discussion if we're very lucky...
> >
> >> As always, we would like to get comments, or additional ideas.
> >>
> >> Separate topics:
> >> * Forest Extension and it's replacement
> > Do we really need one? Current status quo (get_source.sh) works fine.
> >
> >> * Mercurial server update to 1.8 or newer
> > I guess this is related to the forest issue.
> >
> >> * Build&Test system [1]
> >> * Open bug tracking system [2]
> >>
> > You missed off open sourcing that jcheck thing... that's the biggest
> > problem I have with
> > the Mercurial server. :-)
> >
> >> -kto
> >>
> >> [1]
> >> http://mail.openjdk.java.net/pipermail/build-dev/2011-February/004112.html
> >> [2]
> >> http://mail.openjdk.java.net/pipermail/web-discuss/2011-March/000153.html
> >>
> >>
>
--
Andrew :)
Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)
Support Free Java!
Contribute to GNU Classpath and IcedTea
http://www.gnu.org/software/classpath
http://icedtea.classpath.org
PGP Key: F5862A37 (https://keys.indymedia.org/)
Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37
