From frans at meruvian.org Fri Aug 1 00:49:40 2008 From: frans at meruvian.org (Frans Thamura) Date: Fri, 1 Aug 2008 07:49:40 +0700 Subject: OpenJDK for Mac Message-ID: <3a71add70807311749j4e93d860ka4424e88341f73d4@mail.gmail.com> hi there, can i know, how to use OpenJDK code and compile in Mac and make it mac vresion esp in old Mac -- -- Frans Thamura Meruvian Foundation Mobile: +62 855 7888 699 Profile: http://nagasakti.mervpolis.com/roller/flatburger/entry/frans_thamura Linkedin: http://www.linkedin.com/in/fthamura Discuss BlueOxygen Projects at blueoxygen at yahoogroups.com From rob.ross at gmail.com Fri Aug 1 01:00:05 2008 From: rob.ross at gmail.com (Rob Ross) Date: Thu, 31 Jul 2008 18:00:05 -0700 Subject: OpenJDK for Mac In-Reply-To: <3a71add70807311749j4e93d860ka4424e88341f73d4@mail.gmail.com> References: <3a71add70807311749j4e93d860ka4424e88341f73d4@mail.gmail.com> Message-ID: At the present time there is no support for building on Mac from the OpenJDK6/7 project. However, a while ago Landon Fuller got a build of the JRL JDK6 source BSD port. You can download binaries here: http://landonf.bikemonkey.org/static/soylatte/ The binaries will run 32bit on 10.4 & 10.5, or 64bit on 10.5, but only on the latest Intel machines. Also, the port is using X11 to render graphics, so it won't "look" anything like the Apple JDK. So the short story is, there's a kinda hack-ish version of OpenJDK6 available, that works on a limited amount of machines. I was not able to successfully build this project from his sources. I have emailed him several times, but he has not replied. I believe he is extremely busy with his startup at the moment. I am interested in working on getting OpenJDK to run as a native Mac app, but at present I do not have the technical experience to organize this project. But if you're interested in working on this, we should start communicating regularly and start to gather critical mass. 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 Jul 31, 2008, at 5:49 PM, Frans Thamura wrote: > hi there, > > can i know, how to use OpenJDK code and compile in Mac and make it > mac vresion > > esp in old Mac > > -- > -- > Frans Thamura > Meruvian Foundation > > Mobile: +62 855 7888 699 > Profile: http://nagasakti.mervpolis.com/roller/flatburger/entry/ > frans_thamura > > Linkedin: http://www.linkedin.com/in/fthamura > > Discuss BlueOxygen Projects at blueoxygen at yahoogroups.com From rob.ross at gmail.com Fri Aug 1 02:01:46 2008 From: rob.ross at gmail.com (Rob Ross) Date: Thu, 31 Jul 2008 19:01:46 -0700 Subject: OpenJDK for Mac In-Reply-To: <3a71add70807311802p14ea41d6l6dd1a0ed753f6bc5@mail.gmail.com> References: <3a71add70807311749j4e93d860ka4424e88341f73d4@mail.gmail.com> <3a71add70807311802p14ea41d6l6dd1a0ed753f6bc5@mail.gmail.com> Message-ID: Yes. That is the goal of OpenJDK, to port it to many different platforms. They already have support for Windows, Solaris, and various Linux versions. There are some external projects that have ported the JDK 6 source code that was under the JRL license to BSD, FreeBSD, and other Unix variants. They will eventually merge the code Landon Fuller contributed from SoyLatte to the OpenJDK 6 source code, and then we'll be able to start working on the Mac port in earnest. 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 Jul 31, 2008, at 6:02 PM, Frans Thamura wrote: > On Fri, Aug 1, 2008 at 8:00 AM, Rob Ross wrote: >> At the present time there is no support for building on Mac from the >> OpenJDK6/7 project. >> > > is there a plan openjdk people develop more more on another OS > > so we can get a lot of version (binary) in several OS > > F From frans at meruvian.org Fri Aug 1 02:37:41 2008 From: frans at meruvian.org (Frans Thamura) Date: Fri, 1 Aug 2008 09:37:41 +0700 Subject: OpenJDK for Mac In-Reply-To: References: <3a71add70807311749j4e93d860ka4424e88341f73d4@mail.gmail.com> <3a71add70807311802p14ea41d6l6dd1a0ed753f6bc5@mail.gmail.com> Message-ID: <3a71add70807311937m280c869eh36ac4890588185d@mail.gmail.com> On Fri, Aug 1, 2008 at 9:01 AM, Rob Ross wrote: > Yes. That is the goal of OpenJDK, to port it to many different platforms. > They already have support for Windows, Solaris, and various Linux versions. > There are some external projects that have ported the JDK 6 source code that > was under the JRL license to BSD, FreeBSD, and other Unix variants. > > They will eventually merge the code Landon Fuller contributed from SoyLatte > to the OpenJDK 6 source code, and then we'll be able to start working on the > Mac port in earnest. > cool :) i glad this vision F From Onno.Kluyt at Sun.COM Fri Aug 1 13:08:09 2008 From: Onno.Kluyt at Sun.COM (Onno Kluyt) Date: Fri, 01 Aug 2008 09:08:09 -0400 Subject: IRC logging of #openjdk In-Reply-To: <489204FC.6040704@matzon.dk> References: <20080731160001.F27D15B97@eggemoggin.niobe.net> <489204FC.6040704@matzon.dk> Message-ID: Hello Brian, yes the responses were a little surprising to me as well. When I first read your proposal my reaction was "sure, why not". Then reading the responses from Mark, the Andrews and others on how we use the channel and the nature of communication there I started to think the spontaneity and free-form flow of the conversations are very valuable and it would be a pity if we lost that. Onno. On Jul 31, 2008, at 2:31 PM, Brian Matzon wrote: > Mark Reinhold wrote: >> I tend to agree with what Andrew, Mark, Mario, and Andrew have said. >> Logging an IRC channel turns it into a more formal, less spontaneous >> forum, and #openjdk has so far been pleasantly informal. >> > I must admit that I am a fair bit flabbergasted by the response so > far. It is the first time I have met such a "resistance" against > this service. > From the collective 45+ years of logs I have from different > channels, there has never been any change of behavior because > logging has been "enabled". > > However, it is not my choice on how to proceed - so I will of course > respect the opinions that have been voiced so far. > > Unless a gash of positive replies are inbound, I will assume that > the service is unwelcome and I will part the bot, and continue to > refrain from publishing the logs. > > Cheers > /matzon From David.Herron at Sun.COM Fri Aug 1 23: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 David.Herron at Sun.COM Fri Aug 1 23:18:45 2008 From: David.Herron at Sun.COM (David Herron) Date: Fri, 01 Aug 2008 16:18:45 -0700 Subject: Project Proposal: BSD port In-Reply-To: <489355A4.7050503@sun.com> References: <489355A4.7050503@sun.com> Message-ID: <489399D5.4030801@sun.com> 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/ > "Yes" 13949712720901ForOSX !!! From rob.ross at gmail.com Fri Aug 1 23: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 Sat Aug 2 00: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 rob.ross at gmail.com Sat Aug 2 00:30:40 2008 From: rob.ross at gmail.com (Rob Ross) Date: Fri, 1 Aug 2008 17:30:40 -0700 Subject: IRC logging of #openjdk In-Reply-To: References: <20080731160001.F27D15B97@eggemoggin.niobe.net> <489204FC.6040704@matzon.dk> Message-ID: <456572A2-0E66-4DE5-8D6E-EEFE860B097F@gmail.com> Interestingly enough, we had the same sort of experience with our local Java study group. The idea was suggested that we record our meetings as either a real-time web stream or for a video podcast. I thought it was a great idea, because members that couldn't physically make it might still be able to participate over the internet, and it would be a great archive of our discussions, and hopefully attract more people. But many others were uncomfortable with the idea, even when we discussed just recording audio only. They felt it would stifle their ability to speak freely. So it's not an uncommon human reaction. Rob On Aug 1, 2008, at 6:08 AM, Onno Kluyt wrote: > Hello Brian, > yes the responses were a little surprising to me as well. When I > first read your proposal my reaction was "sure, why not". Then > reading the responses from Mark, the Andrews and others on how we > use the channel and the nature of communication there I started to > think the spontaneity and free-form flow of the conversations are > very valuable and it would be a pity if we lost that. > > Onno. > > On Jul 31, 2008, at 2:31 PM, Brian Matzon wrote: > >> Mark Reinhold wrote: >>> I tend to agree with what Andrew, Mark, Mario, and Andrew have said. >>> Logging an IRC channel turns it into a more formal, less spontaneous >>> forum, and #openjdk has so far been pleasantly informal. >>> >> I must admit that I am a fair bit flabbergasted by the response so >> far. It is the first time I have met such a "resistance" against >> this service. >> From the collective 45+ years of logs I have from different >> channels, there has never been any change of behavior because >> logging has been "enabled". >> >> However, it is not my choice on how to proceed - so I will of >> course respect the opinions that have been voiced so far. >> >> Unless a gash of positive replies are inbound, I will assume that >> the service is unwelcome and I will part the bot, and continue to >> refrain from publishing the logs. >> >> Cheers >> /matzon > From Bradford.Wetmore at Sun.COM Sat Aug 2 00:44:08 2008 From: Bradford.Wetmore at Sun.COM (Brad Wetmore) Date: Fri, 01 Aug 2008 17:44:08 -0700 Subject: Project Proposal: BSD port In-Reply-To: <489355A4.7050503@sun.com> References: <489355A4.7050503@sun.com> Message-ID: <4893ADD8.1010105@sun.com> You still around? brad 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/ > From volker.simonis at gmail.com Sat Aug 2 08: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 martinrb at google.com Sat Aug 2 18: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 Dalibor.Topic at Sun.COM Sun Aug 3 17: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 18: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 Xiomara.Jayasena at Sun.COM Mon Aug 4 23:52:29 2008 From: Xiomara.Jayasena at Sun.COM (Xiomara.Jayasena at Sun.COM) Date: Mon, 04 Aug 2008 16:52:29 -0700 Subject: JDK 7 build 32 is available at the openjdk.java.net website Message-ID: <4897963D.6030103@Sun.COM> The OpenJDK source is available at: http://hg.openjdk.java.net/jdk7/jdk7 http://hg.openjdk.java.net/jdk7/jdk7/rev/64da805be725 The OpenJDK source binary plugs for the promoted JDK 7 build 32 are available under the openjdk http://openjdk.java.net website under Source Code (direct link to bundles: http://download.java.net/openjdk/jdk7) Summary of changes: http://download.java.net/jdk7/changes/jdk7-b32.html -Xiomara From kurt at intricatesoftware.com Tue Aug 5 10: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 18: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 22: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 23: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 Kelly.Ohair at Sun.COM Wed Aug 6 16: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 swingler at apple.com Wed Aug 6 16: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 volker.simonis at gmail.com Thu Aug 7 19: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 openjdk at jazillian.com Thu Aug 7 21:44:15 2008 From: openjdk at jazillian.com (Andy Tripp) Date: Thu, 07 Aug 2008 17:44:15 -0400 Subject: challenge question Message-ID: <489B6CAF.9090105@jazillian.com> The Challenge page http://openjdk.java.net/challenge/says: > At the conclusion of the project phase, the Judges will rank the completed projects by the degree of successful completion, the technical merit of the implementation, and the value of the completed project to the community. Will there really be a ranking of completed projects, since the prize money is the same for each? If so, will Sun list the rankings? I'm not requesting that this be done, I'm just curious. I would like to request, though, that Sun post something about the results. Even if it's nothing more than saying something like "all projects were judged to be 'complete' and conformed to the rules". Andy From neugens at limasoftware.net Fri Aug 8 11:58:49 2008 From: neugens at limasoftware.net (Mario Torre) Date: Fri, 08 Aug 2008 13:58:49 +0200 Subject: challenge question In-Reply-To: <489B6CAF.9090105@jazillian.com> References: <489B6CAF.9090105@jazillian.com> Message-ID: <1218196729.3658.5.camel@nirvana> Il giorno gio, 07/08/2008 alle 17.44 -0400, Andy Tripp ha scritto: > The Challenge page http://openjdk.java.net/challenge/says: > > > At the conclusion of the project phase, the Judges will rank the completed projects by the degree of successful completion, the technical merit of the implementation, and the value of the completed project to the community. > > Will there really be a ranking of completed projects, since the prize money is the same for each? > If so, will Sun list the rankings? I'm not requesting that this be done, I'm just curious. > > I would like to request, though, that Sun post something about the results. > Even if it's nothing more than saying something like "all projects were judged to be 'complete' and > conformed to the rules". > > Andy We are not even yet judged! I would be against a ranking if the project all equally succeed. I would instead be personally happy to receive impressions and suggestions for the projects, because I think the real goal should be to improve the OpenJDK code base, not just get the money and forget :) Cheers, Mario From neal at gafter.com Fri Aug 8 14:53:09 2008 From: neal at gafter.com (Neal Gafter) Date: Fri, 8 Aug 2008 07:53:09 -0700 Subject: challenge question In-Reply-To: <1218196729.3658.5.camel@nirvana> References: <489B6CAF.9090105@jazillian.com> <1218196729.3658.5.camel@nirvana> Message-ID: <15e8b9d20808080753s690bcd9flc4a85b6a1c934aa5@mail.gmail.com> I think they may have to rank, as only 6 projects sent a completion announcement, and the official rules do no pay evenly in case there are fewer than 7 completed projects. -Neal On Fri, Aug 8, 2008 at 4:58 AM, Mario Torre wrote: > Il giorno gio, 07/08/2008 alle 17.44 -0400, Andy Tripp ha scritto: > > The Challenge page http://openjdk.java.net/challenge/says: > > > > > At the conclusion of the project phase, the Judges will rank the > completed projects by the degree of successful completion, the technical > merit of the implementation, and the value of the completed project to the > community. > > > > Will there really be a ranking of completed projects, since the prize > money is the same for each? > > If so, will Sun list the rankings? I'm not requesting that this be done, > I'm just curious. > > > > I would like to request, though, that Sun post something about the > results. > > Even if it's nothing more than saying something like "all projects were > judged to be 'complete' and > > conformed to the rules". > > > > Andy > > We are not even yet judged! > > I would be against a ranking if the project all equally succeed. > > I would instead be personally happy to receive impressions and > suggestions for the projects, because I think the real goal should be to > improve the OpenJDK code base, not just get the money and forget :) > > Cheers, > Mario > > From gnu_andrew at member.fsf.org Fri Aug 8 15: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 Xiomara.Jayasena at Sun.COM Fri Aug 15 00:40:03 2008 From: Xiomara.Jayasena at Sun.COM (Xiomara Jayasena) Date: Thu, 14 Aug 2008 17:40:03 -0700 Subject: JDK 7 build 33 is available at the openjdk.java.net website Message-ID: <48A4D063.7070205@sun.com> The OpenJDK source is available at: http://hg.openjdk.java.net/jdk7/jdk7 http://hg.openjdk.java.net/jdk7/jdk7/rev/bb1ef4ee3d2c The OpenJDK source binary plugs for the promoted JDK 7 build 33 are available under the openjdk http://openjdk.java.net website under Source Code (direct link to bundles: http://download.java.net/openjdk/jdk7) Summary of changes: http://download.java.net/jdk7/changes/jdk7-b33.html -Xiomara From Ray.Gans at Sun.COM Tue Aug 19 20:34:22 2008 From: Ray.Gans at Sun.COM (Ray Gans) Date: Tue, 19 Aug 2008 13:34:22 -0700 Subject: challenge question In-Reply-To: <15e8b9d20808080753s690bcd9flc4a85b6a1c934aa5@mail.gmail.com> References: <489B6CAF.9090105@jazillian.com> <1218196729.3658.5.camel@nirvana> <15e8b9d20808080753s690bcd9flc4a85b6a1c934aa5@mail.gmail.com> Message-ID: You are correct Neal. We will let the winners know shortly and public announcement will occur in conjunction with the other Sun Innovation Awards announcements. Stay tuned. ;-) -Ray On Aug 8, 2008, at 7:53 AM, Neal Gafter wrote: > I think they may have to rank, as only 6 projects sent a completion > announcement, and the official rules do no pay evenly in case there > are > fewer than 7 completed projects. > > -Neal > > On Fri, Aug 8, 2008 at 4:58 AM, Mario Torre > wrote: > >> Il giorno gio, 07/08/2008 alle 17.44 -0400, Andy Tripp ha scritto: >>> The Challenge page http://openjdk.java.net/challenge/says: >>> >>>> At the conclusion of the project phase, the Judges will rank the >> completed projects by the degree of successful completion, the >> technical >> merit of the implementation, and the value of the completed project >> to the >> community. >>> >>> Will there really be a ranking of completed projects, since the >>> prize >> money is the same for each? >>> If so, will Sun list the rankings? I'm not requesting that this be >>> done, >> I'm just curious. >>> >>> I would like to request, though, that Sun post something about the >> results. >>> Even if it's nothing more than saying something like "all projects >>> were >> judged to be 'complete' and >>> conformed to the rules". >>> >>> Andy >> >> We are not even yet judged! >> >> I would be against a ranking if the project all equally succeed. >> >> I would instead be personally happy to receive impressions and >> suggestions for the projects, because I think the real goal should >> be to >> improve the OpenJDK code base, not just get the money and forget :) >> >> Cheers, >> Mario >> >> From Ray.Gans at Sun.COM Mon Aug 25 20:02:43 2008 From: Ray.Gans at Sun.COM (Ray Gans) Date: Mon, 25 Aug 2008 13:02:43 -0700 Subject: MarkMail for OpenJDK Message-ID: The good folks at MarkMail have indexed our openjdk mailing lists as part of their service. This provides us with a nice web GUI to search our mail archives. Check it out: http://openjdk.markmail.org/ http://openjdk.markmail.org/search/?q= If you're unfamiliar with MarkMail, click the "?" next to the search box to get some information about how to refine your searches. -Ray From Weijun.Wang at Sun.COM Tue Aug 26 00:12:34 2008 From: Weijun.Wang at Sun.COM (Max (Weijun) Wang) Date: Tue, 26 Aug 2008 08:12:34 +0800 Subject: MarkMail for OpenJDK In-Reply-To: References: Message-ID: The links in the filter pane (what? who?) do not work in Firefox? On Aug 26, 2008, at 4:02 AM, Ray Gans wrote: > The good folks at MarkMail have indexed our openjdk mailing lists as > part of their service. This provides us with a nice web GUI to > search our mail archives. > > Check it out: > > http://openjdk.markmail.org/ > > http://openjdk.markmail.org/search/?q= > > If you're unfamiliar with MarkMail, click the "?" next to the search > box to get some information about how to refine your searches. > > -Ray From Weijun.Wang at Sun.COM Tue Aug 26 00:36:14 2008 From: Weijun.Wang at Sun.COM (Max (Weijun) Wang) Date: Tue, 26 Aug 2008 08:36:14 +0800 Subject: MarkMail for OpenJDK In-Reply-To: References: Message-ID: <89CDDFFB-34C0-48E3-B665-289194784F93@sun.com> Find the reason, I disabled Flash. -Max On Aug 26, 2008, at 8:12 AM, Max (Weijun) Wang wrote: > The links in the filter pane (what? who?) do not work in Firefox? > > On Aug 26, 2008, at 4:02 AM, Ray Gans wrote: > >> The good folks at MarkMail have indexed our openjdk mailing lists >> as part of their service. This provides us with a nice web GUI to >> search our mail archives. >> >> Check it out: >> >> http://openjdk.markmail.org/ >> >> http://openjdk.markmail.org/search/?q= >> >> If you're unfamiliar with MarkMail, click the "?" next to the >> search box to get some information about how to refine your searches. >> >> -Ray > From Xiomara.Jayasena at Sun.COM Fri Aug 29 00:43:10 2008 From: Xiomara.Jayasena at Sun.COM (Xiomara Jayasena) Date: Thu, 28 Aug 2008 17:43:10 -0700 Subject: JDK 7 build 34 is available at the openjdk.java.net website Message-ID: <48B7461E.6060809@sun.com> The OpenJDK source is available at: http://hg.openjdk.java.net/jdk7/jdk7 http://hg.openjdk.java.net/jdk7/jdk7/rev/46a989ab9329 The OpenJDK source binary plugs for the promoted JDK 7 build 34 are available under the openjdk http://openjdk.java.net website under Source Code (direct link to bundles: http://download.java.net/openjdk/jdk7) Summary of changes: http://download.java.net/jdk7/changes/jdk7-b34.html -Xiomara