Project Proposal: JDK 7 Update

Mark Wielaard mark at
Thu Jun 16 21:31:38 UTC 2011

On Thu, 2011-06-16 at 13:51 -0700, mark.reinhold at wrote:
> 2011/6/16 4:20 -0700, mark at
> > What do you mean by buried? You just have to tag the repositories with
> > for each release/update to get exactly at the source at that time. Look
> > at how openjdk6 handles this. There is just one jdk6 forest with each
> > update release tagged. That is a much smoother model to follow IMHO.
> > Otherwise one quickly cannot find the forests through the trees :)
> There are other materials in the JDK 7 Project besides code.  The various
> web pages describing schedule, features, milestones, etc., are likely to
> be of historical interest over the long term.  If we use the existing JDK
> 7 Project for updates then that material would become harder to find, if
> not eventually lost altogether.  The relevant URLs would almost certainly
> change.

Do you mean the pages under ?
We could still keep using them and augment them with new information
on what was added with each update. I don't think the URLs need to
change at all.

> To put it another way, these are logically distinct Projects, with
> distinct participants, goals, and processes.  Shoe-horning them into
> a single Project just risks confusing people.

I admit to be confused :)
If you were talking about jdk6 vs jdk7 vs jdk8 then I would understand.
But I honestly don't see the big difference in scope that would call
for a whole new project and forest now if it is just about continuing
jdk7[.x] development. Not calling that the jdk7 project feels confusing.

> Finally, using the JDK 7 Project for updates would be inconsistent with
> the proposed Bylaws, which define a "JDK Release Project" as being for
> "new releases of Java SE Platform implementations".  Update releases do
> not fit that definition.

Why not? They are just new (updates/bug fixes/enhancements) releases of
the Java SE Platform implementation aren't they?

> I honestly don't understand the aversion, expressed by some, to the
> creation of new forests.  Disk space is cheap.  What's the problem?

Changing names and locations is always a bit confusing. That is just it.
And it is just that jdk6 is going so well and is pleasant to work with
because it is just one forest with each update tagged that made me happy
with that way of working. So personally I would like to see that also be
used to continue jdk7 if possible. It would be shame to break up
something we are used to that is all.

Wouldn't it be an idea to instead of branching off for the next update,
to branch off and archive jdk7 1.0 on a special release page/URL under when we are
satisfied it is finished, put some tar balls, the archived feature,
milestones, builds and calender under it and then keep the jdk7 project
as being the update project? From a developer standpoint that seems
nicer to keep up with than having to change every time there is a new
update just to keep on top of the latest jdk7 development.

BTW. I am not dead against having a new project. If people feel that is
the best thing to do to keep improving jdk7. I am just surprised because
it feels much more natural to just keep using the jdk7 project to work
on jdk7 stuff instead of having to go through all the trouble of setting
up a new project and repositories. But I am sure you feel surprised the
same way, just in reverse :)



More information about the discuss mailing list