From dalibor.topic at googlemail.com Sun Dec 2 22:44:28 2007 From: dalibor.topic at googlemail.com (Dalibor Topic) Date: Sun, 02 Dec 2007 23:44:28 +0100 Subject: Build 24 promotion and the Mercurial Transition Status In-Reply-To: <47506072.5030509@sun.com> References: <47506072.5030509@sun.com> Message-ID: <4753354C.3000706@kaffe.org> Kelly O'Hair wrote: > > Build 24 and the Mercurial Transition Status: > > * We are finishing up our Mercurial dryrun this week. > In the next few days, all the repositories at > http://hg.openjdk.java.net/ > will be re-initialized, making them unrelated to the previous > experimental ones. > They will contain the official starting sources, which will be the > same sources > we started the dryrun with, and the same as Build 23, so don't be > expecting > to see developer changes, yet. > > * Once we have the official jdk7 repositories, we will creating > potential Build 24 > bits (probably on Mon or Tues), and our release engineering team > will have these > bits go through some very basic testing before we officially > promote them and > declare Build 24 done. The release engineering team will be > creating some > mercurial tags and pushing them into the master jdk7 repositories > to label > Build 24 when the promotion happens, hopefully Tues or Wed next week. > > * Internally, we'll need a few days after that to get ourselves > re-setup for > developers to start doing pushes into their team repositories for > Build 25. > Since all these team areas are available at > http://hg.openjdk.java.net/, > everyone should start seeing the jdk7 development 'live', as it > happens. > > * It's not clear when the first team integration into the master > jdk7 area for > Build 25 will happen. We are still trying to nail down some of our > detailed > procedures on how team integrations will work, and we'll probably > adjust them > over time. > > -kto Thank you very much for your hard work (and the team's!) on making the transition happen. I'm looking forward to the commit, patch & review flood! cheers, dalibor topic From gnu_andrew at member.fsf.org Mon Dec 3 09:01:25 2007 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Mon, 3 Dec 2007 09:01:25 +0000 Subject: Build 24 promotion and the Mercurial Transition Status In-Reply-To: <47506072.5030509@sun.com> References: <47506072.5030509@sun.com> Message-ID: <17c6771e0712030101m7c9bf82fnec7206285f9444cd@mail.gmail.com> On 30/11/2007, Kelly O'Hair wrote: > > > Build 24 and the Mercurial Transition Status: > > * We are finishing up our Mercurial dryrun this week. > In the next few days, all the repositories at > http://hg.openjdk.java.net/ > will be re-initialized, making them unrelated to the previous > experimental ones. > They will contain the official starting sources, which will be the > same sources > we started the dryrun with, and the same as Build 23, so don't be > expecting > to see developer changes, yet. > > * Once we have the official jdk7 repositories, we will creating > potential Build 24 > bits (probably on Mon or Tues), and our release engineering team will > have these > bits go through some very basic testing before we officially promote > them and > declare Build 24 done. The release engineering team will be creating > some > mercurial tags and pushing them into the master jdk7 repositories to > label > Build 24 when the promotion happens, hopefully Tues or Wed next week. > > * Internally, we'll need a few days after that to get ourselves > re-setup for > developers to start doing pushes into their team repositories for > Build 25. > Since all these team areas are available at > http://hg.openjdk.java.net/, > everyone should start seeing the jdk7 development 'live', as it > happens. > > * It's not clear when the first team integration into the master jdk7 > area for > Build 25 will happen. We are still trying to nail down some of our > detailed > procedures on how team integrations will work, and we'll probably > adjust them > over time. > > -kto > > > > > > Fantastic news! Good to know Sun JDK development will soon become open! -- Andrew :-) Help end the Java Trap! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnu_andrew at member.fsf.org Mon Dec 3 21:54:33 2007 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Mon, 3 Dec 2007 21:54:33 +0000 Subject: Announcing IcePick, a build framework for compiling the langtools Message-ID: <200712032154.44078.gnu_andrew@member.fsf.org> The aim of the IcePick project is to allow the language tools (javac, javadoc, javah, javap, apt) from the OpenJDK project to be built separately using any 1.5 compliant Java compiler. This is primarily motivated by a desire to allow these tools to be used with virtual machines that make use of the GNU Classpath library rather than simply as part of the larger IcedTea or OpenJDK distribution with the HotSpot or CACAO virtual machines. The advantages of using this toolset as opposed to existing tools distributed with Classpath-based solutions are: * A 1.5 capable Javadoc generator (gjdoc still needs support for the new constructs) * Provision of the apt tool for which there is no other Free software solution. This tool is needed to build the JikesRVM. * More heavily tested implementations of javac, javah and javap than those provided by ecj and the GNU Classpath tools Unlike IcedTea, IcePick's only dependency is a 1.5 capable compiler which can be provided by ecj, a gcj which uses ecj or an existing copy of javac. Because the OpenJDK class libraries and HotSpot are not being built, their requisite dependencies (see BuildRequirements are no longer needed. As a result, IcePick is buildable on a wider range of systems including those not yet supported by IcedTea. This includes those architectures other than x86, x86_64, ppc and ppc64 (the latter two having experimental support on IcedTea thanks to Gary Benson) and systems which can't meet the arduous build requirements of IcedTea/OpenJDK. It also provides a solution for users who want the OpenJDK toolset but don't want to build the entire distribution. It's still fairly untested so please try and give it a whirl and let me know of any problems. Details of how to check it out and build are on the IcedTea wiki: http://icedtea.classpath.org/wiki/IcePick Bugs: http://icedtea.classpath.org/bugzilla/ Thanks, -- Andrew :-) Help end the Java Trap! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mr at sun.com Tue Dec 4 19:55:01 2007 From: mr at sun.com (Mark Reinhold) Date: Tue, 04 Dec 2007 11:55:01 -0800 Subject: Format for JDK 6/7 changeset comments? In-Reply-To: jim.a.graham@sun.com; Fri, 09 Nov 2007 13:01:41 PST; <0JR900029BQURRB0@fe-sfbay-09.sun.com> Message-ID: <20071204195501.D02C02783C7@eggemoggin.niobe.net> (finally getting back to this topic) > Date: Fri, 09 Nov 2007 13:01:41 -0800 > From: jim.a.graham at sun.com > Why not both? Why does it have to be one *or* the other? I really > don't get that aspect of these discussions. > > ... > > It's not like the information included in either location is somehow > legally binding - it's all there just to help us get work done... Having mulled this over during the last couple of weeks, and considering related comments by Andrew Haley and Jesse Glick, I've come around to agree that a short summary describing the change made in a changeset is actually a good idea. Most of us in the JDK team at Sun are used to browsing code histories with the bug database close to hand. Now that we've open-sourced the code however, it's going to travel far and wide, in both time and space, to many places where accessing the information in the bug database is awkward (e.g., if it's only available in the form of archived e-mails) if not simply impossible. The code is also going to wind up being read by many people who don't work in the same way that we Sun employees do, and who expect to see short change summaries accompanying the code. In this context, analyzing the question of what information belongs in changeset comments strictly in terms of information architecture, which frowns upon redundancy, is not the best approach. The primary consumers of this information are us humans, after all, not machines, so we should optimize for our productivity even if it means defining an imperfect information model. We humans are actually pretty good at dealing with redundancy and correcting for the occasional error that may creep into seemingly-redundant information, so it's hard to see how an imperfect model would really slow us down. This view may strike some existing Sun contributors as heretical; sorry. If a small change like this makes it easier for the downstream consumers of our code to make good use of it, and is more consistent with their working style, then the tiny effort required on our part is worthwhile. (I'll post an updated proposal in a moment.) - Mark From mr at sun.com Tue Dec 4 19:56:02 2007 From: mr at sun.com (Mark Reinhold) Date: Tue, 04 Dec 2007 11:56:02 -0800 Subject: Format for JDK 6/7 changeset comments? In-Reply-To: iris.clark@sun.com; Mon, 05 Nov 2007 22:16:54 PST; <200711060616.lA66GsOF022300@ribbit.SFBay.Sun.COM> Message-ID: <20071204195602.572D72783C7@eggemoggin.niobe.net> Here's a revised proposal that, I think, addresses all the issues that've been raised since this discussion started a few weeks ago. (Reminder: This proposal is only for the JDK 7 (and eventually JDK 6) code bases; others may adopt different conventions.) A single change is described by a block of text of the following form: : Summary: Reviewed-by: + Contributed-by: There can be more than one line, but there must be at least one. The summary line is optional, but authors are strongly encouraged to include one if the nature of the change is not obvious from the synopsis. It's just one line, meant to give the reader a clue as to how the code changed. A more complete description of the change belongs in the bug report. A reviewed-by line is required. Reviewers must have the ability to deal with any adverse consequences of the change, and so must themselves be authors. They're therefore identified by their OpenJDK usernames rather than full e-mail addresses. The contributed-by line is optional. There will be exceptions for merge changesets, tag changesets, etc. Example: 1234567: NPE thrown on FileInputStream("") Summary: Rewrite precondition-checking code in io.c Reviewed-by: mr Contributed-by: Ben Bitdiddle If a changeset contains multiple unrelated changes (this is frowned upon, but may happen from time to time) then its comment will contain multiple blocks of the above form, separated by blank lines. Other information that is often included in TeamWare putback comments is not appropriate for Mercurial changeset comments. This includes names of test cases run, links to webrevs, pre-integration test results, approvals from core release teams, etc. Most of this type of information belongs in the bug database, or possibly in ancillary databases (details TBD). (FYI for non-TeamWare users: TeamWare "putback comments" don't have a direct analogue in Mercurial. They're different from changeset comments; if Mercurial supported them then they'd be comments associated with a push operation.) Comments? - Mark From Kelly.Ohair at Sun.COM Tue Dec 4 21:25:52 2007 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Tue, 04 Dec 2007 13:25:52 -0800 Subject: Format for JDK 6/7 changeset comments? In-Reply-To: <20071204195602.572D72783C7@eggemoggin.niobe.net> References: <20071204195602.572D72783C7@eggemoggin.niobe.net> Message-ID: <4755C5E0.5030201@sun.com> I'm ok with this, a few minor questions: - Is a bugid any decimal integer, or is it a 7 digit number? - Will we check the bugid to make sure it's a valid bugid? - Does the synopsis have to match the synopsis in the bugtraq system? - How picky will we be on leading spaces on the line, or around the ':' character? - Can the Summary line be any length? - Should the reviewer name also be required to not be the changeset author? - Are multiple reviewer names blank or comma separated? - Any strict rules on the contributor email line? Company names ok? - Are tab characters allowed? ;^) -kto Mark Reinhold wrote: > Here's a revised proposal that, I think, addresses all the issues that've > been raised since this discussion started a few weeks ago. > > (Reminder: This proposal is only for the JDK 7 (and eventually JDK 6) > code bases; others may adopt different conventions.) > > A single change is described by a block of text of the following form: > > : > Summary: > Reviewed-by: + > Contributed-by: > > There can be more than one line, but there must be at least one. > > The summary line is optional, but authors are strongly encouraged to > include one if the nature of the change is not obvious from the synopsis. > It's just one line, meant to give the reader a clue as to how the code > changed. A more complete description of the change belongs in the bug > report. > > A reviewed-by line is required. Reviewers must have the ability to deal > with any adverse consequences of the change, and so must themselves be > authors. They're therefore identified by their OpenJDK usernames rather > than full e-mail addresses. > > The contributed-by line is optional. > > There will be exceptions for merge changesets, tag changesets, etc. > > Example: > > 1234567: NPE thrown on FileInputStream("") > Summary: Rewrite precondition-checking code in io.c > Reviewed-by: mr > Contributed-by: Ben Bitdiddle > > If a changeset contains multiple unrelated changes (this is frowned upon, > but may happen from time to time) then its comment will contain multiple > blocks of the above form, separated by blank lines. > > Other information that is often included in TeamWare putback comments is > not appropriate for Mercurial changeset comments. This includes names of > test cases run, links to webrevs, pre-integration test results, approvals > from core release teams, etc. Most of this type of information belongs > in the bug database, or possibly in ancillary databases (details TBD). > > (FYI for non-TeamWare users: TeamWare "putback comments" don't have > a direct analogue in Mercurial. They're different from changeset > comments; if Mercurial supported them then they'd be comments > associated with a push operation.) > > Comments? > > - Mark From mr at sun.com Tue Dec 4 21:49:52 2007 From: mr at sun.com (Mark Reinhold) Date: Tue, 04 Dec 2007 13:49:52 -0800 Subject: Format for JDK 6/7 changeset comments? In-Reply-To: kelly.ohair@sun.com; Tue, 04 Dec 2007 13:25:52 PST; <4755C5E0.5030201@sun.com> Message-ID: <20071204214952.4BF172783C7@eggemoggin.niobe.net> > Date: Tue, 04 Dec 2007 13:25:52 -0800 > From: kelly.ohair at sun.com > I'm ok with this, a few minor questions: > > - Is a bugid any decimal integer, or is it a 7 digit number? Seven digits, pointing into Sun's bug database, for now. > - Will we check the bugid to make sure it's a valid bugid? That requires doing a bug-database query which can, with the current system anyway, be kind of slow, and impossible if you're not connected. (We want the hg script that implements these checks to be usable by any developer creating changesets, so that changesets can be validated locally before being pushed up to group integration forests.) We could do this check just on the hg server side, or just when the machine running the check is actually connected. We could also, in the longer term, play various caching tricks to speed up the query. If we did do such a check it'd have limited value. It could only verify that the bugid is associated with the appropriate release, which is worth something I suppose but not as thorough a check as one might like, given the cost. So at the moment I'm leaning against checking bugids mechanically. > - Does the synopsis have to match the synopsis in the bugtraq system? It should, but I don't think it's worth checking mechanically. > - How picky will we be on leading spaces on the line, or around the ':' character? Picky. > - Can the Summary line be any length? Hmm, good question. I suppose we could limit it to prevent mistakes or abuse. 80 characters? 200? Or allow some number of continuation lines, as in e-mail headers, that start with whitespace? (That might be more readable.) > - Should the reviewer name also be required to not be the changeset author? Yep. > - Are multiple reviewer names blank or comma separated? Comma separated, just as in e-mail messages. > - Any strict rules on the contributor email line? Company names ok? Valid RFC-822 e-mail address for the contributor, which must be a specific individual. > - Are tab characters allowed? ;^) Heck no! (I'm shocked that you, of all people, would even ask.) - Mark From John.Coomes at sun.com Wed Dec 5 00:49:20 2007 From: John.Coomes at sun.com (John Coomes) Date: Tue, 4 Dec 2007 16:49:20 -0800 Subject: Format for JDK 6/7 changeset comments? In-Reply-To: <20071204214952.4BF172783C7@eggemoggin.niobe.net> References: <4755C5E0.5030201@sun.com> <20071204214952.4BF172783C7@eggemoggin.niobe.net> Message-ID: <18261.62864.307711.385597@sun.com> Mark Reinhold (mr at sun.com) wrote: > > Date: Tue, 04 Dec 2007 13:25:52 -0800 > > From: kelly.ohair at sun.com > ... > > - Will we check the bugid to make sure it's a valid bugid? > > That requires doing a bug-database query which can, with the current > system anyway, be kind of slow, and impossible if you're not connected. > (We want the hg script that implements these checks to be usable by any > developer creating changesets, so that changesets can be validated > locally before being pushed up to group integration forests.) > > We could do this check just on the hg server side, or just when the > machine running the check is actually connected. We could also, in the > longer term, play various caching tricks to speed up the query. > > If we did do such a check it'd have limited value. It could only verify > that the bugid is associated with the appropriate release, which is worth > something I suppose but not as thorough a check as one might like, given > the cost. > > So at the moment I'm leaning against checking bugids mechanically. Since our (currently internal-only) build automation tools go to a lot of trouble to automatically update the bug database, I think a basic sanity check is worthwhile. Even if it just catches typos initially, getting the bug numbers right will save time for integrators and those that have to do bug archaeology. Gracefully handling the non-connected state would be a nice addition. Personally I could live without it, certainly for a while. > > - Can the Summary line be any length? > > Hmm, good question. I suppose we could limit it to prevent mistakes or > abuse. 80 characters? 200? Or allow some number of continuation lines, > as in e-mail headers, that start with whitespace? (That might be more > readable.) I'd prefer to remove the temptation to create excessively long summary lines, so either a small limit or continuation lines. Please :-). -John From Xiomara.Jayasena at Sun.COM Wed Dec 5 06:15:35 2007 From: Xiomara.Jayasena at Sun.COM (Xiomara Jayasena) Date: Tue, 04 Dec 2007 22:15:35 -0800 Subject: Mercurial switch: JDK 7 build 24 is available at the openjdk.java.net website In-Reply-To: <47563FCC.4080907@sun.com> References: <47563FCC.4080907@sun.com> Message-ID: <47564207.2020606@sun.com> Hi, Note, this is the first build available under Mercurial. > Summary of changes: > http://download.java.net/jdk7/changes/jdk7-b24.html The file above is meant to have no changes in it as there were no code changes. The changes between build 23 and build 24 are the ones for the Mercurial transition. Thanks, -Xiomara Xiomara Jayasena wrote: > > The OpenJDK source is available at: > http://hg.openjdk.java.net/jdk7/jdk7 > and the build 24 source is here: > http://hg.openjdk.java.net/jdk7/jdk7/rev/0a5c5386a678 > > The OpenJDK source binary plugs and Jtreg binary for the promoted JDK > 7 build 24 are available under the openjdk http://openjdk.java.net > website under Source Code (direct link to bundles: > http://download.java.net/openjdk/jdk7) > > Summary of changes: > http://download.java.net/jdk7/changes/jdk7-b24.html > > Thanks, > -Xiomara From Jeannette.Hung at Sun.COM Wed Dec 5 06:37:37 2007 From: Jeannette.Hung at Sun.COM (Jeannette Hung) Date: Tue, 04 Dec 2007 22:37:37 -0800 Subject: Format for JDK 6/7 changeset comments? In-Reply-To: <20071204195602.572D72783C7@eggemoggin.niobe.net> References: <20071204195602.572D72783C7@eggemoggin.niobe.net> Message-ID: <47564731.2050705@sun.com> Perhaps I'm behind on the overall discussion but why is: > Other information that is often included in TeamWare putback comments is > not appropriate for Mercurial changeset comments. This includes names of > test cases run, links to webrevs, pre-integration test results, approvals > from core release teams, etc. Most of this type of information belongs > in the bug database, or possibly in ancillary databases (details TBD). not appropriate? I really like seeing that information so it is obvious what has been done to verify the fix. I understand that it may not be useful to everyone, but if it can be useful, why restrict this information from being here? Or is this more a matter of what is required vs optional? jeannette Mark Reinhold wrote: > Here's a revised proposal that, I think, addresses all the issues that've > been raised since this discussion started a few weeks ago. > > (Reminder: This proposal is only for the JDK 7 (and eventually JDK 6) > code bases; others may adopt different conventions.) > > A single change is described by a block of text of the following form: > > : > Summary: > Reviewed-by: + > Contributed-by: > > There can be more than one line, but there must be at least one. > > The summary line is optional, but authors are strongly encouraged to > include one if the nature of the change is not obvious from the synopsis. > It's just one line, meant to give the reader a clue as to how the code > changed. A more complete description of the change belongs in the bug > report. > > A reviewed-by line is required. Reviewers must have the ability to deal > with any adverse consequences of the change, and so must themselves be > authors. They're therefore identified by their OpenJDK usernames rather > than full e-mail addresses. > > The contributed-by line is optional. > > There will be exceptions for merge changesets, tag changesets, etc. > > Example: > > 1234567: NPE thrown on FileInputStream("") > Summary: Rewrite precondition-checking code in io.c > Reviewed-by: mr > Contributed-by: Ben Bitdiddle > > If a changeset contains multiple unrelated changes (this is frowned upon, > but may happen from time to time) then its comment will contain multiple > blocks of the above form, separated by blank lines. > > Other information that is often included in TeamWare putback comments is > not appropriate for Mercurial changeset comments. This includes names of > test cases run, links to webrevs, pre-integration test results, approvals > from core release teams, etc. Most of this type of information belongs > in the bug database, or possibly in ancillary databases (details TBD). > > (FYI for non-TeamWare users: TeamWare "putback comments" don't have > a direct analogue in Mercurial. They're different from changeset > comments; if Mercurial supported them then they'd be comments > associated with a push operation.) > > Comments? > > - Mark From martin.simbartl at gmail.com Wed Dec 5 14:27:43 2007 From: martin.simbartl at gmail.com (Martin Simbartl) Date: Wed, 5 Dec 2007 15:27:43 +0100 Subject: JDK 7 build 24 is available at the openjdk.java.net website In-Reply-To: <47563FCC.4080907@sun.com> References: <47563FCC.4080907@sun.com> Message-ID: <109d32980712050627l1af4b87en9ff13569a3e3e608@mail.gmail.com> Hello, On Dec 5, 2007 7:06 AM, Xiomara Jayasena wrote: > > The OpenJDK source is available at: > http://hg.openjdk.java.net/jdk7/jdk7 > and the build 24 source is here: > http://hg.openjdk.java.net/jdk7/jdk7/rev/0a5c5386a678 > > The OpenJDK source binary plugs and Jtreg binary for the promoted JDK 7 > build 24 are available under the openjdk http://openjdk.java.net website > under Source Code (direct link to bundles: > http://download.java.net/openjdk/jdk7) > > Summary of changes: > http://download.java.net/jdk7/changes/jdk7-b24.html Is it just me or there is nothing there? Looks like something is broken, or maybe b24 didn't bring any changes. :) > > Thanks, > -Xiomara > -- Martin Simbartl From Weijun.Wang at Sun.COM Wed Dec 5 14:33:08 2007 From: Weijun.Wang at Sun.COM (Max (Weijun) Wang) Date: Wed, 05 Dec 2007 22:33:08 +0800 Subject: JDK 7 build 24 is available at the openjdk.java.net website In-Reply-To: <109d32980712050627l1af4b87en9ff13569a3e3e608@mail.gmail.com> References: <47563FCC.4080907@sun.com> <109d32980712050627l1af4b87en9ff13569a3e3e608@mail.gmail.com> Message-ID: b24 and b23 have no difference at source code level, it's only the Mercurial switch. Max On Dec 5, 2007, at 10:27 PM, Martin Simbartl wrote: > Hello, > > On Dec 5, 2007 7:06 AM, Xiomara Jayasena > wrote: >> >> The OpenJDK source is available at: >> http://hg.openjdk.java.net/jdk7/jdk7 >> and the build 24 source is here: >> http://hg.openjdk.java.net/jdk7/jdk7/rev/0a5c5386a678 >> >> The OpenJDK source binary plugs and Jtreg binary for the promoted >> JDK 7 >> build 24 are available under the openjdk http://openjdk.java.net >> website >> under Source Code (direct link to bundles: >> http://download.java.net/openjdk/jdk7) >> >> Summary of changes: >> http://download.java.net/jdk7/changes/jdk7-b24.html > > Is it just me or there is nothing there? Looks like something is > broken, or maybe b24 didn't bring any changes. :) > > >> >> Thanks, >> -Xiomara >> > > > > -- > Martin Simbartl From Kelly.Ohair at Sun.COM Wed Dec 5 16:14:33 2007 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Wed, 05 Dec 2007 08:14:33 -0800 Subject: Format for JDK 6/7 changeset comments? In-Reply-To: <47564731.2050705@sun.com> References: <20071204195602.572D72783C7@eggemoggin.niobe.net> <47564731.2050705@sun.com> Message-ID: <4756CE69.6070506@sun.com> With Mercurial the changeset defines the webrev, so no need to store one or refer to one. The 'not appropriate' applies to approvals, certificates and data that relate more to the release procedure than the code itself. Teamware putback comments were not managed data like SCCS comments, so if you considered them permanent, they were not. With Mercurial, changeset comments is managed data and also the only comment. Effectively we need to try and separate the management of the source base with the management of the release. -kto Jeannette Hung wrote: > Perhaps I'm behind on the overall discussion but why is: > > > Other information that is often included in TeamWare putback comments is > > not appropriate for Mercurial changeset comments. This includes > names of > > test cases run, links to webrevs, pre-integration test results, > approvals > > from core release teams, etc. Most of this type of information belongs > > in the bug database, or possibly in ancillary databases (details TBD). > > not appropriate? I really like seeing that information so it is obvious > what has been done to verify the fix. I understand that it may not be > useful to everyone, but if it can be useful, why restrict this > information from being here? Or is this more a matter of what is > required vs optional? > > jeannette > > Mark Reinhold wrote: >> Here's a revised proposal that, I think, addresses all the issues that've >> been raised since this discussion started a few weeks ago. >> >> (Reminder: This proposal is only for the JDK 7 (and eventually JDK 6) >> code bases; others may adopt different conventions.) >> >> A single change is described by a block of text of the following form: >> >> : >> Summary: >> Reviewed-by: + >> Contributed-by: >> >> There can be more than one line, but there must be at least one. >> >> The summary line is optional, but authors are strongly encouraged to >> include one if the nature of the change is not obvious from the synopsis. >> It's just one line, meant to give the reader a clue as to how the code >> changed. A more complete description of the change belongs in the bug >> report. >> >> A reviewed-by line is required. Reviewers must have the ability to deal >> with any adverse consequences of the change, and so must themselves be >> authors. They're therefore identified by their OpenJDK usernames rather >> than full e-mail addresses. >> >> The contributed-by line is optional. >> >> There will be exceptions for merge changesets, tag changesets, etc. >> >> Example: >> >> 1234567: NPE thrown on FileInputStream("") >> Summary: Rewrite precondition-checking code in io.c >> Reviewed-by: mr >> Contributed-by: Ben Bitdiddle >> >> If a changeset contains multiple unrelated changes (this is frowned upon, >> but may happen from time to time) then its comment will contain multiple >> blocks of the above form, separated by blank lines. >> >> Other information that is often included in TeamWare putback comments is >> not appropriate for Mercurial changeset comments. This includes names of >> test cases run, links to webrevs, pre-integration test results, approvals >> from core release teams, etc. Most of this type of information belongs >> in the bug database, or possibly in ancillary databases (details TBD). >> >> (FYI for non-TeamWare users: TeamWare "putback comments" don't have >> a direct analogue in Mercurial. They're different from changeset >> comments; if Mercurial supported them then they'd be comments >> associated with a push operation.) >> >> Comments? >> >> - Mark From Xiomara.Jayasena at Sun.COM Wed Dec 5 17:20:15 2007 From: Xiomara.Jayasena at Sun.COM (Xiomara Jayasena) Date: Wed, 05 Dec 2007 09:20:15 -0800 Subject: JDK 7 build 24 is available at the openjdk.java.net website In-Reply-To: <109d32980712050627l1af4b87en9ff13569a3e3e608@mail.gmail.com> References: <47563FCC.4080907@sun.com> <109d32980712050627l1af4b87en9ff13569a3e3e608@mail.gmail.com> Message-ID: <4756DDCF.1040801@sun.com> Martin Simbartl wrote: >> Summary of changes: >> http://download.java.net/jdk7/changes/jdk7-b24.html >> > > Is it just me or there is nothing there? Looks like something is > broken, or maybe b24 didn't bring any changes. :) > There were no code changes. See attached e-mail ;-) -Xiomara -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded message was scrubbed... From: Xiomara Jayasena Subject: Mercurial switch: JDK 7 build 24 is available at the openjdk.java.net website Date: Tue, 04 Dec 2007 22:15:35 -0800 Size: 1526 URL: From ernst.matthias at gmail.com Wed Dec 5 18:40:58 2007 From: ernst.matthias at gmail.com (Matthias Ernst) Date: Wed, 5 Dec 2007 19:40:58 +0100 Subject: JDK 7 build 24 is available at the openjdk.java.net website In-Reply-To: <109d32980712050627l1af4b87en9ff13569a3e3e608@mail.gmail.com> References: <47563FCC.4080907@sun.com> <109d32980712050627l1af4b87en9ff13569a3e3e608@mail.gmail.com> Message-ID: <22ec15240712051040u54f148cem26c6362a6365bddc@mail.gmail.com> Martin, did you use 'fclone' ? I did an 'hg clone' this morning and all I got was a "sad" set of Makefiles. Only just now I realized I need to study Kelly's blog again: http://blogs.sun.com/kto/ Matthias On Dec 5, 2007 3:27 PM, Martin Simbartl wrote: > Hello, > > On Dec 5, 2007 7:06 AM, Xiomara Jayasena wrote: > > > > The OpenJDK source is available at: > > http://hg.openjdk.java.net/jdk7/jdk7 > > and the build 24 source is here: > > http://hg.openjdk.java.net/jdk7/jdk7/rev/0a5c5386a678 > > > > The OpenJDK source binary plugs and Jtreg binary for the promoted JDK 7 > > build 24 are available under the openjdk http://openjdk.java.net website > > under Source Code (direct link to bundles: > > http://download.java.net/openjdk/jdk7) > > > > Summary of changes: > > http://download.java.net/jdk7/changes/jdk7-b24.html > > Is it just me or there is nothing there? Looks like something is > broken, or maybe b24 didn't bring any changes. :) > > > > > > Thanks, > > -Xiomara > > > > > > -- > Martin Simbartl > From Xiomara.Jayasena at Sun.COM Wed Dec 5 18:54:30 2007 From: Xiomara.Jayasena at Sun.COM (Xiomara.Jayasena at Sun.COM) Date: Wed, 05 Dec 2007 10:54:30 -0800 Subject: JDK 7 build 24 is available at the openjdk.java.net website In-Reply-To: <22ec15240712051040u54f148cem26c6362a6365bddc@mail.gmail.com> References: <47563FCC.4080907@sun.com> <109d32980712050627l1af4b87en9ff13569a3e3e608@mail.gmail.com> <22ec15240712051040u54f148cem26c6362a6365bddc@mail.gmail.com> Message-ID: <4756F3E6.8070804@Sun.COM> Matthias, I understood that Martin was talking about the actual summary of changes files. I believe what you are looking for is to do an hg fclone of this: http://hg.openjdk.java.net/jdk7/jdk7/rev/0a5c5386a678 Kelly's blog is of course a great reference. -Xiomara Matthias Ernst wrote: >Martin, > >did you use 'fclone' ? I did an 'hg clone' this morning and all I got >was a "sad" set of Makefiles. >Only just now I realized I need to study Kelly's blog again: >http://blogs.sun.com/kto/ > >Matthias > > >On Dec 5, 2007 3:27 PM, Martin Simbartl wrote: > > >>Hello, >> >>On Dec 5, 2007 7:06 AM, Xiomara Jayasena wrote: >> >> >>>The OpenJDK source is available at: >>>http://hg.openjdk.java.net/jdk7/jdk7 >>>and the build 24 source is here: >>>http://hg.openjdk.java.net/jdk7/jdk7/rev/0a5c5386a678 >>> >>>The OpenJDK source binary plugs and Jtreg binary for the promoted JDK 7 >>>build 24 are available under the openjdk http://openjdk.java.net website >>>under Source Code (direct link to bundles: >>>http://download.java.net/openjdk/jdk7) >>> >>>Summary of changes: >>>http://download.java.net/jdk7/changes/jdk7-b24.html >>> >>> >>Is it just me or there is nothing there? Looks like something is >>broken, or maybe b24 didn't bring any changes. :) >> >> >> >> >>>Thanks, >>>-Xiomara >>> >>> >>> >> >>-- >>Martin Simbartl >> >> >> From ernst.matthias at gmail.com Wed Dec 5 20:10:40 2007 From: ernst.matthias at gmail.com (Matthias Ernst) Date: Wed, 5 Dec 2007 21:10:40 +0100 Subject: JDK 7 build 24 is available at the openjdk.java.net website In-Reply-To: <4756F3E6.8070804@Sun.COM> References: <47563FCC.4080907@sun.com> <109d32980712050627l1af4b87en9ff13569a3e3e608@mail.gmail.com> <22ec15240712051040u54f148cem26c6362a6365bddc@mail.gmail.com> <4756F3E6.8070804@Sun.COM> Message-ID: <22ec15240712051210g58265417t7fbc5213746a9860@mail.gmail.com> > Matthias, > > I understood that Martin was talking about the actual summary of changes > files. > I believe what you are looking for is to do an hg fclone of this: > > http://hg.openjdk.java.net/jdk7/jdk7/rev/0a5c5386a678 I probably projected my problem onto Martin. What I want to point out is that the difference between "clone" and "fclone" is a subtle one that is not immediately obvious. Now I'm gonna go and learn about forests. Matthias From mr at sun.com Wed Dec 5 20:48:48 2007 From: mr at sun.com (Mark Reinhold) Date: Wed, 05 Dec 2007 12:48:48 -0800 Subject: Format for JDK 6/7 changeset comments? In-Reply-To: kelly.ohair@sun.com; Wed, 05 Dec 2007 08:14:33 PST; <4756CE69.6070506@sun.com> Message-ID: <20071205204849.54A792783C7@eggemoggin.niobe.net> > Date: Wed, 05 Dec 2007 08:14:33 -0800 > From: kelly.ohair at sun.com > ... > > Effectively we need to try and separate the management of the source > base with the management of the release. Right. Put another way, we need to separate the code itself from the process by which the code is created and modified. Ten -- or even five -- years from now nobody will care about the kinds of release-management details that are currently published in TeamWare putback comments. Much of that information is ephemeral anyway; it may link to online documents that aren't guaranteed to exist in five years, or it may refer to test hardware or processes that are constantly changing. What people looking at the Mercurial repositories will care about is the code, and the changes made to it, and who made which changes and why. It's not that release-management information isn't important; it's just that it doesn't belong in the code. - Mark From martin.simbartl at gmail.com Wed Dec 5 20:59:25 2007 From: martin.simbartl at gmail.com (Martin Simbartl) Date: Wed, 5 Dec 2007 21:59:25 +0100 Subject: Fwd: JDK 7 build 24 is available at the openjdk.java.net website In-Reply-To: <109d32980712051247k530bfaa2tac82da77bc64fb62@mail.gmail.com> References: <47563FCC.4080907@sun.com> <109d32980712050627l1af4b87en9ff13569a3e3e608@mail.gmail.com> <22ec15240712051040u54f148cem26c6362a6365bddc@mail.gmail.com> <4756F3E6.8070804@Sun.COM> <109d32980712051247k530bfaa2tac82da77bc64fb62@mail.gmail.com> Message-ID: <109d32980712051259n37c9ea17rd0da4ff7742fdf7e@mail.gmail.com> It looks like I sent this email only to Xiomara. If someone will receive this message more times I do apologize. :) Martin ---------- Forwarded message ---------- From: Martin Simbartl Date: Dec 5, 2007 9:47 PM Subject: Re: JDK 7 build 24 is available at the openjdk.java.net website To: Xiomara.Jayasena at sun.com Hi, On Dec 5, 2007 7:54 PM, wrote: > > Matthias, > > I understood that Martin was talking about the actual summary of changes > files. Yes, I was talking about the summary of changes -- http://download.java.net/jdk7/changes/jdk7-b24.html. I was confused that there are now changes there. I read through Kelly's blog and everything is clear now. fclone worked fine for me. At least I hope so. I haven't build the source yet. Matthias, forest is an extension to Mercurial. Here is what I did to install it: * get forest.py from Mercurial repository $ hg clone http://hg.akoha.org/hgforest hgforest * copy forest.py to Mercurial's extension directory--for me on Ubuntu Gutsy it's /usr/share/python-support/mercurial/hgext * create the following symlink $ ln -s /usr/share/python-support/mercurial/hgext/forest.py /var/lib/python-support/python2.5/hgext/forest.py Note: I found two hgext directories on my system and it turned out that hg is actually looking for extensions in /var/lib/python-support/python2.5/hgext. But this directory contains only symlinks to /usr/share/python-support/mercurial/hgex, so I also created one for forest.py. * and enable the forest extension in Mercurial's configuration file--for me it's /etc/mercurial/hgrc.d/hgext.rc--by adding the following line: [extensions] # forest hgext/forest= After that fclone should work. See http://www.selenic.com/mercurial/wiki/index.cgi/ForestExtension for more information. Martin > I believe what you are looking for is to do an hg fclone of this: > > http://hg.openjdk.java.net/jdk7/jdk7/rev/0a5c5386a678 > > > Kelly's blog is of course a great reference. > > -Xiomara > > > Matthias Ernst wrote: > > >Martin, > > > >did you use 'fclone' ? I did an 'hg clone' this morning and all I got > >was a "sad" set of Makefiles. > >Only just now I realized I need to study Kelly's blog again: > >http://blogs.sun.com/kto/ > > > >Matthias > > > > > >On Dec 5, 2007 3:27 PM, Martin Simbartl wrote: > > > > > >>Hello, > >> > >>On Dec 5, 2007 7:06 AM, Xiomara Jayasena wrote: > >> > >> > >>>The OpenJDK source is available at: > >>>http://hg.openjdk.java.net/jdk7/jdk7 > >>>and the build 24 source is here: > >>>http://hg.openjdk.java.net/jdk7/jdk7/rev/0a5c5386a678 > >>> > >>>The OpenJDK source binary plugs and Jtreg binary for the promoted JDK 7 > >>>build 24 are available under the openjdk http://openjdk.java.net website > >>>under Source Code (direct link to bundles: > >>>http://download.java.net/openjdk/jdk7) > >>> > >>>Summary of changes: > >>>http://download.java.net/jdk7/changes/jdk7-b24.html > >>> > >>> > >>Is it just me or there is nothing there? Looks like something is > >>broken, or maybe b24 didn't bring any changes. :) > >> > >> > >> > >> > >>>Thanks, > >>>-Xiomara > >>> > >>> > >>> > >> > >>-- > >>Martin Simbartl > >> > >> > >> > > From neojia at gmail.com Wed Dec 5 21:02:27 2007 From: neojia at gmail.com (Neo Jia) Date: Wed, 5 Dec 2007 13:02:27 -0800 Subject: JDK 7 build 24 is available at the openjdk.java.net website In-Reply-To: <47563FCC.4080907@sun.com> References: <47563FCC.4080907@sun.com> Message-ID: <5d649bdb0712051302t8783a59vf69acaa8a24a5eec@mail.gmail.com> Can we still use the following command to clone? > hg fclone http://hg.openjdk.java.net/jdk7/MASTER abort: Remote forests cannot be cloned because the other repository doesn't support the forest extension. Thanks, Neo On Dec 4, 2007 10:06 PM, Xiomara Jayasena wrote: > > The OpenJDK source is available at: > http://hg.openjdk.java.net/jdk7/jdk7 > and the build 24 source is here: > http://hg.openjdk.java.net/jdk7/jdk7/rev/0a5c5386a678 > > The OpenJDK source binary plugs and Jtreg binary for the promoted JDK 7 > build 24 are available under the openjdk http://openjdk.java.net website > under Source Code (direct link to bundles: > http://download.java.net/openjdk/jdk7) > > Summary of changes: > http://download.java.net/jdk7/changes/jdk7-b24.html > > Thanks, > -Xiomara > -- I would remember that if researchers were not ambitious probably today we haven't the technology we are using! From mr at sun.com Wed Dec 5 21:29:09 2007 From: mr at sun.com (Mark Reinhold) Date: Wed, 05 Dec 2007 13:29:09 -0800 Subject: JDK 7 build 24 is available at the openjdk.java.net website In-Reply-To: neojia@gmail.com; Wed, 05 Dec 2007 13:02:27 PST; <5d649bdb0712051302t8783a59vf69acaa8a24a5eec@mail.gmail.com> Message-ID: <20071205212909.BDA672783C7@eggemoggin.niobe.net> > Date: Wed, 05 Dec 2007 13:02:27 -0800 > From: Neo Jia > Can we still use the following command to clone? > >> hg fclone http://hg.openjdk.java.net/jdk7/MASTER > abort: Remote forests cannot be cloned because the other repository > doesn't support the forest extension. No, try this: % hg fclone http://hg.openjdk.java.net/jdk7/jdk7 (We renamed MASTER to jdk7 a couple weeks ago.) - Mark From Xiomara.Jayasena at Sun.COM Wed Dec 5 21:30:38 2007 From: Xiomara.Jayasena at Sun.COM (Xiomara.Jayasena at Sun.COM) Date: Wed, 05 Dec 2007 13:30:38 -0800 Subject: JDK 7 build 24 is available at the openjdk.java.net website In-Reply-To: <5d649bdb0712051302t8783a59vf69acaa8a24a5eec@mail.gmail.com> References: <47563FCC.4080907@sun.com> <5d649bdb0712051302t8783a59vf69acaa8a24a5eec@mail.gmail.com> Message-ID: <4757187E.7070105@Sun.COM> Neo Jia wrote: >Can we still use the following command to clone? > > > >>hg fclone http://hg.openjdk.java.net/jdk7/MASTER >> >> >abort: Remote forests cannot be cloned because the other repository >doesn't support the forest extension. > > That location is no longer supported and it was moved to the location below. Use hg fclone http://hg.openjdk.java.net/jdk7/jdk7 myjdk7 instead. -Xiomara >Thanks, >Neo > >On Dec 4, 2007 10:06 PM, Xiomara Jayasena wrote: > > >>The OpenJDK source is available at: >>http://hg.openjdk.java.net/jdk7/jdk7 >>and the build 24 source is here: >>http://hg.openjdk.java.net/jdk7/jdk7/rev/0a5c5386a678 >> >>The OpenJDK source binary plugs and Jtreg binary for the promoted JDK 7 >>build 24 are available under the openjdk http://openjdk.java.net website >>under Source Code (direct link to bundles: >>http://download.java.net/openjdk/jdk7) >> >>Summary of changes: >>http://download.java.net/jdk7/changes/jdk7-b24.html >> >>Thanks, >>-Xiomara >> >> >> > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From geir at pobox.com Wed Dec 5 22:24:11 2007 From: geir at pobox.com (Geir Magnusson Jr.) Date: Wed, 5 Dec 2007 17:24:11 -0500 Subject: Project proposal: JDK 7 In-Reply-To: <20071205214959.0438B2783C7@eggemoggin.niobe.net> References: <20071205214959.0438B2783C7@eggemoggin.niobe.net> Message-ID: Shouldn't you be doing JDK 7 in the JCP? geir On Dec 5, 2007, at 4:49 PM, Mark Reinhold wrote: > I hereby propose the creation of a new Project, JDK 7, whose primary > goal will be to produce an open-source implementation of the next > major > revision of the Java SE Platform. > > This project will host the JDK 7 Mercurial repositories, which were > made > available yesterday. Over time, as more of the JDK development > process > moves out into the open, additional information such as integration > and > build schedules, milestone definitions and dates, and development > tasks > and status will be made available. Proposals for specific features > will > also be welcome. > > I will serve as the initial Moderator of this Project. > > - Mark From mr at sun.com Wed Dec 5 22:57:41 2007 From: mr at sun.com (Mark Reinhold) Date: Wed, 05 Dec 2007 14:57:41 -0800 Subject: Project proposal: JDK 7 In-Reply-To: geir@pobox.com; Wed, 05 Dec 2007 17:24:11 EST; Message-ID: <20071205225741.3FC022783C7@eggemoggin.niobe.net> > Date: Wed, 05 Dec 2007 17:24:11 -0500 > From: "Geir Magnusson Jr." > Shouldn't you be doing JDK 7 in the JCP? Hi Geir. I think you know the answer to that question. The JCP defines the Java SE Platform with a specification, a TCK, and a reference implementation (RI). The JDK is an implementation of that specification, and is meant to pass the TCK and serve as the RI. There is not yet a Platform JSR for Java SE 7, so in the meantime the work done in this Project may be considered a first draft of some features and enhancements that will be proposed for inclusion in that JSR. - Mark From geir at pobox.com Wed Dec 5 23:03:20 2007 From: geir at pobox.com (Geir Magnusson Jr.) Date: Wed, 5 Dec 2007 18:03:20 -0500 Subject: Project proposal: JDK 7 In-Reply-To: <20071205225741.3FC022783C7@eggemoggin.niobe.net> References: <20071205225741.3FC022783C7@eggemoggin.niobe.net> Message-ID: <6CF9E9E5-FE9A-4572-AE95-F6D8B9C6393F@pobox.com> On Dec 5, 2007, at 5:57 PM, Mark Reinhold wrote: >> Date: Wed, 05 Dec 2007 17:24:11 -0500 >> From: "Geir Magnusson Jr." > >> Shouldn't you be doing JDK 7 in the JCP? > > Hi Geir. > > I think you know the answer to that question. As do you :) There is no JSR for Java SE 7. I guess I was confused - I thought you were suggesting that this was Java 7. > > > The JCP defines the Java SE Platform with a specification, a TCK, > and a reference implementation (RI). > > The JDK is an implementation of that specification, and is meant > to pass the TCK and serve as the RI. > > There is not yet a Platform JSR for Java SE 7, so in the meantime > the work done in this Project may be considered a first draft of > some features and enhancements that will be proposed for inclusion > in that JSR. Exactly. I was just confused, and concerned that people might accidentally confuse your project with Java SE 7, the spec. I think it's important that Java still evolves in the JCP.... geir From mr at sun.com Wed Dec 5 23:09:01 2007 From: mr at sun.com (Mark Reinhold) Date: Wed, 05 Dec 2007 15:09:01 -0800 Subject: Project proposal: JDK 7 In-Reply-To: geir@pobox.com; Wed, 05 Dec 2007 18:03:20 EST; <6CF9E9E5-FE9A-4572-AE95-F6D8B9C6393F@pobox.com> Message-ID: <20071205230901.70DCD2783C7@eggemoggin.niobe.net> > Date: Wed, 05 Dec 2007 18:03:20 -0500 > From: "Geir Magnusson Jr." > On Dec 5, 2007, at 5:57 PM, Mark Reinhold wrote: >> I think you know the answer to that question. > > As do you :) There is no JSR for Java SE 7. I guess I was confused - > I thought you were suggesting that this was Java 7. Not in the least, but I'm glad for the opportunity to make this clear. >> .. >> >> There is not yet a Platform JSR for Java SE 7, so in the meantime >> the work done in this Project may be considered a first draft of >> some features and enhancements that will be proposed for inclusion >> in that JSR. > > Exactly. > > I was just confused, and concerned that people might accidentally > confuse your project with Java SE 7, the spec. I think it's important > that Java still evolves in the JCP.... I completely agree. - Mark From jesse.glick at sun.com Thu Dec 6 00:55:01 2007 From: jesse.glick at sun.com (Jesse Glick) Date: Wed, 05 Dec 2007 19:55:01 -0500 Subject: Mercurial switch: JDK 7 build 24 is available at the openjdk.java.net website In-Reply-To: <47564207.2020606@sun.com> References: <47563FCC.4080907@sun.com> <47564207.2020606@sun.com> Message-ID: Xiomara Jayasena wrote: > The OpenJDK source is available at: > http://hg.openjdk.java.net/jdk7/jdk7 Congratulations! When I look at the index page http://hg.openjdk.java.net/ I still see the warning "These repositories are EXPERIMENTAL..." which I guess is obsolete and the server maintainer simply forgot to delete it? -- jesse.glick at sun.com netbeans.org ant.apache.org hudson.dev.java.net http://google.com/search?q=e%5E%28pi*i%29%2B1 From Xiomara.Jayasena at Sun.COM Thu Dec 6 01:52:46 2007 From: Xiomara.Jayasena at Sun.COM (Xiomara Jayasena) Date: Wed, 05 Dec 2007 17:52:46 -0800 Subject: Mercurial switch: JDK 7 build 24 is available at the openjdk.java.net website In-Reply-To: References: <47563FCC.4080907@sun.com> <47564207.2020606@sun.com> Message-ID: <475755EE.6010003@sun.com> Jesse Glick wrote: > Xiomara Jayasena wrote: >> The OpenJDK source is available at: >> http://hg.openjdk.java.net/jdk7/jdk7 > > Congratulations! On behalf of our team -- Thank you! > > When I look at the index page > > http://hg.openjdk.java.net/ > > I still see the warning > > "These repositories are EXPERIMENTAL..." > > which I guess is obsolete and the server maintainer simply forgot to > delete it? Sorry about that still being there... only the master repository is in "live" mode at this point. The update of the group integration forests is coming soon. With the mercurial transition many tasks need to get done and that is one of them in the queue. -Xiomara From robilad at kaffe.org Thu Dec 6 09:14:39 2007 From: robilad at kaffe.org (Dalibor Topic) Date: Thu, 06 Dec 2007 10:14:39 +0100 Subject: Project proposal: JDK 7 In-Reply-To: <20071205214959.0438B2783C7@eggemoggin.niobe.net> References: <20071205214959.0438B2783C7@eggemoggin.niobe.net> Message-ID: <4757BD7F.8010501@kaffe.org> Mark Reinhold wrote: > I hereby propose the creation of a new Project, JDK 7, whose primary > goal will be to produce an open-source implementation of the next major > revision of the Java SE Platform. > That's a very nice project proposal, and I hope it finds approval. cheers, dalibor topic From robilad at kaffe.org Thu Dec 6 09:26:50 2007 From: robilad at kaffe.org (Dalibor Topic) Date: Thu, 06 Dec 2007 10:26:50 +0100 Subject: Project proposal: JDK 7 In-Reply-To: <20071205230901.70DCD2783C7@eggemoggin.niobe.net> References: <20071205230901.70DCD2783C7@eggemoggin.niobe.net> Message-ID: <4757C05A.4050408@kaffe.org> Mark Reinhold wrote: >> I was just confused, and concerned that people might accidentally >> confuse your project with Java SE 7, the spec. I think it's important >> that Java still evolves in the JCP.... >> > > I completely agree. > Me too. I'm looking forward to joining the JCP together with other Free Software developers in order to participate in the evolution of Java and the JCP directly. cheers, dalibor topic From robilad at kaffe.org Thu Dec 6 09:39:29 2007 From: robilad at kaffe.org (Dalibor Topic) Date: Thu, 06 Dec 2007 10:39:29 +0100 Subject: Jalimo @ FOSDEM 'Free Java Meeting' In-Reply-To: <474AF418.3040501@sun.com> References: <47460D98.9020103@gmx.net> <474AF418.3040501@sun.com> Message-ID: <4757C351.6080302@kaffe.org> Tom Marble wrote: > Robert Schuster wrote: > >> I have seen the request to participate with a talk at the 'Free Java >> Meeting' at FOSDEM'08[0]. I would like to do so and present JaLiMo which >> is a project which aims to bring a Java(-like) environment to >> Linux-based Mobile devices (hence the name :) ). Mobile in the sense of >> mobile phones, PDAs and internet tablets/UMPC. >> [...] every other distribution can benefit from our work, >> too. Oh, yes: Everything is free and open-source software. :) >> > > This sounds like a great idea! We will have representation from our > own phoneME team so having a part of the agenda on mobile open source Java > makes sense. I see you are already on the wiki.... As we get closer > (and, of course, assuming we get formal approval for our DevRoom today :) ) > we will try to schedule talks into specific time slots. > I've added the Jalimo talk proposal to the wiki, and added a talk proposal by me on the JCP. cheers, dalibor topic From mark at klomp.org Thu Dec 6 11:42:47 2007 From: mark at klomp.org (Mark Wielaard) Date: Thu, 06 Dec 2007 12:42:47 +0100 Subject: Project proposal: JDK 7 In-Reply-To: <4757C05A.4050408@kaffe.org> References: <20071205230901.70DCD2783C7@eggemoggin.niobe.net> <4757C05A.4050408@kaffe.org> Message-ID: <1196941367.3065.8.camel@dijkstra.wildebeest.org> Hi Dalibor, On Thu, 2007-12-06 at 10:26 +0100, Dalibor Topic wrote: > Mark Reinhold wrote: > >> I was just confused, and concerned that people might accidentally > >> confuse your project with Java SE 7, the spec. I think it's important > >> that Java still evolves in the JCP.... > > > > I completely agree. > > > Me too. I'm looking forward to joining the JCP together with other Free > Software developers > in order to participate in the evolution of Java and the JCP directly. Interesting you bring this up Dalibor. If there was a way to make sure participation in the JCP would mean that JSR implementations and proposals would be available under a free license and discussions around them were done in the open (for example as part of OpenJDK) then it would be interesting. But currently the JCP seems to be setup mainly for large entities that want to keep NDAs around their discussions and not share till it is perfect and done. And even then there doesn't seem to be any promise that the results will be free software, or even implementable in a free software environment without the implementers being bound by FOU restrictions or even simple sub and super setting the implementation - something which a free license should always allow its users. So I don't think that the JCP is a very appealing working environment for Free Software developers. Do you have an idea how to improve this? Cheers, Mark From robilad at kaffe.org Thu Dec 6 13:19:59 2007 From: robilad at kaffe.org (Dalibor Topic) Date: Thu, 06 Dec 2007 14:19:59 +0100 Subject: Project proposal: JDK 7 In-Reply-To: <1196941367.3065.8.camel@dijkstra.wildebeest.org> References: <20071205230901.70DCD2783C7@eggemoggin.niobe.net> <4757C05A.4050408@kaffe.org> <1196941367.3065.8.camel@dijkstra.wildebeest.org> Message-ID: <4757F6FF.9020101@kaffe.org> Mark Wielaard wrote: > So I don't think that the JCP is a very appealing working environment > for Free Software developers. Do you have an idea how to improve this? > We've discussed various approaches to improving the JCP for Free Software developers within the GNU Classpath community over the past couple of years, but unfortunately, we didn't find sufficient enthusiasm across the JCP's existing structures for the necessary reforms. Since the Java platform itself wasn't Free Software, we correctly focused on fixing that problem first, as it directly affected everyone in the Free Software community, rather than the problems that mostly affected us as independent implementors.[1] So, with the reference implementation becoming Free Software, the primary problem is pretty much fixed. Now, I believe, is a good time to start thinking how to go about improving the JCP such that it becomes an appealing working environment for Free Software developers. My roadmap looks a bit like this: * I'm very curious about Patrick Curran's session at JavaPolis[2] on the JCP. I'd like to learn more about how the JCP works internally, in order to understand how to efficiently patch it without regressions. My impression from discussions with various JCP members, is that the JCP is currently looking for Free Software developers to provide guidance and assistance during its transition towards a Java world where the Free Software model is the obvious choice for development of community maintained standards. We should take this opportunity seriously, in particular as individual developers and packagers, and not expect the proprietary software vendors on the EC to be able to see the truths we regard as self evident in the same light without some direct guidance.[3] * I'd like to spend some time with you and Patrick in Antwerpen going over the JCP & JSPA pain points, to see how, when, and with whom to proceed to fix them efficiently. I'd like to have an understanding of what we can achieve if the Free Software developers act together in their interest in what time frame. * Then, I believe we should discuss that within the larger Free Software developer and packager community, and at FOSDEM try to come up with a plan of action to address our needs. cheers, dalibor topic [1] Open source works better than open letters for some users, as ESR showed us back in 2003. [2] http://javapolis.com/confluence/pages/viewpage.action?pageId=31669 [3] The indirect approach didn't work as well as the direct engagement did for solving the primary problem, i.e. positively engaging Sun directly during the past two years worked a lot better than positively engaging someone else who may themselves eventually positively influence Sun to liberate Java. I believe the same holds for the JCP as a whole. From James.Melvin at Sun.COM Fri Dec 7 21:01:34 2007 From: James.Melvin at Sun.COM (James.Melvin at Sun.COM) Date: Fri, 07 Dec 2007 16:01:34 -0500 Subject: Mercurial switch: JDK 7 build 24 is available at the openjdk.java.net website In-Reply-To: <475755EE.6010003@sun.com> References: <47563FCC.4080907@sun.com> <47564207.2020606@sun.com> <475755EE.6010003@sun.com> Message-ID: <4759B4AE.9030401@Sun.COM> Just another confirmation (from inside Sun)... I'm able to clone the openjdk forest and build successfully on Solaris Sparc using the instructions provided. Nice work everyone! - Jim Xiomara Jayasena wrote: > Jesse Glick wrote: >> Xiomara Jayasena wrote: >>> The OpenJDK source is available at: >>> http://hg.openjdk.java.net/jdk7/jdk7 >> >> Congratulations! > On behalf of our team -- Thank you! >> >> When I look at the index page >> >> http://hg.openjdk.java.net/ >> >> I still see the warning >> >> "These repositories are EXPERIMENTAL..." >> >> which I guess is obsolete and the server maintainer simply forgot to >> delete it? > Sorry about that still being there... only the master repository is in > "live" mode at this point. The update of the group integration forests > is coming soon. With the mercurial transition many tasks need to get > done and that is one of them in the queue. > -Xiomara > From arnd-hendrik.mathias at nefkom.net Sun Dec 9 16:21:11 2007 From: arnd-hendrik.mathias at nefkom.net (Arnd-Hendrik Mathias) Date: Sun, 09 Dec 2007 17:21:11 +0100 Subject: Source tarballs Message-ID: <475C15F7.7060808@nefkom.net> Hi everyone, can anyone explain me the new philosophy of distributing the OpenJDK sources especially for non-hg-users? I've already drawn and built former releases as tarballs but now as of build b24 the download link points to something appearing like the root directory of the repository. I couldn't find anything that looks like neither a source tarball nor a description of how to download the sources in any other way. Any help would be appreciated. Best regards Arnd-Hendrik From langel at redhat.com Mon Dec 10 17:43:15 2007 From: langel at redhat.com (Lillian Angel) Date: Mon, 10 Dec 2007 12:43:15 -0500 Subject: JDK 7 build 24 is available at the openjdk.java.net website In-Reply-To: <47563FCC.4080907@sun.com> References: <47563FCC.4080907@sun.com> Message-ID: <475D7AB3.8060000@redhat.com> Hi, Will zipped bundles still be released? If not, could "make dist" be implemented to create a zip/tarball based on the release tag? Thanks, Lillian Xiomara Jayasena wrote: > > The OpenJDK source is available at: > http://hg.openjdk.java.net/jdk7/jdk7 > and the build 24 source is here: > http://hg.openjdk.java.net/jdk7/jdk7/rev/0a5c5386a678 > > The OpenJDK source binary plugs and Jtreg binary for the promoted JDK 7 > build 24 are available under the openjdk http://openjdk.java.net website > under Source Code (direct link to bundles: > http://download.java.net/openjdk/jdk7) > > Summary of changes: > http://download.java.net/jdk7/changes/jdk7-b24.html > > Thanks, > -Xiomara From Xiomara.Jayasena at Sun.COM Mon Dec 10 17:54:37 2007 From: Xiomara.Jayasena at Sun.COM (Xiomara.Jayasena at Sun.COM) Date: Mon, 10 Dec 2007 09:54:37 -0800 Subject: Source tarballs In-Reply-To: <475C15F7.7060808@nefkom.net> References: <475C15F7.7060808@nefkom.net> Message-ID: <475D7D5D.6010602@Sun.COM> Hi Arnd-Hendrik, Now that the OpenJDK source is available "live" in the hg repositories it does not make sense to have source tar balls. If we had tar balls this would be out of date with the live repositories, since this would be a snapshot of the repos at a given moment in time. What is preventing you from using hg to do a fclone and get the source? Try the following: hg fclone http://hg.openjdk.java.net/jdk7/jdk7 myjdk7 If a desire build is needed then the tagged repo for that build can be cloned. -Xiomara Arnd-Hendrik Mathias wrote: > Hi everyone, > can anyone explain me the new philosophy of distributing the OpenJDK > sources especially for non-hg-users? I've already drawn and built > former releases as tarballs but now as of build b24 the download link > points to something appearing like the root directory of the > repository. I couldn't find anything that looks like neither a source > tarball nor a description of how to download the sources in any other > way. > Any help would be appreciated. > Best regards > > Arnd-Hendrik From Xiomara.Jayasena at Sun.COM Mon Dec 10 18:00:02 2007 From: Xiomara.Jayasena at Sun.COM (Xiomara.Jayasena at Sun.COM) Date: Mon, 10 Dec 2007 10:00:02 -0800 Subject: JDK 7 build 24 is available at the openjdk.java.net website In-Reply-To: <475D7AB3.8060000@redhat.com> References: <47563FCC.4080907@sun.com> <475D7AB3.8060000@redhat.com> Message-ID: <475D7EA2.5090300@Sun.COM> Hi, Please see my response to this on this thread. http://mail.openjdk.java.net/pipermail/discuss/2007-December/000927.html > If not, could "make dist" be implemented to create a zip/tarball based > on the release tag? I think there might are plans towards a make dist but I am not sure whether it will include the tarball release tags. -Xiomara Lillian Angel wrote: > Hi, > > Will zipped bundles still be released? If not, could "make dist" be > implemented to create a zip/tarball based on the release tag? > > > Thanks, > Lillian > > > Xiomara Jayasena wrote: > >> >> The OpenJDK source is available at: >> http://hg.openjdk.java.net/jdk7/jdk7 >> and the build 24 source is here: >> http://hg.openjdk.java.net/jdk7/jdk7/rev/0a5c5386a678 >> >> The OpenJDK source binary plugs and Jtreg binary for the promoted JDK >> 7 build 24 are available under the openjdk http://openjdk.java.net >> website under Source Code (direct link to bundles: >> http://download.java.net/openjdk/jdk7) >> >> Summary of changes: >> http://download.java.net/jdk7/changes/jdk7-b24.html >> >> Thanks, >> -Xiomara > From arnd-hendrik.mathias at nefkom.net Mon Dec 10 23:31:57 2007 From: arnd-hendrik.mathias at nefkom.net (Arnd-Hendrik Mathias) Date: Tue, 11 Dec 2007 00:31:57 +0100 Subject: Source tarballs In-Reply-To: <475D7D5D.6010602@Sun.COM> References: <475C15F7.7060808@nefkom.net> <475D7D5D.6010602@Sun.COM> Message-ID: <475DCC6D.7020404@nefkom.net> Hi Xiomara, many thanks for your quick reply. > Now that the OpenJDK source is available "live" in the hg repositories > it does not make sense to have source tar balls. If we had tar balls > this would be out of date with the live repositories, since this would > be a snapshot of the repos at a given moment in time. I'd generally prefer to use specific snapshots (quite "stable" tagged ones best) over checkouts of any arbitrary status (at least for a dependable system for daily work). > What is preventing you from using hg to do a fclone and get the source? I am trying to resolve dependencies of other software to build and install by updating my OpenJDK installation. Each additional software package means additional effort by further dependencies (like hg depends on python and a merge program) where each of them means the additional risk of unresolvable dependencies. As I learned in the last months of installing my PC, support for pure 64bit Linux is not a matter of course. That's why I'm trying to avoid to raise another couple of ToDos and to reduce the effort to building the OpenJDK from a packed snapshot. Does the decision mean that snapshots will generally no longer be offered for download in a packed bundle? Best regards Arnd-Hendrik From John.Rose at Sun.COM Tue Dec 11 00:02:04 2007 From: John.Rose at Sun.COM (John Rose) Date: Mon, 10 Dec 2007 16:02:04 -0800 Subject: Source tarballs In-Reply-To: <475DCC6D.7020404@nefkom.net> References: <475C15F7.7060808@nefkom.net> <475D7D5D.6010602@Sun.COM> <475DCC6D.7020404@nefkom.net> Message-ID: <9839C2BD-AA7E-41D7-9616-931A75F6CFD1@sun.com> On Dec 10, 2007, at 3:31 PM, Arnd-Hendrik Mathias wrote: >> Now that the OpenJDK source is available "live" in the hg >> repositories it does not make sense to have source tar balls. If >> we had tar balls this would be out of date with the live >> repositories, since this would be a snapshot of the repos at a >> given moment in time. > I'd generally prefer to use specific snapshots (quite "stable" > tagged ones best) over checkouts of any arbitrary status (at least > for a dependable system for daily work). That's what Xiomara meant about tagged versions. >> What is preventing you from using hg to do a fclone and get the >> source? > I am trying to resolve dependencies of other software to build and > install by updating my OpenJDK installation. Each additional > software package means additional effort Somebody should blog a simple and complete step-by-step recipe for getting from a clean system to "hg fclone" and beyond to a build. Then we could link that article prominently from the download site. Someday we'll have a wiki; that's the natural home of such information. Or maybe it already exists, and I was unfortunate enough to miss it. (I consulted such a recipe for setting up VMware on my MacBook and it saved me both time and frustration.) One tricky bit is that you need three chunks of python: hg itself, the fclone extension, and a newer version of python itself. -- John From Xiomara.Jayasena at Sun.COM Tue Dec 11 00:17:51 2007 From: Xiomara.Jayasena at Sun.COM (Xiomara Jayasena) Date: Mon, 10 Dec 2007 16:17:51 -0800 Subject: Source tarballs In-Reply-To: <475DCC6D.7020404@nefkom.net> References: <475C15F7.7060808@nefkom.net> <475D7D5D.6010602@Sun.COM> <475DCC6D.7020404@nefkom.net> Message-ID: <475DD72F.5030701@sun.com> Hi Arnd-Hendrik, Arnd-Hendrik Mathias wrote: > Hi Xiomara, > many thanks for your quick reply. >> Now that the OpenJDK source is available "live" in the hg >> repositories it does not make sense to have source tar balls. If we >> had tar balls this would be out of date with the live repositories, >> since this would be a snapshot of the repos at a given moment in time. > I'd generally prefer to use specific snapshots (quite "stable" tagged > ones best) over checkouts of any arbitrary status (at least for a > dependable system for daily work). That can still be done by pulling the specific tagged repo. >> What is preventing you from using hg to do a fclone and get the source? > I am trying to resolve dependencies of other software to build and > install by updating my OpenJDK installation. Each additional software > package means additional effort by further dependencies (like hg > depends on python and a merge program) where each of them means the > additional risk of unresolvable dependencies. As I learned in the last > months of installing my PC, support for pure 64bit Linux is not a > matter of course. That's why I'm trying to avoid to raise another > couple of ToDos and to reduce the effort to building the OpenJDK from > a packed snapshot. > Does the decision mean that snapshots will generally no longer be > offered for download in a packed bundle? We really didn't see the need, hence we decided to get rid of them. It seems anyone working in JDK 7 may need to become familiar with hg -- that said I appreciate your input. Here at Sun we will no longer be using the tarred source and expect engineers to do clones and that is the same expectation for developers outside of Sun. If many people think this is crucial then the decision can be re-evaluated. Note: instructions, procedures, process, etc. are still coming... please bare with us as we get all this new stuff in place. In the meantime see http://openjdk.java.net/groups/build/ * *Build Infrastructure bloggers* o Kelly O'Hair (java.net) o Kelly O'Hair (blogs.sun.com) Again thank you for your input :) -Xiomara > Best regards > > Arnd-Hendrik -------------- next part -------------- An HTML attachment was scrubbed... URL: From Andreas.Sterbenz at Sun.COM Tue Dec 11 00:21:50 2007 From: Andreas.Sterbenz at Sun.COM (Andreas Sterbenz) Date: Mon, 10 Dec 2007 16:21:50 -0800 Subject: Source tarballs In-Reply-To: <475DD72F.5030701@sun.com> References: <475C15F7.7060808@nefkom.net> <475D7D5D.6010602@Sun.COM> <475DCC6D.7020404@nefkom.net> <475DD72F.5030701@sun.com> Message-ID: <475DD81E.3040806@sun.com> Xiomara Jayasena wrote: > > We really didn't see the need, hence we decided to get rid of them. It > seems anyone working in JDK 7 may need to become familiar with hg -- > that said I appreciate your input. Here at Sun we will no longer be > using the tarred source and expect engineers to do clones and that is > the same expectation for developers outside of Sun. If many people > think this is crucial then the decision can be re-evaluated. It is still possible to get source tarballs - by going to http://hg.openjdk.java.net/ . Just click on the zip/gz/bz2 link next to the desired repository to get the tip (e.g. http://hg.openjdk.java.net/jdk7/jdk7/archive/tip.tar.bz2) or navigate to the changeset or tag you like and follow the download link (e.g. http://hg.openjdk.java.net/jdk7/jdk7/rev/0a5c5386a678). The only thing it doesn't do is understand forests, so you have to download the source for each of the seven repositories in the forest separately (/if/ you really want them all). Andreas. From Kelly.Ohair at Sun.COM Tue Dec 11 00:31:59 2007 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Mon, 10 Dec 2007 16:31:59 -0800 Subject: JDK 7 build 24 is available at the openjdk.java.net website In-Reply-To: <475D7AB3.8060000@redhat.com> References: <47563FCC.4080907@sun.com> <475D7AB3.8060000@redhat.com> Message-ID: <475DDA7F.1080302@sun.com> I had hoped that Mercurial would have provided some of this source bundling for free, but since we went with a forest, it's not ideal. It's only done on a per-repository basis. If you go to: http://hg.openjdk.java.net/jdk7/jdk7 At the top of the page are some 'zip' 'bz2' 'gz' links. These get you bundles, for example the default 'zip' link gets you the latest changeset or 'tip' for this repository: http://hg.openjdk.java.net/jdk7/jdk7/archive/tip.zip You can get bundles for any changeset number or even a tag, like jdk7-b24: http://hg.openjdk.java.net/jdk7/jdk7/archive/jdk7-b24.zip But as I said, with a forest, this isn't ideal, you'd need to download each repository, probably something like: http://hg.openjdk.java.net/jdk7/jdk7/archive/jdk7-b24.zip http://hg.openjdk.java.net/jdk7/jdk7/jdk/archive/jdk7-b24.zip http://hg.openjdk.java.net/jdk7/jdk7/corba/archive/jdk7-b24.zip http://hg.openjdk.java.net/jdk7/jdk7/jaxp/archive/jdk7-b24.zip http://hg.openjdk.java.net/jdk7/jdk7/jaxws/archive/jdk7-b24.zip http://hg.openjdk.java.net/jdk7/jdk7/hotspot/archive/jdk7-b24.zip http://hg.openjdk.java.net/jdk7/jdk7/langtools/archive/jdk7-b24.zip We need a forest 'zip' option that woould create a single zip file, but I have no idea when that would ever happen. -kto Lillian Angel wrote: > Hi, > > Will zipped bundles still be released? If not, could "make dist" be > implemented to create a zip/tarball based on the release tag? > > > Thanks, > Lillian > > > Xiomara Jayasena wrote: >> >> The OpenJDK source is available at: >> http://hg.openjdk.java.net/jdk7/jdk7 >> and the build 24 source is here: >> http://hg.openjdk.java.net/jdk7/jdk7/rev/0a5c5386a678 >> >> The OpenJDK source binary plugs and Jtreg binary for the promoted JDK >> 7 build 24 are available under the openjdk http://openjdk.java.net >> website under Source Code (direct link to bundles: >> http://download.java.net/openjdk/jdk7) >> >> Summary of changes: >> http://download.java.net/jdk7/changes/jdk7-b24.html >> >> Thanks, >> -Xiomara From Kelly.Ohair at Sun.COM Tue Dec 11 04:29:30 2007 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Mon, 10 Dec 2007 20:29:30 -0800 Subject: Vote results: Build Group sponsorship of the JDK 7 project PASSES (4:0) Message-ID: <475E122A.4070302@sun.com> The proposal for the Build Group to sponsor the creation of the JDK 7 project [1] succeeds with 4 votes for and 0 votes against. In answer to the question "Should the Build Group sponsor this Project?" the individual votes are: Kelly O'Hair Yes Xiomara Jayasena Yes Tim Bell Yes Mark Reinhold Yes [1] is: http://mail.openjdk.java.net/pipermail/announce/2007-December/000049.html -kto From arnd-hendrik.mathias at nefkom.net Wed Dec 12 23:21:41 2007 From: arnd-hendrik.mathias at nefkom.net (Arnd-Hendrik Mathias) Date: Thu, 13 Dec 2007 00:21:41 +0100 Subject: JDK 7 build 24 is available at the openjdk.java.net website In-Reply-To: <475DDA7F.1080302@sun.com> References: <47563FCC.4080907@sun.com> <475D7AB3.8060000@redhat.com> <475DDA7F.1080302@sun.com> Message-ID: <47606D05.2040709@nefkom.net> Hey Kelly, many thanks for the download links you've given below. In case someone may be going to create a short wiki page about the hg-less download and extraction process, I've attached a Makefile which might be helpful for those trying to build from scratch. I've omitted the "building the prerequisites" stuff (download, build and install Ant, JUnit, bootstrap JDK7 binaries and the binary plugins) because the Makefile shall depict the files needed to be downloaded, extracted and restructured/renamed to set up a working source tree. Most users won't re-install the AntJUnitBootstrapJDK7BinaryPlugs boiling each time they build a new OpenJDK snapshot anyway. I recognized one other thing that prevents me from building completely: The "build" target of the /jdk7-jdk7-b24/jdk/make/javax/crypto/Makefile is empty which means that all directories/classes to be included in the /tmp/sun/javax.crypto/unsigned/jce.jar are removed by the prebuild target but not rebuilt subsequently. Is there a special trick, how to build the tmp/sun/javax.crypto/classes/javax/crypto, tmp/sun/javax.crypto/classes/sun/security/internal/interfaces and tmp/sun/javax.crypto/classes/sun/security/internal/spec? Best regards Arnd-Hendrik Kelly O'Hair wrote: > > I had hoped that Mercurial would have provided some of this source > bundling > for free, but since we went with a forest, it's not ideal. It's only > done on a per-repository basis. > > If you go to: > http://hg.openjdk.java.net/jdk7/jdk7 > > At the top of the page are some 'zip' 'bz2' 'gz' links. These get you > bundles, for example the default 'zip' link gets you the latest > changeset or > 'tip' for this repository: > http://hg.openjdk.java.net/jdk7/jdk7/archive/tip.zip > > You can get bundles for any changeset number or even a tag, like > jdk7-b24: > http://hg.openjdk.java.net/jdk7/jdk7/archive/jdk7-b24.zip > > But as I said, with a forest, this isn't ideal, you'd need to download > each repository, probably something like: > http://hg.openjdk.java.net/jdk7/jdk7/archive/jdk7-b24.zip > http://hg.openjdk.java.net/jdk7/jdk7/jdk/archive/jdk7-b24.zip > http://hg.openjdk.java.net/jdk7/jdk7/corba/archive/jdk7-b24.zip > http://hg.openjdk.java.net/jdk7/jdk7/jaxp/archive/jdk7-b24.zip > http://hg.openjdk.java.net/jdk7/jdk7/jaxws/archive/jdk7-b24.zip > http://hg.openjdk.java.net/jdk7/jdk7/hotspot/archive/jdk7-b24.zip > http://hg.openjdk.java.net/jdk7/jdk7/langtools/archive/jdk7-b24.zip > > We need a forest 'zip' option that woould create a single zip file, > but I have no idea when that would ever happen. > > -kto > > > Lillian Angel wrote: >> Hi, >> >> Will zipped bundles still be released? If not, could "make dist" be >> implemented to create a zip/tarball based on the release tag? >> >> >> Thanks, >> Lillian >> >> >> Xiomara Jayasena wrote: >>> >>> The OpenJDK source is available at: >>> http://hg.openjdk.java.net/jdk7/jdk7 >>> and the build 24 source is here: >>> http://hg.openjdk.java.net/jdk7/jdk7/rev/0a5c5386a678 >>> >>> The OpenJDK source binary plugs and Jtreg binary for the promoted >>> JDK 7 build 24 are available under the openjdk >>> http://openjdk.java.net website under Source Code (direct link to >>> bundles: http://download.java.net/openjdk/jdk7) >>> >>> Summary of changes: >>> http://download.java.net/jdk7/changes/jdk7-b24.html >>> >>> Thanks, >>> -Xiomara > > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: Makefile URL: From Kelly.Ohair at Sun.COM Wed Dec 12 23:44:10 2007 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Wed, 12 Dec 2007 15:44:10 -0800 Subject: JDK 7 build 24 is available at the openjdk.java.net website In-Reply-To: <47606D05.2040709@nefkom.net> References: <47563FCC.4080907@sun.com> <475D7AB3.8060000@redhat.com> <475DDA7F.1080302@sun.com> <47606D05.2040709@nefkom.net> Message-ID: <4760724A.1010707@sun.com> Very nice... I haven't tried it yet, but that's very much what I was thinking. I'll have to defer the crypto question to the security guys... hopefully they are listing to the build-dev alias which I CC'd. Thanks for sharing this. -kto Arnd-Hendrik Mathias wrote: > Hey Kelly, > many thanks for the download links you've given below. In case someone > may be going to create a short wiki page about the hg-less download and > extraction process, I've attached a Makefile which might be helpful for > those trying to build from scratch. I've omitted the "building the > prerequisites" stuff (download, build and install Ant, JUnit, bootstrap > JDK7 binaries and the binary plugins) because the Makefile shall depict > the files needed to be downloaded, extracted and restructured/renamed to > set up a working source tree. Most users won't re-install the > AntJUnitBootstrapJDK7BinaryPlugs boiling each time they build a new > OpenJDK snapshot anyway. > > I recognized one other thing that prevents me from building completely: > The "build" target of the /jdk7-jdk7-b24/jdk/make/javax/crypto/Makefile > is empty which means that all directories/classes to be included in the > /tmp/sun/javax.crypto/unsigned/jce.jar are removed by the prebuild > target but not rebuilt subsequently. > Is there a special trick, how to build the > tmp/sun/javax.crypto/classes/javax/crypto, > tmp/sun/javax.crypto/classes/sun/security/internal/interfaces and > tmp/sun/javax.crypto/classes/sun/security/internal/spec? > Best regards > > Arnd-Hendrik > > > Kelly O'Hair wrote: >> >> I had hoped that Mercurial would have provided some of this source >> bundling >> for free, but since we went with a forest, it's not ideal. It's only >> done on a per-repository basis. >> >> If you go to: >> http://hg.openjdk.java.net/jdk7/jdk7 >> >> At the top of the page are some 'zip' 'bz2' 'gz' links. These get you >> bundles, for example the default 'zip' link gets you the latest >> changeset or >> 'tip' for this repository: >> http://hg.openjdk.java.net/jdk7/jdk7/archive/tip.zip >> >> You can get bundles for any changeset number or even a tag, like >> jdk7-b24: >> http://hg.openjdk.java.net/jdk7/jdk7/archive/jdk7-b24.zip >> >> But as I said, with a forest, this isn't ideal, you'd need to download >> each repository, probably something like: >> http://hg.openjdk.java.net/jdk7/jdk7/archive/jdk7-b24.zip >> http://hg.openjdk.java.net/jdk7/jdk7/jdk/archive/jdk7-b24.zip >> http://hg.openjdk.java.net/jdk7/jdk7/corba/archive/jdk7-b24.zip >> http://hg.openjdk.java.net/jdk7/jdk7/jaxp/archive/jdk7-b24.zip >> http://hg.openjdk.java.net/jdk7/jdk7/jaxws/archive/jdk7-b24.zip >> http://hg.openjdk.java.net/jdk7/jdk7/hotspot/archive/jdk7-b24.zip >> http://hg.openjdk.java.net/jdk7/jdk7/langtools/archive/jdk7-b24.zip >> >> We need a forest 'zip' option that woould create a single zip file, >> but I have no idea when that would ever happen. >> >> -kto >> >> >> Lillian Angel wrote: >>> Hi, >>> >>> Will zipped bundles still be released? If not, could "make dist" be >>> implemented to create a zip/tarball based on the release tag? >>> >>> >>> Thanks, >>> Lillian >>> >>> >>> Xiomara Jayasena wrote: >>>> >>>> The OpenJDK source is available at: >>>> http://hg.openjdk.java.net/jdk7/jdk7 >>>> and the build 24 source is here: >>>> http://hg.openjdk.java.net/jdk7/jdk7/rev/0a5c5386a678 >>>> >>>> The OpenJDK source binary plugs and Jtreg binary for the promoted >>>> JDK 7 build 24 are available under the openjdk >>>> http://openjdk.java.net website under Source Code (direct link to >>>> bundles: http://download.java.net/openjdk/jdk7) >>>> >>>> Summary of changes: >>>> http://download.java.net/jdk7/changes/jdk7-b24.html >>>> >>>> Thanks, >>>> -Xiomara >> >> From arnd-hendrik.mathias at nefkom.net Thu Dec 13 14:53:25 2007 From: arnd-hendrik.mathias at nefkom.net (Arnd-Hendrik Mathias) Date: Thu, 13 Dec 2007 15:53:25 +0100 Subject: JDK 7 build 24 is available at the openjdk.java.net website In-Reply-To: <009f01c83d75$5bade490$1309adb0$@com> References: <47563FCC.4080907@sun.com> <475D7AB3.8060000@redhat.com> <475DDA7F.1080302@sun.com> <47606D05.2040709@nefkom.net> <4760724A.1010707@sun.com> <009f01c83d75$5bade490$1309adb0$@com> Message-ID: <47614765.7020008@nefkom.net> Somewhat strange... I received the attachment with my mail coming back via the discuss list. Maybe some other list (build-dev?) removes attachments. Ted Neward wrote: > I don't think the Makefile got attached. > > Ted Neward > Java, .NET, XML Services > Consulting, Teaching, Speaking, Writing > http://www.tedneward.com > > > >> -----Original Message----- >> From: build-dev-bounces at openjdk.java.net [mailto:build-dev- >> bounces at openjdk.java.net] On Behalf Of Kelly O'Hair >> Sent: Wednesday, December 12, 2007 3:44 PM >> To: Arnd-Hendrik Mathias >> Cc: discuss at openjdk.java.net; build-dev >> Subject: Re: JDK 7 build 24 is available at the openjdk.java.net >> website >> >> Very nice... I haven't tried it yet, but that's very much what I was >> thinking. >> >> I'll have to defer the crypto question to the security guys... >> hopefully they >> are listing to the build-dev alias which I CC'd. >> >> Thanks for sharing this. >> >> -kto >> >> Arnd-Hendrik Mathias wrote: >> >>> Hey Kelly, >>> many thanks for the download links you've given below. In case >>> >> someone >> >>> may be going to create a short wiki page about the hg-less download >>> >> and >> >>> extraction process, I've attached a Makefile which might be helpful >>> >> for >> >>> those trying to build from scratch. I've omitted the "building the >>> prerequisites" stuff (download, build and install Ant, JUnit, >>> >> bootstrap >> >>> JDK7 binaries and the binary plugins) because the Makefile shall >>> >> depict >> >>> the files needed to be downloaded, extracted and restructured/renamed >>> >> to >> >>> set up a working source tree. Most users won't re-install the >>> AntJUnitBootstrapJDK7BinaryPlugs boiling each time they build a new >>> OpenJDK snapshot anyway. >>> >>> I recognized one other thing that prevents me from building >>> >> completely: >> >>> The "build" target of the /jdk7-jdk7- >>> >> b24/jdk/make/javax/crypto/Makefile >> >>> is empty which means that all directories/classes to be included in >>> >> the >> >>> /tmp/sun/javax.crypto/unsigned/jce.jar are removed by the prebuild >>> target but not rebuilt subsequently. >>> Is there a special trick, how to build the >>> tmp/sun/javax.crypto/classes/javax/crypto, >>> tmp/sun/javax.crypto/classes/sun/security/internal/interfaces and >>> tmp/sun/javax.crypto/classes/sun/security/internal/spec? >>> Best regards >>> >>> Arnd-Hendrik >>> >>> >>> Kelly O'Hair wrote: >>> >>>> I had hoped that Mercurial would have provided some of this source >>>> bundling >>>> for free, but since we went with a forest, it's not ideal. It's only >>>> done on a per-repository basis. >>>> >>>> If you go to: >>>> http://hg.openjdk.java.net/jdk7/jdk7 >>>> >>>> At the top of the page are some 'zip' 'bz2' 'gz' links. These get >>>> >> you >> >>>> bundles, for example the default 'zip' link gets you the latest >>>> changeset or >>>> 'tip' for this repository: >>>> http://hg.openjdk.java.net/jdk7/jdk7/archive/tip.zip >>>> >>>> You can get bundles for any changeset number or even a tag, like >>>> jdk7-b24: >>>> http://hg.openjdk.java.net/jdk7/jdk7/archive/jdk7-b24.zip >>>> >>>> But as I said, with a forest, this isn't ideal, you'd need to >>>> >> download >> >>>> each repository, probably something like: >>>> http://hg.openjdk.java.net/jdk7/jdk7/archive/jdk7-b24.zip >>>> http://hg.openjdk.java.net/jdk7/jdk7/jdk/archive/jdk7-b24.zip >>>> http://hg.openjdk.java.net/jdk7/jdk7/corba/archive/jdk7-b24.zip >>>> http://hg.openjdk.java.net/jdk7/jdk7/jaxp/archive/jdk7-b24.zip >>>> http://hg.openjdk.java.net/jdk7/jdk7/jaxws/archive/jdk7-b24.zip >>>> http://hg.openjdk.java.net/jdk7/jdk7/hotspot/archive/jdk7-b24.zip >>>> http://hg.openjdk.java.net/jdk7/jdk7/langtools/archive/jdk7- >>>> >> b24.zip >> >>>> We need a forest 'zip' option that woould create a single zip file, >>>> but I have no idea when that would ever happen. >>>> >>>> -kto >>>> >>>> >>>> Lillian Angel wrote: >>>> >>>>> Hi, >>>>> >>>>> Will zipped bundles still be released? If not, could "make dist" be >>>>> implemented to create a zip/tarball based on the release tag? >>>>> >>>>> >>>>> Thanks, >>>>> Lillian >>>>> >>>>> >>>>> Xiomara Jayasena wrote: >>>>> >>>>>> The OpenJDK source is available at: >>>>>> http://hg.openjdk.java.net/jdk7/jdk7 >>>>>> and the build 24 source is here: >>>>>> http://hg.openjdk.java.net/jdk7/jdk7/rev/0a5c5386a678 >>>>>> >>>>>> The OpenJDK source binary plugs and Jtreg binary for the promoted >>>>>> JDK 7 build 24 are available under the openjdk >>>>>> http://openjdk.java.net website under Source Code (direct link to >>>>>> bundles: http://download.java.net/openjdk/jdk7) >>>>>> >>>>>> Summary of changes: >>>>>> http://download.java.net/jdk7/changes/jdk7-b24.html >>>>>> >>>>>> Thanks, >>>>>> -Xiomara >>>>>> >>>> >> No virus found in this incoming message. >> Checked by AVG Free Edition. >> Version: 7.5.503 / Virus Database: 269.17.1/1182 - Release Date: >> 12/12/2007 11:29 AM >> >> > > No virus found in this outgoing message. > Checked by AVG Free Edition. > Version: 7.5.503 / Virus Database: 269.17.1/1182 - Release Date: 12/12/2007 > 11:29 AM > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: Makefile URL: From dalibor.topic at googlemail.com Thu Dec 13 16:43:48 2007 From: dalibor.topic at googlemail.com (Dalibor Topic) Date: Thu, 13 Dec 2007 17:43:48 +0100 Subject: New Project approved: JDK 7 In-Reply-To: <20071212163852.E8C7B2789B5@eggemoggin.niobe.net> References: <20071212163852.E8C7B2789B5@eggemoggin.niobe.net> Message-ID: <47616144.8000107@kaffe.org> Mark Reinhold wrote: > Per the interim governance guidelines for Projects [1] I'm pleased to > announce the creation of the JDK 7 Project [2,3] following the Build > Group's decision [4] to sponsor it. > Congratulations, Mark and best of luck for the project! cheers, dalibor topic From alexanderschunk at t-online.de Fri Dec 14 12:33:53 2007 From: alexanderschunk at t-online.de (alexanderschunk at t-online.de) Date: Fri, 14 Dec 2007 13:33:53 +0100 Subject: Project proposal: Common Mathlib In-Reply-To: <20071205214959.0438B2783C7@eggemoggin.niobe.net> References: <20071205214959.0438B2783C7@eggemoggin.niobe.net> Message-ID: <1J39jl-1OdmPA0@fwd33.aul.t-online.de> An HTML attachment was scrubbed... URL: From alexanderschunk at t-online.de Tue Dec 18 13:34:51 2007 From: alexanderschunk at t-online.de (alexanderschunk at t-online.de) Date: Tue, 18 Dec 2007 14:34:51 +0100 Subject: LinAlg API: Finished Message-ID: <1J4cax-0Ndefw0@fwd28.aul.t-online.de> An HTML attachment was scrubbed... URL: From Andreas.Sterbenz at Sun.COM Thu Dec 20 21:44:33 2007 From: Andreas.Sterbenz at Sun.COM (Andreas Sterbenz) Date: Thu, 20 Dec 2007 13:44:33 -0800 Subject: JDK 7 build 24 is available at the openjdk.java.net website In-Reply-To: <47606D05.2040709@nefkom.net> References: <47563FCC.4080907@sun.com> <475D7AB3.8060000@redhat.com> <475DDA7F.1080302@sun.com> <47606D05.2040709@nefkom.net> Message-ID: <476AE241.1050801@sun.com> Arnd-Hendrik Mathias wrote: > > I recognized one other thing that prevents me from building completely: > The "build" target of the /jdk7-jdk7-b24/jdk/make/javax/crypto/Makefile > is empty which means that all directories/classes to be included in the > /tmp/sun/javax.crypto/unsigned/jce.jar are removed by the prebuild > target but not rebuilt subsequently. > Is there a special trick, how to build the > tmp/sun/javax.crypto/classes/javax/crypto, > tmp/sun/javax.crypto/classes/sun/security/internal/interfaces and > tmp/sun/javax.crypto/classes/sun/security/internal/spec? There is some trickery going on in that Makefile. The classes are compiled with a destination directory of build/$platform-$arch/tmp/sun/ instead of the normal location build/$platform-$arch/sun/ and the latter directory is removed. That works for me. Could you elaborate a little on what you are doing? Which sources are you building? OpenJDK b24? IcedTea, or something else? Which directory are you calling make from? jdk7/jdk/make? jdk7? What is the command you are running? "make"? "make all"? Andreas. From arnd-hendrik.mathias at nefkom.net Thu Dec 20 22:54:31 2007 From: arnd-hendrik.mathias at nefkom.net (Arnd-Hendrik Mathias) Date: Thu, 20 Dec 2007 23:54:31 +0100 Subject: JDK 7 build 24 is available at the openjdk.java.net website In-Reply-To: <476AE241.1050801@sun.com> References: <47563FCC.4080907@sun.com> <475D7AB3.8060000@redhat.com> <475DDA7F.1080302@sun.com> <47606D05.2040709@nefkom.net> <476AE241.1050801@sun.com> Message-ID: <476AF2A7.1000009@nefkom.net> Hi Andreas, Andreas Sterbenz wrote: > Arnd-Hendrik Mathias wrote: >> >> I recognized one other thing that prevents me from building >> completely: The "build" target of the >> /jdk7-jdk7-b24/jdk/make/javax/crypto/Makefile is empty which means >> that all directories/classes to be included in the >> /tmp/sun/javax.crypto/unsigned/jce.jar are removed by the prebuild >> target but not rebuilt subsequently. >> Is there a special trick, how to build the >> tmp/sun/javax.crypto/classes/javax/crypto, >> tmp/sun/javax.crypto/classes/sun/security/internal/interfaces and >> tmp/sun/javax.crypto/classes/sun/security/internal/spec? > > There is some trickery going on in that Makefile. The classes are > compiled with a destination directory of > build/$platform-$arch/tmp/sun/ instead of the normal location > build/$platform-$arch/sun/ and the latter directory is removed. That > works for me. The rm and jar commands seem not to reference any $platform-$arch directories but rather $ALT_OUTPUTDIR/tmp but referencing the tmp directory seems to work. The classes themselves are not compiled at all (not even tried to compile). The make process removes the final classes ($ALT_OUTPUTDIR/classes/...) then the $ALT_OUTPUTDIR/tmp/.../jce.jar and next tries to pack the (not compiled => not existent) classes with jar which doesn't work without compiling them previously. I'll cat the output of make in this directory: make[4]: Entering directory `/src/java/jdk7-b24/jdk7-jdk7-b24/jdk/make/javax/crypto' rm -f -r /opt/jdk/openjdk-1.7.0_b24/classes/javax/crypto /opt/jdk/openjdk-1.7.0_b24/classes/sun/security/internal/interfaces /opt/jdk/openjdk-1.7.0_b24/classes/sun/security/internal/spec /bin/mkdir -p /opt/jdk/openjdk-1.7.0_b24/tmp/sun/javax.crypto/unsigned rm -f /opt/jdk/openjdk-1.7.0_b24/tmp/sun/javax.crypto/unsigned/jce.jar /src/java/jdk7-b24/jdk1.7.0/bin/jar cmf /opt/jdk/openjdk-1.7.0_b24/tmp/sun/javax.crypto/manifest.mf /opt/jdk/openjdk-1.7.0_b24/tmp/sun/javax.crypto/unsigned/jce.jar -C /opt/jdk/openjdk-1.7.0_b24/tmp/sun/javax.crypto/classes javax/crypto -C /opt/jdk/openjdk-1.7.0_b24/tmp/sun/javax.crypto/classes sun/security/internal/interfaces -C /opt/jdk/openjdk-1.7.0_b24/tmp/sun/javax.crypto/classes sun/security/internal/spec \ -J-Xmx896m -J-Xms128m -J-XX:PermSize=32m -J-XX:MaxPermSize=160m /opt/jdk/openjdk-1.7.0_b24/tmp/sun/javax.crypto/classes/javax/crypto : no such file or directory /opt/jdk/openjdk-1.7.0_b24/tmp/sun/javax.crypto/classes/sun/security/internal/interfaces : no such file or directory /opt/jdk/openjdk-1.7.0_b24/tmp/sun/javax.crypto/classes/sun/security/internal/spec : no such file or directory make[4]: *** [/opt/jdk/openjdk-1.7.0_b24/tmp/sun/javax.crypto/unsigned/jce.jar] Error 1 make[4]: Leaving directory `/src/java/jdk7-b24/jdk7-jdk7-b24/jdk/make/javax/crypto' make[3]: *** [all] Error 1 make[3]: Leaving directory `/src/java/jdk7-b24/jdk7-jdk7-b24/jdk/make/javax' make[2]: *** [all] Error 1 make[2]: Leaving directory `/src/java/jdk7-b24/jdk7-jdk7-b24/jdk/make' make[1]: *** [jdk-build] Error 2 make[1]: Leaving directory `/src/java/jdk7-b24/jdk7-jdk7-b24' make: *** [build] Error 2 > Could you elaborate a little on what you are doing? Which sources are > you building? OpenJDK b24? IcedTea, or something else? OpenJDK b24 > Which directory are you calling make from? jdk7/jdk/make? jdk7-jdk7-b24 which is the top directory created by unpacking the jdk7-jdk7-b24.tar.bz2 tarball. > What is the command you are running? "make"? "make all"? make $OPTIONS sanity all This follows the information in the corresponding README file. For further information you can take a brief look into the Makefile I sent previously: It resides one directory above and I use it calling make build from there. Influences from the above Makefile are unlikely, since calling make in the jdk7-jdk7-b24 directory directly the following way make -C jdk7-jdk7-b24 ALT_BINARY_PLUGS_PATH=/src/java/jdk7-b24/plugs/openjdk-binary-plugs ALT_JDK_IMPORT_PATH=/src/java/jdk7-b24/jdk1.7.0 ALT_BOOTDIR=/src/java/jdk7-b24/jdk1.7.0 BOOT_VER=1.7.0 ALT_OUTPUTDIR=/opt/jdk/openjdk-1.7.0_b24 ANT_HOME=/opt/ant/apache-ant-1.7.0 BUILD_NUMBER=b24 sanity all results in the same errors. Best regards Arnd-Hendrik From Andreas.Sterbenz at Sun.COM Fri Dec 21 01:34:45 2007 From: Andreas.Sterbenz at Sun.COM (Andreas Sterbenz) Date: Thu, 20 Dec 2007 17:34:45 -0800 Subject: JDK 7 build 24 is available at the openjdk.java.net website In-Reply-To: <476AF2A7.1000009@nefkom.net> References: <47563FCC.4080907@sun.com> <475D7AB3.8060000@redhat.com> <475DDA7F.1080302@sun.com> <47606D05.2040709@nefkom.net> <476AE241.1050801@sun.com> <476AF2A7.1000009@nefkom.net> Message-ID: <476B1835.6010408@sun.com> Arnd-Hendrik Mathias wrote: >> >> There is some trickery going on in that Makefile. The classes are >> compiled with a destination directory of >> build/$platform-$arch/tmp/sun/ instead of the normal location >> build/$platform-$arch/sun/ and the latter directory is removed. That >> works for me. > The rm and jar commands seem not to reference any $platform-$arch > directories but rather $ALT_OUTPUTDIR/tmp but referencing the tmp > directory seems to work. The classes themselves are not compiled at all > (not even tried to compile). The make process removes the final classes The Makefile defines AUTO_FILES_JAVA_DIRS and includes Classes.gmk, which causes the sources to be compiled. > ($ALT_OUTPUTDIR/classes/...) then the $ALT_OUTPUTDIR/tmp/.../jce.jar and > next tries to pack the (not compiled => not existent) classes with jar It removes $ALT_OUTPUTDIR/classes/, but since the classes are compiled into $ALT_OUTPUTDIR/tmp/ that has no effect on those files. See below output of a rebuild of make/javax/crypto after a previous build of a fresh clone of the Mercurial jdk repository. If you see something different, that must be related to your build environment, e.g. version of make used, out of date binary plugs, etc. Andreas. === >gnumake clobber rm -f ../../../build/solaris-i586/tmp/sun/javax.crypto/strip_prop_options rm -f ../../../build/solaris-i586/tmp/sun/javax.crypto/compile_prop_options rm -f ../../../build/solaris-i586/tmp/sun/javax.crypto/.classes.list rm -f -r ../../../build/solaris-i586/tmp/sun/javax.crypto/obj rm -f -r ../../../build/solaris-i586/tmp/sun/javax.crypto/obj_* rm -f -r ../../../build/solaris-i586/tmp/sun/javax.crypto/classes/javax/crypto rm -f -r ../../../build/solaris-i586/tmp/sun/javax.crypto/classes/sun/security/internal/interfaces rm -f -r ../../../build/solaris-i586/tmp/sun/javax.crypto/classes/sun/security/internal/spec rm -f ../../../build/solaris-i586/tmp/sun/javax.crypto/.classes.list rm -f -r ../../../build/solaris-i586/lib/jce.jar ../../../build/solaris-i586/lib/security/US_export_policy.jar \ ../../../build/solaris-i586/lib/security/local_policy.jar ../../../build/solaris-i586/classes/javax/crypto ../../../build/solaris-i586/classes/sun/security/internal/interfaces ../../../build/solaris-i586/classes/sun/security/internal/spec ../../../build/solaris-i586/tmp/sun/javax.crypto >gnumake all # Java sources to be compiled: (listed in file ../../../build/solaris-i586/tmp/sun/javax.crypto/.classes.list) ../../../src/share/classes/javax/crypto/NoSuchPaddingException.java ../../../src/share/classes/javax/crypto/NullCipher.java ../../../src/share/classes/javax/crypto/KeyAgreementSpi.java ../../../src/share/classes/javax/crypto/EncryptedPrivateKeyInfo.java ../../../src/share/classes/javax/crypto/Mac.java ../../../src/share/classes/javax/crypto/CryptoPermissions.java ../../../src/share/classes/javax/crypto/SecretKeyFactory.java ../../../src/share/classes/javax/crypto/CipherOutputStream.java ../../../src/share/classes/javax/crypto/SecretKey.java ../../../src/share/classes/javax/crypto/spec/DHPublicKeySpec.java ../../../src/share/classes/javax/crypto/spec/DHParameterSpec.java ../../../src/share/classes/javax/crypto/spec/RC5ParameterSpec.java ../../../src/share/classes/javax/crypto/spec/DESedeKeySpec.java ../../../src/share/classes/javax/crypto/spec/DESKeySpec.java ../../../src/share/classes/javax/crypto/spec/DHGenParameterSpec.java ../../../src/share/classes/javax/crypto/spec/RC2ParameterSpec.java ../../../src/share/classes/javax/crypto/spec/DHPrivateKeySpec.java ../../../src/share/classes/javax/crypto/spec/IvParameterSpec.java ../../../src/share/classes/javax/crypto/spec/PBEKeySpec.java ../../../src/share/classes/javax/crypto/spec/OAEPParameterSpec.java ../../../src/share/classes/javax/crypto/spec/PBEParameterSpec.java ../../../src/share/classes/javax/crypto/spec/PSource.java ../../../src/share/classes/javax/crypto/spec/SecretKeySpec.java ../../../src/share/classes/javax/crypto/ExemptionMechanismSpi.java ../../../src/share/classes/javax/crypto/interfaces/PBEKey.java ../../../src/share/classes/javax/crypto/interfaces/DHKey.java ../../../src/share/classes/javax/crypto/interfaces/DHPrivateKey.java ../../../src/share/classes/javax/crypto/interfaces/DHPublicKey.java ../../../src/share/classes/javax/crypto/ExemptionMechanismException.java ../../../src/share/classes/javax/crypto/BadPaddingException.java ../../../src/share/classes/javax/crypto/ShortBufferException.java ../../../src/share/classes/javax/crypto/CipherSpi.java ../../../src/share/classes/javax/crypto/JarVerifier.java ../../../src/share/classes/javax/crypto/JceSecurityManager.java ../../../src/share/classes/javax/crypto/CryptoPolicyParser.java ../../../src/share/classes/javax/crypto/JceSecurity.java ../../../src/share/classes/javax/crypto/CipherInputStream.java ../../../src/share/classes/javax/crypto/CryptoAllPermission.java ../../../src/share/classes/javax/crypto/SecretKeyFactorySpi.java ../../../src/share/classes/javax/crypto/SealedObject.java ../../../src/share/classes/javax/crypto/IllegalBlockSizeException.java ../../../src/share/classes/javax/crypto/KeyGeneratorSpi.java ../../../src/share/classes/javax/crypto/MacSpi.java ../../../src/share/classes/javax/crypto/KeyGenerator.java ../../../src/share/classes/javax/crypto/ExemptionMechanism.java ../../../src/share/classes/javax/crypto/Cipher.java ../../../src/share/classes/javax/crypto/CryptoPermission.java ../../../src/share/classes/javax/crypto/NullCipherSpi.java ../../../src/share/classes/javax/crypto/KeyAgreement.java ../../../src/share/classes/sun/security/internal/interfaces/TlsMasterSecret.java ../../../src/share/classes/sun/security/internal/spec/TlsMasterSecretParameterSpec.java ../../../src/share/classes/sun/security/internal/spec/TlsKeyMaterialSpec.java ../../../src/share/classes/sun/security/internal/spec/TlsRsaPremasterSecretParameterSpec.java ../../../src/share/classes/sun/security/internal/spec/TlsPrfParameterSpec.java ../../../src/share/classes/sun/security/internal/spec/TlsKeyMaterialParameterSpec.java # Running javac: /java/re/jdk/1.7.0/promoted/latest/binaries/solaris-i586/bin/javac -J-XX:ThreadStackSize=768 -J-client -J-Xmx896m -J-Xms128m -J-XX:PermSize=32m -J-XX:MaxPermSize=160m -source 1.5 -target 5 -encoding ascii -Xbootclasspath:../../../build/solaris-i586/classes -sourcepath ../../../build/solaris-i586/gensrc:../../../src/solaris/classes:../../../src/share/classes -d ../../../build/solaris-i586/tmp/sun/javax.crypto/classes @../../../build/solaris-i586/tmp/sun/javax.crypto/.classes.list Note: Some input files use unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. rm -f -r ../../../build/solaris-i586/classes/javax/crypto ../../../build/solaris-i586/classes/sun/security/internal/interfaces ../../../build/solaris-i586/classes/sun/security/internal/spec /usr/bin/mkdir -p ../../../build/solaris-i586/tmp/sun/javax.crypto rm -f ../../../build/solaris-i586/tmp/sun/javax.crypto/manifest.mf ( /usr/bin/sed "s/@@RELEASE@@/1.7.0-internal/" ../../../make/tools/manifest.mf; \ /usr/bin/echo "Extension-Name: javax.crypto"; \ /usr/bin/echo "Implementation-Vendor-Id: com.sun"; ) > ../../../build/solaris-i586/tmp/sun/javax.crypto/manifest.mf /usr/bin/mkdir -p ../../../build/solaris-i586/tmp/sun/javax.crypto/unsigned rm -f ../../../build/solaris-i586/tmp/sun/javax.crypto/unsigned/jce.jar /java/re/jdk/1.6.0/archive/fcs/binaries/solaris-i586/bin/jar cmf ../../../build/solaris-i586/tmp/sun/javax.crypto/manifest.mf ../../../build/solaris-i586/tmp/sun/javax.crypto/unsigned/jce.jar -C ../../../build/solaris-i586/tmp/sun/javax.crypto/classes javax/crypto -C ../../../build/solaris-i586/tmp/sun/javax.crypto/classes sun/security/internal/interfaces -C ../../../build/solaris-i586/tmp/sun/javax.crypto/classes sun/security/internal/spec \ -J-client -J-Xmx896m -J-Xms128m -J-XX:PermSize=32m -J-XX:MaxPermSize=160m /usr/bin/cp -r ../../../build/solaris-i586/tmp/sun/javax.crypto/classes/* ../../../build/solaris-i586/classes /usr/bin/mkdir -p ../../../build/solaris-i586/lib rm -f ../../../build/solaris-i586/lib/jce.jar /usr/bin/cp ../../../build/solaris-i586/tmp/sun/javax.crypto/unsigned/jce.jar ../../../build/solaris-i586/lib/jce.jar /usr/bin/mkdir -p ../../../build/solaris-i586/tmp/sun/javax.crypto/unsigned/policy/unlimited rm -f ../../../build/solaris-i586/tmp/sun/javax.crypto/unsigned/policy/unlimited/US_export_policy.jar /java/re/jdk/1.6.0/archive/fcs/binaries/solaris-i586/bin/jar cmf policy/unlimited/UNLIMITED ../../../build/solaris-i586/tmp/sun/javax.crypto/unsigned/policy/unlimited/US_export_policy.jar \ -C policy/unlimited default_US_export.policy \ -J-client -J-Xmx896m -J-Xms128m -J-XX:PermSize=32m -J-XX:MaxPermSize=160m /usr/bin/mkdir -p ../../../build/solaris-i586/tmp/sun/javax.crypto/unsigned/policy/unlimited rm -f ../../../build/solaris-i586/tmp/sun/javax.crypto/unsigned/policy/unlimited/local_policy.jar /java/re/jdk/1.6.0/archive/fcs/binaries/solaris-i586/bin/jar cmf policy/unlimited/UNLIMITED ../../../build/solaris-i586/tmp/sun/javax.crypto/unsigned/policy/unlimited/local_policy.jar \ -C policy/unlimited default_local.policy \ -J-client -J-Xmx896m -J-Xms128m -J-XX:PermSize=32m -J-XX:MaxPermSize=160m /usr/bin/mkdir -p ../../../build/solaris-i586/tmp/sun/javax.crypto/unsigned/policy/limited rm -f ../../../build/solaris-i586/tmp/sun/javax.crypto/unsigned/policy/limited/US_export_policy.jar /usr/bin/cp ../../../build/solaris-i586/tmp/sun/javax.crypto/unsigned/policy/unlimited/US_export_policy.jar ../../../build/solaris-i586/tmp/sun/javax.crypto/unsigned/policy/limited/US_export_policy.jar /usr/bin/mkdir -p ../../../build/solaris-i586/tmp/sun/javax.crypto/unsigned/policy/limited rm -f ../../../build/solaris-i586/tmp/sun/javax.crypto/unsigned/policy/limited/local_policy.jar /java/re/jdk/1.6.0/archive/fcs/binaries/solaris-i586/bin/jar cmf policy/limited/LIMITED ../../../build/solaris-i586/tmp/sun/javax.crypto/unsigned/policy/limited/local_policy.jar \ -C policy/limited default_local.policy \ -C policy/limited exempt_local.policy \ -J-client -J-Xmx896m -J-Xms128m -J-XX:PermSize=32m -J-XX:MaxPermSize=160m /usr/bin/mkdir -p ../../../build/solaris-i586/lib/security rm -f \ ../../../build/solaris-i586/lib/security/US_export_policy.jar \ ../../../build/solaris-i586/lib/security/local_policy.jar /usr/bin/cp ../../../build/solaris-i586/tmp/sun/javax.crypto/unsigned/policy/limited/US_export_policy.jar ../../../build/solaris-i586/tmp/sun/javax.crypto/unsigned/policy/limited/local_policy.jar ../../../build/solaris-i586/lib/security > === From arnd-hendrik.mathias at nefkom.net Sun Dec 23 15:48:46 2007 From: arnd-hendrik.mathias at nefkom.net (Arnd-Hendrik Mathias) Date: Sun, 23 Dec 2007 16:48:46 +0100 Subject: JDK 7 build 24 is available at the openjdk.java.net website In-Reply-To: <476B1835.6010408@sun.com> References: <47563FCC.4080907@sun.com> <475D7AB3.8060000@redhat.com> <475DDA7F.1080302@sun.com> <47606D05.2040709@nefkom.net> <476AE241.1050801@sun.com> <476AF2A7.1000009@nefkom.net> <476B1835.6010408@sun.com> Message-ID: <476E835E.1020308@nefkom.net> Hi Andreas, Andreas Sterbenz wrote: > See below output of a rebuild of make/javax/crypto after a previous > build of a fresh clone of the Mercurial jdk repository. If you see > something different, that must be related to your build environment, > e.g. version of make used, out of date binary plugs, etc. Since my output looked quite different, it was not really comparable with the correct output you posted. After further examination of the make-/build environment, I found out that the make environment assumes some tools to reside in /usr/bin per default. I found that this can be overwritten by the ALT_USRBIN_PATH variable. However, if tools reside in different directories (/bin /usr/bin ...) setting ALT_USRBIN_PATH= and having the PATH variable set to have all these tools available directly may be the method the most likely to work. In my special case "head" was missing, residing in /bin on my system. After changing this setting jdk7 build process ran a bit longer, until it ran into another problem: Linking of a mass of object files from the jdk/make/sun/splashscreen directory results in a number of missing symbols from the png library: /opt/jdk/openjdk-1.7.0_b24/tmp/sun/sun.awt/splashscreen/obj64/png.o: In function `png_init_mmx_flags': png.c:(.text+0xbc): undefined reference to `png_mmx_support' /opt/jdk/openjdk-1.7.0_b24/tmp/sun/sun.awt/splashscreen/obj64/pngpread.o: In function `png_push_process_row': pngpread.c:(.text+0x89e): undefined reference to `png_read_filter_row' pngpread.c:(.text+0x964): undefined reference to `png_do_read_interlace' /opt/jdk/openjdk-1.7.0_b24/tmp/sun/sun.awt/splashscreen/obj64/pngpread.o: In function `png_progressive_combine_row': pngpread.c:(.text+0x141): undefined reference to `png_combine_row' /opt/jdk/openjdk-1.7.0_b24/tmp/sun/sun.awt/splashscreen/obj64/pngread.o: In function `png_read_row': pngread.c:(.text+0xb64): undefined reference to `png_combine_row' pngread.c:(.text+0xb79): undefined reference to `png_combine_row' pngread.c:(.text+0xc20): undefined reference to `png_read_filter_row' pngread.c:(.text+0xc6a): undefined reference to `png_combine_row' pngread.c:(.text+0xc92): undefined reference to `png_combine_row' pngread.c:(.text+0xc9f): undefined reference to `png_do_read_interlace' pngread.c:(.text+0xd10): undefined reference to `png_combine_row' collect2: ld returned 1 exit status Extending the OTHER_LDLIBS variable in the jdk/make/sun/splashscreen/Makefile by -lpng helps to remove the undefined reference to `png_mmx_support'. The other undefined references remain. After taking a closer look at the libpng.so by e.g. nm /usr/lib/libpng.so | grep png_read_filter_row I found out that these symbols exist in the text segment, but only as internal symbols: 0000000000007de0 t png_read_filter_row How come they can link in your environment at all? Have you built your libpng in a special way and is there a workaround to replace these library calls by OpenJDK-internal implementations or something likewise? Anyway, I still got one other question: What is the background of all of those overwrite variables in the jdk/make/common/Defs-linux.gmk? Omitting the overwrite directive would ease redefining some environment definitions like OPENWIN_HOME or OPENWIN_LIB from command line, for which no ALT_... variables exist. Best regards Arnd-Hendrik From Anthony.Petrov at Sun.COM Sun Dec 23 18:48:25 2007 From: Anthony.Petrov at Sun.COM (Anthony Petrov) Date: Sun, 23 Dec 2007 21:48:25 +0300 Subject: JDK 7 build 24 is available at the openjdk.java.net website In-Reply-To: <476E835E.1020308@nefkom.net> References: <47563FCC.4080907@sun.com> <475D7AB3.8060000@redhat.com> <475DDA7F.1080302@sun.com> <47606D05.2040709@nefkom.net> <476AE241.1050801@sun.com> <476AF2A7.1000009@nefkom.net> <476B1835.6010408@sun.com> <476E835E.1020308@nefkom.net> Message-ID: <476EAD79.7020509@sun.com> Concerning the libpng trouble at the 64-bit environment: this is a known issue, and it had already been fixed, though not integrated yet. I hope that it will hit the master repository as soon as pushes are allowed. PS. Yes, even Sun employees cannot push their fixes into the JDK 7 yet. :) -- best regards, Anthony On 12/23/2007 6:48 PM Arnd-Hendrik Mathias wrote: > Hi Andreas, > > Andreas Sterbenz wrote: >> See below output of a rebuild of make/javax/crypto after a previous >> build of a fresh clone of the Mercurial jdk repository. If you see >> something different, that must be related to your build environment, >> e.g. version of make used, out of date binary plugs, etc. > Since my output looked quite different, it was not really comparable > with the correct output you posted. After further examination of the > make-/build environment, I found out that the make environment assumes > some tools to reside in /usr/bin per default. I found that this can be > overwritten by the ALT_USRBIN_PATH variable. However, if tools reside in > different directories (/bin /usr/bin ...) setting > > ALT_USRBIN_PATH= > > and having the PATH variable set to have all these tools available > directly may be the method the most likely to work. In my special case > "head" was missing, residing in /bin on my system. > > After changing this setting jdk7 build process ran a bit longer, until > it ran into another problem: > Linking of a mass of object files from the jdk/make/sun/splashscreen > directory results in a number of missing symbols from the png library: > > /opt/jdk/openjdk-1.7.0_b24/tmp/sun/sun.awt/splashscreen/obj64/png.o: In > function `png_init_mmx_flags': > png.c:(.text+0xbc): undefined reference to `png_mmx_support' > /opt/jdk/openjdk-1.7.0_b24/tmp/sun/sun.awt/splashscreen/obj64/pngpread.o: > In function `png_push_process_row': > pngpread.c:(.text+0x89e): undefined reference to `png_read_filter_row' > pngpread.c:(.text+0x964): undefined reference to `png_do_read_interlace' > /opt/jdk/openjdk-1.7.0_b24/tmp/sun/sun.awt/splashscreen/obj64/pngpread.o: > In function `png_progressive_combine_row': > pngpread.c:(.text+0x141): undefined reference to `png_combine_row' > /opt/jdk/openjdk-1.7.0_b24/tmp/sun/sun.awt/splashscreen/obj64/pngread.o: > In function `png_read_row': > pngread.c:(.text+0xb64): undefined reference to `png_combine_row' > pngread.c:(.text+0xb79): undefined reference to `png_combine_row' > pngread.c:(.text+0xc20): undefined reference to `png_read_filter_row' > pngread.c:(.text+0xc6a): undefined reference to `png_combine_row' > pngread.c:(.text+0xc92): undefined reference to `png_combine_row' > pngread.c:(.text+0xc9f): undefined reference to `png_do_read_interlace' > pngread.c:(.text+0xd10): undefined reference to `png_combine_row' > collect2: ld returned 1 exit status > > Extending the OTHER_LDLIBS variable in the > jdk/make/sun/splashscreen/Makefile by > > -lpng > > helps to remove the undefined reference to `png_mmx_support'. The other > undefined references remain. > After taking a closer look at the libpng.so by e.g. > > nm /usr/lib/libpng.so | grep png_read_filter_row > > I found out that these symbols exist in the text segment, but only as > internal symbols: > > 0000000000007de0 t png_read_filter_row > > How come they can link in your environment at all? Have you built your > libpng in a special way and is there a workaround to replace these > library calls by OpenJDK-internal implementations or something likewise? > > Anyway, I still got one other question: What is the background of all of > those overwrite variables in the jdk/make/common/Defs-linux.gmk? > Omitting the overwrite directive would ease redefining some environment > definitions like OPENWIN_HOME or OPENWIN_LIB from command line, for > which no ALT_... variables exist. > Best regards > > Arnd-Hendrik From arnd-hendrik.mathias at nefkom.net Sun Dec 23 19:27:42 2007 From: arnd-hendrik.mathias at nefkom.net (Arnd-Hendrik Mathias) Date: Sun, 23 Dec 2007 20:27:42 +0100 Subject: JDK 7 build 24 is available at the openjdk.java.net website In-Reply-To: <476EAD79.7020509@sun.com> References: <47563FCC.4080907@sun.com> <475D7AB3.8060000@redhat.com> <475DDA7F.1080302@sun.com> <47606D05.2040709@nefkom.net> <476AE241.1050801@sun.com> <476AF2A7.1000009@nefkom.net> <476B1835.6010408@sun.com> <476E835E.1020308@nefkom.net> <476EAD79.7020509@sun.com> Message-ID: <476EB6AE.1020507@nefkom.net> Ah, so thanks a lot! Is there some way to get informed as soon as the fix is available? Anthony Petrov wrote: > Concerning the libpng trouble at the 64-bit environment: this is a > known issue, and it had already been fixed, though not integrated yet. > I hope that it will hit the master repository as soon as pushes are > allowed. > > PS. Yes, even Sun employees cannot push their fixes into the JDK 7 > yet. :) From Tim.Bell at Sun.COM Sun Dec 23 20:01:39 2007 From: Tim.Bell at Sun.COM (Tim Bell) Date: Sun, 23 Dec 2007 12:01:39 -0800 Subject: JDK 7 build 24 is available at the openjdk.java.net website In-Reply-To: <476EB6AE.1020507@nefkom.net> References: <47563FCC.4080907@sun.com> <475D7AB3.8060000@redhat.com> <475DDA7F.1080302@sun.com> <47606D05.2040709@nefkom.net> <476AE241.1050801@sun.com> <476AF2A7.1000009@nefkom.net> <476B1835.6010408@sun.com> <476E835E.1020308@nefkom.net> <476EAD79.7020509@sun.com> <476EB6AE.1020507@nefkom.net> Message-ID: <476EBEA3.1080906@sun.com> Arnd-Hendrik Mathias wrote: > Ah, so thanks a lot! Is there some way to get informed as soon as the > fix is available? Subscribe to the mailing list for the group(s) you are interested in. hg push notification mails will soon be sent to the relevant lists for that team's gate [1]. http://mail.openjdk.java.net/mailman/listinfo Notification of pushes to the JDK7 master forest will go to jdk7-gk at openjdk.java.net Tim [1] http://hg.openjdk.java.net/