From Dalibor.Topic at Sun.COM Fri Aug 1 11:11:13 2008 From: Dalibor.Topic at Sun.COM (Dalibor Topic) Date: Fri, 01 Aug 2008 11:11:13 -0700 Subject: Proposal: zero-assembler port of OpenJDK In-Reply-To: <487F5E2D.80304@Sun.COM> References: <20080717141608.GF3861@redhat.com> <487F5E2D.80304@Sun.COM> Message-ID: <489351C1.2060609@sun.com> Dalibor Topic wrote: > Thank you for the fine proposal, Gary, I'm a big fan of your work, and > would like > to encourage list members to discuss it - once the discussion peters > out agreeably, > I'd be happy to do the formal project proposal, and initiate a vote > among members. I think the discussion of this proposal has now closed favorably, so I'll be doing a formal project proposal, and calling the group to vote shortly. cheers, dalibor topic -- ******************************************************************* Dalibor Topic Tel: (+49 40) 23 646 738 Java F/OSS Ambassador AIM: robiladonaim Sun Microsystems GmbH Mobile: (+49 177) 2664 192 Nagelsweg 55 http://openjdk.java.net D-20097 Hamburg mailto:Dalibor.Topic at sun.com Sitz der Gesellschaft: Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht M?nchen: HRB 161028 Gesch?ftsf?hrer: Thomas Schr?der, Wolfgang Engels, Dr. Roland B?mer Vorsitzender des Aufsichtsrates: Martin H?ring From Dalibor.Topic at Sun.COM Fri Aug 1 11:16:25 2008 From: Dalibor.Topic at Sun.COM (Dalibor Topic) Date: Fri, 01 Aug 2008 11:16:25 -0700 Subject: BSD port of OpenJDK In-Reply-To: <20080801021525.GA89848@misty.eyesbeyond.com> References: <20080801021525.GA89848@misty.eyesbeyond.com> Message-ID: <489352F9.1010103@sun.com> Greg Lewis wrote: > G'day all, > > I believe Dalibor will shortly follow this up with an official proposal, > but I just wanted to give a broader overview of whats been happening > with merging the BSD patches into OpenJDK. > > We've now completed all of the legal requirements to be able to merge the > bulk of the BSD patches in, although it will initially start as a separate > project of course. There are a few smaller patches that will have to be > reimplemented, but nothing core to our support. > > Briefly, here is some information about the BSD port: > > . There has been a BSD port since 1.0, although the current set of > changes can really only be traced to the SCSL based 1.2 port. > . We currently have support for FreeBSD, OpenBSD, NetBSD and MacOS X > and for the i386 and amd64 architectures. There are preliminary patches > for FreeBSD/sparc64 and I'm hoping the zero assembler patches will > help us add support for other architectures :). > . The bulk of these changes have already been through compatibility > testing, so we expect the code to be solid already. > . We've always tried to do our porting in a way that would add BSD > support without impacting support for other operating systems, so > I don't believe we'll have any impact on the Linux or Solaris support. > > Anyway, I'm very excited we're finally at a point to be able to do this > and I hope this will be a valuable addition to the OpenJDK project. > > I'd also feel remiss if I didn't at least mention the contributions of > Kurt Miller, Landon Fuller, Jung-uk Kim, Alexey Zelkin, Christos Zoulas > and many others who have worked on the BSD port over the years and the > support we've received from the FreeBSD Foundation. > Thank you very much for the update, Greg - the initial BSD port proposal has been discussed favourably at length previously on this list, and your update is bringing in a lot of goods news, so I'll be making a formal project proposal shortly. cheers, dalibor topic -- ******************************************************************* Dalibor Topic Tel: (+49 40) 23 646 738 Java F/OSS Ambassador AIM: robiladonaim Sun Microsystems GmbH Mobile: (+49 177) 2664 192 Nagelsweg 55 http://openjdk.java.net D-20097 Hamburg mailto:Dalibor.Topic at sun.com Sitz der Gesellschaft: Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht M?nchen: HRB 161028 Gesch?ftsf?hrer: Thomas Schr?der, Wolfgang Engels, Dr. Roland B?mer Vorsitzender des Aufsichtsrates: Martin H?ring From rob.ross at gmail.com Fri Aug 1 12:19:54 2008 From: rob.ross at gmail.com (Rob Ross) Date: Fri, 1 Aug 2008 12:19:54 -0700 Subject: Proposal: zero-assembler port of OpenJDK In-Reply-To: <489351C1.2060609@sun.com> References: <20080717141608.GF3861@redhat.com> <487F5E2D.80304@Sun.COM> <489351C1.2060609@sun.com> Message-ID: <308297BF-DC92-4BF4-8F02-8A0DF5C5103D@gmail.com> I'm late to this discussion, and I'm not a member of any groups so my comments don't carry the same weight. But I just wanted to chime in and say I think this is a brilliant idea, and it will allow for a personal goal of mine to be achieved far easier than otherwise, that of being able to port OpenJDK to the Mac OS X platform running on PPC hardware. Rob Ross, Lead Software Engineer E! Networks --------------------------------------------------- "Beware of he who would deny you access to information, for in his heart he dreams himself your master." -- Commissioner Pravin Lal On Aug 1, 2008, at 11:11 AM, Dalibor Topic wrote: > Dalibor Topic wrote: >> Thank you for the fine proposal, Gary, I'm a big fan of your work, >> and would like >> to encourage list members to discuss it - once the discussion >> peters out agreeably, >> I'd be happy to do the formal project proposal, and initiate a >> vote among members. > I think the discussion of this proposal has now closed favorably, > so I'll be doing a > formal project proposal, and calling the group to vote shortly. > > cheers, > dalibor topic > > -- > ******************************************************************* > Dalibor Topic Tel: (+49 40) 23 646 738 > Java F/OSS Ambassador AIM: robiladonaim > Sun Microsystems GmbH Mobile: (+49 177) 2664 192 > Nagelsweg 55 http://openjdk.java.net > D-20097 Hamburg mailto:Dalibor.Topic at sun.com > Sitz der Gesellschaft: Sonnenallee 1, D-85551 Kirchheim-Heimstetten > Amtsgericht M?nchen: HRB 161028 > Gesch?ftsf?hrer: Thomas Schr?der, Wolfgang Engels, Dr. Roland B?mer > Vorsitzender des Aufsichtsrates: Martin H?ring > > From glewis at eyesbeyond.com Fri Aug 1 13:31:15 2008 From: glewis at eyesbeyond.com (Greg Lewis) Date: Fri, 1 Aug 2008 13:31:15 -0700 Subject: Proposal: zero-assembler port of OpenJDK In-Reply-To: <308297BF-DC92-4BF4-8F02-8A0DF5C5103D@gmail.com> References: <20080717141608.GF3861@redhat.com> <487F5E2D.80304@Sun.COM> <489351C1.2060609@sun.com> <308297BF-DC92-4BF4-8F02-8A0DF5C5103D@gmail.com> Message-ID: <20080801203114.GA81868@misty.eyesbeyond.com> On Fri, Aug 01, 2008 at 12:19:54PM -0700, Rob Ross wrote: > I'm late to this discussion, and I'm not a member of any groups so my > comments don't carry the same weight. But I just wanted to chime in > and say I think this is a brilliant idea, and it will allow for a > personal goal of mine to be achieved far easier than otherwise, that > of being able to port OpenJDK to the Mac OS X platform running on PPC > hardware. If both the zero-assembler and the BSD changes get merged into OpenJDK then you shouldn't have to even do anything (notionally at least :) for Mac OS X 10.4+. > On Aug 1, 2008, at 11:11 AM, Dalibor Topic wrote: > > > Dalibor Topic wrote: > >> Thank you for the fine proposal, Gary, I'm a big fan of your work, > >> and would like > >> to encourage list members to discuss it - once the discussion > >> peters out agreeably, > >> I'd be happy to do the formal project proposal, and initiate a > >> vote among members. > > I think the discussion of this proposal has now closed favorably, > > so I'll be doing a > > formal project proposal, and calling the group to vote shortly. > > > > cheers, > > dalibor topic > > > > -- > > ******************************************************************* > > Dalibor Topic Tel: (+49 40) 23 646 738 > > Java F/OSS Ambassador AIM: robiladonaim > > Sun Microsystems GmbH Mobile: (+49 177) 2664 192 > > Nagelsweg 55 http://openjdk.java.net > > D-20097 Hamburg mailto:Dalibor.Topic at sun.com > > Sitz der Gesellschaft: Sonnenallee 1, D-85551 Kirchheim-Heimstetten > > Amtsgericht M?nchen: HRB 161028 > > Gesch?ftsf?hrer: Thomas Schr?der, Wolfgang Engels, Dr. Roland B?mer > > Vorsitzender des Aufsichtsrates: Martin H?ring > > > > -- Greg Lewis Email : glewis at eyesbeyond.com Eyes Beyond Web : http://www.eyesbeyond.com Information Technology FreeBSD : glewis at FreeBSD.org From David.Herron at Sun.COM Fri Aug 1 16:17:19 2008 From: David.Herron at Sun.COM (David Herron) Date: Fri, 01 Aug 2008 16:17:19 -0700 Subject: Project Proposal: "Zero-assembler port of OpenJDK" In-Reply-To: <489350F0.30603@sun.com> References: <489350F0.30603@sun.com> Message-ID: <4893997F.5010908@sun.com> Dalibor Topic wrote: > In accordance with the OpenJDK guidelines for projects [1], > I hereby propose on behalf of Gary Benson > an OpenJDK Project "Zero-assembler port of OpenJDK". > > This Project will be used for the development of a port of OpenJDK > that uses no assembler and > therefore can trivially be built on any system.[2] > > I propose this project be sponsored by the Porters Group [3] and that > I be the initial moderator of the project. > > cheers, > dalibor topic > > [1] http://openjdk.java.net/projects/ [2] > http://mail.openjdk.java.net/pipermail/porters-dev/2008-July/000160.html > [3] http://openjdk.java.net/groups/porters/ > "Yes" !!!! From Dalibor.Topic at Sun.COM Fri Aug 1 16:20:22 2008 From: Dalibor.Topic at Sun.COM (Dalibor Topic) Date: Fri, 01 Aug 2008 16:20:22 -0700 Subject: CFV: Project sponsorship: Zero-assembler port of OpenJDK Message-ID: <48939A36.1050305@sun.com> Question: Should the Porters' Group sponsor the proposed Zero-assembler port of OpenJDK Project [1]? Please cast your vote by replying, publicly, to this message with either Vote: yes or Vote: no as the first line of the message body. You may, at your option, indicate the reason for your decision on subsequent lines. Votes must be cast in the open; votes sent as private replies will not be counted. The sponsorship decision will be made by a simple majority vote of the Group's Members. Votes are due by midnight UTC next Friday, August 8th. As an optimization, if an absolute majority of the Group's Members votes one way or the other prior to that time then the decision may be rendered earlier. Only Members of the Hackers' Group are eligible to vote on this decision. The current Members are: David Herron Tom Marble Mark Reinhold Dalibor Topic Once a decision has been made the votes will be summarized and reported to this list and also to discuss at openjdk.java.net. cheers, dalibor topic [1] http://mail.openjdk.java.net/pipermail/announce/2008-August/000057.html -- ******************************************************************* Dalibor Topic Tel: (+49 40) 23 646 738 Java F/OSS Ambassador AIM: robiladonaim Sun Microsystems GmbH Mobile: (+49 177) 2664 192 Nagelsweg 55 http://openjdk.java.net D-20097 Hamburg mailto:Dalibor.Topic at sun.com Sitz der Gesellschaft: Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht M?nchen: HRB 161028 Gesch?ftsf?hrer: Thomas Schr?der, Wolfgang Engels, Dr. Roland B?mer Vorsitzender des Aufsichtsrates: Martin H?ring From Dalibor.Topic at Sun.COM Fri Aug 1 16:23:07 2008 From: Dalibor.Topic at Sun.COM (Dalibor Topic) Date: Fri, 01 Aug 2008 16:23:07 -0700 Subject: CFV: Project sponsorship: BSD port Message-ID: <48939ADB.3040006@sun.com> Question: Should the Porters' Group sponsor the proposed BSD port Project [1]? Please cast your vote by replying, publicly, to this message with either Vote: yes or Vote: no as the first line of the message body. You may, at your option, indicate the reason for your decision on subsequent lines. Votes must be cast in the open; votes sent as private replies will not be counted. The sponsorship decision will be made by a simple majority vote of the Group's Members. Votes are due by midnight UTC next Friday, August 8th. As an optimization, if an absolute majority of the Group's Members votes one way or the other prior to that time then the decision may be rendered earlier. Only Members of the Porters' Group are eligible to vote on this decision. The current Members are: David Herron Tom Marble Mark Reinhold Dalibor Topic Once a decision has been made the votes will be summarized and reported to this list and also to discuss at openjdk.java.net. cheers, dalibor topic [1] http://mail.openjdk.java.net/pipermail/announce/2008-August/000058.html -- ******************************************************************* Dalibor Topic Tel: (+49 40) 23 646 738 Java F/OSS Ambassador AIM: robiladonaim Sun Microsystems GmbH Mobile: (+49 177) 2664 192 Nagelsweg 55 http://openjdk.java.net D-20097 Hamburg mailto:Dalibor.Topic at sun.com Sitz der Gesellschaft: Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht M?nchen: HRB 161028 Gesch?ftsf?hrer: Thomas Schr?der, Wolfgang Engels, Dr. Roland B?mer Vorsitzender des Aufsichtsrates: Martin H?ring From Dalibor.Topic at Sun.COM Fri Aug 1 16:24:53 2008 From: Dalibor.Topic at Sun.COM (Dalibor Topic) Date: Fri, 01 Aug 2008 16:24:53 -0700 Subject: CFV: Project sponsorship: Zero-assembler port of OpenJDK In-Reply-To: <48939A36.1050305@sun.com> References: <48939A36.1050305@sun.com> Message-ID: <48939B45.1050009@sun.com> Vote: yes Because it's the right thing to do ;) cheers, dalibor topic -- ******************************************************************* Dalibor Topic Tel: (+49 40) 23 646 738 Java F/OSS Ambassador AIM: robiladonaim Sun Microsystems GmbH Mobile: (+49 177) 2664 192 Nagelsweg 55 http://openjdk.java.net D-20097 Hamburg mailto:Dalibor.Topic at sun.com Sitz der Gesellschaft: Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht M?nchen: HRB 161028 Gesch?ftsf?hrer: Thomas Schr?der, Wolfgang Engels, Dr. Roland B?mer Vorsitzender des Aufsichtsrates: Martin H?ring From rob.ross at gmail.com Fri Aug 1 16:25:56 2008 From: rob.ross at gmail.com (Rob Ross) Date: Fri, 1 Aug 2008 16:25:56 -0700 Subject: Project Proposal: BSD port In-Reply-To: <489355A4.7050503@sun.com> References: <489355A4.7050503@sun.com> Message-ID: <45D280E4-3251-430C-80A8-F10FEE42114C@gmail.com> I'm trying to clarify my understanding of what this means for a Mac- native version of OpenJDK. One of the implementation details of this project will be, for example, the addition of a "BSD" directory under .../jdk/src/, to go along with the existing "linux", "solaris", "windows", folders. Is this correct? So one could download OpenJDK and build it on a Mac (with the suitable hardware and OS version), and run it there as well? But this would be totally in "unix" land, e.g., using X11 for the UI, BSD libraries for the system calls, etc? Is this correct? If so, what would be the logical next steps (after this project has a stable build) in order to add a native Mac OS X port to the OpenJDK, using for example, native Cocoa code (or Core Graphics?) for rendering the UI? Rob Ross, Lead Software Engineer E! Networks --------------------------------------------------- "Beware of he who would deny you access to information, for in his heart he dreams himself your master." -- Commissioner Pravin Lal On Aug 1, 2008, at 11:27 AM, Dalibor Topic wrote: > In accordance with the OpenJDK guidelines for projects [1], > I hereby propose on behalf of Greg Lewis, Kurt Miller and Landon > Fuller > an OpenJDK Project "BSD port of OpenJDK". > > This Project will be used for the development of a port of OpenJDK to > the BSD family of operating systems, including FreeBSD, OpenBSD, > NetBSD > and MacOS X.[2]. > > I propose this project be sponsored by the Porters Group [3] and > that I be the initial moderator of the project. > > cheers, > dalibor topic > > [1] http://openjdk.java.net/projects/ > [2] http://mail.openjdk.java.net/pipermail/porters-dev/2008-July/ > 000170.html > [3] http://openjdk.java.net/groups/porters/ > > -- > ******************************************************************* > Dalibor Topic Tel: (+49 40) 23 646 738 > Java F/OSS Ambassador AIM: robiladonaim > Sun Microsystems GmbH Mobile: (+49 177) 2664 192 > Nagelsweg 55 http://openjdk.java.net > D-20097 Hamburg mailto:Dalibor.Topic at sun.com > Sitz der Gesellschaft: Sonnenallee 1, D-85551 Kirchheim-Heimstetten > Amtsgericht M?nchen: HRB 161028 > Gesch?ftsf?hrer: Thomas Schr?der, Wolfgang Engels, Dr. Roland B?mer > Vorsitzender des Aufsichtsrates: Martin H?ring > > From Dalibor.Topic at Sun.COM Fri Aug 1 16:26:34 2008 From: Dalibor.Topic at Sun.COM (Dalibor Topic) Date: Fri, 01 Aug 2008 16:26:34 -0700 Subject: CFV: Project sponsorship: BSD port In-Reply-To: <48939ADB.3040006@sun.com> References: <48939ADB.3040006@sun.com> Message-ID: <48939BAA.7040307@sun.com> Vote: yes Because the BSD porters rock, and it should go great together with Zero. ;) cheers, dalibor topic -- ******************************************************************* Dalibor Topic Tel: (+49 40) 23 646 738 Java F/OSS Ambassador AIM: robiladonaim Sun Microsystems GmbH Mobile: (+49 177) 2664 192 Nagelsweg 55 http://openjdk.java.net D-20097 Hamburg mailto:Dalibor.Topic at sun.com Sitz der Gesellschaft: Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht M?nchen: HRB 161028 Gesch?ftsf?hrer: Thomas Schr?der, Wolfgang Engels, Dr. Roland B?mer Vorsitzender des Aufsichtsrates: Martin H?ring From David.Herron at Sun.COM Fri Aug 1 16:27:12 2008 From: David.Herron at Sun.COM (David Herron) Date: Fri, 01 Aug 2008 16:27:12 -0700 Subject: CFV: Project sponsorship: Zero-assembler port of OpenJDK In-Reply-To: <48939B45.1050009@sun.com> References: <48939A36.1050305@sun.com> <48939B45.1050009@sun.com> Message-ID: <48939BD0.9060000@sun.com> Dalibor Topic wrote: > Vote: yes > > Because it's the right thing to do ;) > > cheers, > dalibor topic > Geez, I've obviously done it again. (voted by replying to the wrong email) Vote: "Yes" !!!!! From David.Herron at Sun.COM Fri Aug 1 16:27:56 2008 From: David.Herron at Sun.COM (David Herron) Date: Fri, 01 Aug 2008 16:27:56 -0700 Subject: CFV: Project sponsorship: BSD port In-Reply-To: <48939ADB.3040006@sun.com> References: <48939ADB.3040006@sun.com> Message-ID: <48939BFC.3050308@sun.com> Dalibor Topic wrote: > Question: Should the Porters' Group sponsor the proposed BSD port > Project [1]? Vote: Yes 13949712720901ForOSX !!! From Dalibor.Topic at Sun.COM Fri Aug 1 17:24:04 2008 From: Dalibor.Topic at Sun.COM (Dalibor Topic) Date: Fri, 01 Aug 2008 17:24:04 -0700 Subject: Project Proposal: BSD port In-Reply-To: <45D280E4-3251-430C-80A8-F10FEE42114C@gmail.com> References: <489355A4.7050503@sun.com> <45D280E4-3251-430C-80A8-F10FEE42114C@gmail.com> Message-ID: <4893A924.5070509@sun.com> Rob Ross wrote: > So one could download OpenJDK and build it on a Mac (with the suitable > hardware and OS version), and run it there as well? But this would be > totally in "unix" land, e.g., using X11 for the UI, BSD libraries for > the system calls, etc? > > Is this correct? Yes. > If so, what would be the logical next steps (after this project has a > stable build) in order to add a native Mac OS X port to the OpenJDK, > using for example, native Cocoa code (or Core Graphics?) for rendering > the UI? I'm not an AWT guy, but Roman Kennke and Mario Torre hacking on the Cacciocavallo project may be able to help figure out how to plug into the existing architecture. cheers, dalibor topic -- ******************************************************************* Dalibor Topic Tel: (+49 40) 23 646 738 Java F/OSS Ambassador AIM: robiladonaim Sun Microsystems GmbH Mobile: (+49 177) 2664 192 Nagelsweg 55 http://openjdk.java.net D-20097 Hamburg mailto:Dalibor.Topic at sun.com Sitz der Gesellschaft: Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht M?nchen: HRB 161028 Gesch?ftsf?hrer: Thomas Schr?der, Wolfgang Engels, Dr. Roland B?mer Vorsitzender des Aufsichtsrates: Martin H?ring From volker.simonis at gmail.com Sat Aug 2 01:14:51 2008 From: volker.simonis at gmail.com (Volker Simonis) Date: Sat, 2 Aug 2008 12:14:51 +0400 Subject: Project Proposal: BSD port In-Reply-To: <45D280E4-3251-430C-80A8-F10FEE42114C@gmail.com> References: <489355A4.7050503@sun.com> <45D280E4-3251-430C-80A8-F10FEE42114C@gmail.com> Message-ID: On 8/2/08, Rob Ross wrote: > I'm trying to clarify my understanding of what this means for a Mac-native > version of OpenJDK. > > One of the implementation details of this project will be, for example, the > addition of a "BSD" directory under .../jdk/src/, to go along with the > existing "linux", "solaris", "windows", folders. > > Is this correct? > I think this is a crucial question and the answer is not as clear as it may seem at a first glance. The problem is, that currently the "linux" directory contains only the Linux man-pages while the "solaris" directory contains all the "*nix" coding. While Linux and Solaris obviously share a great amount of code, the differences between the systems are factored out by numerous "ifdef" cascades. There are also a lot of places in the code which implicitely assume that the code is onlycompiled on Solaris and Linux (e.g. "ifndef SOLARIS" is used as a marker for Linux). Now that many new ports are created, I think this code organization should be seriously reconsidered, because: - if every port just changes the existing "solaris" source tree and inserts just one more cascade of platform specific macros it will become impossible to merge two or more of these ports together (i.e. to have one source repository which builds on every supported platform). But I think t his must be the final goal - having one source repository which contains as many ports as possible. - if every port makes a copy of the current solaris directory (i.e. the "bsd" directory in this context) this would make merging different ports easier. But it would also lead to a considerable amount of code duplication and maintaining the new ports would be a nightmare, because any changes to the original "solaris" directory, would have to be integrated in all the copies for the different ports. So in my opinion, the right way to go would be to factor out the common "*nix" code into a generic, say "Posix" directory and let the different platform directories ("solaris", "linix", "bsd", "haiku", ...) only contain the differences with regard to the common "Posix" directory (much like the "hotspot" directory is organized into a "shared", "cpu", "os" and "os_cpu" part). The drawback of this solution is that it would require a considerable amount of work (and a lot of work from Sun) because the code for the Solaris and Linux ports would have to be changed. Probably it would be wise, if the porters group would sponsor such an effort in the first place, if it is really interested in having many stable platform ports in the future. > So one could download OpenJDK and build it on a Mac (with the suitable > hardware and OS version), and run it there as well? But this would be > totally in "unix" land, e.g., using X11 for the UI, BSD libraries for the > system calls, etc? > > Is this correct? > > If so, what would be the logical next steps (after this project has a stable > build) in order to add a native Mac OS X port to the OpenJDK, using for > example, native Cocoa code (or Core Graphics?) for rendering the UI? > > > Rob Ross, Lead Software Engineer > E! Networks > > --------------------------------------------------- > "Beware of he who would deny you access to information, for in his heart he > dreams himself your master." -- Commissioner Pravin Lal > > > > > On Aug 1, 2008, at 11:27 AM, Dalibor Topic wrote: > > > In accordance with the OpenJDK guidelines for projects [1], > > I hereby propose on behalf of Greg Lewis, Kurt Miller and Landon Fuller > > an OpenJDK Project "BSD port of OpenJDK". > > > > This Project will be used for the development of a port of OpenJDK to > > the BSD family of operating systems, including FreeBSD, OpenBSD, NetBSD > > and MacOS X.[2]. > > > > I propose this project be sponsored by the Porters Group [3] and > > that I be the initial moderator of the project. > > > > cheers, > > dalibor topic > > > > [1] http://openjdk.java.net/projects/ > > [2] > http://mail.openjdk.java.net/pipermail/porters-dev/2008-July/000170.html > > [3] http://openjdk.java.net/groups/porters/ > > > > -- > > > ******************************************************************* > > Dalibor Topic Tel: (+49 40) 23 646 738 > > Java F/OSS Ambassador AIM: robiladonaim > > Sun Microsystems GmbH Mobile: (+49 177) 2664 192 > > Nagelsweg 55 http://openjdk.java.net > > D-20097 Hamburg mailto:Dalibor.Topic at sun.com > > Sitz der Gesellschaft: Sonnenallee 1, D-85551 Kirchheim-Heimstetten > > Amtsgericht M?nchen: HRB 161028 > > Gesch?ftsf?hrer: Thomas Schr?der, Wolfgang Engels, Dr. Roland B?mer > > Vorsitzender des Aufsichtsrates: Martin H?ring > > > > > > > > From tmarble at info9.net Sat Aug 2 09:31:41 2008 From: tmarble at info9.net (Tom Marble) Date: Sat, 02 Aug 2008 11:31:41 -0500 Subject: CFV: Project sponsorship: Zero-assembler port of OpenJDK In-Reply-To: <48939A36.1050305@sun.com> References: <48939A36.1050305@sun.com> Message-ID: <48948BED.5060007@info9.net> Vote: yes Can I add any more exclamation to that? Thanks Gary for doing this and Dalibor for the CFV. This is going to add so much power to OpenJDK to get to new platforms. Did I ever tell you how much I like ubiquity? Regards, --Tom From tmarble at info9.net Sat Aug 2 09:35:05 2008 From: tmarble at info9.net (Tom Marble) Date: Sat, 02 Aug 2008 11:35:05 -0500 Subject: CFV: Project sponsorship: BSD port In-Reply-To: <48939ADB.3040006@sun.com> References: <48939ADB.3040006@sun.com> Message-ID: <48948CB9.6070500@info9.net> Vote: yes This has been a long time coming... and the time is now! Thank you Dalibor for helping get all the "legal requirements" completely over the "finish line". Trust me, I know what that must have involved :) Clearly getting Duke, Tap and the little Devil together has been long overdue. Thanks BSD hackers! Regards, --Tom From martinrb at google.com Sat Aug 2 11:17:36 2008 From: martinrb at google.com (Martin Buchholz) Date: Sat, 2 Aug 2008 11:17:36 -0700 Subject: Project Proposal: BSD port In-Reply-To: References: <489355A4.7050503@sun.com> <45D280E4-3251-430C-80A8-F10FEE42114C@gmail.com> Message-ID: <1ccfd1c10808021117w49f14b6ay2eaa9712267f4398@mail.gmail.com> I mostly agree with Volker. The JDK code base has historically been targeted at a small number (like 10) of very specific build environments. The "must be windows or solaris or linux" assumption is a big one, but just one of many. Introducing a configure step is probably the right idea. The BSD port is a fine time to make OpenJDK at least more generally portable to any kind of Unix. BSD porters: Please don't just add else-if-BSD everywhere. On the other hand, I don't dislike #ifdefs as much as others (e.g. Volker) do. They need to be isolated, certainly, but with careful coding they have their place. I think #ifdefs are very much preferable to copying the entire src/solaris tree to src/bsd, for example. Unfortunately, there seems to be no way to change the portability layer of OpenJDK without introducing some instability. Good pre-integration testing is key. Martin On Sat, Aug 2, 2008 at 1:14 AM, Volker Simonis wrote: > On 8/2/08, Rob Ross wrote: >> I'm trying to clarify my understanding of what this means for a Mac-native >> version of OpenJDK. >> >> One of the implementation details of this project will be, for example, the >> addition of a "BSD" directory under .../jdk/src/, to go along with the >> existing "linux", "solaris", "windows", folders. >> >> Is this correct? >> > > I think this is a crucial question and the answer is not as clear as > it may seem at a first glance. The problem is, that currently the > "linux" directory contains only the Linux man-pages while the > "solaris" directory contains all the "*nix" coding. While Linux and > Solaris obviously share a great amount of code, the differences > between the systems are factored out by numerous "ifdef" cascades. > There are also a lot of places in the code which implicitely assume > that the code is onlycompiled on Solaris and Linux (e.g. "ifndef > SOLARIS" is used as a marker for Linux). > > Now that many new ports are created, I think this code organization > should be seriously reconsidered, because: > > - if every port just changes the existing "solaris" source tree and > inserts just one more cascade of platform specific macros it will > become impossible to merge two or more of these ports together (i.e. > to have one source repository which builds on every supported > platform). But I think t his must be the final goal - having one > source repository which contains as many ports as possible. > > - if every port makes a copy of the current solaris directory (i.e. > the "bsd" directory in this context) this would make merging different > ports easier. But it would also lead to a considerable amount of code > duplication and maintaining the new ports would be a nightmare, > because any changes to the original "solaris" directory, would have to > be integrated in all the copies for the different ports. > > So in my opinion, the right way to go would be to factor out the > common "*nix" code into a generic, say "Posix" directory and let the > different platform directories ("solaris", "linix", "bsd", "haiku", > ...) only contain the differences with regard to the common "Posix" > directory (much like the "hotspot" directory is organized into a > "shared", "cpu", "os" and "os_cpu" part). > > The drawback of this solution is that it would require a considerable > amount of work (and a lot of work from Sun) because the code for the > Solaris and Linux ports would have to be changed. > > Probably it would be wise, if the porters group would sponsor such an > effort in the first place, if it is really interested in having many > stable platform ports in the future. From mr at sun.com Sat Aug 2 12:28:54 2008 From: mr at sun.com (Mark Reinhold) Date: Sat, 02 Aug 2008 12:28:54 -0700 Subject: CFV: Project sponsorship: Zero-assembler port of OpenJDK In-Reply-To: dalibor.topic@sun.com; Fri, 01 Aug 2008 16:20:22 PDT; <48939A36.1050305@sun.com> Message-ID: <20080802192854.6B1BC2BF18@callebaut.niobe.net> Vote: yes (Of course!) - Mark From mr at sun.com Sat Aug 2 12:30:11 2008 From: mr at sun.com (Mark Reinhold) Date: Sat, 02 Aug 2008 12:30:11 -0700 Subject: CFV: Project sponsorship: BSD port In-Reply-To: dalibor.topic@sun.com; Fri, 01 Aug 2008 16:23:07 PDT; <48939ADB.3040006@sun.com> Message-ID: <20080802193011.187C82BF18@callebaut.niobe.net> Vote: yes (Did you really think I'd vote "no"?) - Mark From Dalibor.Topic at Sun.COM Sun Aug 3 10:24:58 2008 From: Dalibor.Topic at Sun.COM (Dalibor Topic) Date: Sun, 03 Aug 2008 19:24:58 +0200 Subject: CFV: Project sponsorship: Zero-assembler port of OpenJDK In-Reply-To: <48939A36.1050305@sun.com> References: <48939A36.1050305@sun.com> Message-ID: <4895E9EA.2000008@Sun.COM> Dalibor Topic wrote: > Question: Should the Porters' Group sponsor the proposed Zero-assembler > port of OpenJDK Project [1]? The vote has ended with the porters Group unanimously voting to sponsor the Project. Congratulations and welcome! cheers, dalibor topic -- ******************************************************************* Dalibor Topic Tel: (+49 40) 23 646 738 Java F/OSS Ambassador AIM: robiladonaim Sun Microsystems GmbH Mobile: (+49 177) 2664 192 Nagelsweg 55 http://openjdk.java.net D-20097 Hamburg mailto:Dalibor.Topic at sun.com Sitz der Gesellschaft: Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht M?nchen: HRB 161028 Gesch?ftsf?hrer: Thomas Schr?der, Wolfgang Engels, Dr. Roland B?mer Vorsitzender des Aufsichtsrates: Martin H?ring From Dalibor.Topic at Sun.COM Sun Aug 3 11:02:33 2008 From: Dalibor.Topic at Sun.COM (Dalibor Topic) Date: Sun, 03 Aug 2008 20:02:33 +0200 Subject: CFV: Project sponsorship: BSD port In-Reply-To: <48939ADB.3040006@sun.com> References: <48939ADB.3040006@sun.com> Message-ID: <4895F2B9.2070101@Sun.COM> Dalibor Topic wrote: > Question: Should the Porters' Group sponsor the proposed BSD port > Project [1]? The Porters Group has unanimously voted to sponsor the Project. Congratulations and welcome! cheers, dalibor topic -- ******************************************************************* Dalibor Topic Tel: (+49 40) 23 646 738 Java F/OSS Ambassador AIM: robiladonaim Sun Microsystems GmbH Mobile: (+49 177) 2664 192 Nagelsweg 55 http://openjdk.java.net D-20097 Hamburg mailto:Dalibor.Topic at sun.com Sitz der Gesellschaft: Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht M?nchen: HRB 161028 Gesch?ftsf?hrer: Thomas Schr?der, Wolfgang Engels, Dr. Roland B?mer Vorsitzender des Aufsichtsrates: Martin H?ring From gbenson at redhat.com Tue Aug 5 01:07:35 2008 From: gbenson at redhat.com (Gary Benson) Date: Tue, 5 Aug 2008 09:07:35 +0100 Subject: Proposal: zero-assembler port of OpenJDK In-Reply-To: <20080801203114.GA81868@misty.eyesbeyond.com> References: <20080717141608.GF3861@redhat.com> <487F5E2D.80304@Sun.COM> <489351C1.2060609@sun.com> <308297BF-DC92-4BF4-8F02-8A0DF5C5103D@gmail.com> <20080801203114.GA81868@misty.eyesbeyond.com> Message-ID: <20080805080735.GA3174@redhat.com> Greg Lewis wrote: > On Fri, Aug 01, 2008 at 12:19:54PM -0700, Rob Ross wrote: > > I'm late to this discussion, and I'm not a member of any groups > > so my comments don't carry the same weight. But I just wanted to > > chime in and say I think this is a brilliant idea, and it will > > allow for a personal goal of mine to be achieved far easier than > > otherwise, that of being able to port OpenJDK to the Mac OS X > > platform running on PPC hardware. > > If both the zero-assembler and the BSD changes get merged into > OpenJDK then you shouldn't have to even do anything (notionally > at least :) for Mac OS X 10.4+. Zero is currently Linux-specific, so you'd have to port it to BSD. Cheers, Gary -- http://gbenson.net/ From gbenson at redhat.com Tue Aug 5 01:20:16 2008 From: gbenson at redhat.com (Gary Benson) Date: Tue, 5 Aug 2008 09:20:16 +0100 Subject: CFV: Project sponsorship: Zero-assembler port of OpenJDK In-Reply-To: <4895E9EA.2000008@Sun.COM> References: <48939A36.1050305@sun.com> <4895E9EA.2000008@Sun.COM> Message-ID: <20080805082016.GB3174@redhat.com> Dalibor Topic wrote: > Dalibor Topic wrote: > > Question: Should the Porters' Group sponsor the proposed > > Zero-assembler port of OpenJDK Project [1]? > > The vote has ended with the porters Group unanimously voting > to sponsor the Project. > > Congratulations and welcome! Thank you :) What happens now? Cheers, Gary -- http://gbenson.net/ From Dalibor.Topic at Sun.COM Tue Aug 5 03:12:24 2008 From: Dalibor.Topic at Sun.COM (Dalibor Topic) Date: Tue, 05 Aug 2008 12:12:24 +0200 Subject: CFV: Project sponsorship: Zero-assembler port of OpenJDK In-Reply-To: <20080805082016.GB3174@redhat.com> References: <48939A36.1050305@sun.com> <4895E9EA.2000008@Sun.COM> <20080805082016.GB3174@redhat.com> Message-ID: <48982788.3060305@sun.com> Gary Benson wrote: > What happens now? Hi Gary, Mark Reinhold will get in touch with you about your account and setting up the project. cheers, dalibor topic -- ******************************************************************* Dalibor Topic Tel: (+49 40) 23 646 738 Java F/OSS Ambassador AIM: robiladonaim Sun Microsystems GmbH Mobile: (+49 177) 2664 192 Nagelsweg 55 http://openjdk.java.net D-20097 Hamburg mailto:Dalibor.Topic at sun.com Sitz der Gesellschaft: Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht M?nchen: HRB 161028 Gesch?ftsf?hrer: Thomas Schr?der, Wolfgang Engels, Dr. Roland B?mer Vorsitzender des Aufsichtsrates: Martin H?ring From gbenson at redhat.com Tue Aug 5 03:25:44 2008 From: gbenson at redhat.com (Gary Benson) Date: Tue, 5 Aug 2008 11:25:44 +0100 Subject: CFV: Project sponsorship: Zero-assembler port of OpenJDK In-Reply-To: <48982788.3060305@sun.com> References: <48939A36.1050305@sun.com> <4895E9EA.2000008@Sun.COM> <20080805082016.GB3174@redhat.com> <48982788.3060305@sun.com> Message-ID: <20080805102543.GC3174@redhat.com> Dalibor Topic wrote: > Gary Benson wrote: > > What happens now? > > Mark Reinhold will get in touch with you about your account and > setting up the project. Cool, thanks. Cheers, Gary -- http://gbenson.net/ From kurt at intricatesoftware.com Tue Aug 5 03:27:55 2008 From: kurt at intricatesoftware.com (Kurt Miller) Date: Tue, 5 Aug 2008 06:27:55 -0400 Subject: CFV: Project sponsorship: BSD port In-Reply-To: <4895F2B9.2070101@Sun.COM> References: <48939ADB.3040006@sun.com> <4895F2B9.2070101@Sun.COM> Message-ID: <200808050627.56148.kurt@intricatesoftware.com> On Sunday 03 August 2008 2:02:33 pm Dalibor Topic wrote: > Dalibor Topic wrote: > > Question: Should the Porters' Group sponsor the proposed BSD port > > Project [1]? > The Porters Group has unanimously voted to sponsor the Project. > > Congratulations and welcome! > > cheers, > dalibor topic > Thank you Dalibor and the others behind the scenes who helped this along. -Kurt From Kelly.Ohair at Sun.COM Tue Aug 5 11:11:37 2008 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Tue, 05 Aug 2008 11:11:37 -0700 Subject: Project Proposal: BSD port In-Reply-To: <1ccfd1c10808021117w49f14b6ay2eaa9712267f4398@mail.gmail.com> References: <489355A4.7050503@sun.com> <45D280E4-3251-430C-80A8-F10FEE42114C@gmail.com> <1ccfd1c10808021117w49f14b6ay2eaa9712267f4398@mail.gmail.com> Message-ID: <489897D9.6060806@sun.com> I think I'm mostly in agreement with Martin here. Hotspot is different, and I'm not speaking to that, just what is in the jdk7/jdk repository. I have tried over time to make any C code I see be standard conforming and avoided using the src/windows and src/solaris directories, favoring using the src/share area for as much as possible. I don't have the history on why the share vs. solaris vs. linux vs. windows separations were originally created and populated, I think someone with some ancient jdk history might speak to the real meaning of "share". I've treated "share" as "generic" code. I myself would prefer to have one implementation source file with a clean #ifdef approach rather than copied sources, but that's just me. I prefer to see all the implementations of a function in one file. However, I've adapted and over the years have experimented with many ways to do this. A couple of small examples in the OpenJDK sources I am familiar with: hprof, hprof_md.h is in the share area, and it's implemention is split: http://hg.openjdk.java.net/jdk7/jdk7/jdk/file/tip/src/share/demo/jvmti/hprof/hprof_md.h http://hg.openjdk.java.net/jdk7/jdk7/jdk/file/tip/src/solaris/demo/jvmti/hprof/hprof_md.c http://hg.openjdk.java.net/jdk7/jdk7/jdk/file/tip/src/windows/demo/jvmti/hprof/hprof_md.c Note the #ifdef LINUX used in the solaris file. backend (backend to debugger), has different *_md.h files and implementations: http://hg.openjdk.java.net/jdk7/jdk7/jdk/file/tip/src/solaris/back/ http://hg.openjdk.java.net/jdk7/jdk7/jdk/file/tip/src/windows/back/ Note that the share source is actually #including different files and could be influenced by those files doing different #includes. I liked the hprof approach better, but I ended up with ONE file in each of the src/windows/demo/jvmti/hprof and src/solaris/demo/jvmti/hprof directories. And I'd hate to see this file replicated again. How valuable is it to have completely different root source trees for windows and solaris? Could one file with a huge #ifdef in it been any better? Or just *_windows.c and *_posix.c names on the files and keep them in one src tree? Just making the observations, I have no great answers... -kto Martin Buchholz wrote: > I mostly agree with Volker. > > The JDK code base has historically been targeted at a > small number (like 10) of very specific build environments. > The "must be windows or solaris or linux" assumption > is a big one, but just one of many. > Introducing a configure step is probably the right idea. > The BSD port is a fine time to make OpenJDK at least > more generally portable to any kind of Unix. > BSD porters: Please don't just add else-if-BSD everywhere. > > On the other hand, I don't dislike #ifdefs as much as > others (e.g. Volker) do. They need to be isolated, certainly, > but with careful coding they have their place. > I think #ifdefs are very much preferable to copying the > entire src/solaris tree to src/bsd, for example. > > Unfortunately, there seems to be no way to change the > portability layer of OpenJDK without introducing some instability. > Good pre-integration testing is key. > > Martin > > On Sat, Aug 2, 2008 at 1:14 AM, Volker Simonis wrote: >> On 8/2/08, Rob Ross wrote: >>> I'm trying to clarify my understanding of what this means for a Mac-native >>> version of OpenJDK. >>> >>> One of the implementation details of this project will be, for example, the >>> addition of a "BSD" directory under .../jdk/src/, to go along with the >>> existing "linux", "solaris", "windows", folders. >>> >>> Is this correct? >>> >> I think this is a crucial question and the answer is not as clear as >> it may seem at a first glance. The problem is, that currently the >> "linux" directory contains only the Linux man-pages while the >> "solaris" directory contains all the "*nix" coding. While Linux and >> Solaris obviously share a great amount of code, the differences >> between the systems are factored out by numerous "ifdef" cascades. >> There are also a lot of places in the code which implicitely assume >> that the code is onlycompiled on Solaris and Linux (e.g. "ifndef >> SOLARIS" is used as a marker for Linux). >> >> Now that many new ports are created, I think this code organization >> should be seriously reconsidered, because: >> >> - if every port just changes the existing "solaris" source tree and >> inserts just one more cascade of platform specific macros it will >> become impossible to merge two or more of these ports together (i.e. >> to have one source repository which builds on every supported >> platform). But I think t his must be the final goal - having one >> source repository which contains as many ports as possible. >> >> - if every port makes a copy of the current solaris directory (i.e. >> the "bsd" directory in this context) this would make merging different >> ports easier. But it would also lead to a considerable amount of code >> duplication and maintaining the new ports would be a nightmare, >> because any changes to the original "solaris" directory, would have to >> be integrated in all the copies for the different ports. >> >> So in my opinion, the right way to go would be to factor out the >> common "*nix" code into a generic, say "Posix" directory and let the >> different platform directories ("solaris", "linix", "bsd", "haiku", >> ...) only contain the differences with regard to the common "Posix" >> directory (much like the "hotspot" directory is organized into a >> "shared", "cpu", "os" and "os_cpu" part). >> >> The drawback of this solution is that it would require a considerable >> amount of work (and a lot of work from Sun) because the code for the >> Solaris and Linux ports would have to be changed. >> >> Probably it would be wise, if the porters group would sponsor such an >> effort in the first place, if it is really interested in having many >> stable platform ports in the future. From rob.ross at gmail.com Tue Aug 5 15:43:00 2008 From: rob.ross at gmail.com (Rob Ross) Date: Tue, 5 Aug 2008 15:43:00 -0700 Subject: Project Proposal: BSD port In-Reply-To: <489897D9.6060806@sun.com> References: <489355A4.7050503@sun.com> <45D280E4-3251-430C-80A8-F10FEE42114C@gmail.com> <1ccfd1c10808021117w49f14b6ay2eaa9712267f4398@mail.gmail.com> <489897D9.6060806@sun.com> Message-ID: I can't comment on whether it's better to have all *nix statement variants be wrapped in #ifdefs or placed in their own platform- specific folder. It's probably a judgment call on whether platform- specific variations are different enough to warrant their own directory structure. But if you think about the differences between Windows, Mac OS, and *nix X11 native code for things like GUI or file-system access, I think these kinds of differences probably warrant their own directories. The code to render a native window is going to be quite different on these three platforms. It's not just a platform statement variation, you're calling native APIs that may only exist on one platform. So in cases like these, it makes sense to me to keep the code separate. I do like that the actual "low level" Java implementation is defined by private Java classes, that then call native methods to do to actual platform specific work. Thus there would still be need of having Java classes in these platform-specific directories, as the bridge between the higher level public Java APIs and the low-level native methods that eventually implement them. GUI code is the obvious example here, and there are certainly others - audio perhaps? But then again, maybe this list isn't actually as long as I think it is right now. Rob Ross, Lead Software Engineer E! Networks --------------------------------------------------- "Beware of he who would deny you access to information, for in his heart he dreams himself your master." -- Commissioner Pravin Lal On Aug 5, 2008, at 11:11 AM, Kelly O'Hair wrote: > I think I'm mostly in agreement with Martin here. > Hotspot is different, and I'm not speaking to that, just what is > in the jdk7/jdk repository. > > I have tried over time to make any C code I see be standard conforming > and avoided using the src/windows and src/solaris directories, > favoring > using the src/share area for as much as possible. > I don't have the history on why the share vs. solaris vs. linux vs. > windows > separations were originally created and populated, I think someone > with some > ancient jdk history might speak to the real meaning of "share". > I've treated "share" as "generic" code. > > I myself would prefer to have one implementation source file with a > clean > #ifdef approach rather than copied sources, but that's just me. > I prefer to see all the implementations of a function in one file. > > However, I've adapted and over the years have experimented with many > ways to do this. > > A couple of small examples in the OpenJDK sources I am familiar with: > > hprof, hprof_md.h is in the share area, and it's implemention is > split: > > http://hg.openjdk.java.net/jdk7/jdk7/jdk/file/tip/src/share/demo/ > jvmti/hprof/hprof_md.h > http://hg.openjdk.java.net/jdk7/jdk7/jdk/file/tip/src/solaris/demo/ > jvmti/hprof/hprof_md.c > http://hg.openjdk.java.net/jdk7/jdk7/jdk/file/tip/src/windows/demo/ > jvmti/hprof/hprof_md.c > > Note the #ifdef LINUX used in the solaris file. > > backend (backend to debugger), has different *_md.h files and > implementations: > > http://hg.openjdk.java.net/jdk7/jdk7/jdk/file/tip/src/solaris/back/ > http://hg.openjdk.java.net/jdk7/jdk7/jdk/file/tip/src/windows/back/ > > Note that the share source is actually #including different files > and could > be influenced by those files doing different #includes. > I liked the hprof approach better, but I ended up with ONE file > in each > of the src/windows/demo/jvmti/hprof and src/solaris/demo/jvmti/hprof > directories. And I'd hate to see this file replicated again. > > How valuable is it to have completely different root source trees > for windows and solaris? > Could one file with a huge #ifdef in it been any better? > Or just *_windows.c and *_posix.c names on the files and keep them > in one src tree? > > Just making the observations, I have no great answers... > > -kto > > > Martin Buchholz wrote: >> I mostly agree with Volker. >> The JDK code base has historically been targeted at a >> small number (like 10) of very specific build environments. >> The "must be windows or solaris or linux" assumption >> is a big one, but just one of many. >> Introducing a configure step is probably the right idea. >> The BSD port is a fine time to make OpenJDK at least >> more generally portable to any kind of Unix. >> BSD porters: Please don't just add else-if-BSD everywhere. >> On the other hand, I don't dislike #ifdefs as much as >> others (e.g. Volker) do. They need to be isolated, certainly, >> but with careful coding they have their place. >> I think #ifdefs are very much preferable to copying the >> entire src/solaris tree to src/bsd, for example. >> Unfortunately, there seems to be no way to change the >> portability layer of OpenJDK without introducing some instability. >> Good pre-integration testing is key. >> Martin >> On Sat, Aug 2, 2008 at 1:14 AM, Volker Simonis >> wrote: >>> On 8/2/08, Rob Ross wrote: >>>> I'm trying to clarify my understanding of what this means for a >>>> Mac-native >>>> version of OpenJDK. >>>> >>>> One of the implementation details of this project will be, for >>>> example, the >>>> addition of a "BSD" directory under .../jdk/src/, to go along >>>> with the >>>> existing "linux", "solaris", "windows", folders. >>>> >>>> Is this correct? >>>> >>> I think this is a crucial question and the answer is not as clear as >>> it may seem at a first glance. The problem is, that currently the >>> "linux" directory contains only the Linux man-pages while the >>> "solaris" directory contains all the "*nix" coding. While Linux and >>> Solaris obviously share a great amount of code, the differences >>> between the systems are factored out by numerous "ifdef" cascades. >>> There are also a lot of places in the code which implicitely assume >>> that the code is onlycompiled on Solaris and Linux (e.g. "ifndef >>> SOLARIS" is used as a marker for Linux). >>> >>> Now that many new ports are created, I think this code organization >>> should be seriously reconsidered, because: >>> >>> - if every port just changes the existing "solaris" source tree and >>> inserts just one more cascade of platform specific macros it will >>> become impossible to merge two or more of these ports together (i.e. >>> to have one source repository which builds on every supported >>> platform). But I think t his must be the final goal - having one >>> source repository which contains as many ports as possible. >>> >>> - if every port makes a copy of the current solaris directory (i.e. >>> the "bsd" directory in this context) this would make merging >>> different >>> ports easier. But it would also lead to a considerable amount of >>> code >>> duplication and maintaining the new ports would be a nightmare, >>> because any changes to the original "solaris" directory, would >>> have to >>> be integrated in all the copies for the different ports. >>> >>> So in my opinion, the right way to go would be to factor out the >>> common "*nix" code into a generic, say "Posix" directory and let the >>> different platform directories ("solaris", "linix", "bsd", "haiku", >>> ...) only contain the differences with regard to the common "Posix" >>> directory (much like the "hotspot" directory is organized into a >>> "shared", "cpu", "os" and "os_cpu" part). >>> >>> The drawback of this solution is that it would require a >>> considerable >>> amount of work (and a lot of work from Sun) because the code for the >>> Solaris and Linux ports would have to be changed. >>> >>> Probably it would be wise, if the porters group would sponsor >>> such an >>> effort in the first place, if it is really interested in having many >>> stable platform ports in the future. From Dmitri.Trembovetski at Sun.COM Tue Aug 5 16:01:21 2008 From: Dmitri.Trembovetski at Sun.COM (Dmitri Trembovetski) Date: Tue, 05 Aug 2008 16:01:21 -0700 Subject: Project Proposal: BSD port In-Reply-To: References: <489355A4.7050503@sun.com> <45D280E4-3251-430C-80A8-F10FEE42114C@gmail.com> <1ccfd1c10808021117w49f14b6ay2eaa9712267f4398@mail.gmail.com> <489897D9.6060806@sun.com> Message-ID: <4898DBC1.3030500@Sun.COM> Rob Ross wrote: > I can't comment on whether it's better to have all *nix statement > variants be wrapped in #ifdefs or placed in their own platform-specific > folder. It's probably a judgment call on whether platform-specific > variations are different enough to warrant their own directory structure. I agree, but they don't need to have different roots as they are now. Currently we have weird stuff similar to this: jdk/src/windows/native/sun/awt/windows/awt_Win32GraphicsDevice.cpp jdk/src/windows/classes/sun/awt/windows/Win32GraphicsDevice.java It seems that it could as easily be src/native/sun/awt/windows/awt_Win32GraphicsDevice.cpp src/classes/sun/awt/windows/Win32GraphicsDevice.java ... (I'd even remove 'shared') The native code for the most part mimics the java packages names, so if a package is platform-specific, it should probably have the platform in its name (sun.awt.windows in this case, or sun.awt.nix or whatever). The native code's structure would naturally follow the java package naming. For cases where the package name is the same on different platform but the native code is different we could follow Kelly's approach and/or use ifdef-ing. I do realize that such changes would be a huge pain though. Especially for those of us who still need to support earlier releases and port fixes from one tree to another. Thanks, Dmitri From swingler at apple.com Wed Aug 6 09:11:31 2008 From: swingler at apple.com (Mike Swingler) Date: Wed, 6 Aug 2008 09:11:31 -0700 Subject: Project Proposal: BSD port In-Reply-To: <4898DBC1.3030500@Sun.COM> References: <489355A4.7050503@sun.com> <45D280E4-3251-430C-80A8-F10FEE42114C@gmail.com> <1ccfd1c10808021117w49f14b6ay2eaa9712267f4398@mail.gmail.com> <489897D9.6060806@sun.com> <4898DBC1.3030500@Sun.COM> Message-ID: <5B494E46-3242-4260-96B1-0424895D62C5@apple.com> On Aug 5, 2008, at 4:01 PM, Dmitri Trembovetski wrote: > Rob Ross wrote: > >> I can't comment on whether it's better to have all *nix statement >> variants be wrapped in #ifdefs or placed in their own platform- >> specific folder. It's probably a judgment call on whether platform- >> specific variations are different enough to warrant their own >> directory structure. > > I agree, but they don't need to have different roots as they are now. > > Currently we have weird stuff similar to this: > jdk/src/windows/native/sun/awt/windows/awt_Win32GraphicsDevice.cpp > jdk/src/windows/classes/sun/awt/windows/Win32GraphicsDevice.java > > It seems that it could as easily be > src/native/sun/awt/windows/awt_Win32GraphicsDevice.cpp > src/classes/sun/awt/windows/Win32GraphicsDevice.java > ... > (I'd even remove 'shared') > > The native code for the most part mimics the java packages > names, so if a package is platform-specific, it should probably > have the platform in its name (sun.awt.windows in this case, or > sun.awt.nix or whatever). The native code's structure would > naturally follow the java package naming. > > For cases where the package name is the same on different > platform but the native code is different we could follow > Kelly's approach and/or use ifdef-ing. > > I do realize that such changes would be a huge pain though. > Especially for those of us who still need to support > earlier releases and port fixes from one tree to another. I think the ideal thing to do would be to clearly discriminate in the directory structure exactly what difference is between the platforms. If the difference is X11, then create an x11 directory (because not all *nix's are going to be based on X11). If the difference is Win32 vs. Posix threading and file system operations, there should be a win32 and posix directory for that sub-system. The same should be true for fonts, OpenGL work, or any other system where discrimination does not cleanly cleave down platform lines. #ifdef'ing should only be reserved for situations where the code is largely similar, but requires just a tweak one way or the other (like 32 vs. 64-bit). Glomming all the classes together in the same pot and removing the 'shared' directory will encourage everyone to just "compile all the classes", and toss them into the same jar, and ship classes that make no sense on for that platform. Any accessory or utility classes that don't result in a runtime link error only increase the security surface area of attack. Thoughts? Mike Swingler Java Runtime Engineer Apple Inc. From Kelly.Ohair at Sun.COM Wed Aug 6 09:22:53 2008 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Wed, 06 Aug 2008 09:22:53 -0700 Subject: Project Proposal: BSD port In-Reply-To: <5B494E46-3242-4260-96B1-0424895D62C5@apple.com> References: <489355A4.7050503@sun.com> <45D280E4-3251-430C-80A8-F10FEE42114C@gmail.com> <1ccfd1c10808021117w49f14b6ay2eaa9712267f4398@mail.gmail.com> <489897D9.6060806@sun.com> <4898DBC1.3030500@Sun.COM> <5B494E46-3242-4260-96B1-0424895D62C5@apple.com> Message-ID: <4899CFDD.5090603@sun.com> Good points. A while back I changed code that was ifdef'd on the platform changed to being ifdef'd on _LITTLE_ENDIAN, just made more sense and the code was easier to understand. Changing the ifdef's to specific features rather than making it a platform thing makes sense. So I agree with your X11 comment. And also agree that we don't want to deliver classes to a platform that doesn't need them. -kto Mike Swingler wrote: > On Aug 5, 2008, at 4:01 PM, Dmitri Trembovetski wrote: > >> Rob Ross wrote: >> >>> I can't comment on whether it's better to have all *nix statement >>> variants be wrapped in #ifdefs or placed in their own >>> platform-specific folder. It's probably a judgment call on whether >>> platform-specific variations are different enough to warrant their >>> own directory structure. >> >> I agree, but they don't need to have different roots as they are now. >> >> Currently we have weird stuff similar to this: >> jdk/src/windows/native/sun/awt/windows/awt_Win32GraphicsDevice.cpp >> jdk/src/windows/classes/sun/awt/windows/Win32GraphicsDevice.java >> >> It seems that it could as easily be >> src/native/sun/awt/windows/awt_Win32GraphicsDevice.cpp >> src/classes/sun/awt/windows/Win32GraphicsDevice.java >> ... >> (I'd even remove 'shared') >> >> The native code for the most part mimics the java packages >> names, so if a package is platform-specific, it should probably >> have the platform in its name (sun.awt.windows in this case, or >> sun.awt.nix or whatever). The native code's structure would >> naturally follow the java package naming. >> >> For cases where the package name is the same on different >> platform but the native code is different we could follow >> Kelly's approach and/or use ifdef-ing. >> >> I do realize that such changes would be a huge pain though. >> Especially for those of us who still need to support >> earlier releases and port fixes from one tree to another. > > I think the ideal thing to do would be to clearly discriminate in the > directory structure exactly what difference is between the platforms. If > the difference is X11, then create an x11 directory (because not all > *nix's are going to be based on X11). If the difference is Win32 vs. > Posix threading and file system operations, there should be a win32 and > posix directory for that sub-system. The same should be true for fonts, > OpenGL work, or any other system where discrimination does not cleanly > cleave down platform lines. #ifdef'ing should only be reserved for > situations where the code is largely similar, but requires just a tweak > one way or the other (like 32 vs. 64-bit). > > Glomming all the classes together in the same pot and removing the > 'shared' directory will encourage everyone to just "compile all the > classes", and toss them into the same jar, and ship classes that make no > sense on for that platform. Any accessory or utility classes that don't > result in a runtime link error only increase the security surface area > of attack. > > Thoughts? > Mike Swingler > Java Runtime Engineer > Apple Inc. From volker.simonis at gmail.com Thu Aug 7 12:12:24 2008 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 7 Aug 2008 23:12:24 +0400 Subject: Project Proposal: BSD port In-Reply-To: <5B494E46-3242-4260-96B1-0424895D62C5@apple.com> References: <489355A4.7050503@sun.com> <45D280E4-3251-430C-80A8-F10FEE42114C@gmail.com> <1ccfd1c10808021117w49f14b6ay2eaa9712267f4398@mail.gmail.com> <489897D9.6060806@sun.com> <4898DBC1.3030500@Sun.COM> <5B494E46-3242-4260-96B1-0424895D62C5@apple.com> Message-ID: Yea, these are good points. If we take into account that the code in the j2se directory is maintained by several different groups (i.e. AWT, Core Libraries, Networking, Sound, ...) it may be perhaps even usefull to rearrange the platform dependant code in such a way that the first level of subdirectories inside the "j2se" directory denotes the specific group. Every group could than decide for itself, how it wants to handle the platform specific differences. Otherwise, all groups involved would have to agree on a new schema which I imagine could be quite difficult... I know this means even more changes, but perhaps it's the right time to do them now, if there is a common consense on changing the structure of the j2se project anyway. Regards, Volker On 8/6/08, Mike Swingler wrote: > On Aug 5, 2008, at 4:01 PM, Dmitri Trembovetski wrote: > > > Rob Ross wrote: > > > > > > > I can't comment on whether it's better to have all *nix statement > variants be wrapped in #ifdefs or placed in their own platform-specific > folder. It's probably a judgment call on whether platform-specific > variations are different enough to warrant their own directory structure. > > > > > > > I agree, but they don't need to have different roots as they are now. > > > > Currently we have weird stuff similar to this: > > > jdk/src/windows/native/sun/awt/windows/awt_Win32GraphicsDevice.cpp > > > jdk/src/windows/classes/sun/awt/windows/Win32GraphicsDevice.java > > > > It seems that it could as easily be > > src/native/sun/awt/windows/awt_Win32GraphicsDevice.cpp > > src/classes/sun/awt/windows/Win32GraphicsDevice.java > > ... > > (I'd even remove 'shared') > > > > The native code for the most part mimics the java packages > > names, so if a package is platform-specific, it should probably > > have the platform in its name (sun.awt.windows in this case, or > > sun.awt.nix or whatever). The native code's structure would > > naturally follow the java package naming. > > > > For cases where the package name is the same on different > > platform but the native code is different we could follow > > Kelly's approach and/or use ifdef-ing. > > > > I do realize that such changes would be a huge pain though. > > Especially for those of us who still need to support > > earlier releases and port fixes from one tree to another. > > > > I think the ideal thing to do would be to clearly discriminate in the > directory structure exactly what difference is between the platforms. If the > difference is X11, then create an x11 directory (because not all *nix's are > going to be based on X11). If the difference is Win32 vs. Posix threading > and file system operations, there should be a win32 and posix directory for > that sub-system. The same should be true for fonts, OpenGL work, or any > other system where discrimination does not cleanly cleave down platform > lines. #ifdef'ing should only be reserved for situations where the code is > largely similar, but requires just a tweak one way or the other (like 32 vs. > 64-bit). > > Glomming all the classes together in the same pot and removing the 'shared' > directory will encourage everyone to just "compile all the classes", and > toss them into the same jar, and ship classes that make no sense on for that > platform. Any accessory or utility classes that don't result in a runtime > link error only increase the security surface area of attack. > > Thoughts? > Mike Swingler > Java Runtime Engineer > Apple Inc. > From gnu_andrew at member.fsf.org Fri Aug 8 08:01:05 2008 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Fri, 8 Aug 2008 16:01:05 +0100 Subject: Project Proposal: BSD port In-Reply-To: References: <489355A4.7050503@sun.com> <45D280E4-3251-430C-80A8-F10FEE42114C@gmail.com> <1ccfd1c10808021117w49f14b6ay2eaa9712267f4398@mail.gmail.com> <489897D9.6060806@sun.com> <4898DBC1.3030500@Sun.COM> <5B494E46-3242-4260-96B1-0424895D62C5@apple.com> Message-ID: <17c6771e0808080801m38ed7b3ao91cdf565c02e21e4@mail.gmail.com> 2008/8/7 Volker Simonis : > Yea, these are good points. > > If we take into account that the code in the j2se directory is > maintained by several different groups (i.e. AWT, Core Libraries, > Networking, Sound, ...) it may be perhaps even usefull to rearrange > the platform dependant code in such a way that the first level of > subdirectories inside the "j2se" directory denotes the specific group. > Every group could than decide for itself, how it wants to handle the > platform specific differences. Otherwise, all groups involved would > have to agree on a new schema which I imagine could be quite > difficult... > > I know this means even more changes, but perhaps it's the right time > to do them now, if there is a common consense on changing the > structure of the j2se project anyway. > > Regards, > Volker > Better to agreed than have a different schema per group to contend with, which would just add to confusion, especially with those outside Sun where these groups aren't as established concepts. -- Andrew :-) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From landonf at bikemonkey.org Wed Aug 20 15:48:57 2008 From: landonf at bikemonkey.org (Landon Fuller) Date: Wed, 20 Aug 2008 15:48:57 -0700 Subject: Public Build Farm Message-ID: <2EDFECC8-4227-4EA8-B928-A7AF445FE696@bikemonkey.org> Howdy All, We just did the first import of the BSD OpenJDK sources, which includes support for three different operating systems (FreeBSD, OpenBSD, Darwin), on two architectures (x86-32, x86-64). This leaves a lot of room for toe-stepping between various developers. What are people's thoughts on implementing an OpenJDK continual integration/build system using something like Buildbot or Hudson? Is this something Sun / OpenJDK could host? Does it make the most sense to have users to volunteer build servers? -landonf -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part Url : http://mail.openjdk.java.net/pipermail/porters-dev/attachments/20080820/8fee84de/attachment.bin From mr at sun.com Wed Aug 20 15:55:25 2008 From: mr at sun.com (Mark Reinhold) Date: Wed, 20 Aug 2008 15:55:25 -0700 Subject: Public Build Farm In-Reply-To: landonf@bikemonkey.org; Wed, 20 Aug 2008 15:48:57 PDT; <2EDFECC8-4227-4EA8-B928-A7AF445FE696@bikemonkey.org> Message-ID: <20080820225525.785F85CA6@eggemoggin.niobe.net> > Date: Wed, 20 Aug 2008 15:48:57 -0700 > From: Landon Fuller > We just did the first import of the BSD OpenJDK sources, which > includes support for three different operating systems (FreeBSD, > OpenBSD, Darwin), on two architectures (x86-32, x86-64). This leaves a > lot of room for toe-stepping between various developers. > > What are people's thoughts on implementing an OpenJDK continual > integration/build system using something like Buildbot or Hudson? > > Is this something Sun / OpenJDK could host? We can almost certainly host the master portion of such a system, so long as it doesn't need a ton of server-side resources. I don't have direct experience with either Hudson or Buildbot. Does anyone else? > Does it make the most sense to have users to volunteer build servers? Yes, I think so -- our meager capital budget is pretty much absorbed just keeping the basic openjdk.java.net services up and running, so I don't think Sun can fund the construction of a big build farm any time soon. - Mark From gnu_andrew at member.fsf.org Wed Aug 20 17:38:38 2008 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Thu, 21 Aug 2008 01:38:38 +0100 Subject: Public Build Farm In-Reply-To: <20080820225525.785F85CA6@eggemoggin.niobe.net> References: <2EDFECC8-4227-4EA8-B928-A7AF445FE696@bikemonkey.org> <20080820225525.785F85CA6@eggemoggin.niobe.net> Message-ID: <17c6771e0808201738xd76d2e1ke283b5b105463dbe@mail.gmail.com> On 20/08/2008, Mark Reinhold wrote: > > Date: Wed, 20 Aug 2008 15:48:57 -0700 > > From: Landon Fuller > > > > We just did the first import of the BSD OpenJDK sources, which > > includes support for three different operating systems (FreeBSD, > > OpenBSD, Darwin), on two architectures (x86-32, x86-64). This leaves a > > lot of room for toe-stepping between various developers. > > > > What are people's thoughts on implementing an OpenJDK continual > > integration/build system using something like Buildbot or Hudson? > > > > Is this something Sun / OpenJDK could host? > > > We can almost certainly host the master portion of such a system, so long > as it doesn't need a ton of server-side resources. > > I don't have direct experience with either Hudson or Buildbot. Does > anyone else? > > > > Does it make the most sense to have users to volunteer build servers? > > > Yes, I think so -- our meager capital budget is pretty much absorbed just > keeping the basic openjdk.java.net services up and running, so I don't > think Sun can fund the construction of a big build farm any time soon. > > > - Mark > This might also be useful for testing IcedTea patches on proprietary build systems like Solaris (uses Sun Studio) and Windows (uses Visual Studio IIRC). -- Andrew :-) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From dgreen99 at gmail.com Thu Aug 21 13:43:36 2008 From: dgreen99 at gmail.com (David Green) Date: Thu, 21 Aug 2008 13:43:36 -0700 Subject: starting Eclipse on Darwin with OpenJDK Message-ID: <535803b00808211343h784af8e4s5be29eaa2356532e@mail.gmail.com> In the past I've had success launching Eclipse using SoyLatte . With Landon Fuller's recent announcement of OpenJDK on Darwin and Mac I downloaded the OpenJDK binaries posted here. Unfortunately the SWT libraries fail to load. Is there a problem with JNI on Mac OS X? Following is the error message that I saw: !SESSION 2008-08-21 13:22:33.593 ----------------------------------------------- eclipse.buildId=I20080617-2000 java.version=1.7.0-internal java.vendor=Sun Microsystems Inc. BootLoader constants: OS=macosx, ARCH=x86, WS=carbon, NL=en_CA Framework arguments: -keyring /Users/dgreen/.eclipse_keyring -showlocation Command-line arguments: -os macosx -ws carbon -arch x86 -data /Users/dgreen/Documents/workspace-mylyn.wikitext -keyring /Users/dgreen/.eclipse_keyring -consoleLog -showlocation !ENTRY org.eclipse.osgi 4 0 2008-08-21 13:22:34.891 !MESSAGE Application error !STACK 1 java.lang.UnsatisfiedLinkError: no swt-carbon-3448 or swt-carbon in swt.library.path, java.library.path or the jar file at org.eclipse.swt.internal.Library.loadLibrary(Library.java:233) at org.eclipse.swt.internal.Library.loadLibrary(Library.java:151) at org.eclipse.swt.internal.C.(C.java:21) at org.eclipse.swt.widgets.Display.createDisplay(Display.java:972) at org.eclipse.swt.widgets.Display.create(Display.java:966) at org.eclipse.swt.graphics.Device.(Device.java:124) at org.eclipse.swt.widgets.Display.(Display.java:774) at org.eclipse.swt.widgets.Display.(Display.java:765) at org.eclipse.ui.internal.Workbench.createDisplay(Workbench.java:525) at org.eclipse.ui.PlatformUI.createDisplay(PlatformUI.java:161) at org.eclipse.ui.internal.ide.application.IDEApplication.createDisplay(IDEApplication.java:143) at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:88) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:193) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:382) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:623) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:549) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:504) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/porters-dev/attachments/20080821/3a570c62/attachment.html