From dfabulich at warpmail.net Wed May 9 06:39:32 2007 From: dfabulich at warpmail.net (Dan Fabulich) Date: Tue, 8 May 2007 23:39:32 -0700 (Pacific Daylight Time) Subject: Windows build bug, no bug number? Message-ID: As I just pointed out on the build-dev list, the buildable JDK doesn't build on Windows (missing t2k.lib). http://mail.openjdk.java.net/pipermail/build-dev/2007-May/000000.html I filed a bug on this, but bugs.sun.com doesn't issue bug numbers when you file bugs... instead, it puts your bug request in a moderation queue, with no way to directly monitor what's happening to it. That may have made sense before the JDK was open source, but I think that now it makes more sense to assign every bug report a bug number immediately upon submission, (even the bogus bug reports) for discussion purposes only. Thoughts? -Dan Fabulich From Phil.Race at Sun.COM Wed May 9 06:57:52 2007 From: Phil.Race at Sun.COM (Phil Race) Date: Tue, 08 May 2007 23:57:52 -0700 Subject: Windows build bug, no bug number? In-Reply-To: References: Message-ID: <464170F0.5000305@sun.com> Dan Fabulich wrote: > > As I just pointed out on the build-dev list, the buildable JDK doesn't > build on Windows (missing t2k.lib). It wasn't overlooked. I'm not on that build alias but the need for t2k.lib complicated matters as the binary builds used as the source of the plugs don't contain these. If you look for the make-closed-binaries target you'll see it builds a directory 'closed' which contains just the binary plug pieces. Rather than using that and having to put that out, the decision was made to use the full builds so we didn't have to add another download and complication. The tradeoff is windows doesn't build but that will be addressed by removing the dependency on t2k . > http://mail.openjdk.java.net/pipermail/build-dev/2007-May/000000.html > > I filed a bug on this, but bugs.sun.com doesn't issue bug numbers when > you file bugs... instead, it puts your bug request in a moderation > queue, with no way to directly monitor what's happening to it. > > That may have made sense before the JDK was open source, but I think > that now it makes more sense to assign every bug report a bug number > immediately upon submission, (even the bogus bug reports) for > discussion purposes only. There was contemplation of, at the very least, making unprocessed bug submissions public, even before openjdk came into the picture. So I expect this to happen - there are a ton of things that could still be done. -phil. From Tom.Marble at Sun.COM Wed May 9 08:15:03 2007 From: Tom.Marble at Sun.COM (Tom Marble) Date: Wed, 09 May 2007 03:15:03 -0500 Subject: Congratulations Gentoo! Message-ID: <46418307.6020801@sun.com> Betelgeuse: Wow! Congratulations! You posted this ebuild within 5 hours of code release! http://planet.gentoo.org/developers/betelgeuse/2007/05/08/openjdk_ebuild I told John Gage to mention it at the beginning of tomorrow's session http://java.sun.com/javaone/sf/sessions/general/index.jsp I knew you were enthusiastic, but this is simply amazing! Regards, --Tom From Tom.Marble at Sun.COM Wed May 9 08:16:06 2007 From: Tom.Marble at Sun.COM (Tom Marble) Date: Wed, 09 May 2007 03:16:06 -0500 Subject: Gmane gateway delayed Message-ID: <46418346.1030201@sun.com> All: I just want to apologize in advance that the Gmane gateway [1] will be out of sync for a little while until we can ask Lars to set up the new lists and migrate them to the new mailing list server. Thanks for your patience! Regards, --Tom [1] http://blogs.sun.com/tmarble/entry/gmane_for_openjdk From gbenson at redhat.com Wed May 9 10:15:57 2007 From: gbenson at redhat.com (Gary Benson) Date: Wed, 9 May 2007 11:15:57 +0100 Subject: Repository URLs Message-ID: <20070509101556.GJ3830@redhat.com> Hi all, Well, what a nice surprise to wake up to -- thanks Sun :) One minor nit -- the repository URLs on these pages are wrong: https://openjdk.dev.java.net/servlets/ProjectSource https://openjdk.dev.java.net/source/browse/openjdk They should be https://openjdk.dev.java.net/svn/openjdk/jdk/trunk ^^^ Ok, I'm off to have a play with it all... Cheers, Gary From betelgeuse at gentoo.org Wed May 9 11:06:06 2007 From: betelgeuse at gentoo.org (=?UTF-8?B?UGV0dGVyaSBSw6R0eQ==?=) Date: Wed, 09 May 2007 14:06:06 +0300 Subject: Congratulations Gentoo! In-Reply-To: <46418307.6020801@sun.com> References: <46418307.6020801@sun.com> Message-ID: <4641AB1E.6060809@gentoo.org> Tom Marble kirjoitti: > Betelgeuse: > > Wow! Congratulations! You posted this ebuild within > 5 hours of code release! > http://planet.gentoo.org/developers/betelgeuse/2007/05/08/openjdk_ebuild > It didn't take 5 hours to make the ebuild... :D Regards, Petteri -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature URL: From aph at redhat.com Wed May 9 11:56:16 2007 From: aph at redhat.com (Andrew Haley) Date: Wed, 9 May 2007 12:56:16 +0100 Subject: Building on Fedora 6 In-Reply-To: <20070509101556.GJ3830@redhat.com> References: <20070509101556.GJ3830@redhat.com> Message-ID: <17985.46816.842265.565325@zebedee.pink> openjdk-7-ea-src-b12-06_may_2007.zip built on Fedora Core 6 AMD64 with apparently no problems. Changes to jdk_generic_profile.sh control were needed as below: --- j2se/make/jdk_generic_profile.sh 2007-05-06 10:03:44.000000000 +0100 +++ control/jdk_generic_profile.sh 2007-05-09 11:06:18.000000000 +0100 @@ -109,8 +109,12 @@ fi export COMPUTERNAME +unset LD_LIBRARY_PATH +export LANG=C + # Boot jdk -bootjdk=jdk1.6.0 +bootjdk=jdk1.6.0_01 +ALT_CLOSED_JDK_IMPORT_PATH=/home/aph/openjdk/jdk1.7.0/ importjdk=jdk1.7.0 # Uses 'uname -s', but only expect SunOS or Linux, assume Windows otherwise. @@ -155,7 +159,7 @@ elif [ "${osname}" = Linux ] ; then # System place where JDK installed images are stored? - jdk_instances=/opt/java + jdk_instances=/usr/java # Use compilers from /usr/bin path4sdk=/usr/bin:/bin:/usr/sbin:/sbin Installed packages to satisfy the build requirements were: jdk-1.6.0_01-fcs cups-libs.x86_64 1:1.2.10-3.fc6 cups.x86_64 1:1.2.10-3.fc6 gnutls-devel.x86_64 1.4.1-2 cups-devel.i386 1:1.2.10-3.fc6 cups-devel.x86_64 1:1.2.10-3.fc6 libXp.i386 1.0.0-8 libXp-devel.i386 1.0.0-8 libXp-devel.x86_64 1.0.0-8 Andrew. -- Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK Registered in England and Wales No. 3798903 From aph at redhat.com Wed May 9 11:57:15 2007 From: aph at redhat.com (Andrew Haley) Date: Wed, 9 May 2007 12:57:15 +0100 Subject: Repository URLs Message-ID: <17985.46875.375413.718071@zebedee.pink> Gary Benson writes: > Hi all, > > Well, what a nice surprise to wake up to -- thanks Sun :) > > One minor nit -- the repository URLs on these pages are wrong: > > https://openjdk.dev.java.net/servlets/ProjectSource > https://openjdk.dev.java.net/source/browse/openjdk > > They should be https://openjdk.dev.java.net/svn/openjdk/jdk/trunk There's also a bad link in README-builds.html: https://openjdk.java.net/jtreg/ should be http://openjdk.java.net/jtreg/ Andrew. -- Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK Registered in England and Wales No. 3798903 From aph at redhat.com Wed May 9 12:03:02 2007 From: aph at redhat.com (Andrew Haley) Date: Wed, 9 May 2007 13:03:02 +0100 Subject: Building on Fedora 6 In-Reply-To: <17985.42893.809665.95128@zebedee.pink> References: <20070509101556.GJ3830@redhat.com> <17985.42893.809665.95128@zebedee.pink> Message-ID: <17985.47222.767406.158499@zebedee.pink> It's worth mentioning somewhere in the instructions that "make -j" doesn't work when building openjdk. The actual parallelism is supposed to be controlled by HOTSPOT_BUILD_JOBS, but it doesn't seem to be very effective. On a dual-processor box with HOTSPOT_BUILD_JOBS=4 I get: Control build finished: 07-05-09 13:00 1729.91user 166.63system 23:53.03elapsed 132%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (1002major+40812683minor)pagefaults 0swaps which is not bad, but it would be nice to increase the parallalism. Andrew. -- Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK Registered in England and Wales No. 3798903 From Phil.Race at Sun.COM Wed May 9 13:59:52 2007 From: Phil.Race at Sun.COM (Phil Race) Date: Wed, 09 May 2007 06:59:52 -0700 Subject: Building on Fedora 6 In-Reply-To: <17985.46816.842265.565325@zebedee.pink> References: <20070509101556.GJ3830@redhat.com> <17985.46816.842265.565325@zebedee.pink> Message-ID: <4641D3D8.8080401@sun.com> This very probably should be sent to the build-dev list instead but .. Andrew Haley wrote: > openjdk-7-ea-src-b12-06_may_2007.zip built on Fedora Core 6 AMD64 with > apparently no problems. Changes to jdk_generic_profile.sh control > were needed as below: > > --- j2se/make/jdk_generic_profile.sh 2007-05-06 10:03:44.000000000 +0100 > +++ control/jdk_generic_profile.sh 2007-05-09 11:06:18.000000000 +0100 > @@ -109,8 +109,12 @@ > fi > export COMPUTERNAME > > +unset LD_LIBRARY_PATH > We generally consider any shell setting of LD_LIBRARY_PATH to be evil I don't mean JDK I mean much more generally than that Having said that I haven't heard of it causing build problems before. What is the problem it caused you? +export LANG=C I think Kelly mentioned some problems in some locales .. is that what this is for? > + > # Boot jdk > -bootjdk=jdk1.6.0 > +bootjdk=jdk1.6.0_01 > +ALT_CLOSED_JDK_IMPORT_PATH=/home/aph/openjdk/jdk1.7.0/ > these are intended to be changed/set via envt variables passed to make -phil. > importjdk=jdk1.7.0 > > # Uses 'uname -s', but only expect SunOS or Linux, assume Windows otherwise. > @@ -155,7 +159,7 @@ > elif [ "${osname}" = Linux ] ; then > > # System place where JDK installed images are stored? > - jdk_instances=/opt/java > + jdk_instances=/usr/java > > # Use compilers from /usr/bin > path4sdk=/usr/bin:/bin:/usr/sbin:/sbin > > Installed packages to satisfy the build requirements were: > > jdk-1.6.0_01-fcs > cups-libs.x86_64 1:1.2.10-3.fc6 > cups.x86_64 1:1.2.10-3.fc6 > gnutls-devel.x86_64 1.4.1-2 > cups-devel.i386 1:1.2.10-3.fc6 > cups-devel.x86_64 1:1.2.10-3.fc6 > libXp.i386 1.0.0-8 > libXp-devel.i386 1.0.0-8 > libXp-devel.x86_64 1.0.0-8 > > Andrew. > > From david.gilbert at object-refinery.com Wed May 9 15:05:12 2007 From: david.gilbert at object-refinery.com (David Gilbert) Date: Wed, 09 May 2007 16:05:12 +0100 Subject: Regression tests Message-ID: <4641E328.7090803@object-refinery.com> Hi, I've got a fix for a bug in Swing (bug 6463712, related to the JSpinner component) and have written a regression test that can be run using jtreg. Now I'm looking to run some other regression tests to validate my fix before submitting a patch. My understanding is that the available regression tests are in the OpenJDK source bundle in the 'j2se/test' directory...but there is nothing there for 'javax.swing.*'. Elsewhere (on the 2d-dev list) Phil Race said: > Regression tests - these are in the JDK under test but we are required > to vet them almost one by one to verify their provenance and this is > onerous. So most are not there yet. Is there a plan for getting these tests out? Just asking for information, I know you're busy... In the mean time, I'll run checks with Mauve, then I guess I should just submit the patch? Regards, Dave Gilbert http://www.jfree.org/ From dfabulich at warpmail.net Wed May 9 16:00:57 2007 From: dfabulich at warpmail.net (Dan Fabulich) Date: Wed, 9 May 2007 09:00:57 -0700 (Pacific Daylight Time) Subject: Windows build bug, no bug number? In-Reply-To: <464170F0.5000305@sun.com> References: <464170F0.5000305@sun.com> Message-ID: Phil Race wrote: > Dan Fabulich wrote: >> >> As I just pointed out on the build-dev list, the buildable JDK doesn't >> build on Windows (missing t2k.lib). > It wasn't overlooked. > I'm not on that build alias but the need for t2k.lib complicated matters > as the binary builds used as the source of the plugs don't contain > these. If you look for the make-closed-binaries target you'll see it > builds a directory 'closed' which contains just the binary plug pieces. > Rather than using that and having to put that out, the decision was made > to use the full builds so we didn't have to add another download and > complication. > > The tradeoff is windows doesn't build but that will be addressed by > removing the dependency on t2k . I'm not sure I quite understand that decision. Why provide binary plugs on Windows at all if we're not providing the binary files necessary to build the OpenJDK? It also sounds like this decision means that we don't intend to fix the Windows binary plugs, but simply wait until the binary plugs are no longer necessary. But replacing t2k could take months of hard effort. Wouldn't it be easier to release a new binary plug archive with the necessary files? Or even just to provide the necessary files as a separate download? I realize that this is more "complicated," but I think we all agree that it's better to have a complicated build that works than an uncomplicated build that doesn't work! :-) -Dan From aph at redhat.com Wed May 9 16:43:36 2007 From: aph at redhat.com (Andrew Haley) Date: Wed, 9 May 2007 17:43:36 +0100 Subject: Building on Fedora 6 In-Reply-To: <4641D3D8.8080401@sun.com> References: <20070509101556.GJ3830@redhat.com> <17985.46816.842265.565325@zebedee.pink> <4641D3D8.8080401@sun.com> Message-ID: <17985.64056.890139.107208@zebedee.pink> Phil Race writes: > This very probably should be sent to the build-dev list instead but .. > > > Andrew Haley wrote: > > openjdk-7-ea-src-b12-06_may_2007.zip built on Fedora Core 6 AMD64 with > > apparently no problems. Changes to jdk_generic_profile.sh control > > were needed as below: > > > > --- j2se/make/jdk_generic_profile.sh 2007-05-06 10:03:44.000000000 +0100 > > +++ control/jdk_generic_profile.sh 2007-05-09 11:06:18.000000000 +0100 > > @@ -109,8 +109,12 @@ > > fi > > export COMPUTERNAME > > > > +unset LD_LIBRARY_PATH > > > > We generally consider any shell setting of LD_LIBRARY_PATH to be evil > I don't mean JDK I mean much more generally than that > Having said that I haven't heard of it causing build problems before. > What is the problem it caused you? None at all, except that the sanity check whined about it. > +export LANG=C > I think Kelly mentioned some problems in some locales .. is that what > this is for? As above. > > + > > # Boot jdk > > -bootjdk=jdk1.6.0 > > +bootjdk=jdk1.6.0_01 > > +ALT_CLOSED_JDK_IMPORT_PATH=/home/aph/openjdk/jdk1.7.0/ > > these are intended to be changed/set via envt variables passed to make Well, yes, but dk_generic_profile.sh sets those environment variables. I'm presuming that you're not saying that there should be yet another variable-setting script that should be run before running this script. :-) Andrew. -- Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK Registered in England and Wales No. 3798903 From Kelly.Ohair at Sun.COM Wed May 9 16:57:52 2007 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Wed, 09 May 2007 09:57:52 -0700 Subject: Building on Fedora 6 In-Reply-To: <17985.64056.890139.107208@zebedee.pink> References: <20070509101556.GJ3830@redhat.com> <17985.46816.842265.565325@zebedee.pink> <4641D3D8.8080401@sun.com> <17985.64056.890139.107208@zebedee.pink> Message-ID: <4641FD90.2070208@sun.com> Adding the unset LD_LIBRARY_PATH and the export LANG=C to this file makse sense, I'll take care of that. This .sh file is only for use when building the jdk, so it seems reasonable to change this file. The LANG setting is necessary to prevent builds from getting locked into the wrong locale, I forget the details, but builds with ja locale fail as I recall, and I decided that only C locale builds made sense. The LD_LIBRARY_PATH unset might be a problem for some, not for me, but in general you don't want stray libraries loaded from this PATH. The build should only rely on the libraries in /lib and /usr/lib. There have been numerous build failures in the past related to this. The ALT_CLOSED_JDK_IMPORT_PATH setting is something that depends on where the binary plugs got downloaded, so it depends on the builder. It was intended that this be manually set and specifically, it needs to be pointing at one of the Binary Plugs provided on the openjdk.java.net site. Legal issues involved here, e.g. great pains. :^( A builder could just add this one to their own ENV variables, or create a my_jdk_profile.sh file that just does: . j2se/make/jdk_generic_profile.sh export ALT_CLOSED_JDK_IMPORT_PATH=/home/aph/openjdk/jdk1.7.0/ Hope this helps. When JavaOne is over and I recover from all this openjsk mania, I'll get the LANG/LD_LIBRARY_PATH changes in. -kto Andrew Haley wrote: > Phil Race writes: > > This very probably should be sent to the build-dev list instead but .. > > > > > > Andrew Haley wrote: > > > openjdk-7-ea-src-b12-06_may_2007.zip built on Fedora Core 6 AMD64 with > > > apparently no problems. Changes to jdk_generic_profile.sh control > > > were needed as below: > > > > > > --- j2se/make/jdk_generic_profile.sh 2007-05-06 10:03:44.000000000 +0100 > > > +++ control/jdk_generic_profile.sh 2007-05-09 11:06:18.000000000 +0100 > > > @@ -109,8 +109,12 @@ > > > fi > > > export COMPUTERNAME > > > > > > +unset LD_LIBRARY_PATH > > > > > > > We generally consider any shell setting of LD_LIBRARY_PATH to be evil > > I don't mean JDK I mean much more generally than that > > Having said that I haven't heard of it causing build problems before. > > What is the problem it caused you? > > None at all, except that the sanity check whined about it. > > > +export LANG=C > > I think Kelly mentioned some problems in some locales .. is that what > > this is for? > > As above. > > > > + > > > # Boot jdk > > > -bootjdk=jdk1.6.0 > > > +bootjdk=jdk1.6.0_01 > > > +ALT_CLOSED_JDK_IMPORT_PATH=/home/aph/openjdk/jdk1.7.0/ > > > > these are intended to be changed/set via envt variables passed to make > > Well, yes, but dk_generic_profile.sh sets those environment variables. > I'm presuming that you're not saying that there should be yet another > variable-setting script that should be run before running this script. > :-) > > Andrew. > From aph at redhat.com Wed May 9 17:04:14 2007 From: aph at redhat.com (Andrew Haley) Date: Wed, 9 May 2007 18:04:14 +0100 Subject: Building on Fedora 6 In-Reply-To: <4641FD90.2070208@sun.com> References: <20070509101556.GJ3830@redhat.com> <17985.46816.842265.565325@zebedee.pink> <4641D3D8.8080401@sun.com> <17985.64056.890139.107208@zebedee.pink> <4641FD90.2070208@sun.com> Message-ID: <17985.65294.281233.214824@zebedee.pink> Kelly O'Hair writes: > Adding the unset LD_LIBRARY_PATH and the export LANG=C to this file > makse sense, I'll take care of that. This .sh file is only for use when > building the jdk, so it seems reasonable to change this file. > > The LANG setting is necessary to prevent builds from getting locked > into the wrong locale, I forget the details, but builds with ja locale > fail as I recall, and I decided that only C locale builds made sense. > > The LD_LIBRARY_PATH unset might be a problem for some, not for me, but > in general you don't want stray libraries loaded from this PATH. > The build should only rely on the libraries in /lib and /usr/lib. > There have been numerous build failures in the past related to this. > > The ALT_CLOSED_JDK_IMPORT_PATH setting is something that depends on where > the binary plugs got downloaded, so it depends on the builder. > It was intended that this be manually set and specifically, it needs to be > pointing at one of the Binary Plugs provided on the openjdk.java.net site. > Legal issues involved here, e.g. great pains. :^( Which reminds me: is there any need for JDK 1.6 in all of this? The openjdk-7-ea-src-b12-06_may_2007.zip used as the source of the "binary blobs" is a full JDK, is it not? So it could be used as the bootstrap JDK -- there's no need for JDK 1.6. Andrew. -- Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK Registered in England and Wales No. 3798903 From Kelly.Ohair at Sun.COM Wed May 9 23:11:20 2007 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Wed, 09 May 2007 16:11:20 -0700 Subject: Building on Fedora 6 In-Reply-To: <17985.65294.281233.214824@zebedee.pink> References: <20070509101556.GJ3830@redhat.com> <17985.46816.842265.565325@zebedee.pink> <4641D3D8.8080401@sun.com> <17985.64056.890139.107208@zebedee.pink> <4641FD90.2070208@sun.com> <17985.65294.281233.214824@zebedee.pink> Message-ID: <46425518.6020900@sun.com> Andrew Haley wrote: > Kelly O'Hair writes: > > Adding the unset LD_LIBRARY_PATH and the export LANG=C to this file > > makse sense, I'll take care of that. This .sh file is only for use when > > building the jdk, so it seems reasonable to change this file. > > > > The LANG setting is necessary to prevent builds from getting locked > > into the wrong locale, I forget the details, but builds with ja locale > > fail as I recall, and I decided that only C locale builds made sense. > > > > The LD_LIBRARY_PATH unset might be a problem for some, not for me, but > > in general you don't want stray libraries loaded from this PATH. > > The build should only rely on the libraries in /lib and /usr/lib. > > There have been numerous build failures in the past related to this. > > > > The ALT_CLOSED_JDK_IMPORT_PATH setting is something that depends on where > > the binary plugs got downloaded, so it depends on the builder. > > It was intended that this be manually set and specifically, it needs to be > > pointing at one of the Binary Plugs provided on the openjdk.java.net site. > > Legal issues involved here, e.g. great pains. :^( > > Which reminds me: is there any need for JDK 1.6 in all of this? The > openjdk-7-ea-src-b12-06_may_2007.zip used as the source of the "binary > blobs" is a full JDK, is it not? So it could be used as the bootstrap > JDK -- there's no need for JDK 1.6. > Officially, we boot from the previous FCS jdk (1.6.0), unofficially, jdk 1.5 or jdk 1.7 would work as a boot jdk. I suppose it may become an issue later if we somehow become dependent on a jdk 1.6 feature that jdk 1.5 won't work, but I don't know of any issue like that on the horizon. A jdk 1.5 might be already available on your system. Using a boot of jdk 1.7 may have some risks, but should in general work. Note that the "binary plugs" are indeed full jdk 7 images right now, but none of the files will have execute permissions. The binary plugs are distributed with a different license that allows their use as 'binary plugs'. I'd probably keep the binary plugs separate from the boot jdk, but that's just me. Also the binary plugs will need to be updated every time you freshen up your openjdk sources, the boot jdk is a pretty static thing. -kto > Andrew. > From dfabulich at warpmail.net Thu May 10 04:45:13 2007 From: dfabulich at warpmail.net (Dan Fabulich) Date: Wed, 9 May 2007 21:45:13 -0700 (Pacific Daylight Time) Subject: read-only svn and interim fixes Message-ID: I'm confused about how exactly development is supposed to work on OpenJDK in the period between now and when OpenJDK goes live with Mercurial. Specifically, it seems 1) It's going to be a while before Mercurial is available 2) Sun developers are going to continue to check in changes in the meantime 3) The OpenJDK svn server is read-only, even to Sun developers, so no changes will appear there Are we going to get a "big bang" of trunk code once Mercurial goes live? I began wondering about this in the course of discussion on the build-dev list about the critical bug in the Windows binary plugs that makes it impossible to do the build on Windows (missing t2k.lib). [Tim Bell filed bug 6555215, but it is not yet visible on bugs.sun.com.] Phil Rice suggested that the best thing would be to just finish the ongoing work to replace t2k with something like freetype. That makes some sense, but even if that work were done tomorrow, I'd have no way of getting access to those fixes, which sound like they might be pretty substantial. Will I just have to wait until Mercurial to see those fixes? (If so, won't that be potentially a lot of fixes?) If not, how would I get access to incremental changes between now and then? -Dan From Phil.Race at Sun.COM Thu May 10 04:53:34 2007 From: Phil.Race at Sun.COM (Phil Race) Date: Wed, 09 May 2007 21:53:34 -0700 Subject: read-only svn and interim fixes In-Reply-To: References: Message-ID: <4642A54E.8000807@sun.com> Changes will continue to go in to our internal workspace, although the time affter J1 is often relatively quiet. Every week (or so) that we create a new binary build for the web we'll also put out the equivalent opemjdk source bundle. We may even continue to do that once mercurial is available .. not sure we've thought that far ahead. Anyway it could be a bit of a race (not rice :)) as to whether freetype or mercurial is done first. -phil. Dan Fabulich wrote: > > I'm confused about how exactly development is supposed to work on > OpenJDK in the period between now and when OpenJDK goes live with > Mercurial. > > Specifically, it seems > > 1) It's going to be a while before Mercurial is available > 2) Sun developers are going to continue to check in changes in the > meantime > 3) The OpenJDK svn server is read-only, even to Sun developers, so no > changes will appear there > > Are we going to get a "big bang" of trunk code once Mercurial goes live? > > I began wondering about this in the course of discussion on the > build-dev list about the critical bug in the Windows binary plugs that > makes it impossible to do the build on Windows (missing t2k.lib). > [Tim Bell filed bug 6555215, but it is not yet visible on bugs.sun.com.] > > Phil Rice suggested that the best thing would be to just finish the > ongoing work to replace t2k with something like freetype. That makes > some sense, but even if that work were done tomorrow, I'd have no way > of getting access to those fixes, which sound like they might be > pretty substantial. > > Will I just have to wait until Mercurial to see those fixes? (If so, > won't that be potentially a lot of fixes?) If not, how would I get > access to incremental changes between now and then? > > -Dan From neugens at limasoftware.net Thu May 10 11:05:24 2007 From: neugens at limasoftware.net (Mario Torre) Date: Thu, 10 May 2007 13:05:24 +0200 Subject: Building on Fedora 6 Message-ID: <1178795124.4642fc7442eb4@cp.tophost.it> Hello! I've sent this to build-dev too. I have some troubles with the dns and these lists so sorry for double/cross postings. I had some troubles building OpenJDK on Fedora, because it needs openmotif, while on fedora there is only lesstif available. This was not a problem with the build itself, but with the sanity check. I had to apply this patch in order to pass the sanity check on my system. The patch simply checks for the real included file in the awt code, I hope it is useful to everyone. Ciao, Mario -- Lima Software - http://www.limasoftware.net/ GNU Classpath Developer - http://www.classpath.org/ Jabber: neugens at jabber.org - Profile: http://www.gtalkprofile.com/profile/9661.html pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF Please, support open standards: http://opendocumentfellowship.org/petition/ http://www.nosoftwarepatents.com/ ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. -------------- next part -------------- A non-text attachment was scrubbed... Name: build.patch Type: text/x-patch Size: 661 bytes Desc: not available URL: From aph at redhat.com Thu May 10 11:05:55 2007 From: aph at redhat.com (Andrew Haley) Date: Thu, 10 May 2007 12:05:55 +0100 Subject: Building on Fedora 6 In-Reply-To: <46425518.6020900@sun.com> References: <20070509101556.GJ3830@redhat.com> <17985.46816.842265.565325@zebedee.pink> <4641D3D8.8080401@sun.com> <17985.64056.890139.107208@zebedee.pink> <4641FD90.2070208@sun.com> <17985.65294.281233.214824@zebedee.pink> <46425518.6020900@sun.com> Message-ID: <17986.64659.451226.280513@zebedee.pink> Kelly O'Hair writes: > Andrew Haley wrote: > > Which reminds me: is there any need for JDK 1.6 in all of this? > > The openjdk-7-ea-src-b12-06_may_2007.zip used as the source of > > the "binary blobs" is a full JDK, is it not? So it could be used > > as the bootstrap JDK -- there's no need for JDK 1.6. > > > > Officially, we boot from the previous FCS jdk (1.6.0), unofficially, > jdk 1.5 or jdk 1.7 would work as a boot jdk. > I suppose it may become an issue later if we somehow become dependent > on a jdk 1.6 feature that jdk 1.5 won't work, but I don't know of any > issue like that on the horizon. A jdk 1.5 might be already available > on your system. > > Using a boot of jdk 1.7 may have some risks, but should in general > work. > Note that the "binary plugs" are indeed full jdk 7 images right now, > but none of the files will have execute permissions. OK, so I had to chmod -R +x /home/aph/openjdk/jdk1.7.0//bin > The binary plugs are distributed with a different license that allows > their use as 'binary plugs'. I'd probably keep the binary plugs > separate from the boot jdk, but that's just me. > Also the binary plugs will need to be updated every time you freshen > up your openjdk sources, the boot jdk is a pretty static thing. OK. Anyway, this works Just Fine. It's only necessary for developers on GNU/Linux to download jdk-7-ea-plug-b12-linux-amd64-06_may_2007.jar and openjdk-7-ea-src-b12-06_may_2007.zip: gcj is quite capable of running the self-extracting Jar file. Andrew. -- Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK Registered in England and Wales No. 3798903 From kurt at intricatesoftware.com Thu May 10 17:52:02 2007 From: kurt at intricatesoftware.com (Kurt Miller) Date: Thu, 10 May 2007 13:52:02 -0400 Subject: OpenJDK Defend & Indemnify Clauses Message-ID: <46435BC2.9000708@intricatesoftware.com> OpenJDK binaries that have been built with the 'binary plugs' components are governed by two licenses[1]; GPLv2 and the 'Binary License for OpenJDK'. Free and open source projects distributing OpenJDK binary packages should be aware that the 'Binary License for OpenJDK' contains defend and indemnify clauses that may be unacceptable to them [2]. The intent of this email is to raise awareness of the licensing issues associated with the distribution of OpenJDK binary packages and to highlight the importance of replacing the remaining encumbered parts with open-source alternatives. The encumbered parts need to be replaced before a fully GPLv2 binary package can be distributed. [1] The ASSEMBLY_EXCEPTION license (http://openjdk.java.net/legal/assembly-exception.html) explains that the resulting binaries are governed by both the GPL2 *and* the license that the Designated Exception Modules uses. The 'binary plugs' components are a Designated Exception Module. [2] http://openjdk.java.net/legal/binary-license-2007-05-08.html Paragraph 2. (b) (v) From Weijun.Wang at Sun.COM Fri May 11 06:50:10 2007 From: Weijun.Wang at Sun.COM (Max (Weijun) Wang) Date: Fri, 11 May 2007 14:50:10 +0800 Subject: Building on Fedora 6 In-Reply-To: <17986.64659.451226.280513@zebedee.pink> References: <20070509101556.GJ3830@redhat.com> <17985.46816.842265.565325@zebedee.pink> <4641D3D8.8080401@sun.com> <17985.64056.890139.107208@zebedee.pink> <4641FD90.2070208@sun.com> <17985.65294.281233.214824@zebedee.pink> <46425518.6020900@sun.com> <17986.64659.451226.280513@zebedee.pink> Message-ID: My 2 cents: It's called "binary plugs", which means it's used to provide binaries for those components whose sources are not included in the OpenJDK yet. So, even today it looks like a full JDK, tomorrow you may see it includes only several jars and native libraries, and then one day, it will disappear completely. Thanks Max On 2007-5-10, at 19:05, Andrew Haley wrote: > Kelly O'Hair writes: > >> Andrew Haley wrote: > >>> Which reminds me: is there any need for JDK 1.6 in all of this? >>> The openjdk-7-ea-src-b12-06_may_2007.zip used as the source of >>> the "binary blobs" is a full JDK, is it not? So it could be used >>> as the bootstrap JDK -- there's no need for JDK 1.6. >>> >> >> Officially, we boot from the previous FCS jdk (1.6.0), unofficially, >> jdk 1.5 or jdk 1.7 would work as a boot jdk. >> I suppose it may become an issue later if we somehow become dependent >> on a jdk 1.6 feature that jdk 1.5 won't work, but I don't know of any >> issue like that on the horizon. A jdk 1.5 might be already available >> on your system. >> >> Using a boot of jdk 1.7 may have some risks, but should in general >> work. >> Note that the "binary plugs" are indeed full jdk 7 images right now, >> but none of the files will have execute permissions. > > OK, so I had to > > chmod -R +x /home/aph/openjdk/jdk1.7.0//bin > >> The binary plugs are distributed with a different license that allows >> their use as 'binary plugs'. I'd probably keep the binary plugs >> separate from the boot jdk, but that's just me. >> Also the binary plugs will need to be updated every time you freshen >> up your openjdk sources, the boot jdk is a pretty static thing. > > OK. > > Anyway, this works Just Fine. It's only necessary for developers on > GNU/Linux to download jdk-7-ea-plug-b12-linux-amd64-06_may_2007.jar > and openjdk-7-ea-src-b12-06_may_2007.zip: gcj is quite capable of > running the self-extracting Jar file. > > Andrew. > > -- > Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, > Berkshire, SL4 1TE, UK > Registered in England and Wales No. 3798903 From olaf at libero.it Fri May 11 08:04:03 2007 From: olaf at libero.it (Olaf Razzoli) Date: Fri, 11 May 2007 10:04:03 +0200 Subject: missing JRE parts Message-ID: <46442373.10409@libero.it> First of all, thanks to Sun for the important steps into the open source world. After spending some time searching in the source code, it seems that Java Web Start and the web browser Plugin technology are missing. I know they are part of the JRE, and Sun open sourced JDK, but I thought they are necessary to build a complete open source java distribution. I would like to know if and when the source code is supposed to be released. Thanks in advance Olaf From aph at redhat.com Fri May 11 11:34:57 2007 From: aph at redhat.com (Andrew Haley) Date: Fri, 11 May 2007 12:34:57 +0100 Subject: Building on Fedora 6 In-Reply-To: References: <20070509101556.GJ3830@redhat.com> <17985.46816.842265.565325@zebedee.pink> <4641D3D8.8080401@sun.com> <17985.64056.890139.107208@zebedee.pink> <4641FD90.2070208@sun.com> <17985.65294.281233.214824@zebedee.pink> <46425518.6020900@sun.com> <17986.64659.451226.280513@zebedee.pink> Message-ID: <17988.21729.292266.844427@zebedee.pink> Max (Weijun) Wang writes: > My 2 cents: > > It's called "binary plugs", which means it's used to provide binaries > for those components whose sources are not included in the OpenJDK > yet. So, even today it looks like a full JDK, tomorrow you may see it > includes only several jars and native libraries, and then one day, it > will disappear completely. Sure, but it's just a way to solve the bootstrapping problem: once you've built a working JDK, you're not going to need the "binary plugs" any more. I'm talking about free software developers' needs over the next week or two. Andrew. -- Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK Registered in England and Wales No. 3798903 From Phil.Race at Sun.COM Fri May 11 15:50:06 2007 From: Phil.Race at Sun.COM (Phil Race) Date: Fri, 11 May 2007 08:50:06 -0700 Subject: missing JRE parts In-Reply-To: <46442373.10409@libero.it> References: <46442373.10409@libero.it> Message-ID: <464490AE.3010002@sun.com> These are 'bundled' with sun's binary distributions but aren't part of it. So they aren't part of this open source release. My (personal) understanding is we plan to release them but the work is at an early stage. -phil. Olaf Razzoli wrote: > First of all, thanks to Sun for the important steps into the open > source world. > > After spending some time searching in the source code, it seems that > Java Web Start and the web browser Plugin technology are missing. I > know they are part of the JRE, and Sun open sourced JDK, but I thought > they are necessary to build a complete open source java distribution. > I would like to know if and when the source code is supposed to be > released. > Thanks in advance > Olaf From neojia at gmail.com Sat May 19 06:35:25 2007 From: neojia at gmail.com (Neo Jia) Date: Sat, 19 May 2007 01:35:25 -0500 Subject: Any update for the bug database? Message-ID: <5d649bdb0705182335j732e4a8al8e89f8dfd43c30cf@mail.gmail.com> hi, As I was told by Jon in compiler mailing list that there would be an update for the code repository, I would like to raise this question again for the bug database. Will it be replaced by something like bugzilla to support the development in open source community? Thanks, Neo -- I would remember that if researchers were not ambitious probably today we haven't the technology we are using! From David.Herron at Sun.COM Sat May 19 12:57:42 2007 From: David.Herron at Sun.COM (David Herron) Date: Sat, 19 May 2007 05:57:42 -0700 Subject: Any update for the bug database? In-Reply-To: <5d649bdb0705182335j732e4a8al8e89f8dfd43c30cf@mail.gmail.com> References: <5d649bdb0705182335j732e4a8al8e89f8dfd43c30cf@mail.gmail.com> Message-ID: <6C778B93-629B-44C9-AB04-21545AA1A234@sun.com> This is under discussion how to proceed. The discussion is happening across all of Sun's open source projects because we all have similar complications. As I understand it the solution is going to serve all Sun's open source projects. It will be best if there is one pile of bugs to deal with. That leaves the question, how do we handle openjdk bugs from the community AND handle bugs coming from all the existing channels we already have? We have bug fields containing confidential customer information we cannot expose, we have security bugs we don't expose due to our policies of handling security bugs, etc. These issues are not unique to the OpenJDK / Java SE team, but to all of Sun's other software products. Yes, we plan to put "something" better our there. bugs.sun.com is showing its age, that's for sure. A key flaw with bugzilla is it can target only one release. In our existing processes we have multiple release trains executing in parallel ... there's what you might call the HEAD release (currently called OpenJDK / Java7) and there are what you might call branches for each of the prior releases that we produce update releases for (Java 6, Java 5, Java 1.4.2, etc). This means we target a bug to one or more of those release trains depending on what it is. - David Herron On May 18, 2007, at 11:35 PM, Neo Jia wrote: > hi, > > As I was told by Jon in compiler mailing list that there would be an > update for the code repository, I would like to raise this question > again for the bug database. Will it be replaced by something like > bugzilla to support the development in open source community? > > Thanks, > Neo > > -- > I would remember that if researchers were not ambitious > probably today we haven't the technology we are using! From Phil.Race at Sun.COM Sat May 19 16:08:55 2007 From: Phil.Race at Sun.COM (Phil Race) Date: Sat, 19 May 2007 09:08:55 -0700 Subject: Any update for the bug database? In-Reply-To: <6C778B93-629B-44C9-AB04-21545AA1A234@sun.com> References: <5d649bdb0705182335j732e4a8al8e89f8dfd43c30cf@mail.gmail.com> <6C778B93-629B-44C9-AB04-21545AA1A234@sun.com> Message-ID: <464F2117.7010902@sun.com> In top of that we have dozens of 'boundary' systems - which tap into our existing bug database to produce custom reports, provide bulk update mechanisms etc etc. When we transitioned to a new bug database system a couple of years ago, even though we had input into its design it was a very painful and expensive process. The system was in design for literally years and some of it is still having the kinks worked out. I find it really hard to believe we could simply move to bugzilla and not have huge consequences. -phil. David Herron wrote: > > This is under discussion how to proceed. The discussion is happening > across all of Sun's open source projects because we all have similar > complications. As I understand it the solution is going to serve all > Sun's open source projects. > > It will be best if there is one pile of bugs to deal with. That > leaves the question, how do we handle openjdk bugs from the community > AND handle bugs coming from all the existing channels we already > have? We have bug fields containing confidential customer information > we cannot expose, we have security bugs we don't expose due to our > policies of handling security bugs, etc. These issues are not unique > to the OpenJDK / Java SE team, but to all of Sun's other software > products. > > Yes, we plan to put "something" better our there. bugs.sun.com is > showing its age, that's for sure. > > A key flaw with bugzilla is it can target only one release. In our > existing processes we have multiple release trains executing in > parallel ... there's what you might call the HEAD release (currently > called OpenJDK / Java7) and there are what you might call branches for > each of the prior releases that we produce update releases for (Java > 6, Java 5, Java 1.4.2, etc). This means we target a bug to one or > more of those release trains depending on what it is. > > - David Herron > > > On May 18, 2007, at 11:35 PM, Neo Jia wrote: > >> hi, >> >> As I was told by Jon in compiler mailing list that there would be an >> update for the code repository, I would like to raise this question >> again for the bug database. Will it be replaced by something like >> bugzilla to support the development in open source community? >> >> Thanks, >> Neo >> >> --I would remember that if researchers were not ambitious >> probably today we haven't the technology we are using! > From Tom.Marble at Sun.COM Sun May 20 20:25:45 2007 From: Tom.Marble at Sun.COM (Tom Marble) Date: Sun, 20 May 2007 15:25:45 -0500 Subject: test of new Gmane migration Message-ID: <4650AEC9.4070300@sun.com> All: Please ignore this test message whose purpose is to confirm that the Gmane gateway has been migrated from the old list to the new list. --Tom From tromey at redhat.com Mon May 21 18:34:54 2007 From: tromey at redhat.com (Tom Tromey) Date: Mon, 21 May 2007 12:34:54 -0600 Subject: Any update for the bug database? In-Reply-To: <6C778B93-629B-44C9-AB04-21545AA1A234@sun.com> (David Herron's message of "Sat\, 19 May 2007 05\:57\:42 -0700") References: <5d649bdb0705182335j732e4a8al8e89f8dfd43c30cf@mail.gmail.com> <6C778B93-629B-44C9-AB04-21545AA1A234@sun.com> Message-ID: >>>>> "David" == David Herron writes: David> It will be best if there is one pile of bugs to deal with. David> That leaves the question, how do we handle openjdk bugs from David> the community AND handle bugs coming from all the existing David> channels we already have? We have bug fields containing David> confidential customer information we cannot expose, we have David> security bugs we don't expose due to our policies of handling David> security bugs, etc. One stock solution followed by other projects is to have two bug systems -- one for the open source project and another for the company. Then you just need ways, perhaps just manual ones, of pushing bugs "upstream" from the Sun tracker to the OpenJDK tracker. There are exceptions to this, though -- e.g., bugzilla.redhat.com is used for both Fedora and all kinds of Red Hat things. Personally I don't think this is the best way to go. Anyway, is this discussion being held in public? That would be worthwhile. David> A key flaw with bugzilla is it can target only one release. Yeah, this is reasonably painful. There are folks writing "distributed VC-like" bug tracking systems but AFAIK none has really caught on yet. The basic idea here, AIUI, is to have the bugs in the tree, so they can be closed, managed, merged, right along with the sources. Tom From David.Herron at Sun.COM Mon May 21 19:25:34 2007 From: David.Herron at Sun.COM (David Herron) Date: Mon, 21 May 2007 12:25:34 -0700 Subject: Any update for the bug database? In-Reply-To: References: <5d649bdb0705182335j732e4a8al8e89f8dfd43c30cf@mail.gmail.com> <6C778B93-629B-44C9-AB04-21545AA1A234@sun.com> Message-ID: <4651F22E.7070205@sun.com> Oh yeah Tom, you just reminded me of another question... The OpenJDK incorporates code from some external projects. Just like many projects do. So it wouldn't be just how do we push bug data between the public and private systems; but how do we interface our bugs with our own upstream projects? What happens when a bug in one project becomes dependant on a bug in some other project? I suppose that today the connection is handled manually.. e.g. set a URL in the bug description or evaluation. Wouldn't it be nice if the bug systems automatically handled these connections? Some kinda protocol between bug systems. But this is much to large a problem to consider fixing on a global scale right away. As for targeting a bug for multiple releases ... clearly a bug can appear in multiple releases depending on when the bug was created and when it was found. We tend to fix an issue in the HEAD release and optionally backport it to earlier releases based on customer needs. For example this lets the fix bake in the HEAD release to give some time for testing and usage to shake out whether any bugs were created in the process of fixing the bug. (I don't care how good a developer you are; sometimes more problems are created while trying to solve a problem) This means the bug status (closed/fixed/open/etc) needs to be maintained for each related release. - David Herron Tom Tromey wrote: >>>>>> "David" == David Herron writes: >>>>>> > > David> It will be best if there is one pile of bugs to deal with. > David> That leaves the question, how do we handle openjdk bugs from > David> the community AND handle bugs coming from all the existing > David> channels we already have? We have bug fields containing > David> confidential customer information we cannot expose, we have > David> security bugs we don't expose due to our policies of handling > David> security bugs, etc. > > One stock solution followed by other projects is to have two bug > systems -- one for the open source project and another for the > company. Then you just need ways, perhaps just manual ones, of > pushing bugs "upstream" from the Sun tracker to the OpenJDK tracker. > > There are exceptions to this, though -- e.g., bugzilla.redhat.com is > used for both Fedora and all kinds of Red Hat things. Personally I > don't think this is the best way to go. > > Anyway, is this discussion being held in public? That would be > worthwhile. > > David> A key flaw with bugzilla is it can target only one release. > > Yeah, this is reasonably painful. > There are folks writing "distributed VC-like" bug tracking systems but > AFAIK none has really caught on yet. The basic idea here, AIUI, is to > have the bugs in the tree, so they can be closed, managed, merged, > right along with the sources. > > Tom > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sandeep.Konchady at Sun.COM Mon May 21 22:28:50 2007 From: Sandeep.Konchady at Sun.COM (Sandeep Konchady) Date: Mon, 21 May 2007 15:28:50 -0700 Subject: Ability to publish test logs and reports for verification Message-ID: <46521D22.9070500@Sun.COM> Hi, Recently while working on using Valgrind with OpenJDK VM I generated some logs. These have some useful information and could potentially be a bug. To assess this I would have to either send this few MB file to everyone on the mailing list or it may bounce due to large size. Most companies have a secured network behind a firewall. How are these folks (including me) suppose to publish these logs for engineers to take a look at to decide if the issue is a real bug or not? One way is to convert this report into a bug where in I can publish the log. But what if this is not a bug. What I would like to see happen is to have a place holder on openjdk.java.net where in folks can upload their test logs for a predefined period (say a month) after which it gets deleted. This way OpenJDK community can collaborate on these results without having to flood every inbox. Have anyone from OpenJDK team thought about this? Thanks, Sandeep From Peter.Kessler at Sun.COM Tue May 22 00:16:18 2007 From: Peter.Kessler at Sun.COM (Peter B. Kessler) Date: Mon, 21 May 2007 17:16:18 -0700 Subject: Ability to publish test logs and reports for verification In-Reply-To: <46521D22.9070500@Sun.COM> References: <46521D22.9070500@Sun.COM> Message-ID: <46523652.8090009@Sun.COM> Sandeep Konchady wrote: > Hi, > > Recently while working on using Valgrind with OpenJDK VM I generated > some logs. These have some useful information and could potentially be a > bug. To assess this I would have to either send this few MB file to > everyone on the mailing list or it may bounce due to large size. Most > companies have a secured network behind a firewall. How are these folks > (including me) suppose to publish these logs for engineers to take a > look at to decide if the issue is a real bug or not? > > One way is to convert this report into a bug where in I can publish the > log. But what if this is not a bug. What I would like to see happen is > to have a place holder on openjdk.java.net where in folks can upload > their test logs for a predefined period (say a month) after which it > gets deleted. This way OpenJDK community can collaborate on these > results without having to flood every inbox. Have anyone from OpenJDK > team thought about this? > > Thanks, > Sandeep We have thought about it, we just don't have a good solution, yet. I agree it's better not to spam everyone on the list with several megs of log file. In general, we use our bug system to hold data like that. Don't worry that something is "not a bug". If you are wondering about it and want to get an evaluation from someone at Sun, just file a bug report and attach your logs. That way it's safe and we can put an evaluation on it, and it will get kept for all time, so if the issue comes up again we can still get to your logs. At least until we have something better. ... peter From Phil.Race at Sun.COM Wed May 23 20:23:04 2007 From: Phil.Race at Sun.COM (Phil Race) Date: Wed, 23 May 2007 13:23:04 -0700 Subject: Project proposal: fbtoolkit In-Reply-To: <46549DAC.30501@sun.com> References: <46549DAC.30501@sun.com> Message-ID: <4654A2A8.4020400@sun.com> I don't follow what this has to do with Swing. 2D would be more affected .. Swing is ignorant of whether the Motif or X toolkit is specified and even works with the headless toolkit. Also the existing toolkits can still leverage all of the same internal 2D native code for rendering. I don't see where you are going to get that from unless if its going to be a pure Java solution. -phil. Tom Marble wrote: > All: > > In conjunction with Steph Meslin-Weber [1] I would like to propose > a new OpenJDK project: fbtoolkit > > The objective of this project is to produce a body of code which is > a lightweight framebuffer-based peer implementation for AWT and Swing. > The goal of this code is to remove the dependency on X or > other graphics layers such that graphics can be redirected to > a framebuffer (e.g. a raw buffer, VNC, etc.). This example > implementation will prefer pure-Java solutions, with public > extension points available to enter native resources as necessary. > > In prototyping this functionality with OpenJDK it > should be possible demonstrate this graphics redirection > via a command line such as: > % java -Dawt.toolkit=net.java.openjdk.fbtoolkit.Toolkit -jar myApp.jar > > NOTE: there are many other options which one would want > to specify (e.g. bit depth, encoding, geometry, port number, etc.) and > these can all be collected into a properties file which is > implicitly named (based upon the provider) or overridden on > the command line. > > Examples of usage include: implementation debugging, device > emulation, multiple-head clone outputs/inputs, simultaneous > multiple-peer output, etc. > > As this proposal is most closely related to the AWT [2] and Swing [3] > groups they have been added on CC: and as such we would like to > request sponsorship from these groups. > > Please note that per the interim OpenJDK guidelines for Projects [4] > that followups should go the discuss list [5]. > > Thank you for your consideration, > > --Tom & Steph > > [1] Steph is a Participant > Steph's blog: http://blog.tangency.co.uk/ > java.net ident: twiun > [2] the AWT Group: http://openjdk.java.net/groups/awt/ > [3] the Swing Group: http://openjdk.java.net/groups/swing/ > [4] Proposing Projects: http://openjdk.java.net/projects/ > [5] discuss: http://mail.openjdk.java.net/mailman/listinfo/discuss > > From Paul.Hohensee at Sun.COM Thu May 24 00:48:17 2007 From: Paul.Hohensee at Sun.COM (Paul Hohensee - Java SE) Date: Wed, 23 May 2007 20:48:17 -0400 Subject: Project proposal: fbtoolkit In-Reply-To: <46549DAC.30501@sun.com> References: <46549DAC.30501@sun.com> Message-ID: <4654E0D1.9060403@sun.com> You might want to talk to Ron Mann, who did something that sounds like this called SquidKit back in 2000 or so. Politics killed it. He works in the Jini group now. Paul Tom Marble wrote: >All: > >In conjunction with Steph Meslin-Weber [1] I would like to propose >a new OpenJDK project: fbtoolkit > >The objective of this project is to produce a body of code which is >a lightweight framebuffer-based peer implementation for AWT and Swing. >The goal of this code is to remove the dependency on X or >other graphics layers such that graphics can be redirected to >a framebuffer (e.g. a raw buffer, VNC, etc.). This example >implementation will prefer pure-Java solutions, with public >extension points available to enter native resources as necessary. > >In prototyping this functionality with OpenJDK it >should be possible demonstrate this graphics redirection >via a command line such as: >% java -Dawt.toolkit=net.java.openjdk.fbtoolkit.Toolkit -jar myApp.jar > >NOTE: there are many other options which one would want >to specify (e.g. bit depth, encoding, geometry, port number, etc.) and >these can all be collected into a properties file which is >implicitly named (based upon the provider) or overridden on >the command line. > >Examples of usage include: implementation debugging, device >emulation, multiple-head clone outputs/inputs, simultaneous >multiple-peer output, etc. > >As this proposal is most closely related to the AWT [2] and Swing [3] >groups they have been added on CC: and as such we would like to >request sponsorship from these groups. > >Please note that per the interim OpenJDK guidelines for Projects [4] >that followups should go the discuss list [5]. > >Thank you for your consideration, > >--Tom & Steph > >[1] Steph is a Participant > Steph's blog: http://blog.tangency.co.uk/ > java.net ident: twiun >[2] the AWT Group: http://openjdk.java.net/groups/awt/ >[3] the Swing Group: http://openjdk.java.net/groups/swing/ >[4] Proposing Projects: http://openjdk.java.net/projects/ >[5] discuss: http://mail.openjdk.java.net/mailman/listinfo/discuss > > > > From Paul.Hohensee at Sun.COM Thu May 24 00:49:18 2007 From: Paul.Hohensee at Sun.COM (Paul Hohensee - Java SE) Date: Wed, 23 May 2007 20:49:18 -0400 Subject: Project proposal: fbtoolkit In-Reply-To: <46549DAC.30501@sun.com> References: <46549DAC.30501@sun.com> Message-ID: <4654E10E.9080308@sun.com> My apologies for the previous note. 'Reply' isn't the right thing to do on a list like this. Please disregard. Paul Tom Marble wrote: >All: > >In conjunction with Steph Meslin-Weber [1] I would like to propose >a new OpenJDK project: fbtoolkit > >The objective of this project is to produce a body of code which is >a lightweight framebuffer-based peer implementation for AWT and Swing. >The goal of this code is to remove the dependency on X or >other graphics layers such that graphics can be redirected to >a framebuffer (e.g. a raw buffer, VNC, etc.). This example >implementation will prefer pure-Java solutions, with public >extension points available to enter native resources as necessary. > >In prototyping this functionality with OpenJDK it >should be possible demonstrate this graphics redirection >via a command line such as: >% java -Dawt.toolkit=net.java.openjdk.fbtoolkit.Toolkit -jar myApp.jar > >NOTE: there are many other options which one would want >to specify (e.g. bit depth, encoding, geometry, port number, etc.) and >these can all be collected into a properties file which is >implicitly named (based upon the provider) or overridden on >the command line. > >Examples of usage include: implementation debugging, device >emulation, multiple-head clone outputs/inputs, simultaneous >multiple-peer output, etc. > >As this proposal is most closely related to the AWT [2] and Swing [3] >groups they have been added on CC: and as such we would like to >request sponsorship from these groups. > >Please note that per the interim OpenJDK guidelines for Projects [4] >that followups should go the discuss list [5]. > >Thank you for your consideration, > >--Tom & Steph > >[1] Steph is a Participant > Steph's blog: http://blog.tangency.co.uk/ > java.net ident: twiun >[2] the AWT Group: http://openjdk.java.net/groups/awt/ >[3] the Swing Group: http://openjdk.java.net/groups/swing/ >[4] Proposing Projects: http://openjdk.java.net/projects/ >[5] discuss: http://mail.openjdk.java.net/mailman/listinfo/discuss > > > > From Tom.Marble at Sun.COM Thu May 24 01:45:54 2007 From: Tom.Marble at Sun.COM (Tom Marble) Date: Wed, 23 May 2007 20:45:54 -0500 Subject: Project proposal: fbtoolkit In-Reply-To: <4654A2A8.4020400@sun.com> References: <46549DAC.30501@sun.com> <4654A2A8.4020400@sun.com> Message-ID: <4654EE52.6010605@sun.com> Phil Race wrote: > I don't follow what this has to do with Swing. 2D would be more affected .. > Swing is ignorant of whether the Motif or X toolkit is specified > and even works with the headless toolkit. > > Also the existing toolkits can still leverage all of the > same internal 2D native code for rendering. I don't see where > you are going to get that from unless if its going to be > a pure Java solution. Please note that following the Projects guidelines followups are intended to go to the discuss list [1]. I confess I am not a client or graphics expert. I can appreciate the advantages, however, of device emulation and multiple-head clone outputs/inputs, etc. If Swing is less appropriate than 2D then perhaps 2D would be a more appropriate Group to sponsor this Project? Allow me to clarify, as well, that the purpose of this project is experimental and for prototyping. Think of this as a KSL [2] style Project that should be associated with the appropriate Group (i.e. 2D or AWT). Obviously such a Project, if approved, would need a VCS "sandbox" as described in [1]: "Projects that are not tightly related to the development of JDK 7 will, for now, also be given a regular java.net project within the java.net OpenJDK Community." Can we get a Group sponsor? --Tom [1] http://openjdk.java.net/projects/ [2] http://blogs.sun.com/ahe/entry/ksl_open From Phil.Race at Sun.COM Thu May 24 04:25:52 2007 From: Phil.Race at Sun.COM (Phil Race) Date: Wed, 23 May 2007 21:25:52 -0700 Subject: Project proposal: fbtoolkit In-Reply-To: <4654EE52.6010605@sun.com> References: <46549DAC.30501@sun.com> <4654A2A8.4020400@sun.com> <4654EE52.6010605@sun.com> Message-ID: <465513D0.3020202@sun.com> Tom Marble wrote: > Phil Race wrote: > >> I don't follow what this has to do with Swing. 2D would be more affected .. >> Swing is ignorant of whether the Motif or X toolkit is specified >> and even works with the headless toolkit. >> >> Also the existing toolkits can still leverage all of the >> same internal 2D native code for rendering. I don't see where >> you are going to get that from unless if its going to be >> a pure Java solution. >> > > Please note that following the Projects guidelines followups are > intended to go to the discuss list [1]. > Thats a broken process. It should go to affected groups. Any assumption that every one reads or even knows about 'discuss' is wrong and for ever will be. > I confess I am not a client or graphics expert. I can appreciate > the advantages, however, of device emulation and multiple-head > clone outputs/inputs, etc. If Swing is less appropriate than 2D > then perhaps 2D would be a more appropriate Group to sponsor this > Project? > So does it really make sense to propose a project you think is a cool idea you don't understand and then disappear? I think proposals should come only from someone who is committed to the idea and will work on it. > Allow me to clarify, as well, that the purpose of this project > is experimental and for prototyping. Think of this as a KSL [2] > style Project that should be associated with the appropriate > Group (i.e. 2D or AWT). Obviously such a Project, if approved, would > need a VCS "sandbox" as described in [1]: "Projects that are not > tightly related to the development of JDK 7 will, for now, also be > given a regular java.net project within the java.net OpenJDK Community." > > Can we get a Group sponsor? > I don't think we have a clue what sponsorship means. It certainly can't mean in this case any work from Sun engineers ( wish we had time for such ideas ourselves), or taking it back into openjdk in any time in the forseeable future. It just seems like an interesting expt this time, with unproven practical applications. -Phil > --Tom > > [1] http://openjdk.java.net/projects/ > [2] http://blogs.sun.com/ahe/entry/ksl_open > From mr at sun.com Thu May 24 05:12:39 2007 From: mr at sun.com (Mark Reinhold) Date: Wed, 23 May 2007 22:12:39 -0700 Subject: Project proposal: fbtoolkit In-Reply-To: phil.race@sun.com; Wed, 23 May 2007 21:25:52 PDT; <465513D0.3020202@sun.com> Message-ID: <20070524051239.1FF405ED5@callebaut.niobe.net> > Date: Wed, 23 May 2007 21:25:52 -0700 > From: phil.race at sun.com > Tom Marble wrote: >> Please note that following the Projects guidelines followups are >> intended to go to the discuss list [1]. > > Thats a broken process. It should go to affected groups. A Project does not necessarily need group sponsorship, which is why the interim project-proposal process doesn't define a notion of "affected groups". If the proposer of a new Project does know of one or more groups that are potential sponsors then it'd likely be more efficient to poll those groups for support before proposing the new Project, but doing so is not required. > Any assumption that every one reads or even knows about 'discuss' is > wrong and for ever will be. That's why project proposals are posted to the announce list, with follow-ups to the discuss list. Tom did in fact cc the AWT and Swing lists, though in retrospect he probably should've cc'd the 2D list as well. > So does it really make sense to propose a project you think is a cool > idea you don't understand and then disappear? > I think proposals should come only from someone who is committed to the > idea and will work on it. It would be helpful to hear answers to Phil's technical questions, either from Tom, from Steph, or from someone else who intends to work on this Project. >> Allow me to clarify, as well, that the purpose of this project >> is experimental and for prototyping. ... >> >> Can we get a Group sponsor? > > I don't think we have a clue what sponsorship means. It certainly > can't mean in this case any work from Sun engineers ( wish we had time > for such ideas ourselves), or taking it back into openjdk in any time > in the forseeable future. In the interim governance guidelines, sponsorship means only that the majority of the members of a Group think that the project is worthwhile. It does not imply any kind of commitment of effort, nor does it imply that the code will one day be integrated into any particular JDK tree. (I'll clarify this in the guidelines.) > It just seems like an interesting expt this time, with unproven > practical applications. Personally I think that the OpenJDK Community should be open to all kinds of interesting experiments. That's often, after all, the best way to learn things. - Mark From robilad at kaffe.org Thu May 24 10:08:09 2007 From: robilad at kaffe.org (Dalibor Topic) Date: Thu, 24 May 2007 12:08:09 +0200 Subject: Project proposal: fbtoolkit In-Reply-To: <20070524051239.1FF405ED5@callebaut.niobe.net> References: <20070524051239.1FF405ED5@callebaut.niobe.net> Message-ID: <46556409.5030101@kaffe.org> Mark Reinhold wrote: >In the interim governance guidelines, sponsorship means only that the >majority of the members of a Group think that the project is worthwhile. >It does not imply any kind of commitment of effort, nor does it imply >that the code will one day be integrated into any particular JDK tree. >(I'll clarify this in the guidelines.) > > > Here's a pointer to your slides from J1 that give a compact overview of how the structure with projects & groups works http://developers.sun.com/learning/javaoneonline/j1sessn.jsp?sessn=TS-2800&yr=2007&track=5 >>It just seems like an interesting expt this time, with unproven >>practical applications. >> >> > >Personally I think that the OpenJDK Community should be open to all kinds >of interesting experiments. That's often, after all, the best way to >learn things. > > From gcc's experience, having interesting things happen in tree, rather than outside it, like it was done with Kaffe, makes it easier to merge them back into the main branch, if the experiements turn out to be successful, afaict. cheers, dalibor topic From Jeff.Dinkins at Sun.COM Thu May 24 11:55:25 2007 From: Jeff.Dinkins at Sun.COM (Jeff Dinkins) Date: Thu, 24 May 2007 06:55:25 -0500 Subject: Project proposal: fbtoolkit In-Reply-To: <46556409.5030101@kaffe.org> References: <20070524051239.1FF405ED5@callebaut.niobe.net> <46556409.5030101@kaffe.org> Message-ID: <1A100E71-2E05-4744-B024-91704AA48631@Sun.com> >> Personally I think that the OpenJDK Community should be open to >> all kinds >> of interesting experiments. That's often, after all, the best way to >> learn things. >> > From gcc's experience, having interesting things happen in tree, > rather than outside it, like it was done with Kaffe, makes it > easier to merge them back into the main branch, if the experiements > turn out to be successful, afaict. > > cheers, > dalibor topic In GCC how do they keep track of what is experimental vs. in the main branch? Also, at project approval time is it worth tagging items that are pre- blessed as work that will, or will most likely, go back into the main tree (example: JSRs, encumbered replacements)? If so who gets to set the tag or branch location? Or should all new projects be treated the same and start off in an incubator branch? I know, these are really questions for the Governance board to work out for the constitution. Is this alias a reasonable place for these issues to come up for the IGB to take back for discussion? thanks, jeff From aph at redhat.com Thu May 24 12:42:33 2007 From: aph at redhat.com (Andrew Haley) Date: Thu, 24 May 2007 13:42:33 +0100 Subject: Project proposal: fbtoolkit In-Reply-To: <1A100E71-2E05-4744-B024-91704AA48631@Sun.com> References: <20070524051239.1FF405ED5@callebaut.niobe.net> <46556409.5030101@kaffe.org> <1A100E71-2E05-4744-B024-91704AA48631@Sun.com> Message-ID: <18005.34873.20155.820550@zebedee.pink> Jeff Dinkins writes: > > >> Personally I think that the OpenJDK Community should be open to > >> all kinds > >> of interesting experiments. That's often, after all, the best way to > >> learn things. > >> > > From gcc's experience, having interesting things happen in tree, > > rather than outside it, like it was done with Kaffe, makes it > > easier to merge them back into the main branch, if the experiements > > turn out to be successful, afaict. > > In GCC how do they keep track of what is experimental vs. in the main > branch? Experimental stuff is on branches. > Also, at project approval time is it worth tagging items that are pre- > blessed as work that will, or will most likely, go back into the main > tree (example: JSRs, encumbered replacements)? If so who gets to set > the tag or branch location? We don't do that in gcc. Maintainers can all create branches to work on, and are encouraged to do so. > Or should all new projects be treated the same and start off in an > incubator branch? That seems reasonable. We find that this kind of metadata isn't really needed in the actual source control system: that happens on the mailing lists and web pages. Andrew. -- Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK Registered in England and Wales No. 3798903 From robilad at kaffe.org Thu May 24 15:28:33 2007 From: robilad at kaffe.org (Dalibor Topic) Date: Thu, 24 May 2007 17:28:33 +0200 Subject: Project proposal: fbtoolkit In-Reply-To: <1A100E71-2E05-4744-B024-91704AA48631@Sun.com> References: <20070524051239.1FF405ED5@callebaut.niobe.net> <46556409.5030101@kaffe.org> <1A100E71-2E05-4744-B024-91704AA48631@Sun.com> Message-ID: <4655AF21.6000709@kaffe.org> Jeff Dinkins wrote: > >>> Personally I think that the OpenJDK Community should be open to all >>> kinds >>> of interesting experiments. That's often, after all, the best way to >>> learn things. >>> >> From gcc's experience, having interesting things happen in tree, >> rather than outside it, like it was done with Kaffe, makes it easier >> to merge them back into the main branch, if the experiements turn >> out to be successful, afaict. >> >> cheers, >> dalibor topic > > > In GCC how do they keep track of what is experimental vs. in the main > branch? Hi Jeff, assuming your concern is in figuring out what constitutes the main branch, and what constitutes experimental branches in a project like GCC, they have an extensive list of experimental branches (active, inactive, etc.) at http://gcc.gnu.org/svn.html . Some of the branches are explicitely marked as not being considered for merges into the main branch, for example, while others are there for experimental features, backends, frontends, third parties distributing & patching gcc, etc. There are different rules for commits to branches, for example for release branches, the kind of patches that can go in depends on the 'stage' a branch is in, etc. That may or may not be a suitable model for dealing with experimental work for openjdk projects, depending on what the people want & need. > Also, at project approval time is it worth tagging items that are pre- > blessed as work that will, or will most likely, go back into the main > tree (example: JSRs, encumbered replacements)? If so who gets to set > the tag or branch location? > > Or should all new projects be treated the same and start off in an > incubator branch? > > I know, these are really questions for the Governance board to work > out for the constitution. Is this alias a reasonable place for these > issues to come up for the IGB to take back for discussion? I think this list is a good place for bouncing ideas around. If it needs to be more formal / when it needs to be formalized, we can take it to gb-discuss and continue the conversation there. cheers, dalibor topic From steph at tangency.co.uk Thu May 24 15:38:57 2007 From: steph at tangency.co.uk (Steph Meslin-Weber) Date: Thu, 24 May 2007 16:38:57 +0100 Subject: Project proposal: fbtoolkit In-Reply-To: <4654A2A8.4020400@sun.com> References: <46549DAC.30501@sun.com> <4654A2A8.4020400@sun.com> Message-ID: Hi Phil, Thanks for your comments, I wasn't certain how verbose the initial proposal was supposed to be so we left out the details from the usecases. In order to keep this thread in one list (it's starting to confuse Gmail a bit) we could continue this conversation in discuss for now. I have Bcc'd the other lists (including 2d following Mark's use) to let everyone on those lists know to check discuss for followups: Bcc: awt-dev at openjdk.java.net Bcc: 2d-dev at openjdk.java.net Bcc: swing-dev at openjdk.java.net As the discussion moves on we can move it to the one group that seems most appropriate. On 23/05/07, Phil Race wrote: > I don't follow what this has to do with Swing. 2D would be more affected .. > Swing is ignorant of whether the Motif or X toolkit is specified > and even works with the headless toolkit. Agreed, Swing shouldn't use knowledge of the underlying implementation. The reasoning behind including Swing in the discussion is the SwingAWT work by Roman Kennke. In his project, he implemented AWT peers using Swing [1]. Now, whether the Swing implementation is native is another topic of discussion :-) > Also the existing toolkits can still leverage all of the > same internal 2D native code for rendering. I don't see where > you are going to get that from unless if its going to be > a pure Java solution. I think here we tried to show that the example implementation would be written in pure Java, with extension points to break to native code as needed: "This example implementation will prefer pure-Java solutions, with public extension points available to enter native resources as necessary." Starting with pure Java means we have a baseline that is easier to understand than one that jumps back and forth to native code, this also incidentally makes it an ideal example for those wishing to write their own set of peers. It's a given that without those jumps certain optimisations aren't practical to implement, but that's why we'd like to do this in the open so those situations can be discussed and planned for. Before going on to a few usecases, I'd like to mention that I already have a fair amount of code in support of this proof of concept, including providers for raw linux fb, VNC and (as of 2 hours ago, thanks Guillaume!) a pure Java X11 provider; there is also embryonic work on an SDL provider to ensure we cover as many platforms as possible. > > Examples of usage include: implementation debugging, device > > emulation, multiple-head clone outputs/inputs, simultaneous > > multiple-peer output, etc. Example usecases: 1) Implementation debugging is one that is fairly simple to explain, it becomes a tool for us to track down AWT/Swing issues by excluding native resources as a possible error source. (Yes it introduces another factor, but at least it's independent). This also allows for some device emulation, screen sizes, pixel encoding, etc. 2) Realtime output/input on a device (say an N800 [2]) with simultaneous output/input of the exact same screen contents on an attached PC. This is in effect multiplexing two different devices onto a single Java stack. Control of the device from the PC. Useful when your touchscreen driver isn't written yet. 3) Distributed remote software agents exposing a VNC or X11 capable UI. Easier to secure and to use than a fullblown VNC or X11 server on a dedicated host. Easier to deploy too. This is in effect a kernel+jvm+libc on any hardware. Including headless ones like a router. 4) Point of Sale, The network is the machine, etc... lightweight PXE images booting a rich Swing UI direct to their framebuffer. Small PXE image, few external dependencies. For bonus points, let the client decide which provider to load from a Jini cloud depending on need. 5) Multicast a single UI via VNC, kiosk-type advertising or interaction: one window per terminal. Please let me know if I've left a few out. Thanks, Steph [1] awtswing, http://kennke.org/~roman/swing-based-awt.png [2] N800, http://www.nseries.com/n800 [3] Maemo, http://maemo.org/ -- ================================================================ Steph Meslin-Weber, steph at tangency.co.uk ================================================================ From Joshua.Marinacci at Sun.COM Thu May 24 15:34:25 2007 From: Joshua.Marinacci at Sun.COM (Joshua Marinacci) Date: Thu, 24 May 2007 08:34:25 -0700 Subject: Project proposal: fbtoolkit In-Reply-To: <465513D0.3020202@sun.com> References: <46549DAC.30501@sun.com> <4654A2A8.4020400@sun.com> <4654EE52.6010605@sun.com> <465513D0.3020202@sun.com> Message-ID: I'm not sure who exactly would want to sponsor this project and which teams would be involved. Since AWT, 2D, and Swing are so closely related they would likely all be involved. I can speak, however, to the practical need for this project. There are many use cases for a completely virtualized toolkit. * www.glossitope.org This is a project I started which lets you write widgets that run on your desktop in Java. The version I prepared for JavaOne has lots of cool effects that involve scaling, shearing, and otherwise animating the widgets in weird ways. Since the widgets are just Swing panels I draw them into buffered images and then blit those to the screen. This has lots of odd problems that are hard to fix properly, such as dealing with focus, handling combobox popups, and keyboard events. These problems are difficult (if not impossible) to solve outside of core. * Project Looking Glass Paul Byrne and I have discussed this extensively and he even had another researcher start building a headless AWT that could be projected into the Java3D scene graph. They got pretty far but ran into a few places where AWT assumes it has a real windowing system with access to X11 window handles. These are also impossible to fix without changes to core. Solveing this would let them put Swing applications directly into the 3d environment * JOGL Minimal Scene Graph Ken Russell and others would like to project Swing components directly into the JOGL scene graph that they are building. This would let you have a Swing panel that appears normal but can then slide into the background to be replaced by other panel. * full screen video games We would like to let people use Swing components as the heads up display in full screen video games. This means running in an environment where there is no windowing system at all. This would also be useful for kiosks and other semi-embedded environments. So you can see, there is a great need for a virtualized Toolkit. I think that most of the work could be done at the AWT level (and hopefully let me scrap most of my Swing level hacks) but undoubtedly it will affect many areas in core. This is something that is vitally needed to let us take Java SE into new environments. thx, Josh >> Allow me to clarify, as well, that the purpose of this project >> is experimental and for prototyping. Think of this as a KSL [2] >> style Project that should be associated with the appropriate >> Group (i.e. 2D or AWT). Obviously such a Project, if approved, would >> need a VCS "sandbox" as described in [1]: "Projects that are not >> tightly related to the development of JDK 7 will, for now, also be >> given a regular java.net project within the java.net OpenJDK >> Community." >> >> Can we get a Group sponsor? >> > > I don't think we have a clue what sponsorship means. It certainly > can't mean in this case any > work from Sun engineers ( wish we had time for such ideas > ourselves), or taking it back into openjdk > in any time in the forseeable future. > > It just seems like an interesting expt this time, with unproven > practical applications. - Blasting forth in three part harmony! -------------- next part -------------- An HTML attachment was scrubbed... URL: From Dmitri.Trembovetski at Sun.COM Thu May 24 16:46:56 2007 From: Dmitri.Trembovetski at Sun.COM (Dmitri Trembovetski) Date: Thu, 24 May 2007 09:46:56 -0700 Subject: Project proposal: fbtoolkit In-Reply-To: References: <46549DAC.30501@sun.com> <4654A2A8.4020400@sun.com> <4654EE52.6010605@sun.com> <465513D0.3020202@sun.com> Message-ID: <4655C180.1050100@Sun.COM> > * full screen video games > We would like to let people use Swing components as the heads up > display in full screen video games. This means running in an environment > where there is no windowing system at all. This would also be useful > for kiosks and other semi-embedded environments. You can do that right now, Swing works (mostly) fine in fullscreen mode. Thanks, Dmitri Joshua Marinacci wrote: > I'm not sure who exactly would want to sponsor this project and which > teams would be involved. Since AWT, 2D, and Swing are so closely related > they would likely all be involved. I can speak, however, to the > practical need for this project. There are many use cases for a > completely virtualized toolkit. > > * www.glossitope.org > This is a project I started which lets you write widgets that run on > your desktop in Java. The version I prepared for JavaOne has lots of > cool effects that involve scaling, shearing, and otherwise animating the > widgets in weird ways. Since the widgets are just Swing panels I draw > them into buffered images and then blit those to the screen. This has > lots of odd problems that are hard to fix properly, such as dealing with > focus, handling combobox popups, and keyboard events. These problems > are difficult (if not impossible) to solve outside of core. > > * Project Looking Glass > Paul Byrne and I have discussed this extensively and he even had > another researcher start building a headless AWT that could be projected > into the Java3D scene graph. They got pretty far but ran into a few > places where AWT assumes it has a real windowing system with access to > X11 window handles. These are also impossible to fix without changes to > core. Solveing this would let them put Swing applications directly into > the 3d environment > > * JOGL Minimal Scene Graph > Ken Russell and others would like to project Swing components directly > into the JOGL scene graph that they are building. This would let you > have a Swing panel that appears normal but can then slide into the > background to be replaced by other panel. > > * full screen video games > We would like to let people use Swing components as the heads up > display in full screen video games. This means running in an environment > where there is no windowing system at all. This would also be useful > for kiosks and other semi-embedded environments. > > > So you can see, there is a great need for a virtualized Toolkit. I think > that most of the work could be done at the AWT level (and hopefully let > me scrap most of my Swing level hacks) but undoubtedly it will affect > many areas in core. This is something that is vitally needed to let us > take Java SE into new environments. > > thx, > Josh > >>> Allow me to clarify, as well, that the purpose of this project >>> is experimental and for prototyping. Think of this as a KSL [2] >>> style Project that should be associated with the appropriate >>> Group (i.e. 2D or AWT). Obviously such a Project, if approved, would >>> need a VCS "sandbox" as described in [1]: "Projects that are not >>> tightly related to the development of JDK 7 will, for now, also be >>> given a regular java.net project within the java.net OpenJDK Community." >>> >>> Can we get a Group sponsor? >>> >>> >>> >> >> I don't think we have a clue what sponsorship means. It certainly >> can't mean in this case any >> work from Sun engineers ( wish we had time for such ideas ourselves), >> or taking it back into openjdk >> in any time in the forseeable future. >> >> It just seems like an interesting expt this time, with unproven >> practical applications. > > > > - Blasting forth in three part harmony! > > From Oleg.Sukhodolsky at Sun.COM Thu May 24 17:42:14 2007 From: Oleg.Sukhodolsky at Sun.COM (Oleg Sukhodolsky) Date: Thu, 24 May 2007 21:42:14 +0400 Subject: Project proposal: fbtoolkit In-Reply-To: References: <46549DAC.30501@sun.com> <4654A2A8.4020400@sun.com> Message-ID: <4655CE76.30503@sun.com> imho all functionality suggested could be achieved by fb-based XServer, why do you need to reinvent the wheel and develop a toolkit which will implement some functionality of XServer, some functionality of Window Manager, and AWT toolkit. What is the advantage of the approach you suggest? Thanks, Oleg. Steph Meslin-Weber wrote: > Hi Phil, > > Thanks for your comments, I wasn't certain how verbose the initial > proposal was supposed to be so we left out the details from the > usecases. > > In order to keep this thread in one list (it's starting to confuse > Gmail a bit) we could continue this conversation in discuss for now. > I have Bcc'd the other lists (including 2d following Mark's use) to > let everyone on those lists know to check discuss for followups: > Bcc: awt-dev at openjdk.java.net > Bcc: 2d-dev at openjdk.java.net > Bcc: swing-dev at openjdk.java.net > As the discussion moves on we can move it to the one group that seems > most appropriate. > > On 23/05/07, Phil Race wrote: >> I don't follow what this has to do with Swing. 2D would be more >> affected .. >> Swing is ignorant of whether the Motif or X toolkit is specified >> and even works with the headless toolkit. > > Agreed, Swing shouldn't use knowledge of the underlying > implementation. The reasoning behind including Swing in the discussion > is the SwingAWT work by Roman Kennke. In his project, he implemented > AWT peers using Swing [1]. Now, whether the Swing implementation is > native is another topic of discussion :-) > >> Also the existing toolkits can still leverage all of the >> same internal 2D native code for rendering. I don't see where >> you are going to get that from unless if its going to be >> a pure Java solution. > > I think here we tried to show that the example implementation would be > written in pure Java, with extension points to break to native code as > needed: > > "This example implementation will prefer pure-Java solutions, with > public extension points available to enter native resources as > necessary." > > Starting with pure Java means we have a baseline that is easier to > understand than one that jumps back and forth to native code, this > also incidentally makes it an ideal example for those wishing to write > their own set of peers. It's a given that without those jumps certain > optimisations aren't practical to implement, but that's why we'd like > to do this in the open so those situations can be discussed and > planned for. > > > Before going on to a few usecases, I'd like to mention that I already > have a fair amount of code in support of this proof of concept, including > providers for raw linux fb, VNC and (as of 2 hours ago, thanks Guillaume!) > a pure Java X11 provider; there is also embryonic work on an SDL provider > to ensure we cover as many platforms as possible. > >> > Examples of usage include: implementation debugging, device >> > emulation, multiple-head clone outputs/inputs, simultaneous >> > multiple-peer output, etc. > > Example usecases: > > 1) Implementation debugging is one that is fairly simple to explain, > it becomes a tool for us to track down AWT/Swing issues by excluding > native resources as a possible error source. (Yes it introduces > another factor, but at least it's independent). This also allows for > some device emulation, screen sizes, pixel encoding, etc. > > 2) Realtime output/input on a device (say an N800 [2]) with > simultaneous output/input of the exact same screen contents on an > attached PC. This is in effect multiplexing two different devices onto > a single Java stack. Control of the device from the PC. Useful when > your touchscreen driver isn't written yet. > > 3) Distributed remote software agents exposing a VNC or X11 capable > UI. Easier to secure and to use than a fullblown VNC or X11 server on > a dedicated host. Easier to deploy too. This is in effect a > kernel+jvm+libc on any hardware. Including headless ones like a > router. > > 4) Point of Sale, The network is the machine, etc... lightweight PXE > images booting a rich Swing UI direct to their framebuffer. Small PXE > image, few external dependencies. For bonus points, let the client > decide which provider to load from a Jini cloud depending on need. > > 5) Multicast a single UI via VNC, kiosk-type advertising or > interaction: one window per terminal. > > Please let me know if I've left a few out. > > Thanks, > Steph > > [1] awtswing, http://kennke.org/~roman/swing-based-awt.png > [2] N800, http://www.nseries.com/n800 > [3] Maemo, http://maemo.org/ > From mr at sun.com Thu May 24 18:05:07 2007 From: mr at sun.com (Mark Reinhold) Date: Thu, 24 May 2007 11:05:07 -0700 Subject: Project proposal: fbtoolkit In-Reply-To: robilad@kaffe.org; Thu, 24 May 2007 17:28:33 +0200; <4655AF21.6000709@kaffe.org> Message-ID: <20070524180507.70EDC84E3@eggemoggin.niobe.net> > Date: Thu, 24 May 2007 17:28:33 +0200 > From: Dalibor Topic > ... > > assuming your concern is in figuring out what constitutes the main > branch, and what constitutes experimental branches in a project like > GCC, they have an extensive list of experimental branches (active, > inactive, etc.) at http://gcc.gnu.org/svn.html . > > Some of the branches are explicitely marked as not being considered for > merges into the main branch, for example, while others are there for > experimental features, backends, frontends, third parties distributing & > patching gcc, etc. There are different rules for commits to branches, > for example for release branches, the kind of patches that can go in > depends on the 'stage' a branch is in, etc. > > That may or may not be a suitable model for dealing with experimental > work for openjdk projects, depending on what the people want & need. I agree with the essence of what you're saying, but there's a bit of a terminological clash rooted in the choice of SCM systems. The above kind of model makes sense when using a centralized SCM such as CVS or SVN, but with a distributed SCM such as TeamWare or Mercurial a "branch" is just another workspace/repository/tree/whatever. Once we have support for open Mercurial repositories then experimental projects such as fb-toolkit can create their own private repositories that are, in effect, branches of the main JDK repository. Just as in SVN-based communities it'd be up to the maintainers of such repositories to stay in sync with the master repository, if they so desire. > Jeff Dinkins wrote: >> ... >> >> I know, these are really questions for the Governance board to work >> out for the constitution. Is this alias a reasonable place for these >> issues to come up for the IGB to take back for discussion? > > I think this list is a good place for bouncing ideas around. If it needs > to be more formal / when it needs to be formalized, we can take it to > gb-discuss and continue the conversation there. Agreed. - Mark From betelgeuse at gentoo.org Thu May 24 18:35:10 2007 From: betelgeuse at gentoo.org (=?UTF-8?B?UGV0dGVyaSBSw6R0eQ==?=) Date: Thu, 24 May 2007 21:35:10 +0300 Subject: Mailing list handler not handling !ASCII names correctly Message-ID: <4655DADE.5030101@gentoo.org> When I try to subscribe to mailing lists I see: Your real name: Petteri Räty 21:26 < tmarble> ok -- for that would you please send an e-mail to discuss? Regards, Petteri -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature URL: From Jeff.Dinkins at Sun.COM Thu May 24 18:48:21 2007 From: Jeff.Dinkins at Sun.COM (Jeff Dinkins) Date: Thu, 24 May 2007 13:48:21 -0500 Subject: Project proposal: fbtoolkit In-Reply-To: References: <46549DAC.30501@sun.com> <4654A2A8.4020400@sun.com> Message-ID: Tom Marble wrote: > Can we get a Group sponsor? So a point of order: http://openjdk.java.net/projects/ "A Group makes this decision by a simple majority vote of its Members, tallied by its Moderator. If at least one Group agrees to sponsor the proposed Project within the two-week discussion period following the proposal then it will automatically be approved." 1. At some point, we'll need a call for votes from the groups involved. Can anyone make the call for vote, or does the group Moderator do it at their will, e.g. when the discussion dies down, or when 2 weeks are up? 2. Tom and Steph have asked for sponsorship from any of these groups: AWT, Swing, & 2D. Should all three take separate votes? From mr at sun.com Thu May 24 19:07:09 2007 From: mr at sun.com (Mark Reinhold) Date: Thu, 24 May 2007 12:07:09 -0700 Subject: Project proposal: fbtoolkit In-Reply-To: jeff.dinkins@sun.com; Thu, 24 May 2007 13:48:21 CDT; Message-ID: <20070524190709.D287884E3@eggemoggin.niobe.net> > Date: Thu, 24 May 2007 13:48:21 -0500 > From: jeff.dinkins at sun.com > So a point of order: > > http://openjdk.java.net/projects/ > "A Group makes this decision by a simple majority vote of > its Members, tallied by its Moderator. If at least one Group > agrees to sponsor the proposed Project within the two-week > discussion period following the proposal then it will > automatically be approved." > > 1. At some point, we'll need a call for votes from the groups involved. > Can anyone make the call for vote, or does the group Moderator do it > at their will, e.g. when the discussion dies down, or when 2 weeks are > up? The intent is that each Group's Moderator should call for a vote at some appropriate time (use your judgement) within the two-week period. > 2. Tom and Steph have asked for sponsorship from any of these groups: > AWT, Swing, & 2D. Should all three take separate votes? Yes. - Mark From Phil.Race at Sun.COM Thu May 24 23:54:00 2007 From: Phil.Race at Sun.COM (Phil Race) Date: Thu, 24 May 2007 16:54:00 -0700 Subject: Project proposal: fbtoolkit In-Reply-To: References: <46549DAC.30501@sun.com> <4654A2A8.4020400@sun.com> Message-ID: <46562598.7030408@sun.com> Hi Steph, Steph Meslin-Weber wrote: > Hi Phil, > > Thanks for your comments, I wasn't certain how verbose the initial > proposal was supposed to be so we left out the details from the > usecases. I don't think we know either. But I'd err on the side of more is better. > > In order to keep this thread in one list (it's starting to confuse > Gmail a bit) we could continue this conversation in discuss for now. > I have Bcc'd the other lists (including 2d following Mark's use) to > let everyone on those lists know to check discuss for followups: > Bcc: awt-dev at openjdk.java.net > Bcc: 2d-dev at openjdk.java.net > Bcc: swing-dev at openjdk.java.net > As the discussion moves on we can move it to the one group that seems > most appropriate. > > On 23/05/07, Phil Race wrote: >> I don't follow what this has to do with Swing. 2D would be more >> affected .. >> Swing is ignorant of whether the Motif or X toolkit is specified >> and even works with the headless toolkit. > > Agreed, Swing shouldn't use knowledge of the underlying > implementation. The reasoning behind including Swing in the discussion > is the SwingAWT work by Roman Kennke. In his project, he implemented > AWT peers using Swing [1]. Now, whether the Swing implementation is > native is another topic of discussion :-) FYI. If you look at openjdk linux/solaris sources, you'll see that XAWT's TextField and TextArea (ie the editable text widgets) use Swing's Motif emulation. > >> Also the existing toolkits can still leverage all of the >> same internal 2D native code for rendering. I don't see where >> you are going to get that from unless if its going to be >> a pure Java solution. > > I think here we tried to show that the example implementation would be > written in pure Java, with extension points to break to native code as > needed: > > "This example implementation will prefer pure-Java solutions, with > public extension points available to enter native resources as > necessary." > > Starting with pure Java means we have a baseline that is easier to > understand than one that jumps back and forth to native code, this > also incidentally makes it an ideal example for those wishing to write > their own set of peers. It's a given that without those jumps certain > optimisations aren't practical to implement, but that's why we'd like > to do this in the open so those situations can be discussed and > planned for. > What I was getting at is how are you drawing geometry, images, text etc? Are you expecting to still use JDK for this (onto a bufferedimage?) > > Before going on to a few usecases, I'd like to mention that I already > have a fair amount of code in support of this proof of concept, including > providers for raw linux fb, VNC and (as of 2 hours ago, thanks Guillaume!) > a pure Java X11 provider; there is also embryonic work on an SDL provider > to ensure we cover as many platforms as possible. Whilst I maybe understand this and your motivations a little better I'm wondering how is this existing code plugged into a JDK? the awt.Toolkit property was never intended as a 'pluggable SPI'. Its a way for the JDK to select between its built-in toolkit options. If you are drawing your text etc by calling back into JDK to do such rendering for you I'm not sure that this will work reliably or perhaps even at all, if one of the built in toolkits was not activated. -phil. From Ray.Gans at Sun.COM Fri May 25 00:43:29 2007 From: Ray.Gans at Sun.COM (Ray Gans) Date: Thu, 24 May 2007 17:43:29 -0700 Subject: Project proposals In-Reply-To: <20070524190709.D287884E3@eggemoggin.niobe.net> References: <20070524190709.D287884E3@eggemoggin.niobe.net> Message-ID: In my opinion, there should generally be a fairly low bar to jump over to get a project approved -- it should be relevant to OpenJDK of course (i.e., text editors, games, etc. belong somewhere else), but research is usually a good thing, even if the direction isn't necessarily the focus of the majority. Groups should sponsor projects that their memberships want associated with the group -- not because they think a project is worthy of being added to the main source distribution, but because the project is relevant to that group's focus area, or that it someday might be. I would expect that discussions about such projects could naturally occur on the group mailing lists and be of interest to some of the group's participants. Groups of course have the ability to define the height of the acceptance bar because their members get to vote. If that bar is set too high, however, projects will be created somewhere else and not in OpenJDK -- which sometimes is appropriate -- but shouldn't occur so often that people feel unwelcome to participate. Hopefully, group members won't often propose projects that are really terrible ideas or inappropriate for a group. And while I certainly don't think we want to create a community of half-baked abandoned projects, I do believe we want to enable people who are excited about working together to solve problems or try out new directions. Disk space is cheap, ideas are not. -Ray From mcculls at gmail.com Fri May 25 02:18:43 2007 From: mcculls at gmail.com (Stuart McCulloch) Date: Fri, 25 May 2007 10:18:43 +0800 Subject: Project proposal: fbtoolkit In-Reply-To: <4655CE76.30503@sun.com> References: <46549DAC.30501@sun.com> <4654A2A8.4020400@sun.com> <4655CE76.30503@sun.com> Message-ID: <81f0d9c0705241918n4ede3f8aoc8fc7895c5f4fdaf@mail.gmail.com> On 25/05/07, Oleg Sukhodolsky wrote: > imho all functionality suggested could be achieved by fb-based XServer, > why do you need to reinvent the wheel and develop a toolkit which will > implement some functionality of XServer, some functionality of Window > Manager, and AWT toolkit. > > What is the advantage of the approach you suggest? perhaps better use of memory/resources? sometimes a bit of (re)invention can uncover new and interesting paths... On 24/05/07, Phil Race wrote: > I don't think we have a clue what sponsorship means. It certainly can't > mean in this case any work from Sun engineers ( wish we had time for > such ideas ourselves), or taking it back into openjdk in any time in the > forseeable future. I guess the question I have about this discussion is whether openjdk is just a place to grab the JDK source, or whether it's a place where people can really take part, innovate and contribute back? > > Thanks, Oleg. > > Steph Meslin-Weber wrote: > > Hi Phil, > > > > Thanks for your comments, I wasn't certain how verbose the initial > > proposal was supposed to be so we left out the details from the > > usecases. > > > > In order to keep this thread in one list (it's starting to confuse > > Gmail a bit) we could continue this conversation in discuss for now. > > I have Bcc'd the other lists (including 2d following Mark's use) to > > let everyone on those lists know to check discuss for followups: > > Bcc: awt-dev at openjdk.java.net > > Bcc: 2d-dev at openjdk.java.net > > Bcc: swing-dev at openjdk.java.net > > As the discussion moves on we can move it to the one group that seems > > most appropriate. > > > > On 23/05/07, Phil Race wrote: > >> I don't follow what this has to do with Swing. 2D would be more > >> affected .. > >> Swing is ignorant of whether the Motif or X toolkit is specified > >> and even works with the headless toolkit. > > > > Agreed, Swing shouldn't use knowledge of the underlying > > implementation. The reasoning behind including Swing in the discussion > > is the SwingAWT work by Roman Kennke. In his project, he implemented > > AWT peers using Swing [1]. Now, whether the Swing implementation is > > native is another topic of discussion :-) > > > >> Also the existing toolkits can still leverage all of the > >> same internal 2D native code for rendering. I don't see where > >> you are going to get that from unless if its going to be > >> a pure Java solution. > > > > I think here we tried to show that the example implementation would be > > written in pure Java, with extension points to break to native code as > > needed: > > > > "This example implementation will prefer pure-Java solutions, with > > public extension points available to enter native resources as > > necessary." > > > > Starting with pure Java means we have a baseline that is easier to > > understand than one that jumps back and forth to native code, this > > also incidentally makes it an ideal example for those wishing to write > > their own set of peers. It's a given that without those jumps certain > > optimisations aren't practical to implement, but that's why we'd like > > to do this in the open so those situations can be discussed and > > planned for. > > > > > > Before going on to a few usecases, I'd like to mention that I already > > have a fair amount of code in support of this proof of concept, including > > providers for raw linux fb, VNC and (as of 2 hours ago, thanks Guillaume!) > > a pure Java X11 provider; there is also embryonic work on an SDL provider > > to ensure we cover as many platforms as possible. > > > >> > Examples of usage include: implementation debugging, device > >> > emulation, multiple-head clone outputs/inputs, simultaneous > >> > multiple-peer output, etc. > > > > Example usecases: > > > > 1) Implementation debugging is one that is fairly simple to explain, > > it becomes a tool for us to track down AWT/Swing issues by excluding > > native resources as a possible error source. (Yes it introduces > > another factor, but at least it's independent). This also allows for > > some device emulation, screen sizes, pixel encoding, etc. > > > > 2) Realtime output/input on a device (say an N800 [2]) with > > simultaneous output/input of the exact same screen contents on an > > attached PC. This is in effect multiplexing two different devices onto > > a single Java stack. Control of the device from the PC. Useful when > > your touchscreen driver isn't written yet. > > > > 3) Distributed remote software agents exposing a VNC or X11 capable > > UI. Easier to secure and to use than a fullblown VNC or X11 server on > > a dedicated host. Easier to deploy too. This is in effect a > > kernel+jvm+libc on any hardware. Including headless ones like a > > router. > > > > 4) Point of Sale, The network is the machine, etc... lightweight PXE > > images booting a rich Swing UI direct to their framebuffer. Small PXE > > image, few external dependencies. For bonus points, let the client > > decide which provider to load from a Jini cloud depending on need. > > > > 5) Multicast a single UI via VNC, kiosk-type advertising or > > interaction: one window per terminal. > > > > Please let me know if I've left a few out. > > > > Thanks, > > Steph > > > > [1] awtswing, http://kennke.org/~roman/swing-based-awt.png > > [2] N800, http://www.nseries.com/n800 > > [3] Maemo, http://maemo.org/ > > > -- Cheers, Stuart (whose all for open participation) From pieter.libin at gmail.com Fri May 25 17:28:00 2007 From: pieter.libin at gmail.com (Pieter Libin) Date: Fri, 25 May 2007 19:28:00 +0200 Subject: building openjdk without openmotif Message-ID: <50be7b020705251028t1477a36dn10e48470246a613e@mail.gmail.com> Dear all, I build openjdk on my system, and ran into the problem that I didn't pass the sanity check because I installed lesstif in stead of openmotif, I did what was suggested on the following site; http://weblogs.java.net/blog/schaefa/archive/2007/05/openjdk_here_i.html, and was able to build openjdk properly. Did the build actually work, or can I run into problems later? If openjdk works fine with lesstif, I think we should add this in the build documentation and mention it as a working alternative to openmotif. If the above is true, we should also fix the sanity check. Kind regards, Pieter Libin -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jeannette.Hung at Sun.COM Fri May 25 17:35:46 2007 From: Jeannette.Hung at Sun.COM (Jeannette Hung) Date: Fri, 25 May 2007 10:35:46 -0700 Subject: Project proposal: fbtoolkit In-Reply-To: <81f0d9c0705241918n4ede3f8aoc8fc7895c5f4fdaf@mail.gmail.com> References: <46549DAC.30501@sun.com> <4654A2A8.4020400@sun.com> <4655CE76.30503@sun.com> <81f0d9c0705241918n4ede3f8aoc8fc7895c5f4fdaf@mail.gmail.com> Message-ID: <46571E72.2000000@sun.com> Hey Stuart, As you probably know, we had been working feverishly to get our code in a state that we could put it out for JavaOne. The amount of software in the JDK is huge, and the amount of work that we've had to do to get it to where we currently have it has taken a lot of people and many, many hours. Because of all of that work, we haven't had much time to work out all of the rules for interim governance, and even less to communicate what's going on so some of what you are seeing is growing pains as we all build a common understanding of how this community will develop. The kinds of questions being asked by the engineers are typical ones asked internally when Sun engineers propose projects that they would like to be accepted. This is certainly necessary for us because we have to make sure that we are properly using our limited internal resources. This type of scrutiny may make less sense for projects that are staffed by non-Sun engineers. I apologize if you are feeling beleaguered -- that was not our intention. This is just the first proposal that we had seen in our groups and we hadn't heard of the notion of sponsorship before this discussion started so you caught us unawares. jeannette Stuart McCulloch wrote: > On 25/05/07, Oleg Sukhodolsky wrote: >> imho all functionality suggested could be achieved by fb-based XServer, >> why do you need to reinvent the wheel and develop a toolkit which will >> implement some functionality of XServer, some functionality of Window >> Manager, and AWT toolkit. >> >> What is the advantage of the approach you suggest? > > perhaps better use of memory/resources? > > sometimes a bit of (re)invention can uncover new and interesting paths... > > On 24/05/07, Phil Race wrote: >> I don't think we have a clue what sponsorship means. It certainly can't >> mean in this case any work from Sun engineers ( wish we had time for >> such ideas ourselves), or taking it back into openjdk in any time in the >> forseeable future. > > I guess the question I have about this discussion is whether openjdk > is just a place to grab the JDK source, or whether it's a place where > people can really take part, innovate and contribute back? > >> >> Thanks, Oleg. >> >> Steph Meslin-Weber wrote: >> > Hi Phil, >> > >> > Thanks for your comments, I wasn't certain how verbose the initial >> > proposal was supposed to be so we left out the details from the >> > usecases. >> > >> > In order to keep this thread in one list (it's starting to confuse >> > Gmail a bit) we could continue this conversation in discuss for now. >> > I have Bcc'd the other lists (including 2d following Mark's use) to >> > let everyone on those lists know to check discuss for followups: >> > Bcc: awt-dev at openjdk.java.net >> > Bcc: 2d-dev at openjdk.java.net >> > Bcc: swing-dev at openjdk.java.net >> > As the discussion moves on we can move it to the one group that seems >> > most appropriate. >> > >> > On 23/05/07, Phil Race wrote: >> >> I don't follow what this has to do with Swing. 2D would be more >> >> affected .. >> >> Swing is ignorant of whether the Motif or X toolkit is specified >> >> and even works with the headless toolkit. >> > >> > Agreed, Swing shouldn't use knowledge of the underlying >> > implementation. The reasoning behind including Swing in the discussion >> > is the SwingAWT work by Roman Kennke. In his project, he implemented >> > AWT peers using Swing [1]. Now, whether the Swing implementation is >> > native is another topic of discussion :-) >> > >> >> Also the existing toolkits can still leverage all of the >> >> same internal 2D native code for rendering. I don't see where >> >> you are going to get that from unless if its going to be >> >> a pure Java solution. >> > >> > I think here we tried to show that the example implementation would be >> > written in pure Java, with extension points to break to native code as >> > needed: >> > >> > "This example implementation will prefer pure-Java solutions, with >> > public extension points available to enter native resources as >> > necessary." >> > >> > Starting with pure Java means we have a baseline that is easier to >> > understand than one that jumps back and forth to native code, this >> > also incidentally makes it an ideal example for those wishing to write >> > their own set of peers. It's a given that without those jumps certain >> > optimisations aren't practical to implement, but that's why we'd like >> > to do this in the open so those situations can be discussed and >> > planned for. >> > >> > >> > Before going on to a few usecases, I'd like to mention that I already >> > have a fair amount of code in support of this proof of concept, >> including >> > providers for raw linux fb, VNC and (as of 2 hours ago, thanks >> Guillaume!) >> > a pure Java X11 provider; there is also embryonic work on an SDL >> provider >> > to ensure we cover as many platforms as possible. >> > >> >> > Examples of usage include: implementation debugging, device >> >> > emulation, multiple-head clone outputs/inputs, simultaneous >> >> > multiple-peer output, etc. >> > >> > Example usecases: >> > >> > 1) Implementation debugging is one that is fairly simple to explain, >> > it becomes a tool for us to track down AWT/Swing issues by excluding >> > native resources as a possible error source. (Yes it introduces >> > another factor, but at least it's independent). This also allows for >> > some device emulation, screen sizes, pixel encoding, etc. >> > >> > 2) Realtime output/input on a device (say an N800 [2]) with >> > simultaneous output/input of the exact same screen contents on an >> > attached PC. This is in effect multiplexing two different devices >> onto >> > a single Java stack. Control of the device from the PC. Useful when >> > your touchscreen driver isn't written yet. >> > >> > 3) Distributed remote software agents exposing a VNC or X11 capable >> > UI. Easier to secure and to use than a fullblown VNC or X11 server on >> > a dedicated host. Easier to deploy too. This is in effect a >> > kernel+jvm+libc on any hardware. Including headless ones like a >> > router. >> > >> > 4) Point of Sale, The network is the machine, etc... lightweight PXE >> > images booting a rich Swing UI direct to their framebuffer. Small PXE >> > image, few external dependencies. For bonus points, let the client >> > decide which provider to load from a Jini cloud depending on need. >> > >> > 5) Multicast a single UI via VNC, kiosk-type advertising or >> > interaction: one window per terminal. >> > >> > Please let me know if I've left a few out. >> > >> > Thanks, >> > Steph >> > >> > [1] awtswing, http://kennke.org/~roman/swing-based-awt.png >> > [2] N800, http://www.nseries.com/n800 >> > [3] Maemo, http://maemo.org/ >> > >> > From neugens at limasoftware.net Fri May 25 18:33:10 2007 From: neugens at limasoftware.net (Mario Torre) Date: Fri, 25 May 2007 20:33:10 +0200 Subject: building openjdk without openmotif In-Reply-To: <50be7b020705251028t1477a36dn10e48470246a613e@mail.gmail.com> References: <50be7b020705251028t1477a36dn10e48470246a613e@mail.gmail.com> Message-ID: <1180117990.3391.21.camel@nirvana.limasoftware.net> Il giorno ven, 25/05/2007 alle 19.28 +0200, Pieter Libin ha scritto: > Dear all, > > I build openjdk on my system, and ran into the problem that I didn't > pass the sanity check because I installed lesstif in stead of > openmotif, > I did what was suggested on the following site; > http://weblogs.java.net/blog/schaefa/archive/2007/05/openjdk_here_i.html, > and was able to build openjdk properly. > Hello! You don't need to create this file, this is never used in the jdk. I've posted a patch here but no one seems to ever had noticed it (other than Petteri :) so I've never had feedback about its correctness, so, let's say, it works for me. The patch just checks for a file that is actually included from the jdk sources and is in lesstif. http://mail.openjdk.java.net/pipermail/discuss/2007-May/000018.html This is way better than writing a fake header file (just think about it, if this file is really used/needed how is supposed to work then?). Hope that helps, Mario -- Lima Software - http://www.limasoftware.net/ GNU Classpath Developer - http://www.classpath.org/ Jabber: neugens at jabber.org - Profile: http://www.gtalkprofile.com/profile/9661.html pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF Please, support open standards: http://opendocumentfellowship.org/petition/ http://www.nosoftwarepatents.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Questa ? una parte del messaggio firmata digitalmente URL: From Tom.Marble at Sun.COM Fri May 25 21:56:37 2007 From: Tom.Marble at Sun.COM (Tom Marble) Date: Fri, 25 May 2007 16:56:37 -0500 Subject: revised Gmane decoder ring Message-ID: <46575B95.4060904@sun.com> All: Thanks to some amazing efforts by Lars, Torsten and Wolfgang we now have all the OpenJDK lists in Gmane. I have hesitated updating the mailing list page so far because we've had some messages not show up and/or some confusion as a result of cross postings. Eventually this will all get sorted out, I'm sure. Below please find the new decoder ring, and let us know if you find weird behavior (extra points if you can determine root cause!) NOTE: I have had received some complaints about the proliferation of so many OpenJDK mailing lists (with little traffic). One RFE is a "subscribe to all" button (that's a good idea). I would please ask your indulgence with the number of lists as I think that as everyone gets used to them it will make more sense. Cross-posting, however, may not work super well :) Regards, --Tom New OpenJDK Gmane Decoder Ring ------------------------------ NOTE: those with the OLD keyword were originally set up with the ".dev" lists; 2d-dev at openjdk.java.net = http://news.gmane.org/gmane.comp.java.openjdk.2d.devel announce at openjdk.java.net = OLD http://news.gmane.org/gmane.comp.java.openjdk.announce audio-engine-dev at openjdk.java.net = http://news.gmane.org/gmane.comp.java.openjdk.audio-engine.devel awt-dev at openjdk.java.net = http://news.gmane.org/gmane.comp.java.openjdk.awt.devel beans-dev at openjdk.java.net = http://news.gmane.org/gmane.comp.java.openjdk.beans.devel build-dev at openjdk.java.net = http://news.gmane.org/gmane.comp.java.openjdk.build.devel compiler-dev at openjdk.java.net = OLD http://news.gmane.org/gmane.comp.java.openjdk.compiler.devel core-libs-dev at openjdk.java.net = http://news.gmane.org/gmane.comp.java.openjdk.core-libs.devel discuss at openjdk.java.net = OLD http://news.gmane.org/gmane.comp.java.openjdk.general distro-pkg-dev at openjdk.java.net = OLD http://news.gmane.org/gmane.comp.java.openjdk.distro-packaging.devel font-scaler-dev at openjdk.java.net = http://news.gmane.org/gmane.comp.java.openjdk.font-scaler.devel gb-discuss at openjdk.java.net = http://news.gmane.org/gmane.comp.java.openjdk.gb graphics-rasterizer-dev at openjdk.java.net = http://news.gmane.org/gmane.comp.java.openjdk.graphics-rasterizer.devel hotspot-compiler-dev at openjdk.java.net = OLD http://news.gmane.org/gmane.comp.java.openjdk.hotspot.compiler.devel hotspot-dev at openjdk.java.net = OLD http://news.gmane.org/gmane.comp.java.openjdk.hotspot.devel hotspot-gc-dev at openjdk.java.net = OLD http://news.gmane.org/gmane.comp.java.openjdk.hotspot.gc.devel hotspot-runtime-dev at openjdk.java.net = OLD http://news.gmane.org/gmane.comp.java.openjdk.hotspot.runtime.devel i18n-dev at openjdk.java.net = http://news.gmane.org/gmane.comp.java.openjdk.i18n.devel javadoc-dev at openjdk.java.net = http://news.gmane.org/gmane.comp.java.openjdk.javadoc.devel jmx-dev at openjdk.java.net = http://news.gmane.org/gmane.comp.java.openjdk.jmx.devel jsr277-eg-observer at openjdk.java.net = http://news.gmane.org/gmane.comp.java.openjdk.jsr277-eg jtreg-use at openjdk.java.net = OLD http://news.gmane.org/gmane.comp.java.openjdk.jtreg.user nb-projects-dev at openjdk.java.net = http://news.gmane.org/gmane.comp.java.openjdk.nb-projects.devel net-dev at openjdk.java.net = http://news.gmane.org/gmane.comp.java.openjdk.net.devel quality-discuss at openjdk.java.net = http://news.gmane.org/gmane.comp.java.openjdk.quality security-dev at openjdk.java.net = http://news.gmane.org/gmane.comp.java.openjdk.security.devel serviceability-dev at openjdk.java.net = http://news.gmane.org/gmane.comp.java.openjdk.serviceability.devel sound-dev at openjdk.java.net = http://news.gmane.org/gmane.comp.java.openjdk.sound.devel swing-dev at openjdk.java.net = http://news.gmane.org/gmane.comp.java.openjdk.swing.devel web-discuss at openjdk.java.net = http://news.gmane.org/gmane.comp.java.openjdk.website From mr at sun.com Tue May 29 05:22:54 2007 From: mr at sun.com (Mark Reinhold) Date: Mon, 28 May 2007 22:22:54 -0700 Subject: New OpenJDK Project: LinalgAlg and Statistics API In-Reply-To: alexanderschunk@t-online.de; Fri, 25 May 2007 11:20:00 -0000; <1HrXpv-0BwWhs0@fwd30.sul.t-online.de> Message-ID: <20070529052254.E3DC85EDE@callebaut.niobe.net> > Date: Fri, 25 May 2007 11:20 +0000 (GMT) > From: alexanderschunk at t-online.de (Alexander Schunk) > i would like to propose two new OpenJDK libraries: JLinAlg and JProb. > The LinAlg API extends the functionality of the java.lang.math library and offers > classes for Vector, Matrix and Complex calculations. > The Statistics API offers classes for statistic calculations. > These packages can be added to Java via the extension mechanism so these are extended APIs. Thanks for your proposal, but per the interim Project guidelines [1] a new Project can only be proposed by a Member of an existing Group. The initial set of Groups was seeded from the Sun engineering team, plus the Governance Board [2], so perhaps you could find someone in one of those Groups willing to sponsor your proposal. Aside from that administrative issue there's also the question of whether these would be appropriate Projects in the OpenJDK Community. Ultimately this sort of question will be answered by the Constitution, but in the interim period it's up to Sun to decide. My own take is that these may be useful libraries but they don't seem particularly related to the purpose of this Community, which is to collaborate on the OpenJDK source code. In that light Projects such as replacements for encumbered code [3,4,5], alternative implementations of internal interfaces [6], implementations of JSRs in flight [7], and ports to new architectures and operating systems are all clearly within scope. Libraries, however useful, that simply extend existing parts of the platform would likely be better off as independent projects on java.net. What do others think? - Mark [1] http://openjdk.java.net/projects/ [2] http://openjdk.java.net/groups/gb/ [3] http://openjdk.java.net/projects/audio-engine/ [4] http://openjdk.java.net/projects/font-scaler/ [5] http://openjdk.java.net/projects/graphics-rasterizer/ [6] http://mail.openjdk.java.net/pipermail/announce/2007-May/000001.html [7] http://openjdk.java.net/projects/modules/ From steph at tangency.co.uk Tue May 29 09:55:00 2007 From: steph at tangency.co.uk (Steph Meslin-Weber) Date: Tue, 29 May 2007 10:55:00 +0100 Subject: Project proposal: fbtoolkit In-Reply-To: <81f0d9c0705241918n4ede3f8aoc8fc7895c5f4fdaf@mail.gmail.com> References: <46549DAC.30501@sun.com> <4654A2A8.4020400@sun.com> <4655CE76.30503@sun.com> <81f0d9c0705241918n4ede3f8aoc8fc7895c5f4fdaf@mail.gmail.com> Message-ID: On 25/05/07, Stuart McCulloch wrote: > On 25/05/07, Oleg Sukhodolsky wrote: > > imho all functionality suggested could be achieved by fb-based XServer, > > why do you need to reinvent the wheel and develop a toolkit which will > > implement some functionality of XServer, some functionality of Window > > Manager, and AWT toolkit. > > > > What is the advantage of the approach you suggest? > > perhaps better use of memory/resources? > > sometimes a bit of (re)invention can uncover new and interesting paths... Stuart's got my main motivation, I'll add a few numbers to back that up though. Looking at the OpenMoko binary images for use on the Neo1973 as an example, it's clear that adding a minimalist X server adds at least 5MB to your dependency footprint... and that's without font or authentication. Each additional 'driver' such as FBDev, SVGA, etc, seem to add 0.5-1MB extra to it. >From existing proofs of concept I've worked on, I believe we can address the usecases I mentioned in well under 1MB (I'm being conservative here, I think under 400KB would be possible). It goes without saying that the above footprint sizes exclude the JRE ;-). For single-use devices or kiosk-type software, the extra size of an XServer just isn't necessary and could be used for more image/sound assets. -- ================================================================ Steph Meslin-Weber, steph at tangency.co.uk ================================================================ From Yuri.Nesterenko at Sun.COM Tue May 29 10:56:05 2007 From: Yuri.Nesterenko at Sun.COM (Yuri Nesterenko) Date: Tue, 29 May 2007 14:56:05 +0400 Subject: building openjdk without openmotif Message-ID: <20070529105605.GA6892@frigate.russia.sun.com> Hi Pieter, lesstif is ok: the necessary headers are just the same, and openJDK doesn't need anything else from a motif clone. All you need is to define path to the headers in ALT_MOTIF_DIR, and then sanity should work properly. Where exactly in your installation of lesstif you should point, you'll find after a try or two. I personally keep just extracted headers somewhere, without actually installing any motif. Thanks, -Yuri From Chien.Yang at Sun.COM Tue May 29 17:17:10 2007 From: Chien.Yang at Sun.COM (Chien Yang) Date: Tue, 29 May 2007 10:17:10 -0700 Subject: New OpenJDK Project: LinalgAlg and Statistics API In-Reply-To: <1HrXpv-0BwWhs0@fwd30.sul.t-online.de> References: <1HrXpv-0BwWhs0@fwd30.sul.t-online.de> Message-ID: <465C6016.3000701@sun.com> Are you aware of an existing Java Matrix package, JAMA, developed by MathWorks and NIST ? http://math.nist.gov/javanumerics/jama/ - Chien. Alexander Schunk wrote: > > i would like to propose two new OpenJDK libraries: JLinAlg and JProb. > > The LinAlg API extends the functionality of the java.lang.math library > and offers > > classes for Vector, Matrix and Complex calculations. > > The Statistics API offers classes for statistic calculations. > > These packages can be added to Java via the extension mechanism so > these are extended APIs. > > Best Regards > > Alexander Schunk > From brian.beck at sun.com Tue May 29 23:30:29 2007 From: brian.beck at sun.com (Brian Beck) Date: Tue, 29 May 2007 16:30:29 -0700 Subject: Regression tests Message-ID: <465CB795.4010105@sun.com> Dave: Good question. I'm taking this over to swing-dev at openjdk.java.net for further discussion but the short answer is we're working on it. Brian. David Gilbert writes: > Hi, > > I've got a fix for a bug in Swing (bug 6463712, related to the JSpinner > component) and have written a regression test that can be run using > jtreg. Now I'm looking to run some other regression tests to validate > my fix before submitting a patch. My understanding is that the > available regression tests are in the OpenJDK source bundle in the > 'j2se/test' directory...but there is nothing there for 'javax.swing.*'. > Elsewhere (on the 2d-dev list) Phil Race said: > > Regression tests - these are in the JDK under test but we are required > > to vet them almost one by one to verify their provenance and this is > > onerous. So most are not there yet. > Is there a plan for getting these tests out? Just asking for > information, I know you're busy... > > In the mean time, I'll run checks with Mauve, then I guess I should just > submit the patch? > > Regards, > > Dave Gilbert > http://www.jfree.org/ > > From pieter.libin at mybiodata.eu Wed May 30 16:34:15 2007 From: pieter.libin at mybiodata.eu (Pieter Libin) Date: Wed, 30 May 2007 18:34:15 +0200 Subject: making j2se more portable Message-ID: <50be7b020705300934l258f6808te9f14e3576da3802@mail.gmail.com> Dear all, I was looking at the j2se part of the openjdk project, and it looks like there is no specific port section for gnu-linux, only for solaris and windows. This works fine, since there are not so many differences between gnu-linux and solaris. However, I think renaming the solaris directory into unix would make a lot of sense. In this source code we could than refer to os-specific parts, fe os::linux::thread ... These efforts will make it much easier to port j2se to other unix systems. Does anyone agrees with this? Kind regards, Pieter Libin MyBioData.eu From Dmitri.Trembovetski at Sun.COM Wed May 30 16:50:36 2007 From: Dmitri.Trembovetski at Sun.COM (Dmitri Trembovetski) Date: Wed, 30 May 2007 09:50:36 -0700 Subject: making j2se more portable In-Reply-To: <50be7b020705300934l258f6808te9f14e3576da3802@mail.gmail.com> References: <50be7b020705300934l258f6808te9f14e3576da3802@mail.gmail.com> Message-ID: <465DAB5C.6050306@Sun.COM> Yes, this had been discussed before, and the consensus was that it needs to be renamed. There was just too much going on to do the rename before the open sourcing, but I think it was planned for shortly afterwards (may be before the transition to Mercurial?). Thanks, Dmitri Pieter Libin wrote: > Dear all, > > I was looking at the j2se part of the openjdk project, > and it looks like there is no specific port section for gnu-linux, > only for solaris and windows. > This works fine, since there are not so many differences between > gnu-linux and solaris. > However, I think renaming the solaris directory into unix would make a > lot of sense. > In this source code we could than refer to os-specific parts, > fe os::linux::thread ... > > These efforts will make it much easier to port j2se to other unix systems. > > Does anyone agrees with this? > > Kind regards, > > Pieter Libin > MyBioData.eu From David.Herron at Sun.COM Wed May 30 17:16:48 2007 From: David.Herron at Sun.COM (David Herron) Date: Wed, 30 May 2007 10:16:48 -0700 Subject: making j2se more portable In-Reply-To: <465DAB5C.6050306@Sun.COM> References: <50be7b020705300934l258f6808te9f14e3576da3802@mail.gmail.com> <465DAB5C.6050306@Sun.COM> Message-ID: <465DB180.4050507@sun.com> And if we're going to rename things, can we make it not be "j2se" ?? ;-) Dmitri Trembovetski wrote: > > Yes, this had been discussed before, and the > consensus was that it needs to be renamed. > > There was just too much going on to do the rename before > the open sourcing, but I think it was planned for shortly > afterwards (may be before the transition to Mercurial?). > > Thanks, > Dmitri > > > Pieter Libin wrote: >> Dear all, >> >> I was looking at the j2se part of the openjdk project, >> and it looks like there is no specific port section for gnu-linux, >> only for solaris and windows. >> This works fine, since there are not so many differences between >> gnu-linux and solaris. >> However, I think renaming the solaris directory into unix would make a >> lot of sense. >> In this source code we could than refer to os-specific parts, >> fe os::linux::thread ... >> >> These efforts will make it much easier to port j2se to other unix >> systems. >> >> Does anyone agrees with this? >> >> Kind regards, >> >> Pieter Libin >> MyBioData.eu From Dmitri.Trembovetski at Sun.COM Wed May 30 17:23:36 2007 From: Dmitri.Trembovetski at Sun.COM (Dmitri Trembovetski) Date: Wed, 30 May 2007 10:23:36 -0700 Subject: making j2se more portable In-Reply-To: <465DB180.4050507@sun.com> References: <50be7b020705300934l258f6808te9f14e3576da3802@mail.gmail.com> <465DAB5C.6050306@Sun.COM> <465DB180.4050507@sun.com> Message-ID: <465DB318.1090401@Sun.COM> David Herron wrote: > > And if we're going to rename things, can we make it not be "j2se" ?? ;-) Yes, we've got to have "tm" somewhere! =) > > Dmitri Trembovetski wrote: >> >> Yes, this had been discussed before, and the >> consensus was that it needs to be renamed. >> >> There was just too much going on to do the rename before >> the open sourcing, but I think it was planned for shortly >> afterwards (may be before the transition to Mercurial?). >> >> Thanks, >> Dmitri >> >> >> Pieter Libin wrote: >>> Dear all, >>> >>> I was looking at the j2se part of the openjdk project, >>> and it looks like there is no specific port section for gnu-linux, >>> only for solaris and windows. >>> This works fine, since there are not so many differences between >>> gnu-linux and solaris. >>> However, I think renaming the solaris directory into unix would make a >>> lot of sense. >>> In this source code we could than refer to os-specific parts, >>> fe os::linux::thread ... >>> >>> These efforts will make it much easier to port j2se to other unix >>> systems. >>> >>> Does anyone agrees with this? >>> >>> Kind regards, >>> >>> Pieter Libin >>> MyBioData.eu > From gbenson at redhat.com Thu May 31 07:36:16 2007 From: gbenson at redhat.com (Gary Benson) Date: Thu, 31 May 2007 08:36:16 +0100 Subject: making j2se more portable In-Reply-To: <50be7b020705300934l258f6808te9f14e3576da3802@mail.gmail.com> References: <50be7b020705300934l258f6808te9f14e3576da3802@mail.gmail.com> Message-ID: <20070531073615.GA3856@redhat.com> Pieter Libin wrote: > However, I think renaming the solaris directory into unix would > make a lot of sense. "posix" would probably be more correct. Cheers, Gary From Phil.Race at Sun.COM Thu May 31 18:10:54 2007 From: Phil.Race at Sun.COM (Phil Race) Date: Thu, 31 May 2007 11:10:54 -0700 Subject: making j2se more portable In-Reply-To: <20070531073615.GA3856@redhat.com> References: <50be7b020705300934l258f6808te9f14e3576da3802@mail.gmail.com> <20070531073615.GA3856@redhat.com> Message-ID: <465F0FAE.1020806@sun.com> Not sure about that for a couple of reasons * The largest chunk of code in src/solaris is related to UI libs (eg X11 etc) which is not in the scope of POSIX. I suspect the same goes for a chunk of the rest. * Some versions of Windows are in fact POSIX compliant too -phil. Gary Benson wrote: > Pieter Libin wrote: >> However, I think renaming the solaris directory into unix would >> make a lot of sense. > > "posix" would probably be more correct. > > Cheers, > Gary From Anthony.Petrov at Sun.COM Thu May 31 07:11:05 2007 From: Anthony.Petrov at Sun.COM (Anthony Petrov) Date: Thu, 31 May 2007 11:11:05 +0400 Subject: making j2se more portable In-Reply-To: <465DAB5C.6050306@Sun.COM> References: <50be7b020705300934l258f6808te9f14e3576da3802@mail.gmail.com> <465DAB5C.6050306@Sun.COM> Message-ID: <465E7509.8060406@sun.com> Well, if we choose this particular 'unix' name for the directory, won't it cause any legal/(tm) issues? PS. Though I agree, renaming makes a lot of sense, but... -- best regards, Anthony On 05/30/2007 08:50 PM Dmitri Trembovetski wrote: > > Yes, this had been discussed before, and the > consensus was that it needs to be renamed. > > There was just too much going on to do the rename before > the open sourcing, but I think it was planned for shortly > afterwards (may be before the transition to Mercurial?). > > Thanks, > Dmitri > > > Pieter Libin wrote: >> Dear all, >> >> I was looking at the j2se part of the openjdk project, >> and it looks like there is no specific port section for gnu-linux, >> only for solaris and windows. >> This works fine, since there are not so many differences between >> gnu-linux and solaris. >> However, I think renaming the solaris directory into unix would make a >> lot of sense. >> In this source code we could than refer to os-specific parts, >> fe os::linux::thread ... >> >> These efforts will make it much easier to port j2se to other unix >> systems. >> >> Does anyone agrees with this? >> >> Kind regards, >> >> Pieter Libin >> MyBioData.eu > From pieter.libin at mybiodata.eu Thu May 31 10:59:36 2007 From: pieter.libin at mybiodata.eu (Pieter Libin) Date: Thu, 31 May 2007 12:59:36 +0200 Subject: making j2se more portable In-Reply-To: <465DB318.1090401@Sun.COM> References: <50be7b020705300934l258f6808te9f14e3576da3802@mail.gmail.com> <465DAB5C.6050306@Sun.COM> <465DB180.4050507@sun.com> <465DB318.1090401@Sun.COM> Message-ID: <50be7b020705310359q11960f21r37f420d6fb7416e4@mail.gmail.com> I was thinking, I could traverse the files containing Linux and Solaris, and make the necessary changes to use the appropriate os specific code. Is this a good plan? greets, Pieter On 5/30/07, Dmitri Trembovetski wrote: > > > David Herron wrote: > > > > And if we're going to rename things, can we make it not be "j2se" ?? ;-) > > Yes, we've got to have "tm" somewhere! =) > > > > > Dmitri Trembovetski wrote: > >> > >> Yes, this had been discussed before, and the > >> consensus was that it needs to be renamed. > >> > >> There was just too much going on to do the rename before > >> the open sourcing, but I think it was planned for shortly > >> afterwards (may be before the transition to Mercurial?). > >> > >> Thanks, > >> Dmitri > >> > >> > >> Pieter Libin wrote: > >>> Dear all, > >>> > >>> I was looking at the j2se part of the openjdk project, > >>> and it looks like there is no specific port section for gnu-linux, > >>> only for solaris and windows. > >>> This works fine, since there are not so many differences between > >>> gnu-linux and solaris. > >>> However, I think renaming the solaris directory into unix would make a > >>> lot of sense. > >>> In this source code we could than refer to os-specific parts, > >>> fe os::linux::thread ... > >>> > >>> These efforts will make it much easier to port j2se to other unix > >>> systems. > >>> > >>> Does anyone agrees with this? > >>> > >>> Kind regards, > >>> > >>> Pieter Libin > >>> MyBioData.eu > > > From pieter.libin at gmail.com Thu May 31 18:20:38 2007 From: pieter.libin at gmail.com (Pieter Libin) Date: Thu, 31 May 2007 20:20:38 +0200 Subject: making j2se more portable In-Reply-To: <465F0FAE.1020806@sun.com> References: <50be7b020705300934l258f6808te9f14e3576da3802@mail.gmail.com> <20070531073615.GA3856@redhat.com> <465F0FAE.1020806@sun.com> Message-ID: <50be7b020705311120k7d0cccb4wed0d56d639cda74a@mail.gmail.com> the name can be discussed, maybe _nix or something On 5/31/07, Phil Race wrote: > Not sure about that for a couple of reasons > > * The largest chunk of code in src/solaris is related to UI libs > (eg X11 etc) which is not in the scope of POSIX. I suspect the > same goes for a chunk of the rest. > > * Some versions of Windows are in fact POSIX compliant too > > -phil. > > Gary Benson wrote: > > Pieter Libin wrote: > >> However, I think renaming the solaris directory into unix would > >> make a lot of sense. > > > > "posix" would probably be more correct. > > > > Cheers, > > Gary > From Andreas.Sterbenz at Sun.COM Thu May 31 18:36:44 2007 From: Andreas.Sterbenz at Sun.COM (Andreas Sterbenz) Date: Thu, 31 May 2007 11:36:44 -0700 Subject: making j2se more portable In-Reply-To: <50be7b020705310359q11960f21r37f420d6fb7416e4@mail.gmail.com> References: <50be7b020705300934l258f6808te9f14e3576da3802@mail.gmail.com> <465DAB5C.6050306@Sun.COM> <465DB180.4050507@sun.com> <465DB318.1090401@Sun.COM> <50be7b020705310359q11960f21r37f420d6fb7416e4@mail.gmail.com> Message-ID: <465F15BC.5000305@sun.com> Pieter Libin wrote: > I was thinking, > I could traverse the files containing Linux and Solaris, > and make the necessary changes to use the appropriate os specific code. I am confused. Are we talking merely about renaming src/solaris to src/unix (or some such) or are we talking about source changes to use different OS APIs? src/solaris today contains the source code for both the Solaris and Linux specific parts of the JDK. Largely the code is the same between the two, and where there are differences it uses #ifdefs or some similar methods. If we don't use the right APIs on Linux, we should obviously fix that. But that should not require a big reorg of the workspace, just a few source changes here and there. If you want to look for places where we do something wrong, I certainly encourage you to do that and to report your findings to the group owning the code. Andreas. From pieter.libin at mybiodata.eu Thu May 31 19:05:53 2007 From: pieter.libin at mybiodata.eu (Pieter Libin) Date: Thu, 31 May 2007 21:05:53 +0200 Subject: making j2se more portable In-Reply-To: <465F15BC.5000305@sun.com> References: <50be7b020705300934l258f6808te9f14e3576da3802@mail.gmail.com> <465DAB5C.6050306@Sun.COM> <465DB180.4050507@sun.com> <465DB318.1090401@Sun.COM> <50be7b020705310359q11960f21r37f420d6fb7416e4@mail.gmail.com> <465F15BC.5000305@sun.com> Message-ID: <50be7b020705311205t67f530a2h6de8195f4f169124@mail.gmail.com> Dear, changing the directory name is one thing, changing the source code to point to the correct os-specific code is another thing. I was already grepping for "linux" and found less then 500 files, most of them only containing minor differences. I think we could make these changes gradually, and we can already start with this even without changing the directory name. Greetings, Pieter On 5/31/07, Andreas Sterbenz wrote: > Pieter Libin wrote: > > I was thinking, > > I could traverse the files containing Linux and Solaris, > > and make the necessary changes to use the appropriate os specific code. > > I am confused. Are we talking merely about renaming src/solaris to > src/unix (or some such) or are we talking about source changes to use > different OS APIs? > > src/solaris today contains the source code for both the Solaris and Linux > specific parts of the JDK. Largely the code is the same between the two, > and where there are differences it uses #ifdefs or some similar methods. > > If we don't use the right APIs on Linux, we should obviously fix that. But > that should not require a big reorg of the workspace, just a few source > changes here and there. If you want to look for places where we do > something wrong, I certainly encourage you to do that and to report your > findings to the group owning the code. > > Andreas. > >