From Ray.Gans at Sun.COM Thu Jan 3 08:32:42 2008 From: Ray.Gans at Sun.COM (Ray Gans) Date: Thu, 03 Jan 2008 00:32:42 -0800 Subject: Feedback request: OpenJDK Community Innovator's Challenge Grants Message-ID: As you may have heard, Sun has announced the Community Innovation Awards Program (see http://www.sun.com/software/opensource/awards/) for several open source communities that we sponsor. The goal of this program is to foster and recognize innovation in these communities by offering grants/prizes to new efforts that will have an strong impact. The OpenJDK program will be called the OpenJDK Community Innovator's Challenge Grants (OCICG). We want to encourage developers to collaborate and creatively solve key problems facing the OpenJDK Community, initiate new projects that innovate on the OpenJDK code base, leverage the code for new uses, develop curricula and training, and port the code to new platforms, all to further the objectives of the OpenJDK Community in developing and disseminating compatible, free software implementations of the Java SE platform. We'd also like your help to make this program effective, valuable and fun for non- Sun participants. To implement this program, Sun will award several large grants to a few projects that can be completed by August 2008. Help us determine how to best select project proposals for consideration and allocate the money (we have approximately $175,000 to distribute). Here is how we're thinking it should work (though this may change based on your feedback): - On January 14, 2008 Sun will kick off the OCICG program and announce the criteria that will be used to select a set number of projects. OpenJDK participants will be encouraged to submit proposals for a project they want to work on. Proposals could be made by groups of individuals, existing F/OSS teams, companies/organizations, Java User Groups, etc. - Proposals will be accepted until March 3, 2008. At this time the proposals will be judged by a team of people (we're thinking 2 from Sun and 3 from outside Sun). We're also thinking of accepting only seven or less proposals. - Accepted proposals will be announced on March 17 ,2008 with all project work to be completed by August 4, 2008. - Awards will be delivered to completed projects on August 18, 2008 with cash amounts determined by the judges. We're thinking that the most valuable projects should be awarded a larger prize than others ? though all completed projects will be given a cash award. Note that no money will be available until August and all awards must be distributed at that time. Obviously, judges and Sun personnel will be ineligible for any cash awards. Scope and Constraints - The program will begin in January 2008 and end in August 2008. - Since this program is technically an international contest, there are strict rules by which it must be run. For example, participation will be restricted to countries that allow these kinds of contests. We would like to make the program open to as many countries as possible, however, since every country has different laws and requirements, we cannot accommodate everyone. We won't have the exact country list until mid-January. Other rules may also apply that limit what can and can't be done as part of this program. - Projects can only have limited dependence on Sun involvement/ participation. This is for fairness across all projects. Likewise, projects cannot require a commitment by Sun for significant time/ effort for success since we cannot guarantee adequate Sun resources will be available -- for example, a project to build a better bug database for OpenJDK, while very useful, would require heavy involvement by Sun personnel to integrate it with Sun's internal bug management systems. - All project code (if any) must be contributed to Sun under the Sun Contributor Agreement (see http://www.sun.com/software/opensource/ sca.pdf). We are interested in what the OpenJDK community thinks about the OCICG. You can help by providing input on any of the following questions (and whatever else you'd like to comment on). - What kind of projects do you think would be valuable to the OpenJDK community? - What selection criteria should be used to choose the best proposals? - How many proposals should be accepted? - Do you think the OpenJDK community at large should have any input into the proposal selection process? - Who you think would make good objective judges for the program and why? - What thoughts do you have about how the proposal selection process should be handled? - Do you think the OpenJDK community at large should have any input into selecting projects that really excel (and be awarded larger prizes)? - What criteria should be used to determine the payout for cash awards? - How should abandoned or non-completed projects be handled and what should constitute a "completed" project? - How should awards be handled for project team members who drop out or are added after a proposal is accepted? Please send your thoughts to discuss at openjdk.java.net. Thanks, The OpenJDK team at Sun -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnu_andrew at member.fsf.org Thu Jan 3 09:23:35 2008 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Thu, 3 Jan 2008 09:23:35 +0000 Subject: Feedback request: OpenJDK Community Innovator's Challenge Grants In-Reply-To: References: Message-ID: <17c6771e0801030123l1c6b9af9l735db751b7764743@mail.gmail.com> On 03/01/2008, Ray Gans wrote: > > > As you may have heard, Sun has announced the Community Innovation Awards > Program (see *http://www.sun.com/software/opensource/awards/*) > for several open source communities that we sponsor. The goal of this > program is to foster and recognize innovation in these communities by > offering grants/prizes to new efforts that will have an strong impact. > > The OpenJDK program will be called the OpenJDK Community Innovator's > Challenge Grants (OCICG). We want to encourage developers to collaborate and > creatively solve key problems facing the OpenJDK Community, initiate new > projects that innovate on the OpenJDK code base, leverage the code for new > uses, develop curricula and training, and port the code to new platforms, > all to further the objectives of the OpenJDK Community in developing and > disseminating compatible, free software implementations of the Java SE > platform. We'd also like your help to make this program effective, valuable > and fun for non-Sun participants. > > To implement this program, Sun will award several large grants to a few > projects that can be completed by August 2008. Help us determine how to best > select project proposals for consideration and allocate the money (we have > approximately $175,000 to distribute). > > Here is how we're thinking it should work (though this may change based on > your feedback): > > - On January 14, 2008 Sun will kick off the OCICG program and announce the > criteria that will be used to select a set number of projects. OpenJDK > participants will be encouraged to submit proposals for a project they want > to work on. Proposals could be made by groups of individuals, existing F/OSS > teams, companies/organizations, Java User Groups, etc. > - Proposals will be accepted until March 3, 2008. At this time the > proposals will be judged by a team of people (we're thinking 2 from Sun and > 3 from outside Sun). We're also thinking of accepting only seven or less > proposals. > - Accepted proposals will be announced on March 17 ,2008 with all project > work to be completed by August 4, 2008. > - Awards will be delivered to completed projects on August 18, 2008 with > cash amounts determined by the judges. We're thinking that the most valuable > projects should be awarded a larger prize than others ? though all completed > projects will be given a cash award. Note that no money will be available > until August and all awards must be distributed at that time. Obviously, > judges and Sun personnel will be ineligible for any cash awards. > > Scope and Constraints > - The program will begin in January 2008 and end in August 2008. > - Since this program is technically an international contest, there are > strict rules by which it must be run. For example, participation will be > restricted to countries that allow these kinds of contests. We would like to > make the program open to as many countries as possible, however, since every > country has different laws and requirements, we cannot accommodate everyone. > We won't have the exact country list until mid-January. Other rules may also > apply that limit what can and can't be done as part of this program. > - Projects can only have limited dependence on Sun > involvement/participation. This is for fairness across all projects. > Likewise, projects cannot require a commitment by Sun for significant > time/effort for success since we cannot guarantee adequate Sun resources > will be available -- for example, a project to build a better bug database > for OpenJDK, while very useful, would require heavy involvement by Sun > personnel to integrate it with Sun's internal bug management systems. > - All project code (if any) must be contributed to Sun under the Sun > Contributor Agreement (see *http://www.sun.com/software/opensource/sca.pdf > * ). > > We are interested in what the OpenJDK community thinks about the OCICG. > You can help by providing input on any of the following questions (and > whatever else you'd like to comment on). > - What kind of projects do you think would be valuable to the OpenJDK > community? > - What selection criteria should be used to choose the best proposals? > - How many proposals should be accepted? > - Do you think the OpenJDK community at large should have any input into > the proposal selection process? > - Who you think would make good objective judges for the program and why? > - What thoughts do you have about how the proposal selection process > should be handled? > - Do you think the OpenJDK community at large should have any input into > selecting projects that really excel (and be awarded larger prizes)? > - What criteria should be used to determine the payout for cash awards? > - How should abandoned or non-completed projects be handled and what > should constitute a "completed" project? > - How should awards be handled for project team members who drop out or > are added after a proposal is accepted? > > Please send your thoughts to *discuss at openjdk.java.net* > . > > Thanks, > > The OpenJDK team at Sun > > My initial thought is that OpenJDK will suffer from still being a fairly nascent project. Without being disparaging to all the great work done by Sun in releasing the OpenJDK source code (which must have been and still is a huge task), there isn't yet much of an OpenJDK community, other than that which it has adopted from existing projects such as GNU Classpath. Is there really the infrastructure in place to have a timed project take place? That said, I'd love to see it happen and think it would be a great way of fostering such a community if it could be made to happen. As regards projects, I think you have to just give fairly general criteria and see what gets proposed. Only then can you really decide on appropriateness and the exact criteria to use. Again, I think the problem will be that, at least my impression so far, is that there are no really active unfunded projects taking place which really interact with the core OpenJDK code base and bring Sun and external developers together. There is of course a porting effort and the framebuffer toolkit project which are both external, so there may be some interest there. The other projects listed on the OpenJDK site are very much internal Sun projects still; I'm on many of the mailing lists (too many really for most people) and I don't see a lot of traffic on most of them. Certainly nothing like patches, etc. but that's because the public repositories have only just become available. I don't want to sound negative, but when you compare OpenJDK with OpenSolaris, which is also taking part, there's a lot more activity already in existence which will make things a lot easier for them. One solution I think is to give each successful project it's own tree or forest (depending on the scale of the project), just like each team does now. Encourage activity there and interaction between the participants. This is certainly important as you seem to be proposing this to groups rather than individuals, which I think is a plus. Allow frequent commits there (with the appropriate SCA in place of course) and then handle the task of whether or not to feed the result back to the main project in August. When it comes to evaluating success, any successful project needs to have clear defined goals for judging this as part of the proposal. Having the code in a public repository means that both incomplete and complete projects will be accessible afterwards, even if the participants lose interest and disappear. The community can then decide how to handle the resulting work most effectively. As to payouts, it really depends on who you are trying to attract. With Google's Summer of Code, they aim this at individual students where the money is the primary incentive and so the reward is predefined and given in chunks, some of which is awarded before the project even begins (a project that fails midway, for example, still gets the student $2500 out of $4500). My perception of Sun's awards is more of one of bounties for groups of participants, where I think the award can be justifiably set on evaluation of the project and its merit, and then used as a bounty to be awarded only on its successful completion. The scheme would also be helped a lot if the OpenJDK community came up with some suggested projects with appropriate bounties to encourage contributions. It should still be made clear that new proposals are welcome, but this makes it easier for people to get involved who only have a vague idea about what the OpenJDK needs. I hope that's of some help, -- 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 openjdk at jazillian.com Thu Jan 3 19:38:50 2008 From: openjdk at jazillian.com (Andy Tripp) Date: Thu, 03 Jan 2008 14:38:50 -0500 Subject: Feedback request: OpenJDK Community Innovator's Challenge Grants In-Reply-To: References: Message-ID: <477D39CA.6030003@jazillian.com> An HTML attachment was scrubbed... URL: From Tom.Marble at Sun.COM Thu Jan 3 22:44:35 2008 From: Tom.Marble at Sun.COM (Tom Marble) Date: Thu, 03 Jan 2008 16:44:35 -0600 Subject: Source tarballs In-Reply-To: <475DD81E.3040806@sun.com> References: <475C15F7.7060808@nefkom.net> <475D7D5D.6010602@Sun.COM> <475DCC6D.7020404@nefkom.net> <475DD72F.5030701@sun.com> <475DD81E.3040806@sun.com> Message-ID: <477D6553.5000509@sun.com> Andreas Sterbenz wrote: > 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). I'd like to ask if we (Sun) can reconsider publishing one (1) source tarball for promoted builds. This question has come up in the past in the context of many Free Software distro build daemons which proscribe live Internet access during binary builds. Usually there is a "source package" which is uploaded to the build daemon which specifies any build time dependencies (e.g. specific compilers, header file packages) and includes the upstream tarball(s). This question came up again, today, on IRC in the context of building OpenJDK for stable distros. Developers stated that it is very desirable for non-root users to be able to build OpenJDK on stable distros by making only one simple request to their system administrator for a list of build dependency packages. While the user may have Internet access she cannot specify packages which were not part of the stable release. Without an OpenJDK upstream tarball this means that the typical way of getting the OpenJDK source is with "hg fclone" [0]. Which means that one would need Mercurial [1] with the Forest Extension [2] (and Mercurial needs python 2.4). This is complicated by the fact that the Forest Extension (currently, unversioned) is only supported on Mercurial 0.9.3, 0.9.4, and 0.9.5. If we take such a stable distribution, Debian etch [3] for example, then we find the following: python 2.4.4 http://packages.debian.org/etch/python/python 2.5 http://packages.debian.org/etch/python/python2.5 hg 0.9.1 http://packages.debian.org/etch/mercurial 0.9.5 http://packages.debian.org/etch-backports/mercurial BACKPORT forest (no version number) requires Mercurial 0.9.3, 0.9.4, or 0.9.5. This looks promising, except I learned that the "backports" repository is not considered part of the primary distribution and thus could not be used as a build dependency. The other problem is that getting forest.py configured for the system "hg" (i.e. not requiring every user to fix their ~/.hgrc) would require a new package (i.e. mercurial-forest) which is also not possible because such a package did not exist (and still does not) at the time the stable distribution was frozen. In distributions where hg 0.9.5 is available then there is solution (albeit less desirable) to have the user add forest.py to ~/bin and the path to ~/.hgrc (or equivalent in the build directory). Another possible solution, along the lines of what Andreas suggested, would be to grab the 7 tarballs from upstream and then combine them. If I understand this correctly, however, it would require scripting (or publishing) for each promoted build tag a set of changesets for each subordinate repository (e.g. b24 [4]). Compared to this complexity of these solutions if we simply published one tarball then supporting hg 0.9.5 and the forest extension would not be a build requirement. Please let me know what you think (esp. if I have characterized the solutions accurately). Regards, --Tom [0] http://weblogs.java.net/blog/kellyohair/archive/2007/12/openjdk_mercuri_7.html [1] http://www.selenic.com/mercurial/wiki/ [2] http://www.selenic.com/mercurial/wiki/index.cgi/ForestExtension [3] http://www.debian.org/releases/etch/ [4] http://hg.openjdk.java.net/jdk7/jdk7/log/cfeea66a3fa8 From neojia at gmail.com Thu Jan 3 22:53:21 2008 From: neojia at gmail.com (Neo Jia) Date: Thu, 3 Jan 2008 14:53:21 -0800 Subject: Feedback request: OpenJDK Community Innovator's Challenge Grants In-Reply-To: <477D39CA.6030003@jazillian.com> References: <477D39CA.6030003@jazillian.com> Message-ID: <5d649bdb0801031453j4801ba55r7bfc844c7e698780@mail.gmail.com> On Jan 3, 2008 11:38 AM, Andy Tripp wrote: > > Hi Ray, > Here are my thoughts... > > Ray Gans wrote: > > > Proposals could be made by groups of individuals, existing F/OSS teams, > companies/organizations, Java User Groups, etc. > Presumably also individuals, right? > > > - Proposals will be accepted until March 3, 2008. At this time the proposals > will be judged by a team of people (we're thinking 2 from Sun and 3 from > outside Sun). Make this "group of 5" be an OpenJDK group, with all (or most) > discussions on an open mailing list. > > > > Note that no money will be available until August and all awards must be > distributed at that time. > It might be worthwhile to have at least one fairly formal milestone for > each project, so the project developers can be sure they're "on the right > track". > > > > - Projects can only have limited dependence on Sun > involvement/participation. This is for fairness across all projects. > Likewise, projects cannot require a commitment by Sun for significant > time/effort for success since we cannot guarantee adequate Sun resources > will be available -- for example, a project to build a better bug database > for OpenJDK, while very useful, would require heavy involvement by Sun > personnel to integrate it with Sun's internal bug management systems. > > Each proposal should be required to spell out exactly what it requires from > Sun. Using your bug database project example, it might require a snapshot of > the current Sun bug database as simple comma-separated values. One snapshot > at the start of the project and then another snapshot in August to cut over > to the new database. > > > > > > > > - What kind of projects do you think would be valuable to the OpenJDK I can provide something I have when I hack the jdk especially GC part, which might help somebody to start their jdk projects. Where should I put them? It is on my personal wiki now. Thanks, Neo > community? A "How to Hack the OpenJDK" book. > A better bug database (obviously, you've already thought of that :) ). > Massive improvements to the build system (Kelly O'Hair on steriods). > A remote build system that lets a developer make changes locally and submit > changes to a server and get back executables for his platform, without him > having to know anything about how the build works. > A version of Android based on OpenJDK. > > > - What selection criteria should be used to choose the best proposals? The > group should just have some general criteria statement like "Projects that > advance the goals of the OpenJDK project" and then reference a link that > spells out the goals of OpenJDK. Unfortunately, the only such like I can > find is this: http://www.sun.com/software/opensource/java/faq.jsp#e > So maybe spell out the goals yourselves: "increased adoption and increased > innovation" > > > - How many proposals should be accepted? Seven or less sounds good. > > > - Do you think the OpenJDK community at large should have any input into > the proposal selection process? Other than to allow anyone to participate in > a mailing list discussion, no. > > > - Who you think would make good objective judges for the program and why? > Inside Sun, someone like you and a Mark Reinhold/Danny Coward type of > person. Outside Sun, you just want to be sure to pick people who want to > advance OpenJDK itself, as opposed to pushing some social agenda or some > OpenJDK alternative. > > > - What thoughts do you have about how the proposal selection process should > be handled? After the proposal submission period ends, publish the > proposals, allow a couple weeks of discussion on a mailing list, > and then the "group of 5" votes. If greater than 7 submissions, each person > may only vote for 7 proposals and > the 7 proposals with the most votes win. If 7 or less, A yes/no vote on > each. To break down the money awards, > after discussion, any of the 5 can submit a proposal for how to split the > awards. > The first such proposal to get 3 yes votes wins. > > > - Do you think the OpenJDK community at large should have any input into > selecting projects that really excel (and be awarded larger prizes)? Again, > hold the discussions on open mailing lists and allow anyone to comment. > > > - What criteria should be used to determine the payout for cash awards? Use > some vague wording such as "Award amount will be based on potential value to > the OpenJDK community". > And I would keep it to being based on value, not difficulty. No need for a > "degree of difficulty" modifier. > > > - How should abandoned or non-completed projects be handled and what should > constitute a "completed" project? I presume accepted project participants > will have to sign something simple that says they will do their best to > complete > the project by a certain date. It should also mention that if they can't > complete the project, they must post a notice > on the mailing list. > > > - How should awards be handled for project team members who drop out or are > added after a proposal is accepted? Ugh. That's a tough one. I guess that > this thing that accepted projects would have to sign should designate a > single > entity (person or corp) that will receive the money, and that Sun will > award the money to that entity. Who gets > added or deleted or whatever from the project team is then none of Sun's > business. You sure don't want to > try to micromanage that. > > So, this "You've been accepted" document might contain: > * notice that you've been accepted > * expectation that you'll finish by $DATE, that it will be reasonable > quality, and it will be substantially what's in the proposal. > * promise that Sun will pay the amount of $AMOUNT on date $DATE to $ENTITY > upon successful completion > * description of any milestones > * mention that ultimately, "successful completion" will be determined by > this "group of 5". > * mention that Sun stays out of issues about who is on the project > * mention any help that Sun agrees to (e.g. one bug database dump at start, > another at end) > * any other required legal mumbo jumbo > > > > > Please send your thoughts to discuss at openjdk.java.net. > > > Thanks, > > > The OpenJDK team at Sun Good Luck with it! > Andy > > -- I would remember that if researchers were not ambitious probably today we haven't the technology we are using! From Xiomara.Jayasena at Sun.COM Thu Jan 3 23:49:29 2008 From: Xiomara.Jayasena at Sun.COM (Xiomara Jayasena) Date: Thu, 03 Jan 2008 15:49:29 -0800 Subject: Source tarballs In-Reply-To: <477D6553.5000509@sun.com> References: <475C15F7.7060808@nefkom.net> <475D7D5D.6010602@Sun.COM> <475DCC6D.7020404@nefkom.net> <475DD72F.5030701@sun.com> <475DD81E.3040806@sun.com> <477D6553.5000509@sun.com> Message-ID: <477D7489.9000205@sun.com> Hi Tom, Happy New Year! Tom Marble wrote: > > I'd like to ask if we (Sun) can reconsider publishing one (1) > source tarball for promoted builds. > Yes it is definitely being considered -- as it makes sense, especially if it is difficult for people to pull down the 7 tar balls that currently exist now. There are a couple of ways to go about this so that will need to be sorted out. Best regards, -Xiomara -------------- next part -------------- An HTML attachment was scrubbed... URL: From Weijun.Wang at Sun.COM Thu Jan 3 23:53:55 2008 From: Weijun.Wang at Sun.COM (Max (Weijun) Wang) Date: Fri, 04 Jan 2008 07:53:55 +0800 Subject: Source tarballs In-Reply-To: <477D7489.9000205@sun.com> References: <475C15F7.7060808@nefkom.net> <475D7D5D.6010602@Sun.COM> <475DCC6D.7020404@nefkom.net> <475DD72F.5030701@sun.com> <475DD81E.3040806@sun.com> <477D6553.5000509@sun.com> <477D7489.9000205@sun.com> Message-ID: <04B63CDE-8044-42A5-9B32-0FD6B8CC391C@sun.com> Is it easy to hack the hg HTTP server to let it understand forest? Max On Jan 4, 2008, at 7:49 AM, Xiomara Jayasena wrote: > > Hi Tom, > > Happy New Year! > > Tom Marble wrote: >> I'd like to ask if we (Sun) can reconsider publishing one (1) >> source tarball for promoted builds. > > Yes it is definitely being considered -- as it makes sense, > especially if it is difficult for people to pull down the 7 tar > balls that currently exist now. There are a couple of ways to go > about this so that will need to be sorted out. > > Best regards, > -Xiomara > > From landonf at threerings.net Fri Jan 4 00:14:00 2008 From: landonf at threerings.net (Landon Fuller) Date: Thu, 3 Jan 2008 16:14:00 -0800 Subject: Feedback request: OpenJDK Community Innovator's Challenge Grants In-Reply-To: References: Message-ID: <55C4C4C6-6E88-482F-98D1-31A0D6399EA9@threerings.net> On Jan 3, 2008, at 00:32, Ray Gans wrote: > - What kind of projects do you think would be valuable to the > OpenJDK community? I'd love to see more community development on porting work -- including Mac OS X and BSD support (perhaps this is obvious, coming from me). Speaking just for Mac OS, it still needs work on multiple fronts (via the OpenJDK Porting Group and FreeBSD Java Project): - Merging into OpenJDK (part of the larger BSD porting work). - Support for hotspot x86_32 16-byte stack alignment (vs. using - fstack-realign work-around) - x86_64 16-byte stack alignment fixes - Integration of PowerPC support? (gbenson's?) - Native AWT implementation I'm not sure if this is something both Sun and the larger community are interested in =) -landonf -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part URL: From David.Herron at Sun.COM Fri Jan 4 03:18:39 2008 From: David.Herron at Sun.COM (David Herron) Date: Thu, 03 Jan 2008 19:18:39 -0800 Subject: Project Proposal: Haiku port of OpenJDK In-Reply-To: <477D29FF.2070605@gmail.com> References: <477D29FF.2070605@gmail.com> Message-ID: <477DA58F.3030405@sun.com> Yes! Yes! Yes! Yes! Yes! Yes! Yes! Yes! Yes! Yes! Dalibor Topic wrote: > I hereby propose, on behalf of the Haiku OpenJDK port developers, > the creation of a new project to create and maintain a port of OpenJDK > to the Haiku operating system. > > For existing discussion of the proposal, I'd like to refer you to the > thread > initiated by Bryan Varner's post proposing the project on the porters-dev > mailing list at [1]. > > cheers, > dalibor topic > > > [1] > http://mail.openjdk.java.net/pipermail/porters-dev/2007-December/000035.html > From Tom.Marble at Sun.COM Fri Jan 4 05:09:18 2008 From: Tom.Marble at Sun.COM (Tom Marble) Date: Thu, 03 Jan 2008 23:09:18 -0600 Subject: Project Proposal: Haiku port of OpenJDK In-Reply-To: <477D29FF.2070605@gmail.com> References: <477D29FF.2070605@gmail.com> Message-ID: <477DBF7E.5070301@sun.com> Dalibor Topic wrote: > I hereby propose, on behalf of the Haiku OpenJDK port developers, > the creation of a new project to create and maintain a port of OpenJDK > to the Haiku operating system. I approve. I believe that encouraging broad adoption of OpenJDK on as many Operating Systems and Architectures as possible is essential to furthering our goals of Java ubiquity. I regret, Bryan (et al), that it has taken so long to get to this point. It has been a long time since that meeting back in June at the IndyJUG where you first mentioned this to Ian Murdock. I'm glad to support this project. Thanks for your patience and for your contributions to OpenJDK. And thank you, Dalibor, for all of your help in getting Porters going! Regards, --Tom From gnu_andrew at member.fsf.org Fri Jan 4 09:25:05 2008 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Fri, 4 Jan 2008 09:25:05 +0000 Subject: Feedback request: OpenJDK Community Innovator's Challenge Grants In-Reply-To: <55C4C4C6-6E88-482F-98D1-31A0D6399EA9@threerings.net> References: <55C4C4C6-6E88-482F-98D1-31A0D6399EA9@threerings.net> Message-ID: <17c6771e0801040125o69da8abese201576a0cdb7ed8@mail.gmail.com> On 04/01/2008, Landon Fuller wrote: > > > On Jan 3, 2008, at 00:32, Ray Gans wrote: > > - What kind of projects do you think would be valuable to the OpenJDK > community? > > > I'd love to see more community development on porting work -- including > Mac OS X and BSD support (perhaps this is obvious, coming from me). > > Speaking just for Mac OS, it still needs work on multiple fronts (via the > OpenJDK Porting Group and FreeBSD Java Project): > - Merging into OpenJDK (part of the larger BSD porting work). > - Support for hotspot x86_32 16-byte stack alignment (vs. using > -fstack-realign work-around) > - x86_64 16-byte stack alignment fixes > - Integration of PowerPC support? (gbenson's?) > - Native AWT implementation > > I'm not sure if this is something both Sun and the larger community are > interested in =) > > -landonf > > > Speaking as part of the larger community, I'd say I'm definitely interested in such work being done and I think the rate at which porting work has taken place since the OpenJDK was released stands as a vindication of that process (we already have a PPC interpreter, the OpenJDK class library also working with cacao and your own Mac OS work). Concerning the list you've supplied here I'd say that the first (merging the BSD work) is more dependent on Sun (like the bug system example) than such a project would warrant, the second two seem two small to warrant a lengthy project (but correct me if I'm wrong), while the last two sound about right to me. As to a native AWT implementation, I believe there was some success getting the Classpath Gtk+ implementation to work with OpenJDK. Given that Gtk+ now supports Quartz as a backend, making the Classpath implementation work with that backend and then the Gtk+ peers work with OpenJDK would seem like a more manageable target than starting from scratch (and would also benefit other Gtk+ users in general and GNU Classpath... ;) ) -- 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 Fri Jan 4 09:37:48 2008 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Fri, 4 Jan 2008 09:37:48 +0000 Subject: Feedback request: OpenJDK Community Innovator's Challenge Grants In-Reply-To: <477D39CA.6030003@jazillian.com> References: <477D39CA.6030003@jazillian.com> Message-ID: <17c6771e0801040137l146003a4x845740dd04464d7e@mail.gmail.com> On 03/01/2008, Andy Tripp wrote: > > Hi Ray, > Here are my thoughts... > snip... > - Proposals will be accepted until March 3, 2008. At this time the > proposals will be judged by a team of people (we're thinking 2 from Sun and > 3 from outside Sun). > > Make this "group of 5" be an OpenJDK group, with all (or most) discussions > on an open mailing list. > Agreed, I meant to mention this as well and it was sort of implied in my answer. Everything about the process should be done in the open, including the development work itself. Note that no money will be available until August and all awards must be > distributed at that time. > > It might be worthwhile to have at least one fairly formal milestone for > each project, so the project developers can be sure they're "on the right > track". > Some sort of mid-term review would seem a good idea to me. Maybe a mentor associated with each project too? Again, the nascent nature of OpenJDK may make this difficult and really depends on the willingness of the Sun OpenJDK people. - Projects can only have limited dependence on Sun > involvement/participation. This is for fairness across all projects. > Likewise, projects cannot require a commitment by Sun for significant > time/effort for success since we cannot guarantee adequate Sun resources > will be available -- for example, a project to build a better bug database > for OpenJDK, while very useful, would require heavy involvement by Sun > personnel to integrate it with Sun's internal bug management systems. > > Each proposal should be required to spell out exactly what it requires > from Sun. Using your bug database project example, it might require a > snapshot of the current Sun bug database as simple comma-separated values. > One snapshot at the start of the project and then another snapshot in August > to cut over to the new database. > - What kind of projects do you think would be valuable to the OpenJDK community? > A "How to Hack the OpenJDK" book. > A better bug database (obviously, you've already thought of that :) ). > Massive improvements to the build system (Kelly O'Hair on steriods). > A remote build system that lets a developer make changes locally and > submit changes to a server and get back executables for his platform, > without him having to know anything about how the build works. > A version of Android based on OpenJDK. > As Ray implied, I think anything to do with build/integration issues with the project would rely too much on Sun to be feasible. The first one sounds a very good idea, and I think that involving non-development projects such as documentation, etc. would be a good idea. There are certainly some areas of the public API documentation that need work as well ;) I think some sort of wiki development would be a good idea for such a book, but again we have an integration/project management issue in setting that up. - What selection criteria should be used to choose the best proposals? > > The group should just have some general criteria statement like "Projects > that advance the goals of the OpenJDK project" and then reference a link > that spells out the goals of OpenJDK. Unfortunately, the only such like I > can find is this: http://www.sun.com/software/opensource/java/faq.jsp#e > So maybe spell out the goals yourselves: "increased adoption and increased > innovation" > Agreed. snip... > - Who you think would make good objective judges for the program and why? > > Inside Sun, someone like you and a Mark Reinhold/Danny Coward type of > person. Outside Sun, you just want to be sure to pick people who want to > advance OpenJDK itself, as opposed to pushing some social agenda or some > OpenJDK alternative. > The Governance board springs to mind as an ideal candidate for supplying the judges, especially given these suggestions (it already has a 2 Sun, 3 external makeup IIRC). snip... - How should abandoned or non-completed projects be handled and what should > constitute a "completed" project? > > I presume accepted project participants will have to sign something simple > that says they will do their best to complete > the project by a certain date. It should also mention that if they can't > complete the project, they must post a notice > on the mailing list. > I think an open monitored development process for the projects would handle what you mention here. This is a FOSS project, so the work should be done in the open. Some of what you're saying seems to suggest that the participants disappear in to a black hole for five months and then give a report back at the end. If the process is open (and also, if each project has a mentor attached), then such problems would be flagged much earlier and either dealt with, if possible, or at least some use can be made of the partial work done later. snip.. Good Luck with it! > Andy > > Seconded. I hope this is a successful scheme and can really help OpenJDK take off. -- 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 aph at redhat.com Fri Jan 4 10:22:30 2008 From: aph at redhat.com (Andrew Haley) Date: Fri, 4 Jan 2008 10:22:30 +0000 Subject: Feedback request: OpenJDK Community Innovator's Challenge Grants In-Reply-To: <477D39CA.6030003@jazillian.com> References: <477D39CA.6030003@jazillian.com> Message-ID: <18302.2278.365414.442029@zebedee.pink> Reformatted as plain text. Andy, please set your mail preferences to multipart/mixed HTML and text. Thanks, Andrew. Hi Ray, Here are my thoughts... Ray Gans wrote: Proposals could be made by groups of individuals, existing F/OSS teams, companies/organizations, Java User Groups, etc. Presumably also individuals, right? - Proposals will be accepted until March 3, 2008. At this time the proposals will be judged by a team of people (we're thinking 2 from Sun and 3 from outside Sun). Make this "group of 5" be an OpenJDK group, with all (or most) discussions on an open mailing list. Note that no money will be available until August and all awards must be distributed at that time. It might be worthwhile to have at least one fairly formal milestone for each project, so the project developers can be sure they're "on the right track". - Projects can only have limited dependence on Sun involvement/participation. This is for fairness across all projects. Likewise, projects cannot require a commitment by Sun for significant time/effort for success since we cannot guarantee adequate Sun resources will be available -- for example, a project to build a better bug database for OpenJDK, while very useful, would require heavy involvement by Sun personnel to integrate it with Sun's internal bug management systems. Each proposal should be required to spell out exactly what it requires from Sun. Using your bug database project example, it might require a snapshot of the current Sun bug database as simple comma-separated values. One snapshot at the start of the project and then another snapshot in August to cut over to the new database. - What kind of projects do you think would be valuable to the OpenJDK community? A "How to Hack the OpenJDK" book. A better bug database (obviously, you've already thought of that :) ). Massive improvements to the build system (Kelly O'Hair on steriods). A remote build system that lets a developer make changes locally and submit changes to a server and get back executables for his platform, without him having to know anything about how the build works. A version of Android based on OpenJDK. - What selection criteria should be used to choose the best proposals? The group should just have some general criteria statement like "Projects that advance the goals of the OpenJDK project" and then reference a link that spells out the goals of OpenJDK. Unfortunately, the only such like I can find is this: [1]http://www.sun.com/software/opensource/java/faq.jsp#e So maybe spell out the goals yourselves: "increased adoption and increased innovation" - How many proposals should be accepted? Seven or less sounds good. - Do you think the OpenJDK community at large should have any input into the proposal selection process? Other than to allow anyone to participate in a mailing list discussion, no. - Who you think would make good objective judges for the program and why? Inside Sun, someone like you and a Mark Reinhold/Danny Coward type of person. Outside Sun, you just want to be sure to pick people who want to advance OpenJDK itself, as opposed to pushing some social agenda or some OpenJDK alternative. - What thoughts do you have about how the proposal selection process should be handled? After the proposal submission period ends, publish the proposals, allow a couple weeks of discussion on a mailing list, and then the "group of 5" votes. If greater than 7 submissions, each person may only vote for 7 proposals and the 7 proposals with the most votes win. If 7 or less, A yes/no vote on each. To break down the money awards, after discussion, any of the 5 can submit a proposal for how to split the awards. The first such proposal to get 3 yes votes wins. - Do you think the OpenJDK community at large should have any input into selecting projects that really excel (and be awarded larger prizes)? Again, hold the discussions on open mailing lists and allow anyone to comment. - What criteria should be used to determine the payout for cash awards? Use some vague wording such as "Award amount will be based on potential value to the OpenJDK community". And I would keep it to being based on value, not difficulty. No need for a "degree of difficulty" modifier. - How should abandoned or non-completed projects be handled and what should constitute a "completed" project? I presume accepted project participants will have to sign something simple that says they will do their best to complete the project by a certain date. It should also mention that if they can't complete the project, they must post a notice on the mailing list. - How should awards be handled for project team members who drop out or are added after a proposal is accepted? Ugh. That's a tough one. I guess that this thing that accepted projects would have to sign should designate a single entity (person or corp) that will receive the money, and that Sun will award the money to that entity. Who gets added or deleted or whatever from the project team is then none of Sun's business. You sure don't want to try to micromanage that. So, this "You've been accepted" document might contain: * notice that you've been accepted * expectation that you'll finish by $DATE, that it will be reasonable quality, and it will be substantially what's in the proposal. * promise that Sun will pay the amount of $AMOUNT on date $DATE to $ENTITY upon successful completion * description of any milestones * mention that ultimately, "successful completion" will be determined by this "group of 5". * mention that Sun stays out of issues about who is on the project * mention any help that Sun agrees to (e.g. one bug database dump at start, another at end) * any other required legal mumbo jumbo Please send your thoughts to [2]discuss at openjdk.java.net. Thanks, The OpenJDK team at Sun Good Luck with it! Andy References Visible links 1. http://www.sun.com/software/opensource/java/faq.jsp#e 2. mailto:discuss at openjdk.java.net -- Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK Registered in England and Wales No. 3798903 From ernst.matthias at gmail.com Fri Jan 4 11:02:38 2008 From: ernst.matthias at gmail.com (Matthias Ernst) Date: Fri, 4 Jan 2008 12:02:38 +0100 Subject: Source tarballs In-Reply-To: <477D6553.5000509@sun.com> References: <475C15F7.7060808@nefkom.net> <475D7D5D.6010602@Sun.COM> <475DCC6D.7020404@nefkom.net> <475DD72F.5030701@sun.com> <475DD81E.3040806@sun.com> <477D6553.5000509@sun.com> Message-ID: <22ec15240801040302p7f1469b1ibdb4f0f8103fb1f2@mail.gmail.com> On Jan 3, 2008 11:44 PM, Tom Marble wrote: > Without an OpenJDK upstream tarball this means that the typical > way of getting the OpenJDK source is with "hg fclone" [0]. > Which means that one would need Mercurial [1] with the Forest Extension [2] > (and Mercurial needs python 2.4). This is complicated by the > fact that the Forest Extension (currently, unversioned) is only > supported on Mercurial 0.9.3, 0.9.4, and 0.9.5. While forest does make it easier it is not required. I did not install forest and had good experience with simply cloning the various repositories manually, i.e. hg clone ..../langtools hg clone ..../corba ... If this were copy'n'pasteable on the openjdk homepage it might be good enough? Matthias From gnu_andrew at member.fsf.org Fri Jan 4 12:34:27 2008 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Fri, 4 Jan 2008 12:34:27 +0000 Subject: Source tarballs In-Reply-To: <477D7489.9000205@sun.com> References: <475C15F7.7060808@nefkom.net> <475D7D5D.6010602@Sun.COM> <475DCC6D.7020404@nefkom.net> <475DD72F.5030701@sun.com> <475DD81E.3040806@sun.com> <477D6553.5000509@sun.com> <477D7489.9000205@sun.com> Message-ID: <17c6771e0801040434v3a571da9ued45d5c01bbf34bb@mail.gmail.com> On 03/01/2008, Xiomara Jayasena wrote: > > > Hi Tom, > > Happy New Year! > > Tom Marble wrote: > > I'd like to ask if we (Sun) can reconsider publishing one (1) > source tarball for promoted builds. > > > Yes it is definitely being considered -- as it makes sense, especially if > it is difficult for people to pull down the 7 tar balls that currently exist > now. There are a couple of ways to go about this so that will need to be > sorted out. > > Best regards, > -Xiomara > > > Maybe I'm missing something here, but surely it just takes someone at Sun to pull the b24 changeset using fclone, remove the hg metadata, tarball it and upload it to the site? This would be a lot simpler than pushing the Mercurial+forest extension requirement on to every downstream consumer. -- 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 dalibor.topic at googlemail.com Fri Jan 4 15:18:49 2008 From: dalibor.topic at googlemail.com (Dalibor Topic) Date: Fri, 04 Jan 2008 16:18:49 +0100 Subject: Project Proposal JDK 6 Message-ID: <477E4E59.7010103@kaffe.org> Hi Joe, your proposal seems to have gone lost in the holiday cheer, and I haven't seen any discussion of it on the lists. I think that it's an obvious next step for OpenJDK and would love to see it happen. Do you have a specific group in mind that you'd like to ask to sponsor the project? The build group, also sponsoring the JDK 7 project, would seem to be the right place to go to. cheers, dalibor topic From gnu_andrew at member.fsf.org Fri Jan 4 17:01:03 2008 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Fri, 4 Jan 2008 17:01:03 +0000 Subject: Project Proposal JDK 6 In-Reply-To: <477E4E59.7010103@kaffe.org> References: <477E4E59.7010103@kaffe.org> Message-ID: <17c6771e0801040901w1774ec65m86d48bb8476c5a23@mail.gmail.com> On 04/01/2008, Dalibor Topic wrote: > > Hi Joe, > > your proposal seems to have gone lost in the holiday cheer, and I > haven't seen > any discussion of it on the lists. > > I think that it's an obvious next step for OpenJDK and would love to see > it happen. > > Do you have a specific group in mind that you'd like to ask to sponsor > the project? > The build group, also sponsoring the JDK 7 project, would seem to be the > right place > to go to. > > cheers, > dalibor topic > Hi Joe, Dalibor, I had a similar interest in this project. For one, as I also commented on your blog about this, it seems an ideal opportunity for community involvement with a clear target and fairly low-hanging fruit. I'm assuming that making JDK7 a JDK6 implementation is largely a matter of getting it to pass the JDK6 TCK and not include any superfluous packages/methods/etc. from JDK7. Such cleanup work (rather than fresh development work), obviously with appropriate guidance, would seem to be ideal introductory stuff for a FOSS project, as has been shown by the janitorial tasks on other projects such as Linux and WINE (the latter being my own stepping stone into FOSS development many years ago). However, from your blog, I got the impression that this was instead just something that again would appear from Sun as a complete product. What are your thoughts on this? Cheers, -- 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 Xiomara.Jayasena at Sun.COM Fri Jan 4 18:45:17 2008 From: Xiomara.Jayasena at Sun.COM (Xiomara Jayasena) Date: Fri, 04 Jan 2008 10:45:17 -0800 Subject: Source tarballs In-Reply-To: <17c6771e0801040434v3a571da9ued45d5c01bbf34bb@mail.gmail.com> References: <475C15F7.7060808@nefkom.net> <475D7D5D.6010602@Sun.COM> <475DCC6D.7020404@nefkom.net> <475DD72F.5030701@sun.com> <475DD81E.3040806@sun.com> <477D6553.5000509@sun.com> <477D7489.9000205@sun.com> <17c6771e0801040434v3a571da9ued45d5c01bbf34bb@mail.gmail.com> Message-ID: <477E7EBD.8080804@sun.com> Andrew John Hughes wrote: > > Yes it is definitely being considered -- as it makes sense, > especially if it is difficult for people to pull down the 7 tar > balls that currently exist now. There are a couple of ways to go > about this so that will need to be sorted out. > > Best regards, > -Xiomara > > > > > Maybe I'm missing something here, but surely it just takes someone at > Sun to pull the b24 changeset using fclone, remove the hg metadata, > tarball it and upload it to the site? > This would be a lot simpler than pushing the Mercurial+forest > extension requirement on to every downstream consumer. Thank you for your input! What you mentioned above is one way to do it. Although I do not think Mercurial is needed to download the zips provided by Mercurial itself. e.g.: 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 -Xiomara :-) -- > 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 robilad at kaffe.org Fri Jan 4 18:51:46 2008 From: robilad at kaffe.org (Dalibor Topic) Date: Fri, 04 Jan 2008 19:51:46 +0100 Subject: Project Proposal JDK 6 In-Reply-To: <477E4E59.7010103@kaffe.org> References: <477E4E59.7010103@kaffe.org> Message-ID: <477E8042.3020802@kaffe.org> Dalibor Topic wrote: > Hi Joe, > > your proposal seems to have gone lost in the holiday cheer, and I > haven't seen > any discussion of it on the lists. > > I think that it's an obvious next step for OpenJDK and would love to > see it happen. > > Do you have a specific group in mind that you'd like to ask to sponsor > the project? > The build group, also sponsoring the JDK 7 project, would seem to be > the right place > to go to. While I'm talking about the build group, I should probably poke Mark and Kelly about this. Mark, Kelly, what do you think? cheers, dalibor topic From gnu_andrew at member.fsf.org Fri Jan 4 18:52:34 2008 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Fri, 4 Jan 2008 18:52:34 +0000 Subject: Source tarballs In-Reply-To: <477E7EBD.8080804@sun.com> References: <475C15F7.7060808@nefkom.net> <475D7D5D.6010602@Sun.COM> <475DCC6D.7020404@nefkom.net> <475DD72F.5030701@sun.com> <475DD81E.3040806@sun.com> <477D6553.5000509@sun.com> <477D7489.9000205@sun.com> <17c6771e0801040434v3a571da9ued45d5c01bbf34bb@mail.gmail.com> <477E7EBD.8080804@sun.com> Message-ID: <17c6771e0801041052p32730fa7o2ca1f5e830f6906e@mail.gmail.com> On 04/01/2008, Xiomara Jayasena wrote: > > Andrew John Hughes wrote: > > Yes it is definitely being considered -- as it makes sense, especially if > > it is difficult for people to pull down the 7 tar balls that currently exist > > now. There are a couple of ways to go about this so that will need to be > > sorted out. > > > > Best regards, > > -Xiomara > > > > > > > > Maybe I'm missing something here, but surely it just takes someone at Sun > to pull the b24 changeset using fclone, remove the hg metadata, tarball it > and upload it to the site? > This would be a lot simpler than pushing the Mercurial+forest extension > requirement on to every downstream consumer. > > > Thank you for your input! > > What you mentioned above is one way to do it. Although I do not think > Mercurial is needed to download the zips provided by Mercurial itself. > > e.g.: > 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 > > > -Xiomara :-) > > > -- > > Andrew :-) > > Help end the Java Trap! > Contribute to GNU Classpath and the OpenJDK > http://www.gnu.org/software/classpath > http://openjdk.java.net > > > Yes, I'm aware of the zips which is probably a slightly cleaner way of doing the tarball than deleting the Mercurial metadata manually. I actually find it quite astonishing that a tarball of a release was just dropped and we are even having to debate this. It was probably tricker to roll a tarball from the internal Sun repositories so why it's not being done just because the source repository is now available is strange. I don't know of any other FOSS project that doesn't have bother available, at least for releases. 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 -------------- An HTML attachment was scrubbed... URL: From Xiomara.Jayasena at Sun.COM Fri Jan 4 19:23:05 2008 From: Xiomara.Jayasena at Sun.COM (Xiomara Jayasena) Date: Fri, 04 Jan 2008 11:23:05 -0800 Subject: Source tarballs In-Reply-To: <17c6771e0801041052p32730fa7o2ca1f5e830f6906e@mail.gmail.com> References: <475C15F7.7060808@nefkom.net> <475D7D5D.6010602@Sun.COM> <475DCC6D.7020404@nefkom.net> <475DD72F.5030701@sun.com> <475DD81E.3040806@sun.com> <477D6553.5000509@sun.com> <477D7489.9000205@sun.com> <17c6771e0801040434v3a571da9ued45d5c01bbf34bb@mail.gmail.com> <477E7EBD.8080804@sun.com> <17c6771e0801041052p32730fa7o2ca1f5e830f6906e@mail.gmail.com> Message-ID: <477E8799.2050703@sun.com> Andrew John Hughes wrote: > > > On 04/01/2008, *Xiomara Jayasena* > wrote: > > Andrew John Hughes wrote: >> >> Yes it is definitely being considered -- as it makes sense, >> especially if it is difficult for people to pull down the 7 >> tar balls that currently exist now. There are a couple of >> ways to go about this so that will need to be sorted out. >> >> Best regards, >> -Xiomara >> >> >> >> >> Maybe I'm missing something here, but surely it just takes >> someone at Sun to pull the b24 changeset using fclone, remove the >> hg metadata, tarball it and upload it to the site? >> This would be a lot simpler than pushing the Mercurial+forest >> extension requirement on to every downstream consumer. > > Thank you for your input! > > What you mentioned above is one way to do it. Although I do not > think Mercurial is needed to download the zips provided by > Mercurial itself. > > e.g.: > 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 > > > > -Xiomara :-) > > > -- >> Andrew :-) >> >> Help end the Java Trap! >> Contribute to GNU Classpath and the OpenJDK >> http://www.gnu.org/software/classpath >> http://openjdk.java.net > > > Yes, I'm aware of the zips which is probably a slightly cleaner way of > doing the tarball than deleting the Mercurial metadata manually. > I actually find it quite astonishing that a tarball of a release was > just dropped and we are even having to debate this. It was probably > tricker > to roll a tarball from the internal Sun repositories so why it's not > being done just because the source repository is now available is strange. > I don't know of any other FOSS project that doesn't have bother > available, at least for releases. There are a few options to get the source now ;-) unlike before. Many things have changed that have gotten us to the point of where we are -- that said nothing is final and we are flexible :-) -Xiomara > > 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 -------------- An HTML attachment was scrubbed... URL: From robilad at kaffe.org Fri Jan 4 19:26:27 2008 From: robilad at kaffe.org (Dalibor Topic) Date: Fri, 04 Jan 2008 20:26:27 +0100 Subject: Source tarballs In-Reply-To: <477D6553.5000509@sun.com> References: <475C15F7.7060808@nefkom.net> <475D7D5D.6010602@Sun.COM> <475DCC6D.7020404@nefkom.net> <475DD72F.5030701@sun.com> <475DD81E.3040806@sun.com> <477D6553.5000509@sun.com> Message-ID: <477E8863.3090102@kaffe.org> Tom Marble wrote: > Andreas Sterbenz wrote: > >> 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). >> > > I'd like to ask if we (Sun) can reconsider publishing one (1) > source tarball for promoted builds. > > This question has come up in the past in the context of many > Free Software distro build daemons which proscribe live Internet > access during binary builds. Usually there is a "source package" > which is uploaded to the build daemon which specifies any build > time dependencies (e.g. specific compilers, header file packages) > and includes the upstream tarball(s). > > This question came up again, today, on IRC in the context of > building OpenJDK for stable distros. Developers stated that it > is very desirable for non-root users to be able to build OpenJDK > on stable distros by making only one simple request to their > system administrator for a list of build dependency packages. > While the user may have Internet access she cannot specify > packages which were not part of the stable release. That makes sense, and usually having some easy way to get the source code for particular snapshots without requiring the installation of a VCS is a nice thing for redistributors, build daemons, etc. The gcc project, for example, publishes weekly snapshots, which are then made available from GNU mirrors like ftp://ftp.mirrorservice.org/sites/sourceware.org/pub/gcc/snapshots/ as regular tar.bz2 archives. cheers, dalibor topic From openjdk at jazillian.com Fri Jan 4 20:34:51 2008 From: openjdk at jazillian.com (Andy Tripp) Date: Fri, 04 Jan 2008 15:34:51 -0500 Subject: Feedback request: OpenJDK Community Innovator's Challenge Grants In-Reply-To: <17c6771e0801040137l146003a4x845740dd04464d7e@mail.gmail.com> References: <477D39CA.6030003@jazillian.com> <17c6771e0801040137l146003a4x845740dd04464d7e@mail.gmail.com> Message-ID: <477E986B.70001@jazillian.com> Andrew John Hughes wrote: > Agreed, I meant to mention this as well and it was sort of implied in > my answer. Everything about the process should be done in the open, > including the development work itself. I agree, though it may be difficult for Sun to enforce any specific "openness". Maybe Sun could just add an item to their "Your project has been accepted" letter asking that you keep it as open as possible. > > There are certainly some areas of the public API documentation that > need work as well ;) Which makes me think of another project idea: a project to clean up all the cruft in the bug database. Last I checked, there were over 25,000 bugs, and going through them at random seemed to indicate that most are simple API documentation fixes and clarifications, non-bugs, and other junk. I would bet that most of the active bugs are not being worked and never will be. I'd love to see some iron-fisted person go through and get it down to around 5,000 "real" bugs. But then again, maybe I'm the only one who's bothered by the volume. And I suppose this would require too much work inside Sun also. > > I think an open monitored development process for the projects would > handle what you mention here. This is a FOSS project, so the work > should be done in the open. Some of what you're saying seems to > suggest that the participants disappear in to a black hole for five > months and then give a report back at the end. If the process is open > (and also, if each project has a mentor attached), then such problems > would be flagged much earlier and either dealt with, if possible, or > at least some use can be made of the partial work done later. Yes, it's tough to break out of my closed-source mindset :) On the other hand, I'm thinking that the progress of writing a book or choosing a better bug database is a bit abstract, and not well captured by an SVN tree. From Joe.Darcy at Sun.COM Fri Jan 4 22:08:17 2008 From: Joe.Darcy at Sun.COM (Joseph D. Darcy) Date: Fri, 04 Jan 2008 14:08:17 -0800 Subject: Project Proposal JDK 6 In-Reply-To: <17c6771e0801040901w1774ec65m86d48bb8476c5a23@mail.gmail.com> References: <477E4E59.7010103@kaffe.org> <17c6771e0801040901w1774ec65m86d48bb8476c5a23@mail.gmail.com> Message-ID: <477EAE51.8010704@sun.com> Hello Andrew and Dalibor. Andrew John Hughes wrote: > > > On 04/01/2008, *Dalibor Topic* > wrote: > > Hi Joe, > > your proposal seems to have gone lost in the holiday cheer, and I > haven't seen > any discussion of it on the lists. > > I think that it's an obvious next step for OpenJDK and would love to > see > it happen. > > Do you have a specific group in mind that you'd like to ask to sponsor > the project? > The build group, also sponsoring the JDK 7 project, would seem to be the > right place > to go to. > > cheers, > dalibor topic > > > Hi Joe, Dalibor, > > I had a similar interest in this project. For one, as I also commented > on your blog about this, it seems an ideal opportunity for community > involvement with a clear target and fairly low-hanging fruit. I'm > assuming that making JDK7 a JDK6 implementation is largely a matter of > getting it to pass the JDK6 TCK and not include any superfluous > packages/methods/etc. from JDK7. Such cleanup work (rather than fresh > development work), obviously with appropriate guidance, would seem to be > ideal introductory stuff for a FOSS project, as has been shown by the > janitorial tasks on other projects such as Linux and WINE (the latter > being my own stepping stone into FOSS development many years ago). > However, from your blog, I got the impression that this was instead just > something that again would appear from Sun as a complete product. What > are your thoughts on this? > > Cheers, For the last few weeks I've been on vacation taking in some of that holiday cheer myself and will be officially back to work on Monday :-) As discussed in previous email from Kelly, the Mercurial procedures for JDK repositories aren't fully worked out yet so in the meantime we've been working internally on addressing the "antibugs" of JDK 7 changes inappropriate for a Java SE 6 implementation back in teamware workspaces inside Sun. That effort is already fairly far along, but we'll certainly welcome external community involvement in working on remaining aspects of the project. More later in 2008, regards, -Joe From tony.p.lee at gmail.com Sat Jan 5 01:03:55 2008 From: tony.p.lee at gmail.com (Tony Lee) Date: Fri, 4 Jan 2008 17:03:55 -0800 Subject: Building openjdk for ARM Linux. Message-ID: <470b63970801041703t24e9e121y39681700a6b5265f@mail.gmail.com> Hello, I am new to jdk but very comfortable with compiling opensource packages. I try to build jdk7 on ARM Linux platform with Fedora Core 6. The build failed with the following message: >From the msg, it looks like I need to install older version of jdk before I compile for jdk7, is this correct? Has anyone succeed in compile the openjdk 7 for ARM linux platform? --------------------Error msg -------------------------- -bash-3.1# make /bin/sh: /NOT-SET/devtools/share/ant/latest/bin/ant: No such file or directory /bin/sh: /NOT-SET/devtools/share/findbugs/latest/bin/findbugs: No such file or directory ../make/common/shared/Sanity-Settings.gmk:121: WARNING: ANT_VER should not be empty [Sanity-Settings.gmk] ../make/common/shared/Sanity-Settings.gmk:122: WARNING: FINDBUGS_VER should not be empty [Sanity-Settings.gmk] /bin/sh: line 0: [: /bin/sh:: integer expression expected /bin/sh: line 0: [: /bin/sh:: integer expression expected linux armv5tejl 1.7.0-internal build started: 08-01-04 16:09 make[1]: Entering directory `/share/openjdk/compiler/jdk-jdk7-b24/make/tools/freetypecheck' freetypecheck.c: In function ???main???: freetypecheck.c:45: warning: comparison is always false due to limited range of data type freetypecheck.c:54: warning: comparison is always false due to limited range of data type make[1]: Leaving directory `/share/openjdk/compiler/jdk-jdk7-b24/make/tools/freetypecheck' Bootstrap Settings: BOOTDIR = /NO_BOOTDIR ALT_BOOTDIR = BOOT_VER = /bin/sh: /NO_BOOTDIR/bin/java: No such file or directory [requires at least 1.5] OUTPUTDIR = ./../build/linux-armv5tejl ALT_OUTPUTDIR = ABS_OUTPUTDIR = /share/openjdk/compiler/jdk-jdk7-b24/build/linux-armv5tejl -- -Tony Having fun with FPGA, gige, mpeg, snmp, ppc, Linux, ARM. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Bradford.Wetmore at Sun.COM Sat Jan 5 03:10:58 2008 From: Bradford.Wetmore at Sun.COM (Brad Wetmore) Date: Fri, 04 Jan 2008 19:10:58 -0800 Subject: Building openjdk for ARM Linux. In-Reply-To: <470b63970801041703t24e9e121y39681700a6b5265f@mail.gmail.com> References: <470b63970801041703t24e9e121y39681700a6b5265f@mail.gmail.com> Message-ID: <477EF542.4030303@sun.com> Tony Lee wrote: > >From the msg, it looks like I need to install older version of jdk > before I compile for jdk7, is this correct? Yes. You need a "bootstrap" JDK for various parts of the build. Please see: http://hg.openjdk.java.net/jdk7/jdk7/raw-file/tip/README-builds.html specifically: http://hg.openjdk.java.net/jdk7/jdk7/raw-file/tip/README-builds.html#bootjdk http://hg.openjdk.java.net/jdk7/jdk7/raw-file/tip/README-builds.html#linux Hope this helps. Brad From aph at redhat.com Sat Jan 5 10:53:58 2008 From: aph at redhat.com (Andrew Haley) Date: Sat, 5 Jan 2008 10:53:58 +0000 Subject: Building openjdk for ARM Linux. In-Reply-To: <470b63970801041703t24e9e121y39681700a6b5265f@mail.gmail.com> References: <470b63970801041703t24e9e121y39681700a6b5265f@mail.gmail.com> Message-ID: <18303.25030.93337.109497@zebedee.pink> Tony Lee writes: > Hello, > > I am new to jdk but very comfortable with compiling opensource packages. > > I try to build jdk7 on ARM Linux platform with Fedora Core 6. > > The build failed with the following message: > > > >From the msg, it looks like I need to install older version of jdk before I > compile for jdk7, is this correct? > > Has anyone succeed in compile the openjdk 7 for ARM linux platform? A great deal of OpenJDK is written in assembly language. Unless you've written an ARM version of all this it isn't going to work. Andrew. -- Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK Registered in England and Wales No. 3798903 From pieter.libin at mybiodata.eu Sat Jan 5 13:37:08 2008 From: pieter.libin at mybiodata.eu (Pieter Libin) Date: Sat, 5 Jan 2008 14:37:08 +0100 Subject: Building openjdk for ARM Linux. In-Reply-To: <18303.25030.93337.109497@zebedee.pink> References: <470b63970801041703t24e9e121y39681700a6b5265f@mail.gmail.com> <18303.25030.93337.109497@zebedee.pink> Message-ID: <50be7b020801050537l621861a5nd398372679fc29f0@mail.gmail.com> I thought there also was a c++ interpreter available, maybe it's a good idea to start with this instead of writing all the ARM assembly. Pieter On Jan 5, 2008 11:53 AM, Andrew Haley wrote: > Tony Lee writes: > > Hello, > > > > I am new to jdk but very comfortable with compiling opensource packages. > > > > I try to build jdk7 on ARM Linux platform with Fedora Core 6. > > > > The build failed with the following message: > > > > > > >From the msg, it looks like I need to install older version of jdk before I > > compile for jdk7, is this correct? > > > > Has anyone succeed in compile the openjdk 7 for ARM linux platform? > > A great deal of OpenJDK is written in assembly language. Unless > you've written an ARM version of all this it isn't going to work. > > Andrew. > > -- > Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK > Registered in England and Wales No. 3798903 > From David.Herron at Sun.COM Sat Jan 5 16:18:48 2008 From: David.Herron at Sun.COM (David Herron) Date: Sat, 05 Jan 2008 08:18:48 -0800 Subject: Building openjdk for ARM Linux. In-Reply-To: <50be7b020801050537l621861a5nd398372679fc29f0@mail.gmail.com> References: <470b63970801041703t24e9e121y39681700a6b5265f@mail.gmail.com> <18303.25030.93337.109497@zebedee.pink> <50be7b020801050537l621861a5nd398372679fc29f0@mail.gmail.com> Message-ID: <477FADE8.7080904@sun.com> Gary Benson has been making some interesting postings along these lines. http://gbenson.livejournal.com/ - David Herron Pieter Libin wrote: > I thought there also was a c++ interpreter available, > maybe it's a good idea to start with this instead of writing all the > ARM assembly. > > Pieter > > On Jan 5, 2008 11:53 AM, Andrew Haley wrote: > >> Tony Lee writes: >> > Hello, >> > >> > I am new to jdk but very comfortable with compiling opensource packages. >> > >> > I try to build jdk7 on ARM Linux platform with Fedora Core 6. >> > >> > The build failed with the following message: >> > >> > >> > >From the msg, it looks like I need to install older version of jdk before I >> > compile for jdk7, is this correct? >> > >> > Has anyone succeed in compile the openjdk 7 for ARM linux platform? >> >> A great deal of OpenJDK is written in assembly language. Unless >> you've written an ARM version of all this it isn't going to work. >> >> Andrew. >> >> -- >> Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK >> Registered in England and Wales No. 3798903 >> >> From tony.p.lee at gmail.com Sat Jan 5 22:29:05 2008 From: tony.p.lee at gmail.com (Tony Lee) Date: Sat, 5 Jan 2008 14:29:05 -0800 Subject: Building openjdk for ARM Linux. In-Reply-To: <477EF542.4030303@sun.com> References: <470b63970801041703t24e9e121y39681700a6b5265f@mail.gmail.com> <477EF542.4030303@sun.com> Message-ID: <470b63970801051429gfc469a4mddad21c049227a5b@mail.gmail.com> On Jan 4, 2008 7:10 PM, Brad Wetmore wrote: > Yes. You need a "bootstrap" JDK for various parts of the build. > > Please see: > > http://hg.openjdk.java.net/jdk7/jdk7/raw-file/tip/README-builds.html > > specifically: > > > http://hg.openjdk.java.net/jdk7/jdk7/raw-file/tip/README-builds.html#bootjdk > http://hg.openjdk.java.net/jdk7/jdk7/raw-file/tip/README-builds.html#linux > > Hope this helps. > > Thanks Brad. I guess the answer is no for now. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnu_andrew at member.fsf.org Sun Jan 6 00:56:43 2008 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Sun, 6 Jan 2008 00:56:43 +0000 Subject: Feedback request: OpenJDK Community Innovator's Challenge Grants In-Reply-To: <477E986B.70001@jazillian.com> References: <477D39CA.6030003@jazillian.com> <17c6771e0801040137l146003a4x845740dd04464d7e@mail.gmail.com> <477E986B.70001@jazillian.com> Message-ID: <17c6771e0801051656v5bd33351ubb4f559e61962b3f@mail.gmail.com> On 04/01/2008, Andy Tripp wrote: > > Andrew John Hughes wrote: > > Agreed, I meant to mention this as well and it was sort of implied in > > my answer. Everything about the process should be done in the open, > > including the development work itself. > I agree, though it may be difficult for Sun to enforce any specific > "openness". Maybe Sun could just add an > item to their "Your project has been accepted" letter asking that you > keep it as open as possible. Well, in running the program, I believe Sun have some power over things. At the very minimum, it should be required that all work is uploaded somewhere at the end of the time period. This is what happens with Google's Summer of Code -- code.google.com has a project which hosts all the code created during this summer's event. > > > There are certainly some areas of the public API documentation that > > need work as well ;) > Which makes me think of another project idea: a project to clean up all > the cruft in the bug database. Last I checked, there > were over 25,000 bugs, and going through them at random seemed to > indicate that most are simple API documentation fixes and > clarifications, non-bugs, and other junk. I would bet that most of the > active bugs are not being worked and never will be. > I'd love to see some iron-fisted person go through and get it down to > around 5,000 "real" bugs. But then again, maybe I'm > the only one who's bothered by the volume. And I suppose this would > require too much work inside Sun also. This would work fine if OpenJDK already had a usable bug database like other FOSS projects (e.g. I could see such a thing being done fairly easily with GNU Classpath, which has the same issue but on a much smaller scale). Given that bug reports currently require all sorts of internal Sun approval, this just wouldn't be practical. That said, I agree it's an issue and again a nice piece of low-hanging fruit when things get going properly. > > > I think an open monitored development process for the projects would > > handle what you mention here. This is a FOSS project, so the work > > should be done in the open. Some of what you're saying seems to > > suggest that the participants disappear in to a black hole for five > > months and then give a report back at the end. If the process is open > > (and also, if each project has a mentor attached), then such problems > > would be flagged much earlier and either dealt with, if possible, or > > at least some use can be made of the partial work done later. > Yes, it's tough to break out of my closed-source mindset :) On the other > hand, I'm thinking that the progress of writing a book > or choosing a better bug database is a bit abstract, and not well > captured by an SVN tree. > > Well, yes, a design process like choosing and implementing a new bug database is more a case for a wiki I think, but again, this was given as an impractical project in the first e-mail anyway! Certainly a book could be developed collaboratively using a version control system. Most FOSS project documentation is developed along with the source code base in this manner, and I can think of a few examples of books done this way (e.g. the one for SVN itself IIRC). They can be used for more than just source code. 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 -------------- An HTML attachment was scrubbed... URL: From arnd-hendrik.mathias at nefkom.net Sun Jan 6 01:54:48 2008 From: arnd-hendrik.mathias at nefkom.net (Arnd-Hendrik Mathias) Date: Sun, 06 Jan 2008 02:54:48 +0100 Subject: Feedback request: OpenJDK Community Innovator's Challenge Grants In-Reply-To: References: Message-ID: <478034E8.5000207@nefkom.net> Hi everybody, Ray Gans wrote: > - What kind of projects do you think would be valuable to the OpenJDK > community? Personally, I'd love to see the OpenJDK build environment get rid of the dependencies stuff like - pre-installed bootstrap JDK - binary plugs - ANT (again depending on a pre-installed JDK) ... (...sure, the rest of the "usual" make/build/... tools can remain... ;?) Aiming at an OpenJDK capable to be grabbed as tarball and be built from scratch on a new system. Best regards Arnd-Hendrik -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnu_andrew at member.fsf.org Sun Jan 6 02:49:04 2008 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Sun, 6 Jan 2008 02:49:04 +0000 Subject: Feedback request: OpenJDK Community Innovator's Challenge Grants In-Reply-To: <478034E8.5000207@nefkom.net> References: <478034E8.5000207@nefkom.net> Message-ID: <17c6771e0801051849n4dd8cc50kdc8553da54b57c85@mail.gmail.com> On 06/01/2008, Arnd-Hendrik Mathias wrote: > > Hi everybody, > > Ray Gans wrote: > > - What kind of projects do you think would be valuable to the OpenJDK > community? > > Personally, I'd love to see the OpenJDK build environment get rid of the > dependencies stuff like > - pre-installed bootstrap JDK > - binary plugs > - ANT (again depending on a pre-installed JDK) > ... > (...sure, the rest of the "usual" make/build/... tools can remain... ;?) > Aiming at an OpenJDK capable to be grabbed as tarball and be built from > scratch on a new system. > Best regards > > Arnd-Hendrik > Have you looked at IcedTea? (http://icedtea.classpath.org) It at least gets rid of the binary plugs issue and goes a long way to making the build process usable. Hopefully Sun will integrate these changes at some point. The issue of having a Java VM+class library already will remain a problem because there are no non-Java compilers any more (for 1.5 on). It's pretty much Sun's or the Eclipse compiler, both of which are written in Java, so you need a Java VM + class library to run them. I'd love to see Ant disappear as a requirement, but Sun are moving in the opposite direction (using the Ant build for langtools, etc. was introduced in b21). If it could be built using the autotools like most FOSS projects, that would be ideal. -- 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 arnd-hendrik.mathias at nefkom.net Sun Jan 6 23:47:16 2008 From: arnd-hendrik.mathias at nefkom.net (Arnd-Hendrik Mathias) Date: Mon, 07 Jan 2008 00:47:16 +0100 Subject: Feedback request: OpenJDK Community Innovator's Challenge Grants In-Reply-To: <17c6771e0801051849n4dd8cc50kdc8553da54b57c85@mail.gmail.com> References: <478034E8.5000207@nefkom.net> <17c6771e0801051849n4dd8cc50kdc8553da54b57c85@mail.gmail.com> Message-ID: <47816884.8040604@nefkom.net> Hi Andrew, Andrew John Hughes wrote: > Have you looked at IcedTea? (http://icedtea.classpath.org) Thanks for the hint. It looks cool. > It at least gets rid of the binary plugs issue and goes a long way to > making the build process usable. Hopefully Sun will integrate these > changes at some point. I'd welcome this to happen. > The issue of having a Java VM+class library already will remain a > problem because there are no non-Java compilers any more (for 1.5 > on). It's pretty much Sun's or the Eclipse compiler, both of which > are written in Java, so you need a Java VM + class library to run them. How about some concept like using some java2native compilers or some java enabled gcc to build the necessary set of bootstrap JDK components in a pre-build-step and then using these for building the real OpenJDK. > I'd love to see Ant disappear as a requirement, but Sun are moving in > the opposite direction (using the Ant build for langtools, etc. was > introduced in b21). Sounds not so good. > If it could be built using the autotools like most FOSS projects, that > would be ideal. Yes! Yes! Yes!... ;?) By the way...as another "proposal" (already asked a number of times by different people): Are there currently any plans or activities to create an OpenJDK SeaMonkey(Mozilla)-plugin? Arnd-Hendrik From gnu_andrew at member.fsf.org Mon Jan 7 00:43:55 2008 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Mon, 7 Jan 2008 00:43:55 +0000 Subject: Feedback request: OpenJDK Community Innovator's Challenge Grants In-Reply-To: <47816884.8040604@nefkom.net> References: <478034E8.5000207@nefkom.net> <17c6771e0801051849n4dd8cc50kdc8553da54b57c85@mail.gmail.com> <47816884.8040604@nefkom.net> Message-ID: <17c6771e0801061643w320d8032l86796d779773152@mail.gmail.com> snip... > > The issue of having a Java VM+class library already will remain a > > problem because there are no non-Java compilers any more (for 1.5 > > on). It's pretty much Sun's or the Eclipse compiler, both of which > > are written in Java, so you need a Java VM + class library to run them. > How about some concept like using some java2native compilers or some > java enabled gcc to build the necessary set of bootstrap JDK components > in a pre-build-step and then using these for building the real OpenJDK. This is what I've been looking at with IcePick (mentioned on the IcedTea website). This can take just the langtools repository from OpenJDK and build it using an autotools setup to give you a copy of javac, javap, javadoc and apt. One feature I'm going to add there is being able to do a native compile of the tools as well, which would remove the remaining requirement of a VM+class library. snip... > > By the way...as another "proposal" (already asked a number of times by > different people): Are there currently any plans or activities to create > an OpenJDK SeaMonkey(Mozilla)-plugin? > gcjwebplugin is in IcedTea. > Arnd-Hendrik > Thanks, -- Andrew :-) Help end the Java Trap! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net From gbenson at redhat.com Mon Jan 7 08:43:36 2008 From: gbenson at redhat.com (Gary Benson) Date: Mon, 7 Jan 2008 08:43:36 +0000 Subject: Building openjdk for ARM Linux. In-Reply-To: <50be7b020801050537l621861a5nd398372679fc29f0@mail.gmail.com> References: <470b63970801041703t24e9e121y39681700a6b5265f@mail.gmail.com> <18303.25030.93337.109497@zebedee.pink> <50be7b020801050537l621861a5nd398372679fc29f0@mail.gmail.com> Message-ID: <20080107084335.GA3799@redhat.com> Pieter Libin wrote: > I thought there also was a c++ interpreter available, > maybe it's a good idea to start with this instead of writing all > the ARM assembly. The C++ interpreter still requires a fair amount of assembly, and platform specific code in general. Check out the ports directory in IcedTea: there's a bare minimum ppc port in there which is is essentially what you need to write for any new processor. Cheers, Gary From aph at redhat.com Mon Jan 7 10:03:19 2008 From: aph at redhat.com (Andrew Haley) Date: Mon, 7 Jan 2008 10:03:19 +0000 Subject: Feedback request: OpenJDK Community Innovator's Challenge Grants In-Reply-To: <47816884.8040604@nefkom.net> References: <478034E8.5000207@nefkom.net> <17c6771e0801051849n4dd8cc50kdc8553da54b57c85@mail.gmail.com> <47816884.8040604@nefkom.net> Message-ID: <18305.63719.125363.896219@zebedee.pink> Arnd-Hendrik Mathias writes: > How about some concept like using some java2native compilers or > some java enabled gcc to build the necessary set of bootstrap JDK > components in a pre-build-step and then using these for building > the real OpenJDK. That's how IcedTea works. Andrew. -- Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK Registered in England and Wales No. 3798903 From gnu_andrew at member.fsf.org Mon Jan 7 10:06:24 2008 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Mon, 7 Jan 2008 10:06:24 +0000 Subject: Feedback request: OpenJDK Community Innovator's Challenge Grants In-Reply-To: <18305.63719.125363.896219@zebedee.pink> References: <478034E8.5000207@nefkom.net> <17c6771e0801051849n4dd8cc50kdc8553da54b57c85@mail.gmail.com> <47816884.8040604@nefkom.net> <18305.63719.125363.896219@zebedee.pink> Message-ID: <17c6771e0801070206k4b10d300h5544b40c67679c1@mail.gmail.com> On 07/01/2008, Andrew Haley wrote: > > Arnd-Hendrik Mathias writes: > > > How about some concept like using some java2native compilers or > > some java enabled gcc to build the necessary set of bootstrap JDK > > components in a pre-build-step and then using these for building > > the real OpenJDK. > > That's how IcedTea works. > > Andrew. > > -- > Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, > Berkshire, SL4 1TE, UK > Registered in England and Wales No. 3798903 > It doesn't do anything native, AFAIK -- it just creates a pseudo-bootstrap JDK. -- 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 aph at redhat.com Mon Jan 7 11:45:59 2008 From: aph at redhat.com (Andrew Haley) Date: Mon, 7 Jan 2008 11:45:59 +0000 Subject: Feedback request: OpenJDK Community Innovator's Challenge Grants In-Reply-To: <17c6771e0801070206k4b10d300h5544b40c67679c1@mail.gmail.com> References: <478034E8.5000207@nefkom.net> <17c6771e0801051849n4dd8cc50kdc8553da54b57c85@mail.gmail.com> <47816884.8040604@nefkom.net> <18305.63719.125363.896219@zebedee.pink> <17c6771e0801070206k4b10d300h5544b40c67679c1@mail.gmail.com> Message-ID: <18306.4343.714808.312952@zebedee.pink> Andrew John Hughes writes: > On 07/01/2008, Andrew Haley wrote: > > > > Arnd-Hendrik Mathias writes: > > > > > How about some concept like using some java2native compilers or > > > some java enabled gcc to build the necessary set of bootstrap JDK > > > components in a pre-build-step and then using these for building > > > the real OpenJDK. > > > > That's how IcedTea works. > > It doesn't do anything native, AFAIK -- it just creates a pseudo-bootstrap > JDK. What does "it doesn't do anything native, AFAIK" mean? I can't tell if you agree with me or not. Andrew. -- Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK Registered in England and Wales No. 3798903 From gnu_andrew at member.fsf.org Mon Jan 7 13:08:30 2008 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Mon, 7 Jan 2008 13:08:30 +0000 Subject: Feedback request: OpenJDK Community Innovator's Challenge Grants In-Reply-To: <18306.4343.714808.312952@zebedee.pink> References: <478034E8.5000207@nefkom.net> <17c6771e0801051849n4dd8cc50kdc8553da54b57c85@mail.gmail.com> <47816884.8040604@nefkom.net> <18305.63719.125363.896219@zebedee.pink> <17c6771e0801070206k4b10d300h5544b40c67679c1@mail.gmail.com> <18306.4343.714808.312952@zebedee.pink> Message-ID: <17c6771e0801070508s52a9544fy38efccc395dfaf6f@mail.gmail.com> On 07/01/2008, Andrew Haley wrote: > > Andrew John Hughes writes: > > On 07/01/2008, Andrew Haley wrote: > > > > > > Arnd-Hendrik Mathias writes: > > > > > > > How about some concept like using some java2native compilers or > > > > some java enabled gcc to build the necessary set of bootstrap JDK > > > > components in a pre-build-step and then using these for building > > > > the real OpenJDK. > > > > > > That's how IcedTea works. > > > > It doesn't do anything native, AFAIK -- it just creates a > pseudo-bootstrap > > JDK. > > What does "it doesn't do anything native, AFAIK" mean? I can't tell > if you agree with me or not. > > Andrew. > > -- > Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, > Berkshire, SL4 1TE, UK > Registered in England and Wales No. 3798903 > I interpreted the question (perhaps wrongly) as looking for a solution that wouldn't require a Java VM and class library i.e. that there would be a preliminary step that created a native toolchain of javac, etc. which could then be used to bootstrap the OpenJDK in full. IcedTea only does half of this; it creates the pseudo-bootstrap environment using ecj and a Java VM, but this is not native. I'm not sure how much of an issue that is, as you'd still need libgcj to run the native binaries. So I suppose I half agree with what you said... :D -- 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 aph at redhat.com Mon Jan 7 13:46:09 2008 From: aph at redhat.com (Andrew Haley) Date: Mon, 7 Jan 2008 13:46:09 +0000 Subject: Feedback request: OpenJDK Community Innovator's Challenge Grants In-Reply-To: <17c6771e0801070508s52a9544fy38efccc395dfaf6f@mail.gmail.com> References: <478034E8.5000207@nefkom.net> <17c6771e0801051849n4dd8cc50kdc8553da54b57c85@mail.gmail.com> <47816884.8040604@nefkom.net> <18305.63719.125363.896219@zebedee.pink> <17c6771e0801070206k4b10d300h5544b40c67679c1@mail.gmail.com> <18306.4343.714808.312952@zebedee.pink> <17c6771e0801070508s52a9544fy38efccc395dfaf6f@mail.gmail.com> Message-ID: <18306.11553.202792.517850@zebedee.pink> Andrew John Hughes writes: > On 07/01/2008, Andrew Haley wrote: > > > > Andrew John Hughes writes: > > > On 07/01/2008, Andrew Haley wrote: > > > > > > > > Arnd-Hendrik Mathias writes: > > > > > > > > > How about some concept like using some java2native compilers or > > > > > some java enabled gcc to build the necessary set of bootstrap JDK > > > > > components in a pre-build-step and then using these for building > > > > > the real OpenJDK. > > > > > > > > That's how IcedTea works. > > > > > > It doesn't do anything native, AFAIK -- it just creates a > > pseudo-bootstrap > > > JDK. > > > > What does "it doesn't do anything native, AFAIK" mean? I can't tell > > if you agree with me or not. > > I interpreted the question (perhaps wrongly) as looking for a > solution that wouldn't require a Java VM and class library > i.e. that there would be a preliminary step that created a native > toolchain of javac, etc. which could then be used to bootstrap the > OpenJDK in full. IcedTea only does half of this; it creates the > pseudo-bootstrap environment using ecj and a Java VM, but this is > not native. I still don't know what you mean by this. The OP said "use some java enabled gcc to build the necessary set of bootstrap JDK components in a pre-build-step." That's exactly what we do with gcj! > I'm not sure how much of an issue that is, as you'd still need > libgcj to run the native binaries. None at all, I wouldn't have thought. Andrew. -- Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK Registered in England and Wales No. 3798903 From gnu_andrew at member.fsf.org Mon Jan 7 14:51:25 2008 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Mon, 7 Jan 2008 14:51:25 +0000 Subject: Feedback request: OpenJDK Community Innovator's Challenge Grants In-Reply-To: <18306.11553.202792.517850@zebedee.pink> References: <478034E8.5000207@nefkom.net> <17c6771e0801051849n4dd8cc50kdc8553da54b57c85@mail.gmail.com> <47816884.8040604@nefkom.net> <18305.63719.125363.896219@zebedee.pink> <17c6771e0801070206k4b10d300h5544b40c67679c1@mail.gmail.com> <18306.4343.714808.312952@zebedee.pink> <17c6771e0801070508s52a9544fy38efccc395dfaf6f@mail.gmail.com> <18306.11553.202792.517850@zebedee.pink> Message-ID: <17c6771e0801070651m645b5692m316a9ca630547a7a@mail.gmail.com> On 07/01/2008, Andrew Haley wrote: > > Andrew John Hughes writes: > > On 07/01/2008, Andrew Haley wrote: > > > > > > Andrew John Hughes writes: > > > > On 07/01/2008, Andrew Haley wrote: > > > > > > > > > > Arnd-Hendrik Mathias writes: > > > > > > > > > > > How about some concept like using some java2native compilers or > > > > > > some java enabled gcc to build the necessary set of bootstrap > JDK > > > > > > components in a pre-build-step and then using these for building > > > > > > the real OpenJDK. > > > > > > > > > > That's how IcedTea works. > > > > > > > > It doesn't do anything native, AFAIK -- it just creates a > > > pseudo-bootstrap > > > > JDK. > > > > > > What does "it doesn't do anything native, AFAIK" mean? I can't tell > > > if you agree with me or not. > > > > I interpreted the question (perhaps wrongly) as looking for a > > solution that wouldn't require a Java VM and class library > > i.e. that there would be a preliminary step that created a native > > toolchain of javac, etc. which could then be used to bootstrap the > > OpenJDK in full. IcedTea only does half of this; it creates the > > pseudo-bootstrap environment using ecj and a Java VM, but this is > > not native. > > I still don't know what you mean by this. The OP said "use some java > enabled gcc to build the necessary set of bootstrap JDK components in > a pre-build-step." That's exactly what we do with gcj! > > > I'm not sure how much of an issue that is, as you'd still need > > libgcj to run the native binaries. > > None at all, I wouldn't have thought. > > Andrew. > > -- > Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, > Berkshire, SL4 1TE, UK > Registered in England and Wales No. 3798903 > I guess it was the mention of 'java2native compilers' that confused me -- I thought he specifically wanted a native solution, and we were discussing the bootstrap issue of every 1.5 compiler being written in Java. Yes, IcedTea works with gcj but equally what it does could be achieved with any of the Classpath VMs. -- 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 Steve.Goldman at Sun.COM Mon Jan 7 14:59:40 2008 From: Steve.Goldman at Sun.COM (steve goldman) Date: Mon, 07 Jan 2008 09:59:40 -0500 Subject: Building openjdk for ARM Linux. In-Reply-To: <50be7b020801050537l621861a5nd398372679fc29f0@mail.gmail.com> References: <470b63970801041703t24e9e121y39681700a6b5265f@mail.gmail.com> <18303.25030.93337.109497@zebedee.pink> <50be7b020801050537l621861a5nd398372679fc29f0@mail.gmail.com> Message-ID: <47823E5C.2050505@sun.com> Pieter Libin wrote: > I thought there also was a c++ interpreter available, > maybe it's a good idea to start with this instead of writing all the > ARM assembly. > There is still plenty of assembly code (and an assembler) that you need to write even if you use the c++ interpreter. -- Steve From Kelly.Ohair at Sun.COM Wed Jan 9 19:58:30 2008 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Wed, 09 Jan 2008 11:58:30 -0800 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: <47852766.3000404@sun.com> Adding build-dev to the CC list, seems like these are build issues... 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. At some point in time (a long long time ago?), it was decided that the jdk Makefiles should always run utilities with a full pathname and not rely on the PATH setting. I kind of understand what the issue was, PATH ordering issues can be extremely hard to diagnose. But I myself find it a maintenance nightmare because of what you have run into. I don't know if this will change, and there is some risk of relying on PATH especially on Windows, but just so you know, this is a known issue and debate. I tend to think that we should rely on PATH more, especially when it relates to the basic utility commands like 'cd', 'sed', etc. I hate having to use '$(CD)' in the makefiles instead of just 'cd'. :^( Maybe a PATH sanity check on the utilities used somehow, devise a simple use case for each utility used, and verify the utility from PATH is acceptable... Ah... but I know what you will say, just use autotools... well... does autotools work on Windows with VS2003? :^( > > 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? Sounds like the above is a known png issue... > > 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. This is the same question I have. These have been handed down over time and I'm not exactly sure why the override (you did mean override, right?) was used so much. I consider the use of override bad style, figuring out how make variables get defined is hard enough without complicating things with an override setting. The 'override VAR += XXX' might make sense, but even then you can get the same results by introducing another variable, and it might be more obvious what's happening that way, but we don't use the += with override. (For those of you unfamiliar with GNU make 'override', see http://www.gnu.org/software/make/manual/make.html#Override-Directive) I do know that the name TMPDIR was an issue, but we changed that to TEMPDIR a long time ago and the override on TEMPDIR is probably not necessary anymore. (TMPDIR was treated special in Linux or GNU make at some point??? but it's a name that should be avoided, or at least avoided as your own variable name :^). But I'm a little nervous about all these Linux variables that use override: --- override ALT_CODESET_KEY = _NL_CTYPE_CODESET_NAME override AWT_RUNPATH = override HAVE_ALTZONE = false override HAVE_FILIOH = false override HAVE_GETHRTIME = false override HAVE_GETHRVTIME = false override HAVE_SIGIGNORE = true override LEX_LIBRARY = -lfl ifeq ($(STATIC_CXX),true) override LIBCXX = -Wl,-Bstatic -lstdc++ -lgcc -Wl,-Bdynamic else override LIBCXX = -lstdc++ endif override LIBPOSIX4 = override LIBSOCKET = override LIBTHREAD = override MOOT_PRIORITIES = true override NO_INTERRUPTIBLE_IO = true override OPENWIN_HOME = /usr/X11R6 ifeq ($(ARCH), amd64) override OPENWIN_LIB = $(OPENWIN_HOME)/lib64 else override OPENWIN_LIB = $(OPENWIN_HOME)/lib endif override OTHER_M4FLAGS = -D__GLIBC__ -DGNU_ASSEMBLER override SUN_CMM_SUBDIR = override THREADS_FLAG = native override USE_GNU_M4 = true override USING_GNU_TAR = true override WRITE_LIBVERSION = false # USE_EXECNAME forces the launcher to look up argv[0] on $PATH, and put the # resulting resolved absolute name of the executable in the environment # variable EXECNAME. That executable name is then used that to locate the # installation area. override USE_EXECNAME = true --- Some I recognize, but every one of these variables would need to be investigated to see why the override was necessary and if we can safely remove it. Why not allow someone to set these on the command line if they wanted? I'm certainly in favor of removing unnecessary override's. -kto > Best regards > > Arnd-Hendrik From Debra.Scott at Sun.COM Thu Jan 10 00:25:43 2008 From: Debra.Scott at Sun.COM (Debra Scott) Date: Wed, 09 Jan 2008 18:25:43 -0600 Subject: JDK documentation Message-ID: <47856607.4040202@sun.com> Hi All, I'd like to get people's thoughts on the documentation for the JDK platform. * How many people feel it is important for the the docs to be open sourced so the community can contribute to them? * How many people have seen at least one occasion where they would have added something to the documentation, or made a correction, if they had been able? (a large or small percentage?) * Given that we need documentation in a structured format that allows for content sharing and multiple delivery vehicles, does anyone have any recommendations for a system that is both easily editable, like a Wiki, and easily repurposable, like XML-structured docs? * If so, do people know of conversion tools, and/or would they be willing to help with conversions? * If not, would they be willing to participate in the development of such a system? -Thanks for your feedback, Debbie -- ========================================================================== Debra Scott 39 Golden Wheat Ln Manager of Java SE Documentation Wrightstown, WI 54180 Information Products Group Phone: 877-219-2362 x51743 Global Product Development & Operations, Sun Microsystems, Inc ========================================================================== From dalibor.topic at googlemail.com Thu Jan 10 00:29:01 2008 From: dalibor.topic at googlemail.com (Dalibor Topic) Date: Thu, 10 Jan 2008 01:29:01 +0100 Subject: JDK 7 build 24 is available at the openjdk.java.net website In-Reply-To: <47852766.3000404@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> <47852766.3000404@sun.com> Message-ID: <478566CD.5060600@kaffe.org> Kelly O'Hair wrote: > Maybe a PATH sanity check on the utilities used somehow, devise a simple > use case for each utility used, and verify the utility from PATH is > acceptable... Ah... but I know what you will say, just use autotools... > well... does autotools work on Windows with VS2003? :^( Last time around I had to use msvc 2003 from autotools, I used http://cccl.sourceforge.net/ to make it work, and it worked for me. cheers, dalibor topic From scolebourne at joda.org Thu Jan 10 00:56:20 2008 From: scolebourne at joda.org (Stephen Colebourne) Date: Thu, 10 Jan 2008 00:56:20 +0000 Subject: JDK documentation In-Reply-To: <47856607.4040202@sun.com> References: <47856607.4040202@sun.com> Message-ID: <47856D34.40301@joda.org> Debra Scott wrote: > I'd like to get people's thoughts on the documentation > for the JDK platform. > > * How many people feel it is important for the the docs to be open > sourced so the community can contribute to them? Are you referring to javadoc, or other docs? > * How many people have seen at least one occasion > where they would have added something to the > documentation, or made a correction, if they > had been able? (a large or small percentage?) I have had plenty of simple javadoc fixes I've seen and might have made (like documenting what happens with null). But I suspect that is not what you are driving at. Stephen From amitksaha at netbeans.org Thu Jan 10 05:42:27 2008 From: amitksaha at netbeans.org (Amit Kumar Saha) Date: Thu, 10 Jan 2008 11:12:27 +0530 Subject: JDK documentation In-Reply-To: <547db2260801092141y57e0135fga204ea1706365144@mail.gmail.com> References: <47856607.4040202@sun.com> <547db2260801092141y57e0135fga204ea1706365144@mail.gmail.com> Message-ID: <547db2260801092142m4e7c6c23jf9410e66d2821af2@mail.gmail.com> On 1/10/08, Debra Scott wrote: > Hi All, > > I'd like to get people's thoughts on the documentation > for the JDK platform. > > * How many people feel it is important for the the docs to be open > sourced so the community can contribute to them? How about something which is modeled on the "NetBeans Community Docs" (http://wiki.netbeans.org/wiki/view/CommunityDocs)? > > > * How many people have seen at least one occasion > where they would have added something to the > documentation, or made a correction, if they > had been able? (a large or small percentage?) > > * Given that we need documentation in a structured > format that allows for content sharing and multiple > delivery vehicles, does anyone have any recommendations > for a system that is both easily editable, like a > Wiki, and easily repurposable, like XML-structured > docs? How about using ODT? Just my thoughts, opinions! Thanks, Amit -- Amit Kumar Saha *NetBeans Community Docs Coordinator* Writer, Programmer, Researcher http://amitsaha.in.googlepages.com http://amitksaha.blogspot.com From mthornton at optrak.co.uk Thu Jan 10 09:04:35 2008 From: mthornton at optrak.co.uk (Mark Thornton) Date: Thu, 10 Jan 2008 09:04:35 +0000 Subject: JDK documentation In-Reply-To: <47856607.4040202@sun.com> References: <47856607.4040202@sun.com> Message-ID: <4785DFA3.2070809@optrak.co.uk> Debra Scott wrote: > Hi All, > > I'd like to get people's thoughts on the documentation > for the JDK platform. > > * How many people feel it is important for the the docs to be open > sourced so the community can contribute to them? I think this would be very valuable. > > > * How many people have seen at least one occasion > where they would have added something to the > documentation, or made a correction, if they > had been able? (a large or small percentage?) There are numerous changes many small, some more substantial that I might have made. As it is some exist as comments to bugs on the bug parade (and have been referenced by the evaluation). A particular flaw in the current documentation is the poor (often non-existent) documenting of platform specific behaviour. Some people seem very clear that this information should go somewhere else, without doing anything to ensure that a suitable other place is created and populated. Mark Thornton From david.gilbert at object-refinery.com Thu Jan 10 10:00:08 2008 From: david.gilbert at object-refinery.com (David Gilbert) Date: Thu, 10 Jan 2008 10:00:08 +0000 Subject: JDK documentation In-Reply-To: <47856607.4040202@sun.com> References: <47856607.4040202@sun.com> Message-ID: <4785ECA8.1030201@object-refinery.com> Hi, Debra Scott wrote: > Hi All, > > I'd like to get people's thoughts on the documentation > for the JDK platform. > > * How many people feel it is important for the the docs to be open > sourced so the community can contribute to them? Very important. > > * How many people have seen at least one occasion > where they would have added something to the > documentation, or made a correction, if they > had been able? (a large or small percentage?) In the API docs, I've often spotted corner cases that aren't documented. In the past, I've documented these in the GNU Classpath API. I should probably start submitting patches to OpenJDK for these, but I wonder if that's very efficient because the changes are small and the process is not so lightweight as we had for GNU Classpath (that's not a criticism, it's just an observation, because I understand the need for greater rigor in the OpenJDK process). > * Given that we need documentation in a structured > format that allows for content sharing and multiple > delivery vehicles, does anyone have any recommendations > for a system that is both easily editable, like a > Wiki, and easily repurposable, like XML-structured > docs? A few years ago, the guys at JavaLobby started an excellent initiative called JDocs. They loaded up the Javadocs for the JDK and invited the community to annotate them with useful pointers, sample code etc. Sun (or its lawyers) unfortunately squashed the initiative and it more or less died (JDocs is still there, but the project seemed to lose momentum after the Java SE APIs were removed). Maybe you could get in touch with Rick Ross and Matthew Schmidt at Javalobby and ask them about it...an perhaps inject some new life into JDocs. Regards, Dave Gilbert http://www.jfree.org/ From Debra.Scott at Sun.COM Thu Jan 10 10:53:57 2008 From: Debra.Scott at Sun.COM (Debra Scott) Date: Thu, 10 Jan 2008 04:53:57 -0600 Subject: JDK documentation In-Reply-To: <47856D34.40301@joda.org> References: <47856607.4040202@sun.com> <47856D34.40301@joda.org> Message-ID: <4785F945.1080604@sun.com> As javadoc is already open source, I'm not talking about those docs (which are fixed through the source code files) I'm talking about the JDK guide documentation that is part of the JDK documentation download bundle -Debbie Stephen Colebourne wrote: > Debra Scott wrote: > >> I'd like to get people's thoughts on the documentation >> for the JDK platform. >> >> * How many people feel it is important for the the docs to be open >> sourced so the community can contribute to them? > > > Are you referring to javadoc, or other docs? > >> * How many people have seen at least one occasion >> where they would have added something to the >> documentation, or made a correction, if they >> had been able? (a large or small percentage?) > > > I have had plenty of simple javadoc fixes I've seen and might have made > (like documenting what happens with null). But I suspect that is not > what you are driving at. > > Stephen -- ========================================================================== Debra Scott 39 Golden Wheat Ln Manager of Java SE Documentation Wrightstown, WI 54180 Information Products Group Phone: 877-219-2362 x51743 Global Product Development & Operations, Sun Microsystems, Inc ========================================================================== From David.Holmes at Sun.COM Thu Jan 10 11:15:45 2008 From: David.Holmes at Sun.COM (David Holmes - Sun Microsystems) Date: Thu, 10 Jan 2008 21:15:45 +1000 Subject: JDK documentation In-Reply-To: <4785F945.1080604@sun.com> References: <47856607.4040202@sun.com> <47856D34.40301@joda.org> <4785F945.1080604@sun.com> Message-ID: <4785FE61.2050904@sun.com> Debra, Thanks for clarifying that it was the guides you meant - I totally agree they should be opened up and expanded/improved by the community. But I disagree with what you say about the javadocs. While the javadoc are part of the source files, they form the specification for the platform API's and as far as I am aware the specification for the Java platform is not open-sourced. So any "fixes" to the javadocs would not, I believe, be acceptable through OpenJDK contributions, unless done as part of a JSR. Hopefully Mark, or someone else in the know, could clarify this. I know I've been frustrated over the years by the apparent inability to get anything but the most trivial typos fixed in the docs, except during major releases. It would be nice if that could change but I'm not aware that it has at this stage. Cheers, David Holmes Debra Scott said the following on 10/01/08 08:53 PM: > As javadoc is already open source, I'm not talking about those docs > (which are fixed through the source code files) > > I'm talking about the JDK guide documentation that is part > of the JDK documentation download bundle > > -Debbie > > Stephen Colebourne wrote: >> Debra Scott wrote: >> >>> I'd like to get people's thoughts on the documentation >>> for the JDK platform. >>> >>> * How many people feel it is important for the the docs to be open >>> sourced so the community can contribute to them? >> >> >> Are you referring to javadoc, or other docs? >> >>> * How many people have seen at least one occasion >>> where they would have added something to the >>> documentation, or made a correction, if they >>> had been able? (a large or small percentage?) >> >> >> I have had plenty of simple javadoc fixes I've seen and might have >> made (like documenting what happens with null). But I suspect that is >> not what you are driving at. >> >> Stephen > From Debra.Scott at Sun.COM Thu Jan 10 11:26:42 2008 From: Debra.Scott at Sun.COM (Debra Scott) Date: Thu, 10 Jan 2008 05:26:42 -0600 Subject: JDK documentation In-Reply-To: <4785ECA8.1030201@object-refinery.com> References: <47856607.4040202@sun.com> <4785ECA8.1030201@object-refinery.com> Message-ID: <478600F2.8000400@sun.com> All, I apologize for not being clear on my original post. The JDK documentation, that provided in the zip file we refer to as the JDK documentation bundle, includes: * API docs (javadocs, which are already open source as they are derived from the .java source files) -- I'm not referring to these as you already have access to changing these as part of source code contributions/fixes * guides documentation (for example, see http://java.sun.com/javase/6/docs/technotes/guides/) * tools (for example, see http://java.sun.com/javase/6/docs/technotes/tools) Do most of you only use the API docs and are these the docs you think of? If so, maybe it isn't worth the effort to open source the rest of our documentation? -Debbie David Gilbert wrote: > Hi, > > Debra Scott wrote: > >> Hi All, >> >> I'd like to get people's thoughts on the documentation >> for the JDK platform. >> >> * How many people feel it is important for the the docs to be open >> sourced so the community can contribute to them? > > Very important. > >> >> * How many people have seen at least one occasion >> where they would have added something to the >> documentation, or made a correction, if they >> had been able? (a large or small percentage?) > > In the API docs, I've often spotted corner cases that aren't > documented. In the past, I've documented these in the GNU Classpath > API. I should probably start submitting patches to OpenJDK for these, > but I wonder if that's very efficient because the changes are small and > the process is not so lightweight as we had for GNU Classpath (that's > not a criticism, it's just an observation, because I understand the need > for greater rigor in the OpenJDK process). > >> * Given that we need documentation in a structured >> format that allows for content sharing and multiple >> delivery vehicles, does anyone have any recommendations >> for a system that is both easily editable, like a >> Wiki, and easily repurposable, like XML-structured >> docs? > > A few years ago, the guys at JavaLobby started an excellent initiative > called JDocs. They loaded up the Javadocs for the JDK and invited the > community to annotate them with useful pointers, sample code etc. Sun > (or its lawyers) unfortunately squashed the initiative and it more or > less died (JDocs is still there, but the project seemed to lose momentum > after the Java SE APIs were removed). Maybe you could get in touch with > Rick Ross and Matthew Schmidt at Javalobby and ask them about it...an > perhaps inject some new life into JDocs. > > Regards, > > Dave Gilbert > http://www.jfree.org/ -- ========================================================================== Debra Scott 39 Golden Wheat Ln Manager of Java SE Documentation Wrightstown, WI 54180 Information Products Group Phone: 877-219-2362 x51743 Global Product Development & Operations, Sun Microsystems, Inc ========================================================================== From david.gilbert at object-refinery.com Thu Jan 10 11:29:07 2008 From: david.gilbert at object-refinery.com (David Gilbert) Date: Thu, 10 Jan 2008 11:29:07 +0000 Subject: JDK documentation In-Reply-To: <4785FE61.2050904@sun.com> References: <47856607.4040202@sun.com> <47856D34.40301@joda.org> <4785F945.1080604@sun.com> <4785FE61.2050904@sun.com> Message-ID: <47860183.7090603@object-refinery.com> David Holmes - Sun Microsystems wrote: > > But I disagree with what you say about the javadocs. While the javadoc > are part of the source files, they form the specification for the > platform API's and as far as I am aware the specification for the Java > platform is not open-sourced. So any "fixes" to the javadocs would > not, I believe, be acceptable through OpenJDK contributions, unless > done as part of a JSR. Hopefully Mark, or someone else in the know, > could clarify this. > > I know I've been frustrated over the years by the apparent inability > to get anything but the most trivial typos fixed in the docs, except > during major releases. It would be nice if that could change but I'm > not aware that it has at this stage. I really think there is a need for two versions of the Javadocs, one that is a specification (that is, what we have now) and another that is "developer documentation". The latter is, I believe, what the Javalobby guys were/are trying to do with JDocs.com. Promoting their existing effort seems worth exploring, in my opinion, especially since it can exist independently of the source code. Regards, Dave Gilbert http://www.jfree.org/ From mthornton at optrak.co.uk Thu Jan 10 11:34:55 2008 From: mthornton at optrak.co.uk (Mark Thornton) Date: Thu, 10 Jan 2008 11:34:55 +0000 Subject: JDK documentation In-Reply-To: <47860183.7090603@object-refinery.com> References: <47856607.4040202@sun.com> <47856D34.40301@joda.org> <4785F945.1080604@sun.com> <4785FE61.2050904@sun.com> <47860183.7090603@object-refinery.com> Message-ID: <478602DF.1010700@optrak.co.uk> David Gilbert wrote: > David Holmes - Sun Microsystems wrote: >> >> But I disagree with what you say about the javadocs. While the >> javadoc are part of the source files, they form the specification for >> the platform API's and as far as I am aware the specification for the >> Java platform is not open-sourced. So any "fixes" to the javadocs >> would not, I believe, be acceptable through OpenJDK contributions, >> unless done as part of a JSR. Hopefully Mark, or someone else in the >> know, could clarify this. >> >> I know I've been frustrated over the years by the apparent inability >> to get anything but the most trivial typos fixed in the docs, except >> during major releases. It would be nice if that could change but I'm >> not aware that it has at this stage. > I really think there is a need for two versions of the Javadocs, one > that is a specification (that is, what we have now) and another that > is "developer documentation". The latter is, I believe, what the > Javalobby guys were/are trying to do with JDocs.com. Promoting their > existing effort seems worth exploring, in my opinion, especially since > it can exist independently of the source code. > Some things like platform specific behaviour would be very convenient if included as annotations on the Java Doc rather than in some completely separate (non existent) document. Others like how to run RMID as a service need to be part of the tool documentation. Mark Thornton From Lance.Andersen at Sun.COM Thu Jan 10 14:10:14 2008 From: Lance.Andersen at Sun.COM (Lance Andersen) Date: Thu, 10 Jan 2008 09:10:14 -0500 Subject: JDK documentation In-Reply-To: <478600F2.8000400@sun.com> References: <47856607.4040202@sun.com> <4785ECA8.1030201@object-refinery.com> <478600F2.8000400@sun.com> Message-ID: Hi Debbie,, On Jan 10, 2008, at 6:26 AM, Debra Scott wrote: > All, > > I apologize for not being clear on my original post. > > The JDK documentation, that provided in the zip file we > refer to as the JDK documentation bundle, includes: > > * API docs (javadocs, which are already open source as they are > derived from the .java source files) -- I'm not referring to these > as you already have access to changing these as part of source code > contributions/fixes > These javadocs cannot arbitrarily be changed as these are part of the specification without working through the Expert Group (or spec lead review at a minimum) Regards lance > * guides documentation (for example, see http://java.sun.com/javase/6/docs/technotes/guides/) > > * tools (for example, see > http://java.sun.com/javase/6/docs/technotes/tools) > > > Do most of you only use the API docs and are these the docs you > think of? > If so, maybe it isn't worth the effort to open source the rest of our > documentation? > > > -Debbie > > > > David Gilbert wrote: >> Hi, >> Debra Scott wrote: >>> Hi All, >>> >>> I'd like to get people's thoughts on the documentation >>> for the JDK platform. >>> >>> * How many people feel it is important for the the docs to be open >>> sourced so the community can contribute to them? >> Very important. >>> >>> * How many people have seen at least one occasion >>> where they would have added something to the >>> documentation, or made a correction, if they >>> had been able? (a large or small percentage?) >> In the API docs, I've often spotted corner cases that aren't >> documented. In the past, I've documented these in the GNU >> Classpath API. I should probably start submitting patches to >> OpenJDK for these, but I wonder if that's very efficient because >> the changes are small and the process is not so lightweight as we >> had for GNU Classpath (that's not a criticism, it's just an >> observation, because I understand the need for greater rigor in the >> OpenJDK process). >>> * Given that we need documentation in a structured >>> format that allows for content sharing and multiple >>> delivery vehicles, does anyone have any recommendations >>> for a system that is both easily editable, like a >>> Wiki, and easily repurposable, like XML-structured >>> docs? >> A few years ago, the guys at JavaLobby started an excellent >> initiative called JDocs. They loaded up the Javadocs for the JDK >> and invited the community to annotate them with useful pointers, >> sample code etc. Sun (or its lawyers) unfortunately squashed the >> initiative and it more or less died (JDocs is still there, but the >> project seemed to lose momentum after the Java SE APIs were >> removed). Maybe you could get in touch with Rick Ross and Matthew >> Schmidt at Javalobby and ask them about it...an perhaps inject some >> new life into JDocs. >> Regards, >> Dave Gilbert >> http://www.jfree.org/ > > -- > > = > = > = > = > ====================================================================== > Debra Scott 39 Golden Wheat Ln > Manager of Java SE Documentation Wrightstown, WI 54180 > Information Products Group Phone: 877-219-2362 > x51743 > Global Product Development & Operations, Sun Microsystems, Inc > = > = > = > = > ====================================================================== From aph at redhat.com Thu Jan 10 14:16:23 2008 From: aph at redhat.com (Andrew Haley) Date: Thu, 10 Jan 2008 14:16:23 +0000 Subject: JDK documentation In-Reply-To: <4785FE61.2050904@sun.com> References: <47856607.4040202@sun.com> <47856D34.40301@joda.org> <4785F945.1080604@sun.com> <4785FE61.2050904@sun.com> Message-ID: <18310.10423.306004.811650@zebedee.pink> David Holmes - Sun Microsystems writes: > Thanks for clarifying that it was the guides you meant - I totally > agree they should be opened up and expanded/improved by the > community. > > But I disagree with what you say about the javadocs. While the > javadoc are part of the source files, they form the specification > for the platform API's and as far as I am aware the specification > for the Java platform is not open-sourced. So any "fixes" to the > javadocs would not, I believe, be acceptable through OpenJDK > contributions, unless done as part of a JSR. Hopefully Mark, or > someone else in the know, could clarify this. > > I know I've been frustrated over the years by the apparent > inability to get anything but the most trivial typos fixed in the > docs, except during major releases. It would be nice if that could > change but I'm not aware that it has at this stage. Most of the changes I'd make to the javadocs are clarifications, not changes in intent. To clarify, here's an example that bit me. The javadoc for javax.management.MBeanServer.registerMBean() says, in full, "Registers a pre-existing object as an MBean with the MBean server. If the object name given is null, the MBean must provide its own name by implementing the MBeanRegistration interface and returning the name from the preRegister method." The overview at the top of the page also says "When an MBean is registered or unregistered in the MBean server a MBeanServerNotification Notification is emitted." So, you can only tell that registerMBean() has this side-effect if you read the whole page. I would change that method's decription to something like "Registers a pre-existing object as an MBean with the MBean server, emitting a MBeanServerNotification Notification. If the object name given is null, ...." This is not a specification change, but makes it easier to understand the javadoc. Andrew. -- Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK Registered in England and Wales No. 3798903 From gnu_andrew at member.fsf.org Thu Jan 10 14:34:22 2008 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Thu, 10 Jan 2008 14:34:22 +0000 Subject: JDK documentation In-Reply-To: <478600F2.8000400@sun.com> References: <47856607.4040202@sun.com> <4785ECA8.1030201@object-refinery.com> <478600F2.8000400@sun.com> Message-ID: <17c6771e0801100634p44edfc91jdaaf39b4ef7ff1b3@mail.gmail.com> On 10/01/2008, Debra Scott wrote: > All, > > I apologize for not being clear on my original post. > > The JDK documentation, that provided in the zip file we > refer to as the JDK documentation bundle, includes: > > * API docs (javadocs, which are already open source as they are > derived from the .java source files) -- I'm not referring to these > as you already have access to changing these as part of source code > contributions/fixes > As others have said, these can't be changed easily as they form the specification for the Java platform. Indeed, they are the basis for other implementations such as GNU Classpath. It's tricky, because you do really need another layer of API documentation that documents the local implementation issues. Many a time when working on GNU Classpath it's been a case of 'that sounds nice, but how would you actually implement it?' or in using it 'so how does this actually work?' An example is the cases where there is an interface as part of the specification and then implementations of that are dependent on the JDK. It hasn't always been clear what you get with the OpenJDK: I remember reading the printing API, thinking I could use it to manipulate PDFs, but you couldn't because there wasn't a PDF backend (there may be now -- this is 2002). A lot of these issues are solved partially by the availability of source of course, but are still issues for end users. Andrew Haley makes a good point with the JMX example, which I remember caught us out when implementing that class. There are certainly cases where things could be made clearer and more usable without altering the specification. There are also some that are downright unusable e.g. classes in java.beans.beancontext IIRC -- it's a good job they have a separate and open PDF spec! > * guides documentation (for example, see > http://java.sun.com/javase/6/docs/technotes/guides/) > > * tools (for example, see > http://java.sun.com/javase/6/docs/technotes/tools) > > > Do most of you only use the API docs and are these the docs you think of? > If so, maybe it isn't worth the effort to open source the rest of our > documentation? > I think many of us think of the API documentation. To be honest, the other two I've not used as much simply because until now I haven't been using Sun's JDK as it was proprietary. I guess this is the case for a lot of GNU Classpath developers, who will have only checked these docs to see what kind of user interface the equivalent tools in GNU Classpath should provide. I'm actually quite surprised that they aren't part of the OpenJDK source code drop. That's where GNU Classpath's documentation is held and it would seem a more appropriate place. Certainly if people are going to hack on the OpenJDK, then the documentation needs to be kept in sync with these changes! Obviously, translation would be another advantage too now you can pull on a worldwide community of developers instead of just Sun employees. > > -Debbie > > > > David Gilbert wrote: > > Hi, > > > > Debra Scott wrote: > > > >> Hi All, > >> > >> I'd like to get people's thoughts on the documentation > >> for the JDK platform. > >> > >> * How many people feel it is important for the the docs to be open > >> sourced so the community can contribute to them? > > > > Very important. > > > >> > >> * How many people have seen at least one occasion > >> where they would have added something to the > >> documentation, or made a correction, if they > >> had been able? (a large or small percentage?) > > > > In the API docs, I've often spotted corner cases that aren't > > documented. In the past, I've documented these in the GNU Classpath > > API. I should probably start submitting patches to OpenJDK for these, > > but I wonder if that's very efficient because the changes are small and > > the process is not so lightweight as we had for GNU Classpath (that's > > not a criticism, it's just an observation, because I understand the need > > for greater rigor in the OpenJDK process). > > > >> * Given that we need documentation in a structured > >> format that allows for content sharing and multiple > >> delivery vehicles, does anyone have any recommendations > >> for a system that is both easily editable, like a > >> Wiki, and easily repurposable, like XML-structured > >> docs? > > > > A few years ago, the guys at JavaLobby started an excellent initiative > > called JDocs. They loaded up the Javadocs for the JDK and invited the > > community to annotate them with useful pointers, sample code etc. Sun > > (or its lawyers) unfortunately squashed the initiative and it more or > > less died (JDocs is still there, but the project seemed to lose momentum > > after the Java SE APIs were removed). Maybe you could get in touch with > > Rick Ross and Matthew Schmidt at Javalobby and ask them about it...an > > perhaps inject some new life into JDocs. > > > > Regards, > > > > Dave Gilbert > > http://www.jfree.org/ > > -- > > ========================================================================== > Debra Scott 39 Golden Wheat Ln > Manager of Java SE Documentation Wrightstown, WI 54180 > Information Products Group Phone: 877-219-2362 x51743 > Global Product Development & Operations, Sun Microsystems, Inc > ========================================================================== > -- Andrew :-) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net From openjdk at jazillian.com Thu Jan 10 16:03:15 2008 From: openjdk at jazillian.com (Andy Tripp) Date: Thu, 10 Jan 2008 11:03:15 -0500 Subject: JDK documentation In-Reply-To: <478600F2.8000400@sun.com> References: <47856607.4040202@sun.com> <4785ECA8.1030201@object-refinery.com> <478600F2.8000400@sun.com> Message-ID: <478641C3.5060104@jazillian.com> > Do most of you only use the API docs and are these the docs you think > of? > If so, maybe it isn't worth the effort to open source the rest of our > documentation? As you can probably tell, the API docs are far more important than the other docs, at least for the non-beginners who read this mailing list. The other docs seem fine to me. There are many other "guides" and the documentation for the tools is pretty straightforward. As others have pointed out, there is a huge issue around the API docs. How can we all contribute useful clarifications, corrections, and additions without going through the whole JCP process? How do you maintain some reasonable control to keep the quality up while keeping it very simple to make changes? In short, how do you let me quickly fix a typo in the API, but stop me from adding the comment "this method sucks!" Seems like you'll have to decide whether to spend the rest of your life tackling this API issue, or not. I don't much care what the process is for the other docs. I've talked to Ray Gans about the API issue - he may have some ideas. Andy From mthornton at optrak.co.uk Thu Jan 10 16:11:16 2008 From: mthornton at optrak.co.uk (Mark Thornton) Date: Thu, 10 Jan 2008 16:11:16 +0000 Subject: JDK documentation In-Reply-To: <478641C3.5060104@jazillian.com> References: <47856607.4040202@sun.com> <4785ECA8.1030201@object-refinery.com> <478600F2.8000400@sun.com> <478641C3.5060104@jazillian.com> Message-ID: <478643A4.8000205@optrak.co.uk> Andy Tripp wrote: > to keep the quality up while keeping it very simple to make changes? > In short, > how do you let me quickly fix a typo in the API, but stop me from adding > the comment "this method sucks!" There are quite a few methods (and classes) where a @notRecommended tag might be appropriate. A JavaDoc that moved these (and @deprecated) methods to a supplementary page would be great too. Mark Thornton From jesse.glick at sun.com Thu Jan 10 16:34:11 2008 From: jesse.glick at sun.com (Jesse Glick) Date: Thu, 10 Jan 2008 11:34:11 -0500 Subject: JDK documentation In-Reply-To: <47860183.7090603@object-refinery.com> References: <47856607.4040202@sun.com> <47856D34.40301@joda.org> <4785F945.1080604@sun.com> <4785FE61.2050904@sun.com> <47860183.7090603@object-refinery.com> Message-ID: David Gilbert wrote: > I really think there is a need for two versions of the Javadocs, one > that is a specification (that is, what we have now) and another that > is "developer documentation". Has anyone considered using explicitly nonnormative sections? The W3C marks sections of printed specifications nonnormative ("informational" and not "normative") - examples, motivations, implementation hints, etc. For NetBeans documentation, we sometimes put blocks of nonnormative text in Javadoc. It is a simple matter of using CSS to make such blocks appear with a special background color, maybe a vertical banner in the gutter saying "NONNORMATIVE", etc. You just put in Javadoc: /** * Returns the frobnitz quotient of this reactor core. * Must be in the interval [0,1) and no greater than * the frobnitz coquotient. *
* Most implementations use 0.5. *
*/ public float getFrobnitzQuotient() {return 0.5;} Here is an example of output using a very simple CSS rule: http://bits.netbeans.org/dev/javadoc/org-openide-filesystems/org/openide/filesystems/FileUtil.html#toFileObject(java.io.File) I expect it would not be difficult to make a tool which processes documentation and strips out all nonnormative sections so as to create an official API specification. (It would be good to check that popular IDEs render the nonnormative section specially e.g. in code completion popups.) > what the Javalobby guys were/are trying to do with JDocs.com Sort of a JDK Talmud, if you will. The challenge is discoverability: docs that the user does not know exist are of no help. -- jesse.glick at sun.com netbeans.org ant.apache.org hudson.dev.java.net selenic.com/mercurial http://google.com/search?q=e%5E%28pi*i%29%2B1 From Kelly.Ohair at Sun.COM Thu Jan 10 17:53:41 2008 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Thu, 10 Jan 2008 09:53:41 -0800 Subject: JDK documentation In-Reply-To: <478641C3.5060104@jazillian.com> References: <47856607.4040202@sun.com> <4785ECA8.1030201@object-refinery.com> <478600F2.8000400@sun.com> <478641C3.5060104@jazillian.com> Message-ID: <47865BA5.10507@sun.com> It would be nice to have anyone be able to add notes or annotations to the API docs that aren't considered officially part of the spec, like example usage code or examples where it doesn't work as expected, non-obvious coding gotchas etc. This kind of wiki like data would need to be monitored or controlled in some way and connected to the official API docs??? Just brain storming... -kto Andy Tripp wrote: > >> Do most of you only use the API docs and are these the docs you think >> of? >> If so, maybe it isn't worth the effort to open source the rest of our >> documentation? > As you can probably tell, the API docs are far more important than the > other docs, > at least for the non-beginners who read this mailing list. The other > docs seem fine to > me. There are many other "guides" and the documentation for the tools is > pretty > straightforward. > > As others have pointed out, there is a huge issue around the API docs. How > can we all contribute useful clarifications, corrections, and additions > without going > through the whole JCP process? How do you maintain some reasonable control > to keep the quality up while keeping it very simple to make changes? In > short, > how do you let me quickly fix a typo in the API, but stop me from adding > the comment "this method sucks!" > > Seems like you'll have to decide whether to spend the rest of your life > tackling this API issue, > or not. I don't much care what the process is for the other docs. > > I've talked to Ray Gans about the API issue - he may have some ideas. > > Andy From robilad at kaffe.org Thu Jan 10 20:37:18 2008 From: robilad at kaffe.org (Dalibor Topic) Date: Thu, 10 Jan 2008 21:37:18 +0100 Subject: Feedback request: OpenJDK Community Innovator's Challenge Grants In-Reply-To: <17c6771e0801040137l146003a4x845740dd04464d7e@mail.gmail.com> References: <477D39CA.6030003@jazillian.com> <17c6771e0801040137l146003a4x845740dd04464d7e@mail.gmail.com> Message-ID: <478681FE.7070506@kaffe.org> Andrew John Hughes wrote: > >> - Who you think would make good objective judges for the program >> and why? > Inside Sun, someone like you and a Mark Reinhold/Danny Coward type > of person. Outside Sun, you just want to be sure to pick people > who want to advance OpenJDK itself, as opposed to pushing some > social agenda or some OpenJDK alternative. > > > > The Governance board springs to mind as an ideal candidate for > supplying the judges, especially given these suggestions (it already > has a 2 Sun, 3 external makeup IIRC). > I'd disagree, as the IGB's role is 'legislative', in my opinion, while this would be an 'executive' role. Separating the power over processes (IGB gets to approve groups) from the power over the 'purse' (judges get to approve projects that go ahead) would avoid any potential conflicts of interest. cheers, dalibor topic From David.Holmes at Sun.COM Fri Jan 11 00:16:21 2008 From: David.Holmes at Sun.COM (David Holmes - Sun Microsystems) Date: Fri, 11 Jan 2008 10:16:21 +1000 Subject: JDK documentation In-Reply-To: <18310.10423.306004.811650@zebedee.pink> References: <47856607.4040202@sun.com> <47856D34.40301@joda.org> <4785F945.1080604@sun.com> <4785FE61.2050904@sun.com> <18310.10423.306004.811650@zebedee.pink> Message-ID: <4786B555.7020800@sun.com> I don't want to start a meta-debate on these kinds of changes, but I feel the need to add a couple more comments :) Andrew Haley said the following on 11/01/08 12:16 AM: > Most of the changes I'd make to the javadocs are clarifications, not > changes in intent. To clarify, here's an example that bit me. I understand, but even clarifications are not necessarily straight-forward. The point is that someone, or a group of someones, will have to evaluate all javadoc changes to establish whether the change is truly a "clarification". At the moment all that can be easily fixed is true typos and html tagging. > ... So, > you can only tell that registerMBean() has this side-effect if you > read the whole page. I'm afraid (for better or worse) that this is a style of documentation used in many of the JDK libraries. Things that are common across methods are often documented once at the class level eg. "Unless otherwise stated all methods that take a collection object as an argument with throw NullPointerException if the argument is null." And things that are common across classes/types are often documented at the package level - see the java.util.concurrent package (and sub-package) docs. There are distinct advantages to writing things correctly once rather than repeating them all over and risk missing some cases, and risk omitting changes if there is a need for change. The requirement of this approach is that the user must read all of the relevant docs ie to understand a method you should first have read read the package docs, then the class docs, and then the method doc. Cheers, David Holmes From dalibor.topic at googlemail.com Fri Jan 11 01:38:08 2008 From: dalibor.topic at googlemail.com (Dalibor Topic) Date: Fri, 11 Jan 2008 02:38:08 +0100 Subject: Feedback request: OpenJDK Community Innovator's Challenge Grants In-Reply-To: References: Message-ID: <4786C880.3040704@kaffe.org> Ray Gans schrieb: > - Proposals will be accepted until March 3, 2008. At this time the > proposals will be judged by a team of people (we're thinking 2 from > Sun and 3 from outside Sun). We're also thinking of accepting only > seven or less proposals. I don't think the affiliation and number of the judges matters much, they just need to have the necessary technical background with OpenJDK to be able to evaluate the feasibility of proposals in the given time frame, and at this point in time, that's mostly going to be developers from Sun, anyway. > Scope and Constraints > - What kind of projects do you think would be valuable to the OpenJDK > community? * Making the windows build easier, for example by making it work on a plain Cygwin installation with gcc/g++. That would allow more developers using Windows to get past the initial barrier, and is a bit of a recurring topic on the build list. * Making openjdk cross-compileable. May involve using autotools for a skeleton overlay build system. * OpenJDK janitors (a la Kerneljanitors) to clean up findbugs/pmd/javac/ecj/* & easy bug database issues. * Eclipse project env to mirror the Netbeans one. Make the native code bits hackable in the IDEs, too. * openjdk gump instance / tinderbox/buildbot setup / other automated regression testing infrastructure * JSR 277 / JSR 291 bridge & teaching JRepo about other repository formats (Debian, Fedora, Maven, etc.) * Create an installable prototype of the modules project's work that doesn't require binary plugs to build / make the current code work on JDK6. * Projects proposed by existing groups > - How many proposals should be accepted? Since I'd expect those projects to (need to) work without much mentoring, and the results from google summer of code are usually mixed in terms of what ends up being merged in and maintained upstream, I'd say the more the merrier. (I say 'need to' as I expect that the Sun devs will be extremely busy with J1 preparations in the months before May, and will probably all disappear into a well deserved vacation afterwards.) cheers, dalibor topic From Eric.Armstrong at Sun.COM Fri Jan 11 01:53:25 2008 From: Eric.Armstrong at Sun.COM (Eric Armstrong) Date: Thu, 10 Jan 2008 17:53:25 -0800 Subject: JDK documentation In-Reply-To: <4786B555.7020800@sun.com> References: <47856607.4040202@sun.com> <47856D34.40301@joda.org> <4785F945.1080604@sun.com> <4785FE61.2050904@sun.com> <18310.10423.306004.811650@zebedee.pink> <4786B555.7020800@sun.com> Message-ID: <4786CC15.5010100@sun.com> Small addition here: The DITA document format was specifically designed in a way that lets you stay DRY (no repetition), while at the same time transcluding relevant bits everywhere they're needed. So it's "write once, view everywhere". Of course, the API comment mechanism doesn't very well lend itself to a structured XML document format like DITA, but it is an interesting thought experiment to imagine what such a thing /would/ look like. Some possibilities: * Conversion of API comments to DITA topics, using the topic types already defined at Apache--with an augmentation of comment contents to allow for DITA "conrefs" (the content-references that implement transclusion) * Specialized DITA topics (extensions) that transclude code, producing a separation that makes comments editable by many, while code is editable by only a few--along with an IDE plugin that creates a dynamic editing environment which makes them appear as a unified whole. * Further application of XML structures to the code, with an editor that gives you a fully-integrated outline view that you can collapse and expand at will. Such a system might help to solve a related problem: The fact that the comments are in the code makes them easily available and easily edited by coders (which probably explains why Java has the best API docs on the planet). But at the same time, the fact that they are divorced from standard documentation mechanisms makes them harder to linkcheck, spellcheck, do global substitutions, or apply any of the other publication tools and procedures that are ordinarily used for documents. David Holmes - Sun Microsystems wrote: > I don't want to start a meta-debate on these kinds of changes, but I > feel the need to add a couple more comments :) > > Andrew Haley said the following on 11/01/08 12:16 AM: >> Most of the changes I'd make to the javadocs are clarifications, not >> changes in intent. To clarify, here's an example that bit me. > > I understand, but even clarifications are not necessarily > straight-forward. The point is that someone, or a group of someones, > will have to evaluate all javadoc changes to establish whether the > change is truly a "clarification". At the moment all that can be easily > fixed is true typos and html tagging. > >> ... So, >> you can only tell that registerMBean() has this side-effect if you >> read the whole page. > > I'm afraid (for better or worse) that this is a style of documentation > used in many of the JDK libraries. Things that are common across methods > are often documented once at the class level eg. "Unless otherwise > stated all methods that take a collection object as an argument with > throw NullPointerException if the argument is null." And things that are > common across classes/types are often documented at the package level - > see the java.util.concurrent package (and sub-package) docs. > > There are distinct advantages to writing things correctly once rather > than repeating them all over and risk missing some cases, and risk > omitting changes if there is a need for change. The requirement of this > approach is that the user must read all of the relevant docs ie to > understand a method you should first have read read the package docs, > then the class docs, and then the method doc. > > > Cheers, > David Holmes -- Eric Armstrong, Document Systems Architect, Sun Microsystems http://blogs.sun.com/coolstuff http://www.artima.com/weblogs/index.jsp?blogger=cooltools From Eric.Armstrong at Sun.COM Fri Jan 11 02:21:47 2008 From: Eric.Armstrong at Sun.COM (Eric Armstrong) Date: Thu, 10 Jan 2008 18:21:47 -0800 Subject: JDK documentation In-Reply-To: <4786CC15.5010100@sun.com> References: <47856607.4040202@sun.com> <47856D34.40301@joda.org> <4785F945.1080604@sun.com> <4785FE61.2050904@sun.com> <18310.10423.306004.811650@zebedee.pink> <4786B555.7020800@sun.com> <4786CC15.5010100@sun.com> Message-ID: <4786D2BB.60908@sun.com> It was just pointed out to me that not everyone knows the acronyms I used: DRY -- Don't Repeat Yourself (reuse, reuse, reuse) DITA -- Darwin Information-Typing Architecture An open source XML format developed at IBM. It lets you create small modular bits of info that you glue together to make docs. The modular bits have "types" (hence, information-typing), and you can extend those types to create versions for special purposes (hence Darwinian). Significantly brilliant. Harder than HTML to edit, but you can slice and dice your content, tag it with metadata, produce HTML, PDF, Help, DocBook, and more. Eric Armstrong wrote: > Small addition here: > > The DITA document format was specifically designed in a > way that lets you stay DRY (no repetition), while at the > same time transcluding relevant bits everywhere they're > needed. So it's "write once, view everywhere". > > Of course, the API comment mechanism doesn't very well lend > itself to a structured XML document format like DITA, but > it is an interesting thought experiment to imagine what such > a thing /would/ look like. > > Some possibilities: > > * Conversion of API comments to DITA topics, using the > topic types already defined at Apache--with an augmentation > of comment contents to allow for DITA "conrefs" > (the content-references that implement transclusion) > > * Specialized DITA topics (extensions) that transclude code, > producing a separation that makes comments editable by > many, while code is editable by only a few--along with > an IDE plugin that creates a dynamic editing environment > which makes them appear as a unified whole. > > * Further application of XML structures to the code, with > an editor that gives you a fully-integrated outline view > that you can collapse and expand at will. > > Such a system might help to solve a related problem: > The fact that the comments are in the code makes them easily > available and easily edited by coders (which probably explains > why Java has the best API docs on the planet). But at the same > time, the fact that they are divorced from standard documentation > mechanisms makes them harder to linkcheck, spellcheck, do > global substitutions, or apply any of the other publication > tools and procedures that are ordinarily used for documents. > > David Holmes - Sun Microsystems wrote: >> I don't want to start a meta-debate on these kinds of changes, but I >> feel the need to add a couple more comments :) >> >> Andrew Haley said the following on 11/01/08 12:16 AM: >>> Most of the changes I'd make to the javadocs are clarifications, not >>> changes in intent. To clarify, here's an example that bit me. >> >> I understand, but even clarifications are not necessarily >> straight-forward. The point is that someone, or a group of someones, >> will have to evaluate all javadoc changes to establish whether the >> change is truly a "clarification". At the moment all that can be >> easily fixed is true typos and html tagging. >> >>> ... So, >>> you can only tell that registerMBean() has this side-effect if you >>> read the whole page. >> >> I'm afraid (for better or worse) that this is a style of documentation >> used in many of the JDK libraries. Things that are common across >> methods are often documented once at the class level eg. "Unless >> otherwise stated all methods that take a collection object as an >> argument with throw NullPointerException if the argument is null." And >> things that are common across classes/types are often documented at >> the package level - see the java.util.concurrent package (and >> sub-package) docs. >> >> There are distinct advantages to writing things correctly once rather >> than repeating them all over and risk missing some cases, and risk >> omitting changes if there is a need for change. The requirement of >> this approach is that the user must read all of the relevant docs ie >> to understand a method you should first have read read the package >> docs, then the class docs, and then the method doc. >> >> >> Cheers, >> David Holmes > > -- Eric Armstrong, Document Systems Architect, Sun Microsystems http://blogs.sun.com/coolstuff http://www.artima.com/weblogs/index.jsp?blogger=cooltools From Martin.Buchholz at Sun.COM Fri Jan 11 04:45:44 2008 From: Martin.Buchholz at Sun.COM (Martin Buchholz) Date: Thu, 10 Jan 2008 20:45:44 -0800 Subject: Feedback request: OpenJDK Community Innovator's Challenge Grants In-Reply-To: <477E986B.70001@jazillian.com> References: <477D39CA.6030003@jazillian.com> <17c6771e0801040137l146003a4x845740dd04464d7e@mail.gmail.com> <477E986B.70001@jazillian.com> Message-ID: <4786F478.3060606@sun.com> Andy Tripp wrote: > Which makes me think of another project idea: a project to clean up all > the cruft in the bug database. Last I checked, there > were over 25,000 bugs, and going through them at random seemed to > indicate that most are simple API documentation fixes and > clarifications, non-bugs, and other junk. I would bet that most of the > active bugs are not being worked and never will be. > I'd love to see some iron-fisted person go through and get it down to > around 5,000 "real" bugs. But then again, maybe I'm > the only one who's bothered by the volume. And I suppose this would > require too much work inside Sun also. I disagree that the simple documentation bugs aren't also real bugs. The bug database is a valuable resource to the project. It is true that certain areas of the bug database languish, but this is often because a maintainer has left or is not motivated to work on the bug database. But who knows? A future maintainer might actually enjoy bug-fixing (as I do). The best way to reduce the number of "trivial bugs" is to fix them. And the best way to encourage bug-fixing is making it easy (and fun!). Martin From andrew at operationaldynamics.com Fri Jan 11 07:15:06 2008 From: andrew at operationaldynamics.com (Andrew Cowie) Date: Fri, 11 Jan 2008 18:15:06 +1100 Subject: JDK documentation In-Reply-To: <4785FE61.2050904@sun.com> References: <47856607.4040202@sun.com> <47856D34.40301@joda.org> <4785F945.1080604@sun.com> <4785FE61.2050904@sun.com> Message-ID: <1200035706.18345.9.camel@moonglow.roaming.operationaldynamics.com> On Thu, 2008-01-10 at 21:15 +1000, David Holmes wrote: > But I disagree with what you say about the javadocs. While the javadoc > are part of the source files, they form the specification for the > platform API's ... So any "fixes" to the javadocs would not, > I believe, be acceptable through OpenJDK contributions, unless done as > part of a JSR. I think we need to have a serious look at figuring out a way to differentiate between documentation changes that along the way change the explanation of the behaviour [and thus, unfortunately, the Java spec (sic)] and documentation changes which just improve the documentation quality without materially changing the behaviour that is being described. > I know I've been frustrated over the years by the apparent inability to > get anything but the most trivial typos fixed in the docs, except during > major releases. It would be nice if that could change Indeed. Perhaps the "Just Get On With It" pattern might be allowed to apply here? ... If people submit patches that make the docs better that don't change the definition of the expected behaviour, perhaps those reviewing can ease off a bit and merely consider whether they are an improvement/clarification (and thus able to be accepted as is) or really are a library specification change (in which case, defer to JSR to your heart's content, and see ya circa Java 1.14 or so) AfC Sydney -- Andrew Frederick Cowie Managing Director Operational Dynamics Consulting, Pty Ltd We are an operations engineering consultancy focusing on strategy, organizational architecture, systems review, and change management procedures: enabling successful use of open source in mission critical enterprises, worldwide. http://www.operationaldynamics.com/ Sydney New York Toronto London -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From David.Holmes at Sun.COM Fri Jan 11 10:22:20 2008 From: David.Holmes at Sun.COM (David Holmes - Sun Microsystems) Date: Fri, 11 Jan 2008 20:22:20 +1000 Subject: JDK documentation In-Reply-To: <1200035706.18345.9.camel@moonglow.roaming.operationaldynamics.com> References: <47856607.4040202@sun.com> <47856D34.40301@joda.org> <4785F945.1080604@sun.com> <4785FE61.2050904@sun.com> <1200035706.18345.9.camel@moonglow.roaming.operationaldynamics.com> Message-ID: <4787435C.2050001@sun.com> Andrew, But as I said in my other posting it isn't always that simple. What is a clarification for you in one method might introduce an inconsistency into how something is covered across the class. Any javadoc changes - beyond blatant typos and html tagging - need to be carefully considered, for correctness, clarity and consistency with other documentation. Cheers, David Holmes Andrew Cowie said the following on 11/01/08 05:15 PM: > On Thu, 2008-01-10 at 21:15 +1000, David Holmes wrote: >> But I disagree with what you say about the javadocs. While the javadoc >> are part of the source files, they form the specification for the >> platform API's ... So any "fixes" to the javadocs would not, >> I believe, be acceptable through OpenJDK contributions, unless done as >> part of a JSR. > > I think we need to have a serious look at figuring out a way to > differentiate between documentation changes that along the way change > the explanation of the behaviour [and thus, unfortunately, the Java spec > (sic)] and documentation changes which just improve the documentation > quality without materially changing the behaviour that is being > described. > >> I know I've been frustrated over the years by the apparent inability to >> get anything but the most trivial typos fixed in the docs, except during >> major releases. It would be nice if that could change > > Indeed. > > Perhaps the "Just Get On With It" pattern might be allowed to apply > here? ... If people submit patches that make the docs better that don't > change the definition of the expected behaviour, perhaps those reviewing > can ease off a bit and merely consider whether they are an > improvement/clarification (and thus able to be accepted as is) or really > are a library specification change (in which case, defer to JSR to your > heart's content, and see ya circa Java 1.14 or so) > > AfC > Sydney > From mthornton at optrak.co.uk Fri Jan 11 10:39:16 2008 From: mthornton at optrak.co.uk (Mark Thornton) Date: Fri, 11 Jan 2008 10:39:16 +0000 Subject: JDK documentation In-Reply-To: <4787435C.2050001@sun.com> References: <47856607.4040202@sun.com> <47856D34.40301@joda.org> <4785F945.1080604@sun.com> <4785FE61.2050904@sun.com> <1200035706.18345.9.camel@moonglow.roaming.operationaldynamics.com> <4787435C.2050001@sun.com> Message-ID: <47874754.5080203@optrak.co.uk> David Holmes - Sun Microsystems wrote: > Andrew, > > But as I said in my other posting it isn't always that simple. What is > a clarification for you in one method might introduce an inconsistency > into how something is covered across the class. > > Any javadoc changes - beyond blatant typos and html tagging - need to > be carefully considered, for correctness, clarity and consistency with > other documentation. > > Cheers, > David Holmes Which is why a means of annotating JavaDoc would be so attractive. The annotations wouldn't be in the source code but stored in a separate database. The annotations (and/or their authors) might also be rated so we could ask for just the AAA rated annotations to appear in the margins or even none at all. On DRY, if you have a note on the meaning of a null pattern parameter at the top of a class, it would be helpful to have links from each relevant parameter to that note. Mark Thornton From aph at redhat.com Fri Jan 11 11:48:09 2008 From: aph at redhat.com (Andrew Haley) Date: Fri, 11 Jan 2008 11:48:09 +0000 Subject: JDK documentation In-Reply-To: <4786B555.7020800@sun.com> References: <47856607.4040202@sun.com> <47856D34.40301@joda.org> <4785F945.1080604@sun.com> <4785FE61.2050904@sun.com> <18310.10423.306004.811650@zebedee.pink> <4786B555.7020800@sun.com> Message-ID: <18311.22393.929065.45781@zebedee.pink> David Holmes - Sun Microsystems writes: > I don't want to start a meta-debate on these kinds of changes, but I > feel the need to add a couple more comments :) > > Andrew Haley said the following on 11/01/08 12:16 AM: > > Most of the changes I'd make to the javadocs are clarifications, not > > changes in intent. To clarify, here's an example that bit me. > > I understand, but even clarifications are not necessarily > straight-forward. The point is that someone, or a group of > someones, will have to evaluate all javadoc changes to establish > whether the change is truly a "clarification". Sure, but that's surely no different from any other change to the source code. Write a patch, submit, get it approved. > At the moment all that can be easily fixed is true typos and html > tagging. > > > ... So, you can only tell that registerMBean() has this > > side-effect if you read the whole page. > > I'm afraid (for better or worse) that this is a style of > documentation used in many of the JDK libraries. Things that are > common across methods are often documented once at the class level > eg. "Unless otherwise stated all methods that take a collection > object as an argument with throw NullPointerException if the > argument is null." And things that are common across classes/types > are often documented at the package level - see the > java.util.concurrent package (and sub-package) docs. > > There are distinct advantages to writing things correctly once > rather than repeating them all over and risk missing some cases, > and risk omitting changes if there is a need for change. The > requirement of this approach is that the user must read all of the > relevant docs ie to understand a method you should first have read > read the package docs, then the class docs, and then the method > doc. Of course, but that doesn't mean that in this case someone could not add an informative note along the lines of INFORMATIVE: This method has the side-effect of emitting a MBeanServerNotification Notification; see the XXXX para above. This note is clearly not normative so it doesn't change the spec, but it does make life much easier for the reader. How would it hurt? Getting such a change approved should not be difficult, given reasonable patch approval processes. It's surely not necessary to get committee approval for every such change. Andrew. -- Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK Registered in England and Wales No. 3798903 From Eamonn.McManus at Sun.COM Fri Jan 11 12:10:27 2008 From: Eamonn.McManus at Sun.COM (Eamonn McManus) Date: Fri, 11 Jan 2008 13:10:27 +0100 Subject: JDK documentation In-Reply-To: <18310.10423.306004.811650@zebedee.pink> References: <47856607.4040202@sun.com> <47856D34.40301@joda.org> <4785F945.1080604@sun.com> <4785FE61.2050904@sun.com> <18310.10423.306004.811650@zebedee.pink> Message-ID: <47875CB3.6030701@sun.com> Andrew, I realize that this doesn't address the more general problem being discussed here, but we can at least fix the JMX documentation in version 2.0 of the API, which is currently targeted for JDK 7. I've logged RFE 6649542 to track this. Regards, ?amonn McManus JMX Spec Lead http://weblogs.java.net/blog/emcmanus/ Andrew Haley wrote: > David Holmes - Sun Microsystems writes: > > > Thanks for clarifying that it was the guides you meant - I totally > > agree they should be opened up and expanded/improved by the > > community. > > > > But I disagree with what you say about the javadocs. While the > > javadoc are part of the source files, they form the specification > > for the platform API's and as far as I am aware the specification > > for the Java platform is not open-sourced. So any "fixes" to the > > javadocs would not, I believe, be acceptable through OpenJDK > > contributions, unless done as part of a JSR. Hopefully Mark, or > > someone else in the know, could clarify this. > > > > I know I've been frustrated over the years by the apparent > > inability to get anything but the most trivial typos fixed in the > > docs, except during major releases. It would be nice if that could > > change but I'm not aware that it has at this stage. > > Most of the changes I'd make to the javadocs are clarifications, not > changes in intent. To clarify, here's an example that bit me. > > The javadoc for javax.management.MBeanServer.registerMBean() says, in > full, "Registers a pre-existing object as an MBean with the MBean > server. If the object name given is null, the MBean must provide its > own name by implementing the MBeanRegistration interface and returning > the name from the preRegister method." The overview at the top of the > page also says "When an MBean is registered or unregistered in the > MBean server a MBeanServerNotification Notification is emitted." So, > you can only tell that registerMBean() has this side-effect if you > read the whole page. > > I would change that method's decription to something like "Registers a > pre-existing object as an MBean with the MBean server, emitting a > MBeanServerNotification Notification. If the object name given is > null, ...." > > This is not a specification change, but makes it easier to understand > the javadoc. > > Andrew. > > From openjdk at jazillian.com Fri Jan 11 17:57:24 2008 From: openjdk at jazillian.com (Andy Tripp) Date: Fri, 11 Jan 2008 12:57:24 -0500 Subject: Feedback request: OpenJDK Community Innovator's Challenge Grants In-Reply-To: <4786F478.3060606@sun.com> References: <477D39CA.6030003@jazillian.com> <17c6771e0801040137l146003a4x845740dd04464d7e@mail.gmail.com> <477E986B.70001@jazillian.com> <4786F478.3060606@sun.com> Message-ID: <4787AE04.9070303@jazillian.com> Martin Buchholz wrote: > Andy Tripp wrote: > >> Which makes me think of another project idea: a project to clean up all >> the cruft in the bug database. Last I checked, there >> were over 25,000 bugs, and going through them at random seemed to >> indicate that most are simple API documentation fixes and >> clarifications, non-bugs, and other junk. I would bet that most of the >> active bugs are not being worked and never will be. >> I'd love to see some iron-fisted person go through and get it down to >> around 5,000 "real" bugs. But then again, maybe I'm >> the only one who's bothered by the volume. And I suppose this would >> require too much work inside Sun also. >> > > I disagree that the simple documentation bugs aren't also real bugs. > The bug database is a valuable resource to the project. > It is true that certain areas of the bug database languish, > but this is often because a maintainer has left or is not > motivated to work on the bug database. But who knows? > A future maintainer might actually enjoy bug-fixing (as I do). > The best way to reduce the number of "trivial bugs" is to fix them. > And the best way to encourage bug-fixing is making it easy (and fun!). > > Martin > Yes, I agree. I meant that someone should get the number of existing bugs way down by actually fixing them - blasting through and quickly fixing all the easy documentation problems. I would love to see if I could fix a few thousand trivial bugs very quickly all by myself. The problem is, that just isn't possible with the current overhead. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Tom.Marble at Sun.COM Fri Jan 11 20:02:16 2008 From: Tom.Marble at Sun.COM (Tom Marble) Date: Fri, 11 Jan 2008 14:02:16 -0600 Subject: Feedback request: OpenJDK Community Innovator's Challenge Grants In-Reply-To: References: Message-ID: <4787CB48.6020308@sun.com> Ray Gans wrote: > - Proposals will be accepted until March 3, 2008. At this time the > proposals will be judged by a team of people (we're thinking 2 from Sun > and 3 from outside Sun). Here's a challenge that I see... we want "qualified" judges: developers that are familiar with the OpenJDK code base. However if we find three judges from the community we may have just eliminated 3 great potential applicants. What if we chose all 5 judges from Sun employees -- who are not qualified to apply anyway? Regards, --Tom From fabien.duminy at webmails.com Fri Jan 11 21:22:37 2008 From: fabien.duminy at webmails.com (Fabien DUMINY) Date: Fri, 11 Jan 2008 22:22:37 +0100 Subject: Feedback request: OpenJDK Community Innovator's Challenge Grants In-Reply-To: <4787CB48.6020308@sun.com> References: <4787CB48.6020308@sun.com> Message-ID: <4787DE1D.9030007@webmails.com> Tom Marble a ?crit : > Ray Gans wrote: > >> - Proposals will be accepted until March 3, 2008. At this time the >> proposals will be judged by a team of people (we're thinking 2 from Sun >> and 3 from outside Sun). >> > > Here's a challenge that I see... we want "qualified" judges: developers > that are familiar with the OpenJDK code base. However if we find > three judges from the community we may have just eliminated 3 great > potential applicants. > > What if we chose all 5 judges from Sun employees -- who are not > qualified to apply anyway? > > Regards, > > --Tom > What do you think about that ? - first step : we let people wanting to be judge propose their candidacy - second step : after some delay, if there is more than 5 candidates, the community will vote for them. of course, we could impose more contraints like : - there must some judges from sun - the candidates must know well the code base, as tom said but I am not sure how we can deal with these points. Regards, Fabien. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnu_andrew at member.fsf.org Fri Jan 11 22:03:20 2008 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Fri, 11 Jan 2008 22:03:20 +0000 Subject: Feedback request: OpenJDK Community Innovator's Challenge Grants In-Reply-To: <4787CB48.6020308@sun.com> References: <4787CB48.6020308@sun.com> Message-ID: <17c6771e0801111403n17c46b85g59f0685d1ba5416b@mail.gmail.com> On 11/01/2008, Tom Marble wrote: > Ray Gans wrote: > > - Proposals will be accepted until March 3, 2008. At this time the > > proposals will be judged by a team of people (we're thinking 2 from Sun > > and 3 from outside Sun). > > Here's a challenge that I see... we want "qualified" judges: developers > that are familiar with the OpenJDK code base. However if we find > three judges from the community we may have just eliminated 3 great > potential applicants. > > What if we chose all 5 judges from Sun employees -- who are not > qualified to apply anyway? > > Regards, > > --Tom > > FWIW, choosing 5 Sun employees who know the OpenJDK code base inside out would make the most sense to me. As Tom says, they are ineligible anyway and I feel only Sun employees would have the experience necessary. Ideally, they could represent a wide spectrum of the different groups (one GUI/graphics related, one networking, one quality, etc.) Are there any plans for Sun employees to act as mentors? -- Andrew :-) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net From David.Holmes at Sun.COM Sat Jan 12 00:06:57 2008 From: David.Holmes at Sun.COM (David Holmes - Sun Microsystems) Date: Sat, 12 Jan 2008 10:06:57 +1000 Subject: JDK documentation In-Reply-To: <18311.22393.929065.45781@zebedee.pink> References: <47856607.4040202@sun.com> <47856D34.40301@joda.org> <4785F945.1080604@sun.com> <4785FE61.2050904@sun.com> <18310.10423.306004.811650@zebedee.pink> <4786B555.7020800@sun.com> <18311.22393.929065.45781@zebedee.pink> Message-ID: <478804A1.2060102@sun.com> Andrew, Andrew Haley said the following on 11/01/08 09:48 PM: > David Holmes - Sun Microsystems writes: > > I understand, but even clarifications are not necessarily > > straight-forward. The point is that someone, or a group of > > someones, will have to evaluate all javadoc changes to establish > > whether the change is truly a "clarification". > > Sure, but that's surely no different from any other change to the > source code. Write a patch, submit, get it approved. But the difference is who has to do the approving. For code changes, it's peer review, for spec (aka doc) changes its a different set of "peers". Cheers, David Holmes From Tom.Marble at Sun.COM Mon Jan 14 03:38:51 2008 From: Tom.Marble at Sun.COM (Tom Marble) Date: Sun, 13 Jan 2008 21:38:51 -0600 Subject: Feedback request: OpenJDK Community Innovator's Challenge Grants In-Reply-To: <4787DE1D.9030007@webmails.com> References: <4787CB48.6020308@sun.com> <4787DE1D.9030007@webmails.com> Message-ID: <478AD94B.4060209@sun.com> Fabien DUMINY wrote: > Tom Marble a ?crit : >> What if we chose all 5 judges from Sun employees -- who are not >> qualified to apply anyway? >> > What do you think about that ? > - first step : we let people wanting to be judge propose their candidacy > - second step : after some delay, if there is more than 5 candidates, > the community will vote for them. > > of course, we could impose more contraints like : > - there must some judges from sun > - the candidates must know well the code base, as tom said > but I am not sure how we can deal with these points. My concern is that we have some fixed dates for the contest and that if we vote to have judges vote on the contest it will risk taking too long. However, in the event that my guess is incorrect, it would be worthwhile to take an informal poll. If any of you (non-Sun) OpenJDK developers would consider judging the Awards contest please let me know. Based on the number of responses in the next couple of days we should have a sense of how many external judge candidates there are. Thanks, --Tom From openjdk at jazillian.com Mon Jan 14 22:58:22 2008 From: openjdk at jazillian.com (Andy Tripp) Date: Mon, 14 Jan 2008 17:58:22 -0500 Subject: Feedback request: OpenJDK Community Innovator's Challenge Grants In-Reply-To: <4787CB48.6020308@sun.com> References: <4787CB48.6020308@sun.com> Message-ID: <478BE90E.6050405@jazillian.com> Tom Marble wrote: > Ray Gans wrote: > >> - Proposals will be accepted until March 3, 2008. At this time the >> proposals will be judged by a team of people (we're thinking 2 from Sun >> and 3 from outside Sun). >> > > Here's a challenge that I see... we want "qualified" judges: developers > that are familiar with the OpenJDK code base. However if we find > three judges from the community we may have just eliminated 3 great > potential applicants. > > What if we chose all 5 judges from Sun employees -- who are not > qualified to apply anyway? > I think that would make a lot of sense. My first reaction was "no, it should be more open", but then I realized that they're really just judging who should get some money from Sun. Also, I don't think all 5 need to be deeply involved with the code base. It might help to bring a bit of "business perspective" about what projects would really help OpenJDK, in addition to what's feasible. > Regards, > > --Tom > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Richard.Sands at Sun.COM Tue Jan 15 23:27:34 2008 From: Richard.Sands at Sun.COM (Rich Sands) Date: Tue, 15 Jan 2008 18:27:34 -0500 Subject: DRAFT Community Awards Rules In-Reply-To: <478D326C.7010800@sun.com> References: <20080115221914.F1B57278A19@eggemoggin.niobe.net> <478D326C.7010800@sun.com> Message-ID: <478D4166.5000609@sun.com> Here's a draft set of rules for the contest we've been discussing. Please read and comment. Deadline for doing anything with comments is probably this coming Sunday, Jan 20. We can't promise we'll incorporate all suggestions but we really appreciate and value your ideas. Thanks, -- rms --------------- [DRAFT -- FOR DISCUSSION ONLY] OPENJDK COMMUNITY INNOVATORS' CHALLENGE OFFICIAL RULES NO PURCHASE NECESSARY 1. DESCRIPTION OF THE CONTEST: The OpenJDK Community Innovator's Challenge ("Contest") is designed to encourage developers to collaborate and creatively solve key problems facing the OpenJDK Community, initiate new projects that innovate on the OpenJDK code base, leverage the code for new uses, develop curricula and training, and port the code to new platforms, all to further the objectives of the OpenJDK Community in developing and disseminating compatible, free software implementations of the Java SE platform based on the OpenJDK code base. The Contest is comprised of two stages. The first stage is the proposal stage in which entrants are invited to submit a proposed software programming idea. All eligible proposals submitted during this stage will be judged by a panel of experts in accordance with the criteria set forth in Rule 7 below. The judges will select between two and seven of the best proposals and the entrants who have submitted those proposals will be designated as Finalists and advance to the second stage of the Contest. During the second stage of the Contest, the selected Finalists will be asked to build and submit the project deliverables described in the proposal. Each Finalist who successfully completes building the project deliverables will receive a Prize as described in Rule 8. Rules and regulations of the Contest are provided herein. 2. ELIGIBILITY: This Contest is open only to individuals or groups of individuals all of whom are, at the time of entry, of the legal age of majority in their country, province or state of legal residence and residents of Australia, Belgium, Brazil, [We are looking into Brazil and Belgium for you.] Canada, Czech Republic, China, Denmark, France, Germany, India, Indonesia, Israel, Italy, Japan, Korea, Mexico, Netherlands [We are looking into the Netherlands for you], Poland, Russia, Spain, Sweden, Switzerland, Thailand, the United Kingdom, and the fifty United States and the District of Columbia. Void in Puerto Rico, Quebec and where prohibited by law. Employees of Sponsor and Sun Microsystems, Inc. ("Sun"), and each of its parent companies, affiliates and subsidiaries, participating advertising and promotion agencies (and members of their immediate family, defined as parents, children, siblings and spouse, regardless of where they reside, and/or those living in the same household) are not eligible. Sun Campus Ambassadors are eligible to participate. You must also have access to the Internet and a valid email address in order to enter. Entries may be submitted by a single individual or by a team of up to10 individuals. An individual may enter the contest no more than one time, whether as a single individual or as a member of a team. If an entry is submitted by a team, each individual member of the team must meet the eligibility requirements set forth above. The term "Entrant" as used in these Official Rules shall be deemed to refer to each eligible individual and/or team that submits an entry. ALL DEADLINES SET FORTH IN THESE OFFICIAL RULES ARE STATED IN PACIFIC STANDARD TIME. EACH ENTRANT IS RESPONSIBLE FOR DETERMINING THE CORRESPONDING TIME ZONE IN THE RESPECTIVE JURISDICTION. 3. HOW TO ENTER: To enter, Entrants must develop and submit an original idea that meets the goals set forth for the Contest. ( the "Proposal"). All Proposals must be submitted between January 23, 2008 at 12:00AM Pacific Standard Time ("PST") and March 2, 2008 at 11:59PM PST (the "Proposal Stage"), To submit a Proposal send a plain text document included in or attached to an email sent to the [EMAIL] alias within the OpenJDK community. The subject line of this email must have the words "FINAL PROPOSAL" in it. Please note that it is both acceptable and encouraged for draft proposals to be submitted to this alias for discussion and suggestions from the community, prior to submitting as a final Proposal. To be eligible, the Proposal must meet each of the following requirements: a. It must be an original idea that can be employed in the OpenJDK Community with the potential to leverage and extend the code base or Community infrastructure and features. b. It must be carried out in accordance with the Community's governance as set forth in the Charter ( http://openjdk.java.net/legal/charter/ ), and in the procedures for group ( http://openjdk.java.net/groups/ ) and project ( http://openjdk.java.net/projects/ ) initiation. c. It must not exceed a maximum of 3000 words. d. It may address or embody one or more of the following project types, or any other project that fulfills the aims of the Contest and meets the entry requirements: (i) Develops and implements new APIs, language features, tools, or implementation methodologies that extend the applicability or use of the Java SE platform into new markets, simplifies the development process and use of the platform, improves performance, scalability, security, or other implementation characteristics, or improves the end-user experience. These ideas need not be formally proposed as JSRs. (ii) Implements a compatible, free software alternative to a remaining bit of encumbered code or improves the quality or performance of the free software alternatives that have already been incorporated as part of the OpenJDK code base to clear encumbrances. (iii) Ports the OpenJDK code base to a new and interesting OS and/or hardware architecture. (iv) Establishes curricula, tools, and courseware that leverages the OpenJDK code base in teaching computer science, applied mathematics, or electrical engineering. e. It must specifically call out any dependence on Sun involvement/participation for success. For fairness, Entries may have only limited dependence on Sun involvement/participation and may not require a commitment by Sun for significant time/effort for success. Dependence on Sun includes required effort on the part of Sun engineering in order to deliver code, information, or assistance to an Entrant in order to successfully complete a Proposal. f. It must specifically describe what will constitute a complete implementation of the Proposal. This description will be used by the Judges to determine whether a particular Finalist Proposal is complete and meets the requirements to be awarded a Prize at the conclusion of the Contest. For example, a Proposal might state that completion will be determined by the Project containing code that implements all of the features specified in the Proposal ("feature complete" or alpha code quality). 4. ADDITIONAL PROPOSAL REQUIREMENTS: Each Proposal must also comply with all of the following requirements: a. The Proposal must be in English. Proposals in any other language will not be considered. b. Proposals that are lewd, obscene, sexually explicit, pornographic, disparaging, defamatory, libelous, obscene, or otherwise contain any inappropriate content or objectionable material may be disqualified at any time in the sole and unfettered discretion of the judges and/or the Sponsor. c. The Proposal must be the Entrant's original work, created solely by the Entrant, and must not infringe the copyright, trademark, privacy, publicity, or other intellectual rights of any person or entity. d. All code, if any must be contributed to Sun under the terms of the Sun Contributor Agreement (see http://www.sun.com/software/opensource/contributor_agreement.jsp ). e. All work on Proposals, including without limitation communications among team members, and any source code or information repositories associated with the Proposal must be accessible to all developers visiting the OpenJDK Project website, and must be done in the open. f. The Proposal must not contain any commercial content or logos of any entity other than Sponsor and Sun Microsystems, Inc. which may be incorporated only under the terms of any applicable licenses. 5. JUDGING OF PROPOSALS: At the conclusion of the Proposal Stage, a panel of expert judges (the "Judges") will select at least two and no more than seven Proposals as the "Finalists" based on the following equally weighted criteria: a. Qualifications and prior experience of Entrants, including project management expertise, demonstrated technical knowledge, and proven experience working on F/OSS projects. b. A documented project plan with specific measureable milestones in support of the identified completion criteria. c. Usefulness to developers and users of the Java SE platform. A Proposal should address a clear need that otherwise is going unsatisfied for developers of Java SE applications or libraries, or for end-users of the Java SE platform. d. Impact of the Proposal on achieving the top-level goals of the OpenJDK Community, including spreading Java SE to new markets, platforms, and uses, increasing the ease of development and participation for the OpenJDK Community, and demonstrating the innovation possible for the Java platform under a Free software license. The Finalists will be announced on or about March 17, 2008. The number of Finalists to be selected will be determined by the Judges in their sole and absolute discretion. In the event that no Proposals are submitted that meet the criteria as set forth in these Official Rules as determined by the Sponsor and/or the Judges in their sole discretion, Sponsor reserves the right to terminate the Contest and not to award any prizes. In the event that more than one Proposal is received with the same or nearly identical idea, only the first such Proposal received will be eligible, based on the date of the first draft submission of the Proposal to the Contest entry mailing list. Finalists will be notified by email, telephone or postal mail, within Sponsor's discretion. Decisions of Judges are final and binding. [AT THIS POINT. ALL FINALISTS ENTERING THE PROJECT STAGE SHOULD HAVE SIGNED WHAT THEY NEED TO SIGN INCLUDING AFFIDAVITS OF ELIGIBILITY, RELEASES, ETC.] 6. THE PROJECT STAGE: The Project Stage of the Contest will begin on March 18, 2008 at 12:00AM PST, and end on August 4, 2008 at 11:59PM PST (the "Project Stage). During the Project Stage the selected Finalists will be asked to and construct their Proposal (the "Project") according to the specification of completeness that is a part of the accepted Proposal. Completed Projects must be submitted no later than August 4, 2008 at 11:59 PM PST by submitting an email to the [EMAIL] alias of the OpenJDK Community with the words "FINAL PROJECT" in the subject line. This email must provide specific instructions for how to access code or other project materials from source code repositories or websites, constituting the entire Project implementation of a particular Finalist Proposal. Each Project must use only open source and free software tools and libraries with the exception of any non-free, encumbered binaries that are a part of the OpenJDK code base. Each Project must also comply with the requirements set forth herein applicable to the Proposal. Projects must be completed and fully operational, as determined within the sole discretion of the judges.. 7. WINNER SELECTION: All completed Projects submitted will be judged by the Judges in accordance with the following criteria: a. [50%] Degree to which the final Project implementation meets the completion specification of the Proposal. b. [30%] Technical merit of the Project implementation. c. [20%] Value of the completed Project deliverables to others in the OpenJDK Community to further the goals of OpenJDK. This includes documentation, transparency of development, and responsiveness to the comments, suggestions, and critiques of others in the community. The Projects will be ranked by the Judges based on the application of the judging criteria. The highest ranking Project will be deemed the First Prize Winner, the second highest ranking Project will be deemed the Second Prize Winner and so forth in descending order, up to a maximum of Seven Prize Winners. In the event of a tie the project with the higher technical merit will win. Winners will be notified of their prize ranking on or about August 18, 2008, by email, telephone or postal mail, within Sponsor's discretion. Winners will be announced on or about August 18, 2008. All decisions of judges are final and binding. 8. PRIZES: A total prize package of $175,000 will be awarded. The $175,000 prize package will be divided among all Winners in accordance with the chart set forth below. The exact amount of each prize will depend on the total number of eligible Projects submitted. For example, if three eligible Projects are submitted, the First Prize Winner will receive $75,000; the Second Prize Winner will receive $50,000 and the Third Prize Winner will receive $50,000. Each prize amount, depending on the number of eligible Projects is provided in the chart below: Prize Ranks ------------------------------------------------------------------------- #complete 1st 2nd 3rd 4th 5th 6th 7th 1 $175,000 2 $100,000 $75,000 3 $75,000 $50,000 $50,000 4 $75,000 $50,000 $25,000 $25,000 5 $75,000 $37,500 $37,500 $25,000 $25,000 6 $50,000 $25,000 $25,000 $25,000 $25,000 $25,000 7 $25,000 $25,000 $25,000 $25,000 $25,000 $25,000 $25,000 All other expenses not specified herein are the responsibility of the winners. All costs associated with currency exchange are the sole responsibility of the winners. ALL TAXES AND ANY APPLICABLE WITHHOLDING AND REPORTING REQUIREMENTS ARE THE SOLE RESPONSIBILITY OF THE WINNERS. In the event that a winning Project was submitted by a team, the Prize will be divided equally among all team members. The only prize for winning the Contest will be a cash award. Winning Proposals and Projects will not, as a consequence of being selected as Finalists or Prize Winners in the Contest, become a part of the Java SE Specification nor be integrated into the OpenJDK code base as an implementation component. New APIs must be submitted to the Java Community Process (JCP) as a JSR, and be accepted according to the JCP's rules in order to become a part of the Java SE Specification. Projects completed as a part of the Contest will be treated the same as any other code contributions to the OpenJDK Project, and subject to the governance processes that control acceptance and integration of code contributions. THE PROPOSAL, PROJECT AND ALL OTHER INFORMATION AND BIOGRAPHICAL MATERIAL SUBMITTED BY EACH ENTRANT AND/OR FINALIST ARE HEREINAFTER COLLECTIVELY REFERRED TO AS THE "ENTRY." 9. CONDITIONS OF PARTICIPATION: All federal, state, provincial and local laws and regulations apply. Submission of Entry into this Contest constitutes Entrant's agreement to be bound by the terms of these Official Rules and by the decisions of Sponsor, which are final and binding on all matters pertaining to this Contest. Return of any Finalist/Prize Winner notification may result in disqualification and selection of an alternate Finalist/Prize Winner. Any potential Finalist or Prize Winner who cannot be contacted within 15 days of first attempted notification will forfeit the prize. Potential prize winner may be required to sign and return an Affidavit of Eligibility/Liability & where legally permissible, a Publicity Release within 30 days following the date of first attempted notification. Failure to comply within this time period may result in disqualification and selection of an alternate Prize Winner. By submitting an Entry each Entrant hereby grants to the Sponsor and all users of OpenJDK Community a royalty-free, perpetual, irrevocable, worldwide, non-exclusive and fully sub-licensable right and license under Entrant's intellectual property rights to reproduce, modify, adapt, publish, translate, create derivative works from, distribute, perform, display and use the Entry (in whole or part, Proposal and/or Project) and to incorporate it in other works in any form, media, or technology now known or later developed, all subject to the obligation to retain any copyright notices included in the Entry. By submitting an Entry, Entrant hereby agrees to grant to Sponsor, and to any party who receives such Entry, a perpetual, non-exclusive, worldwide, no-charge, royalty-free, patent license to make, have made, use, sell, offer to sell, import and otherwise transfer the Entry,(in whole or in part, Proposal and/or Project) where such license applies only to those patent claims licensable by the Entrant that are covered by the Entry alone or by combination of the Entry with the work to which such Entries were submitted. No patent license is granted: (a) for any code that Sponsor has deleted from the Entry; or (b) for infringements caused by either: (i) third party modifications of the Entry, or (ii) the combination of the Entry with other software or other devices if such combination causes the infringement. Except as set forth above, Entrant retains all right, title and interest in and to the Entry and may use the Entry for his/her own purposes. The assignment and licenses granted above are effective on the date the Entry was submitted. These terms do not supersede any other assignment or grant of rights according to any other separate agreements between Entrants and other parties including the Sun Contributor Agreement (SCA). By submitting an Entry, Entrants agree that Sponsor shall have the right to use, copy, modify and make available the application or code in connection with the operation, conduct, administration, and advertising and promotion of the Contest via communication to the public, including, but not limited to the right to make screenshots, animations and video clips available to the public for promotional and publicity purposes. Acceptance of the prize constitutes permission for, and Prize Winner's consent to Sponsor, Sun and its agencies to use the Prize Winner's name, likeness and/or Entry, in whole or in part for advertising and promotional purposes without additional compensation, unless prohibited by law. To the extent permitted by law, entrants agree to hold Sponsor, Sun and each of its parent, subsidiaries, agents, directors, officers, employees, representatives, and assigns harmless from any injury or damage caused or claimed to be caused by participation in the Contest and/or use or acceptance of any prize won, except to the extent that any death or personal injury is caused by the negligence of the Sponsor. Sponsor and Sun are not responsible for any typographical or other error in the printing of the offer, administration of the Contest or in the announcement of the prize. An Entrant may be prohibited from participating in this Contest if, in the Sponsor's sole discretion, it reasonably believes that the Entrant has attempted to undermine the legitimate operation of this Contest by cheating, deception, or other unfair playing practices or annoys, abuses, threatens or harasses any other Entrants, the Sponsor or associated agencies. 10. NO RECOURSE TO JUDICIAL OR OTHER PROCEDURES: To the extent permitted by law, the rights to litigate, to seek injunctive relief or to make any other recourse to judicial or any other procedure in case of disputes or claims resulting from or in connection with this Contest are hereby excluded, and any Entrant expressly waives any and all such rights. In the event that a court of competent jurisdiction finds the foregoing waiver unenforceable, Entrants hereby consent to the jurisdiction and venue residing exclusively within the federal or state courts in the state of California, United States. Entrants agree that these Official Rules are governed by the laws of California. 11. DATA PRIVACY: Entrants agree that personal data, especially name and address, may be processed, stored and otherwise used for the purposes and within the context of the Contest and any other purposes outlined in these Official Rules. The data may also be used by the Sponsor in order to check Entrants' identity, their postal address and telephone number, or to otherwise verify their eligibility to participate in the Contest. Entrants have a right to access, review, rectify or cancel any personal data held by the Sponsor by writing to Sponsor (Attention: OpenJDK Community Innovator's Challenge Grants) at the address listed below. If Entrant's data is not provided or is canceled, Entrant's Entry will be ineligible. By participating in the Contest, Entrants hereby agree to all personal information uses and disclaimers as explained in Sponsor's Privacy Policy found at http://www.sun.com/privacy/ . Participation in the Contest further constitutes Entrant's full and unconditional agreement to and acceptance of these Official Rules and Sponsor's Privacy Policy and willingness to be contacted by telephone and/or email. If Entrant is a French resident, by entering the Contest such Entrant gives consent to the transfer of the personal data outside the European Union in connection with the above purposes, and that such data will be transferred to the United States. 12. WARRANTY AND INDEMNITY: Entrants certify that their Entry is original and that they are the sole and exclusive owner and right holder of the submitted Entry and that they have the right to submit the Entry in the Contest. Each Entrant agrees not to submit any Entry that (1) infringes any 3rd party proprietary, intellectual property, industrial property, personal rights or other rights, including without limitation, copyright, trademark, patent, trade secret or confidentiality obligation; (2) includes any personally identifiable information or (3) otherwise violates applicable law in any countries in the world. To the maximum extent permitted by law, each Entrant indemnifies and agrees to keep indemnified the Sponsor and Sun at all times from and against any liability, claims, demands, losses, damages, costs and expenses resulting from any act, default or omission of the Entrant and/or a breach of any warranty set forth herein. To the maximum extent permitted by law, each Entrant indemnifies and agrees to keep indemnified the Sponsor and Sun at all times from and against any liability, actions, claims, demands, losses, damages, costs and expenses for or in respect of which the Sponsor or Sun will or may become liable by reason of or related or incidental to any act, default or omission by an Entrant under these Official Rules including without limitation resulting from or in relation to any breach, non-observance, act or omission whether negligent or otherwise, pursuant to these official rules by an Entrant. 13. ELIMINATION: Any false information provided within the context of the Contest by any Entrant concerning identity, postal address, telephone number, ownership of right or noncompliance with these rules or the like may result in the immediate elimination of the Entrant from the Contest. Sponsor further reserves the right at any time, including after announcement of Finalists and/or Prize Winners to disqualify any Entry that it believes in its sole and unfettered discretion infringes upon or violates the rights of any third party or otherwise does not comply with these Official Rules. 14. INTERNET: Sponsor is not responsible for electronic transmission errors resulting in omission, interruption, deletion, defect, delay in operations or transmission. Sponsor is not responsible for theft or destruction or unauthorized access to or alterations of Entry materials, or for technical, network, telephone equipment, electronic, computer, hardware or software malfunctions or limitations of any kind. Sponsor is not responsible for inaccurate transmissions of or failure to receive Entry information by Sponsor on account of technical problems or traffic congestion on the Internet or at any Web site or any combination thereof, except to the extent that any death or personal injury is caused by the negligence of the Sponsor. If for any reason the Internet portion of the program is not capable of running as planned, including infection by computer virus, bugs, tampering, unauthorized intervention, fraud, technical failures, disruption or termination of the Contest site for any reason or any other causes which corrupt or affect the administration, security, fairness, integrity, or proper conduct of this Contest. Sponsor reserves the right at its sole discretion to immediately cancel, terminate, modify or suspend the Contest. Sponsor reserves the right to select winners from eligible entries received as of the termination date. Sponsor further reserves the right to disqualify any individual who tampers with the entry process. Caution: Any attempt by an Entrant to deliberately damage any Web site or undermine the legitimate operation of the Contest is a violation of criminal and civil laws and should such an attempt be made, Sponsor reserves the right to seek damages from any such Entrant to the fullest extent of the law. 15. SEVERABILITY: If any provision(s) of these Official Rules are held to be invalid or unenforceable, all remaining provisions hereof will remain in full force and effect. 16. WINNER'S LIST: For Winner's name, log onto http://openjdk.java.net on or about August 18, 2008, available for a period of up to 60 days. 17. SPONSOR: The Sponsor of this Contest is the OpenJDK Community, at http://openjdk.java.net . Sun Microsystems, Inc., however, is funding all of the prize awards. The official postal mail address of the contest sponsor is: OpenJDK Community Innovators' Challenge Grants c/o Ray Gans Sun Microsystems, Inc. 4220 Network Circle Santa Clara, CA 95054 [DRAFT -- FOR DISCUSSION ONLY] From gnu_andrew at member.fsf.org Wed Jan 16 00:29:37 2008 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Wed, 16 Jan 2008 00:29:37 +0000 Subject: DRAFT Community Awards Rules In-Reply-To: <478D4166.5000609@sun.com> References: <20080115221914.F1B57278A19@eggemoggin.niobe.net> <478D326C.7010800@sun.com> <478D4166.5000609@sun.com> Message-ID: <17c6771e0801151629w6e1d6163i27ad65e3fdbbae45@mail.gmail.com> On 15/01/2008, Rich Sands wrote: > Here's a draft set of rules for the contest we've been discussing. > Please read and comment. Deadline for doing anything with comments is > probably this coming Sunday, Jan 20. We can't promise we'll incorporate > all suggestions but we really appreciate and value your ideas. > > Thanks, > > -- rms > Thanks for all the hard work that's gone into this and for offering such an opportunity in the first place. Most of it seems fine, with a lot being boilerplate legalese that is required for this sort of thing. I've highlighted specific sections and made comments below. snip... > Sun Campus Ambassadors are eligible to participate. For my own sake, I hope this line is approved ;) snip... > > (i) Develops and implements new APIs, language features, > tools, or implementation methodologies that extend the > applicability or use of the Java SE platform into new > markets, simplifies the development process and use of the > platform, improves performance, scalability, security, or > other implementation characteristics, or improves the > end-user experience. These ideas need not be formally > proposed as JSRs. > Does this also include existing JSRs? If so, will some guidance be made available as to current JSRs applicable to the current OpenJDK code base? The biggest issue I see with implementing a current JSR however is access to the specification, which required accepting a license last time I tried. Proposed JSRs would be much more exciting and hopefully a great way of getting new blood into the JDK! :) > (ii) Implements a compatible, free software alternative to > a remaining bit of encumbered code or improves the quality > or performance of the free software alternatives that have > already been incorporated as part of the OpenJDK code base > to clear encumbrances. > Similar issue to the last; this would need some guidance as to what are the remaining encumbrances and the progress on them within Sun. snip... > e. It must specifically call out any dependence on Sun > involvement/participation for success. For fairness, > Entries may have only limited dependence on Sun > involvement/participation and may not require a commitment > by Sun for significant time/effort for success. Dependence > on Sun includes required effort on the part of Sun > engineering in order to deliver code, information, or > assistance to an Entrant in order to successfully complete > a Proposal. > For this to work in practice, it would help if the current state of the OpenJDK was made as clear as possible (e.g. encumbrances, current development work inside Sun, etc.) snip... > b. Proposals that are lewd, obscene, sexually explicit, > pornographic, disparaging, defamatory, libelous, obscene, > or otherwise contain any inappropriate content or > objectionable material may be disqualified at any time in > the sole and unfettered discretion of the judges and/or the > Sponsor. > I dread to think what a pornographic OpenJDK project proposal would look like... snip... > e. All work on Proposals, including without limitation > communications among team members, and any source code or > information repositories associated with the Proposal must > be accessible to all developers visiting the OpenJDK > Project website, and must be done in the open. > Couldn't agree more with this, especially with regards open development processes. Is it worth putting anything in about the license to be adopted for the code? You could simplistic assume it will be GPL+Classpath exception like the majority of the OpenJDK code base, but the above doesn't make this explicit. The source code could be accessible to developers of the OpenJDK community but under a restrictive license, as I read this. snip... > 6. THE PROJECT STAGE: > The Project Stage of the Contest will begin on March 18, 2008 at > 12:00AM PST, and end on August 4, 2008 at 11:59PM PST (the > "Project Stage). During the Project Stage the selected Finalists > will be asked to and construct their Proposal (the > "Project") according to the specification of completeness > that is a part of the accepted Proposal. Completed Projects must be > submitted no later than August 4, 2008 at 11:59 PM PST by submitting > an email to the [EMAIL] alias of the OpenJDK Community with the words > "FINAL PROJECT" in the subject line. This email must > provide specific instructions for how to access code or other project > materials from source code repositories or websites, constituting the > entire Project implementation of a particular Finalist Proposal. Each > Project must use only open source and free software tools and > libraries with the exception of any non-free, encumbered binaries that > are a part of the OpenJDK code base. Each Project must also comply > with the requirements set forth herein applicable to the Proposal. > Projects must be completed and fully operational, as determined within > the sole discretion of the judges.. > This seems very 'hands off', but then the prize is only awarded at the end :) Google's Summer of Code is much more heavy handed but then they award money throughout the process. Is there any possibility of projects having a mentor, an explicit contact point within the OpenJDK community? This might reduce the chance of projects just getting lost. The same comments with respect to licensing apply here I guess. snip... Thanks, -- Andrew :-) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net From David.Herron at Sun.COM Wed Jan 16 00:53:51 2008 From: David.Herron at Sun.COM (David Herron) Date: Tue, 15 Jan 2008 16:53:51 -0800 Subject: DRAFT Community Awards Rules In-Reply-To: <17c6771e0801151629w6e1d6163i27ad65e3fdbbae45@mail.gmail.com> References: <20080115221914.F1B57278A19@eggemoggin.niobe.net> <478D326C.7010800@sun.com> <478D4166.5000609@sun.com> <17c6771e0801151629w6e1d6163i27ad65e3fdbbae45@mail.gmail.com> Message-ID: <478D559F.9080303@sun.com> Andrew John Hughes wrote: >> b. Proposals that are lewd, obscene, sexually explicit, >> pornographic, disparaging, defamatory, libelous, obscene, >> or otherwise contain any inappropriate content or >> objectionable material may be disqualified at any time in >> the sole and unfettered discretion of the judges and/or the >> Sponsor. >> > > I dread to think what a pornographic OpenJDK project proposal would look like... > > snip... > Well, you start with duke.dev.java.net and use your imagination from there... - David -------------- next part -------------- An HTML attachment was scrubbed... URL: From openjdk at jazillian.com Wed Jan 16 16:49:49 2008 From: openjdk at jazillian.com (Andy Tripp) Date: Wed, 16 Jan 2008 11:49:49 -0500 Subject: DRAFT Community Awards Rules In-Reply-To: <478D4166.5000609@sun.com> References: <20080115221914.F1B57278A19@eggemoggin.niobe.net> <478D326C.7010800@sun.com> <478D4166.5000609@sun.com> Message-ID: <478E35AD.4060803@jazillian.com> > > of up to10 individuals. An individual may enter the contest no more > than one time, whether as a single individual or as a member of a > team. Why limit people/groups to just one proposal? > > Entries may have only limited dependence on Sun > involvement/participation and may not require a commitment I'd change both "may"s to "must". > > > e. All work on Proposals, including without limitation > communications among team members, and any source code or > information repositories associated with the Proposal must > be accessible to all developers visiting the OpenJDK > Project website, and must be done in the open. I think it's a bit harsh to require all communication among team members to be in the open. It's fine to require all code and email, but it's not reasonable to require verbal communication be documented. > a. Qualifications and prior experience of Entrants, including > project management expertise, demonstrated technical > knowledge, and proven experience working on F/OSS projects. I would change "F/OSS projects" to "Java projects" or something vague like "relevent software projects". No need to exclude those who haven't been working on F/OSS projects. > > > In the event that more than one Proposal is > received with the same or nearly identical idea, only the first such > Proposal received will be eligible, based on the date of the first > draft submission of the Proposal to the Contest entry mailing list. > I would change this to "...all such Proposals will be considered, and only one will be chosen, based on the criteria in section 5." On the issue of the dollar amounts, I'm worried that someone might put together a proposal with the idea that "If I can get $75000 or more this will be worth my time", only to find that 7 good proposals have been submitted, and so he may then withdraw the proposal. No way around that problem, I guess. I also wonder if the Judges would naturally take into consideration which projects may get done anyway, even without the reward. The judges might naturally say "well, that project is already started and clearly going to be done anyway...". So, in all fairness, using that criteria should be explicitly allowed or disallowed here. Andy From Kelly.Ohair at Sun.COM Wed Jan 16 17:15:54 2008 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Wed, 16 Jan 2008 09:15:54 -0800 Subject: Vote results: Build Group sponsorship of the JDK 6 project PASSES (3:0) Message-ID: <478E3BCA.8000803@sun.com> The proposal for the Build Group to sponsor the creation of the JDK 6 project [1] succeeds with 3 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 [1] is: http://mail.openjdk.java.net/pipermail/announce/2007-December/000051.html -kto From mr at sun.com Wed Jan 16 23:47:10 2008 From: mr at sun.com (Mark Reinhold) Date: Wed, 16 Jan 2008 15:47:10 -0800 Subject: Vote results: Build Group sponsorship of the JDK 6 project PASSES (3:0) In-Reply-To: kelly.ohair@sun.com; Wed, 16 Jan 2008 09:15:54 PST; <478E3BCA.8000803@sun.com> Message-ID: <20080116234710.F18DE278A19@eggemoggin.niobe.net> Kelly: Thanks for running this vote, but unfortunately it was taken after the 14-day limit defined in the interim governance rules. I've asked the IGB to recognize it anyway [1]. - Mark [1] http://mail.openjdk.java.net/pipermail/gb-discuss/2008-January/000039.html From robilad at kaffe.org Thu Jan 17 01:40:28 2008 From: robilad at kaffe.org (Dalibor Topic) Date: Thu, 17 Jan 2008 02:40:28 +0100 Subject: DRAFT Community Awards Rules In-Reply-To: <478E35AD.4060803@jazillian.com> References: <20080115221914.F1B57278A19@eggemoggin.niobe.net> <478D326C.7010800@sun.com> <478D4166.5000609@sun.com> <478E35AD.4060803@jazillian.com> Message-ID: <478EB20C.6090209@kaffe.org> Andy Tripp wrote: > >> >> of up to10 individuals. An individual may enter the contest no more >> than one time, whether as a single individual or as a member of a >> team. > Why limit people/groups to just one proposal? Presumably to have fewer, but more seriously thought out proposals, than a 'lottery' type of situation where submitting more proposals is better. >> e. All work on Proposals, including without limitation >> communications among team members, and any source code or >> information repositories associated with the Proposal must >> be accessible to all developers visiting the OpenJDK >> Project website, and must be done in the open. > I think it's a bit harsh to require all communication among team members to > be in the open. It's fine to require all code and email, but it's not > reasonable > to require verbal communication be documented. blogs, meeting minutes & IRC logs could work for that, I guess. cheers, dalibor topic From openjdk at jazillian.com Thu Jan 17 15:28:40 2008 From: openjdk at jazillian.com (Andy Tripp) Date: Thu, 17 Jan 2008 10:28:40 -0500 Subject: DRAFT Community Awards Rules In-Reply-To: <478EB20C.6090209@kaffe.org> References: <20080115221914.F1B57278A19@eggemoggin.niobe.net> <478D326C.7010800@sun.com> <478D4166.5000609@sun.com> <478E35AD.4060803@jazillian.com> <478EB20C.6090209@kaffe.org> Message-ID: <478F7428.3080807@jazillian.com> Dalibor Topic wrote: > Andy Tripp wrote: >> >>> >>> of up to10 individuals. An individual may enter the contest no more >>> than one time, whether as a single individual or as a member of a >>> team. >> Why limit people/groups to just one proposal? > > Presumably to have fewer, but more seriously thought out proposals, > than a 'lottery' type of situation where submitting more proposals is > better. I'm worried that, say, IBM could only submit one proposal, when they have two distinct groups ready to work two distinct projects. > >>> e. All work on Proposals, including without limitation >>> communications among team members, and any source code or >>> information repositories associated with the Proposal must >>> be accessible to all developers visiting the OpenJDK >>> Project website, and must be done in the open. >> I think it's a bit harsh to require all communication among team >> members to >> be in the open. It's fine to require all code and email, but it's not >> reasonable >> to require verbal communication be documented. > > blogs, meeting minutes & IRC logs could work for that, I guess. I'm picturing whiteboard discussions, phone calls, pair programing, etc. Also, I now notice that it doesn't say communication "relating to the proposal". So I'd reword "communications" to "written communications pertaining to the Proposal" > > > cheers, > dalibor topic > From dalibor.topic at googlemail.com Thu Jan 17 22:27:48 2008 From: dalibor.topic at googlemail.com (Dalibor Topic) Date: Thu, 17 Jan 2008 23:27:48 +0100 Subject: Call for vote [Fwd: Project Proposal: Haiku port of OpenJDK] In-Reply-To: <477E4A4D.1060301@kaffe.org> References: <477E4A4D.1060301@kaffe.org> Message-ID: <985bee770801171427k314161d9v35e843052d1797cb@mail.gmail.com> On Jan 4, 2008 4:01 PM, Dalibor Topic wrote: > Dear members of the porters group, > > it is my pleasure to call you to vote in my role as the group's > moderator. The issue being voted on is > > * Should the porters group sponsor the project to port OpenJDK > to the Haiku OS? > > Please vote with yes or no. The voting period is two weeks. The vote has passed. The members of the porters group have cast 4 votes for sponsoring the project, with no votes against it. The porters group therefore has decided to sponsor the project. I'd like to thank all the members of the group for their votes, and everyone for their contributions in the discussion of the proposal, and I'd like to congratulate the Haiku OS OpenJDK porters team, and welcome them into OpenJDK family of projects. cheers, dalibor topic From gnu_andrew at member.fsf.org Thu Jan 17 23:04:23 2008 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Thu, 17 Jan 2008 23:04:23 +0000 Subject: DRAFT Community Awards Rules In-Reply-To: <478F7428.3080807@jazillian.com> References: <20080115221914.F1B57278A19@eggemoggin.niobe.net> <478D326C.7010800@sun.com> <478D4166.5000609@sun.com> <478E35AD.4060803@jazillian.com> <478EB20C.6090209@kaffe.org> <478F7428.3080807@jazillian.com> Message-ID: <17c6771e0801171504u75d8c3a4u4d60a73a5977956b@mail.gmail.com> On 17/01/2008, Andy Tripp wrote: > Dalibor Topic wrote: > > Andy Tripp wrote: > >> > >>> > >>> of up to10 individuals. An individual may enter the contest no more > >>> than one time, whether as a single individual or as a member of a > >>> team. > >> Why limit people/groups to just one proposal? > > > > Presumably to have fewer, but more seriously thought out proposals, > > than a 'lottery' type of situation where submitting more proposals is > > better. > I'm worried that, say, IBM could only submit one proposal, when they > have two distinct groups ready to work two distinct projects. My understanding was they would enter as a team of individuals, and thus didn't see such an issue. Maybe this issue could be clarified further. > > > > -- Andrew :-) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net From bryan at varnernet.com Thu Jan 17 23:37:11 2008 From: bryan at varnernet.com (Bryan Varner) Date: Thu, 17 Jan 2008 18:37:11 -0500 Subject: Call for vote [Fwd: Project Proposal: Haiku port of OpenJDK] In-Reply-To: <985bee770801171427k314161d9v35e843052d1797cb@mail.gmail.com> References: <477E4A4D.1060301@kaffe.org> <985bee770801171427k314161d9v35e843052d1797cb@mail.gmail.com> Message-ID: <478FE6A7.4060704@varnernet.com> > I'd like to thank all the members of the group for their votes, and > everyone for their contributions in the discussion of the proposal, and > I'd like to congratulate the Haiku OS OpenJDK porters team, and > welcome them into OpenJDK family of projects. As would I. Thanks for the support, everyone. We'll try to make you proud. ;-) -Bryan From David.Herron at Sun.COM Fri Jan 18 00:21:56 2008 From: David.Herron at Sun.COM (David Herron) Date: Thu, 17 Jan 2008 16:21:56 -0800 Subject: [Fwd: DLJ bundles for 5.0u14 and 6u4 have been posted on jdk-distros.dev.java.net] Message-ID: <478FF124.5090700@sun.com> FYI -------------- next part -------------- An embedded message was scrubbed... From: David Herron Subject: DLJ bundles for 5.0u14 and 6u4 have been posted on jdk-distros.dev.java.net Date: Thu, 17 Jan 2008 16:19:17 -0800 Size: 5130 URL: From Onno.Kluyt at Sun.COM Wed Jan 23 14:44:46 2008 From: Onno.Kluyt at Sun.COM (Onno Kluyt) Date: Wed, 23 Jan 2008 06:44:46 -0800 Subject: New Project approved: JDK 6 In-Reply-To: <20080123052724.8CDD574FA@callebaut.niobe.net> References: <20080123052724.8CDD574FA@callebaut.niobe.net> Message-ID: Happiness! On Jan 22, 2008, at 9:27 PM, Mark Reinhold wrote: > Per the interim governance guidelines for Projects [1] I'm pleased to > announce the creation of the JDK 6 Project [2,3] following the Build > Group's decision [4] to sponsor it. > > - Mark > > > [1] http://openjdk.java.net/projects > [2] http://mail.openjdk.java.net/pipermail/announce/2007-December/ > 000051.html > [3] http://openjdk.java.net/projects/jdk6 > [4] http://mail.openjdk.java.net/pipermail/build-dev/2008-January/ > 000696.html From aph at redhat.com Wed Jan 23 14:53:02 2008 From: aph at redhat.com (Andrew Haley) Date: Wed, 23 Jan 2008 14:53:02 +0000 Subject: New Project approved: JDK 6 In-Reply-To: <20080123052724.8CDD574FA@callebaut.niobe.net> References: <20080123052724.8CDD574FA@callebaut.niobe.net> Message-ID: <479754CE.1090509@redhat.com> Mark Reinhold wrote: > Per the interim governance guidelines for Projects [1] I'm pleased to > announce the creation of the JDK 6 Project [2,3] following the Build > Group's decision [4] to sponsor it. How very splendid! Good news, indeed. Andrew. From robilad at kaffe.org Thu Jan 24 14:59:03 2008 From: robilad at kaffe.org (Dalibor Topic) Date: Thu, 24 Jan 2008 15:59:03 +0100 Subject: New Project approved: JDK 6 In-Reply-To: <479754CE.1090509@redhat.com> References: <20080123052724.8CDD574FA@callebaut.niobe.net> <479754CE.1090509@redhat.com> Message-ID: <4798A7B7.8050106@kaffe.org> Andrew Haley wrote: > Mark Reinhold wrote: >> Per the interim governance guidelines for Projects [1] I'm pleased to >> announce the creation of the JDK 6 Project [2,3] following the Build >> Group's decision [4] to sponsor it. > > How very splendid! Good news, indeed. Yep, looking forward to see it developed out in the open. Joe, could you add a URL for the mercurial repository on the project's web page? cheers, dalibor topic From Joe.Darcy at Sun.COM Fri Jan 25 07:31:35 2008 From: Joe.Darcy at Sun.COM (Joseph D. Darcy) Date: Thu, 24 Jan 2008 23:31:35 -0800 Subject: New Project approved: JDK 6 In-Reply-To: <4798A7B7.8050106@kaffe.org> References: <20080123052724.8CDD574FA@callebaut.niobe.net> <479754CE.1090509@redhat.com> <4798A7B7.8050106@kaffe.org> Message-ID: <47999057.1080602@sun.com> Dalibor Topic wrote: > Andrew Haley wrote: >> Mark Reinhold wrote: >>> Per the interim governance guidelines for Projects [1] I'm pleased to >>> announce the creation of the JDK 6 Project [2,3] following the Build >>> Group's decision [4] to sponsor it. >> >> How very splendid! Good news, indeed. > Yep, looking forward to see it developed out in the open. > > Joe, could you add a URL for the mercurial repository on the project's > web page? Hi Dalibor. I've sent out an email to the OpenJDK 6 dev list [1]. In summary, we won't have Mercurial repositories immediately; I'm working on the remaining Sun-internal processes to get the code out. I'll add a link to the source bundles and Mercurial repositories once they are available. -Joe [1] http://mail.openjdk.java.net/pipermail/jdk6-dev/2008-January/000000.html From robilad at kaffe.org Fri Jan 25 12:15:03 2008 From: robilad at kaffe.org (Dalibor Topic) Date: Fri, 25 Jan 2008 13:15:03 +0100 Subject: New Project approved: JDK 6 In-Reply-To: <47999057.1080602@sun.com> References: <20080123052724.8CDD574FA@callebaut.niobe.net> <479754CE.1090509@redhat.com> <4798A7B7.8050106@kaffe.org> <47999057.1080602@sun.com> Message-ID: <4799D2C7.9000605@kaffe.org> Joseph D. Darcy wrote: > Dalibor Topic wrote: >> Andrew Haley wrote: >>> Mark Reinhold wrote: >>>> Per the interim governance guidelines for Projects [1] I'm pleased to >>>> announce the creation of the JDK 6 Project [2,3] following the Build >>>> Group's decision [4] to sponsor it. >>> >>> How very splendid! Good news, indeed. >> Yep, looking forward to see it developed out in the open. >> >> Joe, could you add a URL for the mercurial repository on the >> project's web page? > > Hi Dalibor. > > I've sent out an email to the OpenJDK 6 dev list [1]. In summary, we > won't have Mercurial repositories immediately; I'm working on the > remaining Sun-internal processes to get the code out. I'll add a link > to the source bundles and Mercurial repositories once they are available. Thanks, Joe, I'm looking forward to the code. cheers, dalibor topic From mr at sun.com Fri Jan 25 13:42:50 2008 From: mr at sun.com (Mark Reinhold) Date: Fri, 25 Jan 2008 05:42:50 -0800 Subject: Mercurial update Message-ID: <20080125134250.7668674FA@callebaut.niobe.net> In December we officially switched from TeamWare, the old Sun-internal source-code management system, to Mercurial. No changesets have yet been pushed into the JDK 7 repositories because the last few remaining bits of infrastructure are not yet complete. These include a small Mercurial extension to check changeset comments, legal notices, and repository invariants, and also the core community database, which tracks Members, Groups, Projects, repositories, and the relationships between all these things. (The extension will, naturally, be published under the GPL for use outside of Sun.) Those remaining bits should be done in the next week or two, at which point the changesets can start flowing. For some additional perspective please see John Rose's message to build-dev earlier this morning [1]. In retrospect it was, perhaps, premature to do the cutover in December, without every last bit of the infrastructure up and running, but we are where we are. - Mark [1] http://mail.openjdk.java.net/pipermail/build-dev/2008-January/000720.html From gnu_andrew at member.fsf.org Fri Jan 25 16:47:40 2008 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Fri, 25 Jan 2008 16:47:40 +0000 Subject: Mercurial update In-Reply-To: <20080125134250.7668674FA@callebaut.niobe.net> References: <20080125134250.7668674FA@callebaut.niobe.net> Message-ID: <17c6771e0801250847w525387c0ra9d489f29dab6c6f@mail.gmail.com> On 25/01/2008, Mark Reinhold wrote: > In December we officially switched from TeamWare, the old Sun-internal > source-code management system, to Mercurial. > > No changesets have yet been pushed into the JDK 7 repositories because > the last few remaining bits of infrastructure are not yet complete. > These include a small Mercurial extension to check changeset comments, > legal notices, and repository invariants, and also the core community > database, which tracks Members, Groups, Projects, repositories, and the > relationships between all these things. (The extension will, naturally, > be published under the GPL for use outside of Sun.) > > Those remaining bits should be done in the next week or two, at which > point the changesets can start flowing. > > For some additional perspective please see John Rose's message to > build-dev earlier this morning [1]. > > In retrospect it was, perhaps, premature to do the cutover in December, > without every last bit of the infrastructure up and running, but we are > where we are. > > - Mark > > > [1] http://mail.openjdk.java.net/pipermail/build-dev/2008-January/000720.html > Hi Mark, Thanks for filling us in and for all your hard work making the JDK processes open and community accessible. It's very much appreciated and we anticipate the day when those changesets do start flowing :) -- Andrew :-) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net From robilad at kaffe.org Fri Jan 25 20:02:41 2008 From: robilad at kaffe.org (Dalibor Topic) Date: Fri, 25 Jan 2008 21:02:41 +0100 Subject: New Group Proposal: OpenJDK Conformance In-Reply-To: <200709281757.l8SHvTCf005259@ribbit.SFBay.Sun.COM> References: <200709281757.l8SHvTCf005259@ribbit.SFBay.Sun.COM> Message-ID: <479A4061.9070905@kaffe.org> iris.clark at sun.com wrote: > This group will have two mailing lists. The first is open to everyone > and will contain discussions around compatibility, conformance > testing, and general JCK installation and usability. The second > mailing list is open only to group members who have signed the OpenJDK > Community TCK Licensee Agreement. Discussions on this list will focus > on understanding the behavior and validity of specific tests and other > confidential materials. > Hi Iris & conformance team, I was wondering if the mailing lists have been created, as I haven't seen them on the conformance group's page, or the openjdk mailing list archives[2]. cheers, dalibor topic [1] http://openjdk.java.net/groups/conformance/ [2] http://mail.openjdk.java.net/mailman/listinfo From Paul.Rank at Sun.COM Fri Jan 25 20:41:39 2008 From: Paul.Rank at Sun.COM (Paul Rank) Date: Fri, 25 Jan 2008 12:41:39 -0800 Subject: New Group Proposal: OpenJDK Conformance In-Reply-To: <479A4061.9070905@kaffe.org> References: <200709281757.l8SHvTCf005259@ribbit.SFBay.Sun.COM> <479A4061.9070905@kaffe.org> Message-ID: <479A4983.60807@sun.com> Hi Dalibor, The mailing list for members who have signed the OpenJDK Community TCK Licensee Agreement has been created. However, the general conformance alias has not yet been created. Tim, are you the correct person to take care of this? Thanks, Paul Dalibor Topic wrote: > iris.clark at sun.com wrote: >> This group will have two mailing lists. The first is open to everyone >> and will contain discussions around compatibility, conformance >> testing, and general JCK installation and usability. The second >> mailing list is open only to group members who have signed the OpenJDK >> Community TCK Licensee Agreement. Discussions on this list will focus >> on understanding the behavior and validity of specific tests and other >> confidential materials. >> > > Hi Iris & conformance team, > > I was wondering if the mailing lists have been created, as I haven't > seen them on the conformance group's page, or the openjdk mailing list > archives[2]. > > cheers, > dalibor topic > > [1] http://openjdk.java.net/groups/conformance/ > [2] http://mail.openjdk.java.net/mailman/listinfo From Tim.Bell at Sun.COM Fri Jan 25 20:51:55 2008 From: Tim.Bell at Sun.COM (Tim Bell) Date: Fri, 25 Jan 2008 12:51:55 -0800 Subject: New Group Proposal: OpenJDK Conformance In-Reply-To: <479A4983.60807@sun.com> References: <200709281757.l8SHvTCf005259@ribbit.SFBay.Sun.COM> <479A4061.9070905@kaffe.org> <479A4983.60807@sun.com> Message-ID: <479A4BEB.5060007@sun.com> Paul Rank wrote: > However, the general conformance > alias has not yet been created. Tim, are you the correct person to take > care of this? Yes, I can do it. What do you want the public list to be called? Is it conformance-octla? Tim From Paul.Rank at Sun.COM Fri Jan 25 20:54:38 2008 From: Paul.Rank at Sun.COM (Paul Rank) Date: Fri, 25 Jan 2008 12:54:38 -0800 Subject: New Group Proposal: OpenJDK Conformance In-Reply-To: <479A4BEB.5060007@sun.com> References: <200709281757.l8SHvTCf005259@ribbit.SFBay.Sun.COM> <479A4061.9070905@kaffe.org> <479A4983.60807@sun.com> <479A4BEB.5060007@sun.com> Message-ID: <479A4C8E.8050006@sun.com> Tim Bell wrote: > Paul Rank wrote: >> However, the general conformance alias has not yet been created. Tim, >> are you the correct person to take care of this? > > Yes, I can do it. What do you want the public list to be called? Hi Tim, That would be great :-) > > Is it conformance-octla? We should name it simply "conformance". Thanks, Paul > > Tim From robilad at kaffe.org Fri Jan 25 21:28:32 2008 From: robilad at kaffe.org (Dalibor Topic) Date: Fri, 25 Jan 2008 22:28:32 +0100 Subject: New Group Proposal: OpenJDK Conformance In-Reply-To: <479A4983.60807@sun.com> References: <200709281757.l8SHvTCf005259@ribbit.SFBay.Sun.COM> <479A4061.9070905@kaffe.org> <479A4983.60807@sun.com> Message-ID: <479A5480.9050902@kaffe.org> Paul Rank wrote: > Hi Dalibor, > The mailing list for members who have signed the OpenJDK Community TCK > Licensee Agreement has been created. However, the general conformance > alias has not yet been created. Tim, are you the correct person to take > care of this? Thanks Paul, it's good to see the group moving ahead. In the interest of those members of the OpenJDK project that have not yet signed the OpenJDK Community TCK License Agreement, and general transparency, could you summarize the threads on the already created non-public list briefly (if there were any), once the public mailing list is created? cheers, dalibor topic From Tim.Bell at Sun.COM Fri Jan 25 21:36:31 2008 From: Tim.Bell at Sun.COM (Tim Bell) Date: Fri, 25 Jan 2008 13:36:31 -0800 Subject: New Group Proposal: OpenJDK Conformance In-Reply-To: <479A4C8E.8050006@sun.com> References: <200709281757.l8SHvTCf005259@ribbit.SFBay.Sun.COM> <479A4061.9070905@kaffe.org> <479A4983.60807@sun.com> <479A4BEB.5060007@sun.com> <479A4C8E.8050006@sun.com> Message-ID: <479A565F.90503@sun.com> Paul Rank wrote: > We should name it simply "conformance". Done. The web page for users is: http://mail.openjdk.java.net/mailman/listinfo/conformance There is also an email-based interface for users (not administrators) of the list; you can get info about using it by sending a message with just the word `help' as subject or in the body, to: conformance-request (at) openjdk.java.net Tim From Paul.Rank at Sun.COM Fri Jan 25 21:37:02 2008 From: Paul.Rank at Sun.COM (Paul Rank) Date: Fri, 25 Jan 2008 13:37:02 -0800 Subject: New Group Proposal: OpenJDK Conformance In-Reply-To: <479A5480.9050902@kaffe.org> References: <200709281757.l8SHvTCf005259@ribbit.SFBay.Sun.COM> <479A4061.9070905@kaffe.org> <479A4983.60807@sun.com> <479A5480.9050902@kaffe.org> Message-ID: <479A567E.4040001@sun.com> Hi Dalibor, Traffic has been very light on the non-public alias (I do expect that to change eventually :-) ) so there isn't much to summarize yet. But yes, I will be happy to provide a summary. Thanks, Paul Dalibor Topic wrote: > Paul Rank wrote: >> Hi Dalibor, >> The mailing list for members who have signed the OpenJDK Community >> TCK Licensee Agreement has been created. However, the general >> conformance alias has not yet been created. Tim, are you the correct >> person to take care of this? > > Thanks Paul, it's good to see the group moving ahead. > > In the interest of those members of the OpenJDK project that have not > yet signed the OpenJDK Community TCK License Agreement, and general > transparency, could you summarize the threads on the already created > non-public list briefly (if there were any), once the public mailing > list is created? > > cheers, > dalibor topic From Paul.Rank at Sun.COM Fri Jan 25 21:41:39 2008 From: Paul.Rank at Sun.COM (Paul Rank) Date: Fri, 25 Jan 2008 13:41:39 -0800 Subject: New Group Proposal: OpenJDK Conformance In-Reply-To: <479A565F.90503@sun.com> References: <200709281757.l8SHvTCf005259@ribbit.SFBay.Sun.COM> <479A4061.9070905@kaffe.org> <479A4983.60807@sun.com> <479A4BEB.5060007@sun.com> <479A4C8E.8050006@sun.com> <479A565F.90503@sun.com> Message-ID: <479A5793.7050309@sun.com> Thanks for setting this up Tim. I'll work on getting the bulk of the Sun JCK team signed up for the alias over the next few days. Paul Tim Bell wrote: > Paul Rank wrote: > >> We should name it simply "conformance". > > Done. > > The web page for users is: > > http://mail.openjdk.java.net/mailman/listinfo/conformance > > There is also an email-based interface for users (not administrators) > of the list; you can get info about using it by sending a message > with just the word `help' as subject or in the body, to: > > conformance-request (at) openjdk.java.net > > Tim From robilad at kaffe.org Fri Jan 25 21:43:11 2008 From: robilad at kaffe.org (Dalibor Topic) Date: Fri, 25 Jan 2008 22:43:11 +0100 Subject: New Group Proposal: OpenJDK Conformance In-Reply-To: <479A567E.4040001@sun.com> References: <200709281757.l8SHvTCf005259@ribbit.SFBay.Sun.COM> <479A4061.9070905@kaffe.org> <479A4983.60807@sun.com> <479A5480.9050902@kaffe.org> <479A567E.4040001@sun.com> Message-ID: <479A57EF.5040300@kaffe.org> Paul Rank wrote: > Hi Dalibor, > Traffic has been very light on the non-public alias (I do expect that to > change eventually :-) ) so there isn't much to summarize yet. But yes, > I will be happy to provide a summary. Great, thank you very much, that'd be great. With privileges come responsibilities, yadda, yadda, ... ;) cheers, dalibor topic From Tim.Bell at Sun.COM Fri Jan 25 21:56:54 2008 From: Tim.Bell at Sun.COM (Tim Bell) Date: Fri, 25 Jan 2008 13:56:54 -0800 Subject: New Group Proposal: OpenJDK Conformance In-Reply-To: <479A565F.90503@sun.com> References: <200709281757.l8SHvTCf005259@ribbit.SFBay.Sun.COM> <479A4061.9070905@kaffe.org> <479A4983.60807@sun.com> <479A4BEB.5060007@sun.com> <479A4C8E.8050006@sun.com> <479A565F.90503@sun.com> Message-ID: <479A5B26.1070809@sun.com> > name it simply "conformance". To stay in line with the names of other mailing lists on openjdk.java.net we are moving instead to `conformance-discuss' The web page for users is: http://mail.openjdk.java.net/mailman/listinfo/conformance-discuss There is also an email-based interface for users (not administrators) of the list; you can get info about using it by sending a message with just the word `help' as subject or in the body, to: conformance-discuss-request (at) openjdk.java.net Sorry for the switch at the last minute. Tim From Richard.Sands at Sun.COM Tue Jan 29 04:40:04 2008 From: Richard.Sands at Sun.COM (Rich Sands) Date: Mon, 28 Jan 2008 23:40:04 -0500 Subject: Announcing the OpenJDK Community Innovators' Challenge Message-ID: <479EAE24.2090406@sun.com> Its on! Check out http://openjdk.java.net/challenge And please join the challenge-discuss at openjdk.java.net mailing list which is where all the discussion, proposal submissions, and action will happen. There's an Official Rules document that spell out in detail how the Challenge will work. And of course, upholding an OpenJDK tradition - an FAQ. And did I mention $175,000 in awards? Good luck, everyone and have fun with it! -- rms -- Rich Sands Phone: +1 781 881 4067 / x81524 Community Marketing Manager Email: richard.sands at sun.com Java SE Marketing SMS: 6172830027 at vtext.com Sun Microsystems, Inc. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From gnu_andrew at member.fsf.org Tue Jan 29 21:28:09 2008 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Tue, 29 Jan 2008 21:28:09 +0000 Subject: New Project approved: JDK 6 In-Reply-To: <47999057.1080602@sun.com> References: <20080123052724.8CDD574FA@callebaut.niobe.net> <479754CE.1090509@redhat.com> <4798A7B7.8050106@kaffe.org> <47999057.1080602@sun.com> Message-ID: <17c6771e0801291328r2db8298che96d50927e7952a0@mail.gmail.com> On 25/01/2008, Joseph D. Darcy wrote: > Dalibor Topic wrote: > > Andrew Haley wrote: > >> Mark Reinhold wrote: > >>> Per the interim governance guidelines for Projects [1] I'm pleased to > >>> announce the creation of the JDK 6 Project [2,3] following the Build > >>> Group's decision [4] to sponsor it. > >> > >> How very splendid! Good news, indeed. > > Yep, looking forward to see it developed out in the open. > > > > Joe, could you add a URL for the mercurial repository on the project's > > web page? > > Hi Dalibor. > > I've sent out an email to the OpenJDK 6 dev list [1]. In summary, we > won't have Mercurial repositories immediately; I'm working on the > remaining Sun-internal processes to get the code out. I'll add a link > to the source bundles and Mercurial repositories once they are available. > > -Joe > > [1] http://mail.openjdk.java.net/pipermail/jdk6-dev/2008-January/000000.html > I presume having this pass the JDK 6 TCK will require the Javascript hole (and any other API facing ones) to be filled. Is the plan just to continue with the binary blobs 'solution' or is there an encumbrance removing hunk of code heading to a Mercurial repository near us soon? -- Andrew :-) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net From Joe.Darcy at Sun.COM Wed Jan 30 22:48:00 2008 From: Joe.Darcy at Sun.COM (Joseph D. Darcy) Date: Wed, 30 Jan 2008 14:48:00 -0800 Subject: New Project approved: JDK 6 In-Reply-To: <17c6771e0801291328r2db8298che96d50927e7952a0@mail.gmail.com> References: <20080123052724.8CDD574FA@callebaut.niobe.net> <479754CE.1090509@redhat.com> <4798A7B7.8050106@kaffe.org> <47999057.1080602@sun.com> <17c6771e0801291328r2db8298che96d50927e7952a0@mail.gmail.com> Message-ID: <47A0FEA0.1070309@sun.com> Andrew John Hughes wrote: > On 25/01/2008, Joseph D. Darcy wrote: >> Dalibor Topic wrote: >>> Andrew Haley wrote: >>>> Mark Reinhold wrote: >>>>> Per the interim governance guidelines for Projects [1] I'm pleased to >>>>> announce the creation of the JDK 6 Project [2,3] following the Build >>>>> Group's decision [4] to sponsor it. >>>> How very splendid! Good news, indeed. >>> Yep, looking forward to see it developed out in the open. >>> >>> Joe, could you add a URL for the mercurial repository on the project's >>> web page? >> Hi Dalibor. >> >> I've sent out an email to the OpenJDK 6 dev list [1]. In summary, we >> won't have Mercurial repositories immediately; I'm working on the >> remaining Sun-internal processes to get the code out. I'll add a link >> to the source bundles and Mercurial repositories once they are available. >> >> -Joe >> >> [1] http://mail.openjdk.java.net/pipermail/jdk6-dev/2008-January/000000.html >> > > I presume having this pass the JDK 6 TCK will require the Javascript > hole (and any other API facing ones) to be filled. Is the plan just > to continue with the binary blobs 'solution' or is there an > encumbrance removing hunk of code heading to a Mercurial repository > near us soon? The initial drop of 6-open will likely have the same set of binary plugs as currently in JDK 7. Removing those remaining encumbered plugs remains a goal for both OpenJDK 6 and 7. What is the Javascript hole you are referring to? -Joe From lars.westergren at ki.se Thu Jan 31 09:01:55 2008 From: lars.westergren at ki.se (Lars Westergren) Date: Thu, 31 Jan 2008 10:01:55 +0100 Subject: Getting started with the OpenJDK tutorial Message-ID: <47A18E83.9050503@ki.se> Hi, I created a step by step "getting started" guide to the OpenJDK after holding a presentation about it at Javaforum in Stockholm. It is creative commons so if anyone wants to expand on it or publish anywhere else you welcome, I hope you find it useful. http://larswestergren.blogspot.com/2007/12/beginners-guide-to-openjdk-contributing.html Cheers, Lars From mark at klomp.org Thu Jan 31 10:19:08 2008 From: mark at klomp.org (Mark Wielaard) Date: Thu, 31 Jan 2008 11:19:08 +0100 Subject: New Project approved: JDK 6 In-Reply-To: <47A0FEA0.1070309@sun.com> References: <20080123052724.8CDD574FA@callebaut.niobe.net> <479754CE.1090509@redhat.com> <4798A7B7.8050106@kaffe.org> <47999057.1080602@sun.com> <17c6771e0801291328r2db8298che96d50927e7952a0@mail.gmail.com> <47A0FEA0.1070309@sun.com> Message-ID: <1201774748.3155.20.camel@dijkstra.wildebeest.org> Hi Joe, On Wed, 2008-01-30 at 14:48 -0800, Joseph D. Darcy wrote: > What is the Javascript hole you are referring to? There are two 'holes' with respect to Javascript. - The core library scripting doesn't currently support javascript. This could be fixed by integrating Rhino (http://www.mozilla.org/rhino/) - There is a general hole with regard to applet support in browsers. In IcedTea this is filled by integrating gcjwebplugin. This works pretty nicely except for the java/javascript (LiveConnect) support. Thomas Fitszimmons is working on a gcjweblugin rewrite to make that happen. And maybe the Sun plugin code (which probably already has LiveConnect implemented) could be added to OpenJDK one day. But I don't know the status of that one. Some of this is tracked in IcedTea: http://icedtea.classpath.org/wiki/FrequentlyAskedQuestions#What_is_the_status_of_javascript.3F http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=85 Cheers, Mark From gnu_andrew at member.fsf.org Thu Jan 31 22:41:37 2008 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Thu, 31 Jan 2008 22:41:37 +0000 Subject: New Project approved: JDK 6 In-Reply-To: <1201774748.3155.20.camel@dijkstra.wildebeest.org> References: <20080123052724.8CDD574FA@callebaut.niobe.net> <479754CE.1090509@redhat.com> <4798A7B7.8050106@kaffe.org> <47999057.1080602@sun.com> <17c6771e0801291328r2db8298che96d50927e7952a0@mail.gmail.com> <47A0FEA0.1070309@sun.com> <1201774748.3155.20.camel@dijkstra.wildebeest.org> Message-ID: <17c6771e0801311441r4346ca7bj3f69d911f5271638@mail.gmail.com> On 31/01/2008, Mark Wielaard wrote: > Hi Joe, > > On Wed, 2008-01-30 at 14:48 -0800, Joseph D. Darcy wrote: > > What is the Javascript hole you are referring to? > > There are two 'holes' with respect to Javascript. > - The core library scripting doesn't currently support javascript. > This could be fixed by integrating Rhino > (http://www.mozilla.org/rhino/) > - There is a general hole with regard to applet support in browsers. > In IcedTea this is filled by integrating gcjwebplugin. > This works pretty nicely except for the java/javascript (LiveConnect) > support. Thomas Fitszimmons is working on a gcjweblugin rewrite to > make that happen. > > And maybe the Sun plugin code (which probably already has > LiveConnect implemented) could be added to OpenJDK one day. > But I don't know the status of that one. > > Some of this is tracked in IcedTea: > http://icedtea.classpath.org/wiki/FrequentlyAskedQuestions#What_is_the_status_of_javascript.3F > http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=85 > > Cheers, > > Mark > > Thanks Mark :) The first is the one I was referring to, but Joe answered my question anyway; OpenJDK 6 will still have binary plugs so I guess we need an IcedTea 6 to make it usable for now :) Is Rhino usable? I thought Rhino was already filling the hole in the proprietary JDK and thus that it had to be taken out, which seems strange given it's MPL / GPL 2 licensed. -- Andrew :-) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net