From mark at klomp.org Fri Jul 6 08:52:53 2007 From: mark at klomp.org (Mark Wielaard) Date: Fri, 06 Jul 2007 10:52:53 +0200 Subject: JavaSE 7 build 15 is available at the openjdk.java.net website In-Reply-To: <468D9018.80903@sun.com> References: <468D9018.80903@sun.com> Message-ID: <1183711974.3651.45.camel@dijkstra.wildebeest.org> On Thu, 2007-07-05 at 17:43 -0700, Xiomara Jayasena wrote: > The OpenJDK source, Compiler source and Jtreg binary for the promoted > JavaSE 7 build b15 is available under the openjdk > https://openjdk.dev.java.net website under Source Code (direct link to > bundles: http://download.java.net/openjdk/jdk7 ) > > The OpenJDK sources are also available at the subversion repository > https://openjdk.dev.java.net/source/browse/openjdk For those looking for the changes in this release look at: http://download.java.net/jdk7/changes/jdk7-b15.html The read-only mercurial mirror on icedtea.classpath.org (as announced on distro-pkg-dev) did indeed auto update without any manual interference necessary, so you can also get the update through hg pull && hg update now if you use that. 556 files updated, 0 files merged, 24 files removed, 0 files unresolved BTW. When will the source code for jtreg be released? Cheers, Mark From fkung at redhat.com Fri Jul 6 16:57:14 2007 From: fkung at redhat.com (Francis Kung) Date: Fri, 06 Jul 2007 12:57:14 -0400 Subject: JavaSE 7 build 15 is available at the openjdk.java.net website In-Reply-To: <468D9018.80903@sun.com> References: <468D9018.80903@sun.com> Message-ID: <468E746A.6070806@redhat.com> Hi, > The OpenJDK source, Compiler source and Jtreg binary for the promoted > JavaSE 7 build b15 is available under the openjdk > https://openjdk.dev.java.net website under Source Code (direct link to > bundles: http://download.java.net/openjdk/jdk7 ) I am seeing a build failure with this release: openjdk/hotspot/src/cpu/i486/vm/assembler_i486.hpp:161: error: extra qualification ?Address::? on member ?Address? Applying this patch fixes the issue: http://icedtea.classpath.org/hg/icedtea/diff/f37ba6246a75/patches/icedtea-buildfix.patch Cheers, Francis From David.Herron at Sun.COM Fri Jul 6 17:21:32 2007 From: David.Herron at Sun.COM (David Herron) Date: Fri, 06 Jul 2007 10:21:32 -0700 Subject: Harness source availability; was: Re: JavaSE 7 build 15 is available at the openjdk.java.net website In-Reply-To: <1183711974.3651.45.camel@dijkstra.wildebeest.org> References: <468D9018.80903@sun.com> <1183711974.3651.45.camel@dijkstra.wildebeest.org> Message-ID: <468E7A1C.3030501@sun.com> Mark Wielaard wrote: > BTW. When will the source code for jtreg be released? > > Cheers, > > Mark Hi Mark, I cannot answer about jtreg source code release, that's a question for others to answer. But I am curious for some data which will help with a proposal I'm due to make next week. Is it required, from your perspective, that the harness source be available? If so, why? I think there's no legal requirement .. that an open source test can be executed by a binary-only harness so long as there's license compatibility allowing for this. The impending proposal I'm due to make is about release of some tests from the quality team. There are various considerations under which we are likely to release those tests using a harness that's used by the quality team and to keep our cost low the proposal is to release this harness as a binary, just as jtreg has been released as a binary. It would help me to understand your thinking regarding a binary harness. - David Herron From mark at klomp.org Sat Jul 7 00:49:50 2007 From: mark at klomp.org (Mark Wielaard) Date: Sat, 07 Jul 2007 02:49:50 +0200 Subject: Harness source availability; was: Re: JavaSE 7 build 15 is available at the openjdk.java.net website In-Reply-To: <468E7A1C.3030501@sun.com> References: <468D9018.80903@sun.com> <1183711974.3651.45.camel@dijkstra.wildebeest.org> <468E7A1C.3030501@sun.com> Message-ID: <1183769391.3651.119.camel@dijkstra.wildebeest.org> Hi David, On Fri, 2007-07-06 at 10:21 -0700, David Herron wrote: > Mark Wielaard wrote: > > BTW. When will the source code for jtreg be released? > > I cannot answer about jtreg source code release, that's a question for > others to answer. But I am curious for some data which will help with a > proposal I'm due to make next week. > > Is it required, from your perspective, that the harness source be > available? If so, why? > > I think there's no legal requirement .. that an open source test can be > executed by a binary-only harness so long as there's license > compatibility allowing for this. Well a binary harness is just not free software. So we immediately have the practical problem that those people only working with free software will not make use of any of the tests. These people include the distro packagers (like Fedora and Debian). This is a problem since to make sure the quality of packages is maintained the testsuite is often run during the package build process. If the harness isn't free software then it and all the tests that are dependent on it cannot be distributed with the package (sources) and so any derivative distribution (think rhel -> centos, debian -> ubuntu, or liveCDs derived from some existing distro, etc) that rebuilds the packages for their platform (which might have subtle differences like the exact library versions, or just a different default set of optimisations) doesn't get to run those tests and so there is less compatibility and quality assurance. > The impending proposal I'm due to make is about release of some tests > from the quality team. There are various considerations under which we > are likely to release those tests using a harness that's used by the > quality team and to keep our cost low the proposal is to release this > harness as a binary, just as jtreg has been released as a binary. It > would help me to understand your thinking regarding a binary harness. It would be a shame if you wouldn't release parts if you cannot at the moment also release the harness. So please do release as much as you feel comfortable with. But don't be surprised if people will want to replace the harness with something based on free software. Just like they are doing for the binary plugs in the openjdk libraries. It is just what people like best, having (and creating) a full set of free tools. And in the long run it is also the most pragmatic solution since given enough time there will be some reason to want to change or adapt such a harness. Maybe it actually has a bug! Or it is missing some feature (and you can be sure that day will come the more you rely on it). Cheers, Mark From David.Herron at Sun.COM Sat Jul 7 01:54:19 2007 From: David.Herron at Sun.COM (David Herron) Date: Fri, 06 Jul 2007 18:54:19 -0700 Subject: Harness source availability; was: Re: JavaSE 7 build 15 is available at the openjdk.java.net website In-Reply-To: <1183769391.3651.119.camel@dijkstra.wildebeest.org> References: <468D9018.80903@sun.com> <1183711974.3651.45.camel@dijkstra.wildebeest.org> <468E7A1C.3030501@sun.com> <1183769391.3651.119.camel@dijkstra.wildebeest.org> Message-ID: <468EF24B.4050706@sun.com> Hey Mark, That's good feedback and it will make for an interesting counterpoint when I talk with my managers next week. FWIW my thought regarding releasing the source to our (SQE's) harness is that I don't know how y'all will respond to this harness. If we release it and you hate it then we will have wasted a lot of man-hours getting it published. I'm thinking to release the binary, look at the response, and then act accordingly. But it sounds like you're likely to ignore it and I won't be able to judge the response ... Hurm. - David Herron Mark Wielaard wrote: > It would be a shame if you wouldn't release parts if you cannot at the > moment also release the harness. So please do release as much as you > feel comfortable with. But don't be surprised if people will want to > replace the harness with something based on free software. Just like > they are doing for the binary plugs in the openjdk libraries. It is just > what people like best, having (and creating) a full set of free tools. > > And in the long run it is also the most pragmatic solution since given > enough time there will be some reason to want to change or adapt such a > harness. Maybe it actually has a bug! Or it is missing some feature (and > you can be sure that day will come the more you rely on it). > > Cheers, > > Mark > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From neugens at limasoftware.net Sat Jul 7 10:59:39 2007 From: neugens at limasoftware.net (Mario Torre) Date: Sat, 07 Jul 2007 12:59:39 +0200 Subject: Harness source availability; was: Re: JavaSE 7 build 15 is available at the openjdk.java.net website In-Reply-To: <468EF24B.4050706@sun.com> References: <468D9018.80903@sun.com> <1183711974.3651.45.camel@dijkstra.wildebeest.org> <468E7A1C.3030501@sun.com> <1183769391.3651.119.camel@dijkstra.wildebeest.org> <468EF24B.4050706@sun.com> Message-ID: <1183805979.3752.21.camel@nirvana.limasoftware.net> Il giorno ven, 06/07/2007 alle 18.54 -0700, David Herron ha scritto: > > Hey Mark, > > That's good feedback and it will make for an interesting counterpoint > when I talk with my managers next week. > > FWIW my thought regarding releasing the source to our (SQE's) harness > is that I don't know how y'all will respond to this harness. If we > release it and you hate it then we will have wasted a lot of man-hours > getting it published. I'm thinking to release the binary, look at the > response, and then act accordingly. But it sounds like you're likely > to ignore it and I won't be able to judge the response ... > > Hurm. > > - David Herron Hi David! Just my two cents... As part of the Mauve (and Classpath of course) developers I've learned how tests are even more important on a jvm/classlibrary when you need to assure a quality level to your products, no matters how the test harness is done. More over, people tests things in a variety of ways, for example, few days ago Andrew John Hughes told me that his work on JikesRVM with Classpath exposed a number of interesting bugs and that we should include building JikesRVM by default in our testing cycle (and most of our tests are not even part of Mauve, but are simple or real life applications [1]). I don't get the point of "If we release it and you hate it then we will have wasted a lot of man-hours getting it published". Sure, there is risk... but if we don't like it, we will change it! The more the tests, the better the result. So, if this can be of any help, and you don't have any legal stuff to be worried about, I'm sure we will welcome the new bits just like we did with OpenJDK, Netbeans, Glassfish and OpenOffice (oh, yeah, and Solaris! missing something else?) After all, the only possibility I see for us to reject the harness is that it is of very poor quality and actually it is useless, but this is science fiction given the high level of your engineers. Of course, if that is the case, you have worse problem to take care about! :) [2] Just my 0.02 ?. Ciao, Mario [1] Even wild free software projects spend lots of time testing, yeah, we like to watch our code running :) [2] Just kidding, I was really impressed at FOSDEM about what you said on this matter. -- Lima Software - http://www.limasoftware.net/ GNU Classpath Developer - http://www.classpath.org/ Fedora Ambassador - http://fedoraproject.org/wiki/MarioTorre Jabber: neugens at jabber.org 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 gbenson at redhat.com Sat Jul 7 11:28:02 2007 From: gbenson at redhat.com (Gary Benson) Date: Sat, 7 Jul 2007 12:28:02 +0100 Subject: Harness source availability; was: Re: JavaSE 7 build 15 is available at the openjdk.java.net website In-Reply-To: <468EF24B.4050706@sun.com> References: <468D9018.80903@sun.com> <1183711974.3651.45.camel@dijkstra.wildebeest.org> <468E7A1C.3030501@sun.com> <1183769391.3651.119.camel@dijkstra.wildebeest.org> <468EF24B.4050706@sun.com> Message-ID: <20070707112802.GA19318@redhat.com> Hi David, Free software developers can have this weird blind spot for non-free stuff. It can seem like puritanism or zealotry but there's actually a deep sense of pragmatism behind it. Most people who would be interested in a test harness aren't going to see it as a curiosity, something to play with for a day or a week and then forget. They're going to want to integrate it into their build systems, maybe write some tests of their own. This kind of thing requires a certain investment of time and effort, so you want to make sure that your investment will pay off long term. But with a closed harness, well, sooner or later you're going to hit a bug, or there'll be some functionality that could make your life a million times easier, if only you had the ability to add it. Or maybe you just upgrade your OS one day to find the harness now doesn't run, and maybe the harness provider doesn't care about your new OS so never makes a release. All your work was for nothing. Over time most of us have been bitten one way or another by something like this. Cheers, Gary David Herron wrote: > Hey Mark, > > That's good feedback and it will make for an interesting > counterpoint when I talk with my managers next week. > > FWIW my thought regarding releasing the source to our (SQE's) > harness is that I don't know how y'all will respond to this > harness. If we release it and you hate it then we will have > wasted a lot of man-hours getting it published. I'm thinking > to release the binary, look at the response, and then act > accordingly. But it sounds like you're likely to ignore it > and I won't be able to judge the response ... > > Hurm. > > - David Herron > > Mark Wielaard wrote: > > It would be a shame if you wouldn't release parts if you cannot at > > the moment also release the harness. So please do release as much > > as you feel comfortable with. But don't be surprised if people > > will want to replace the harness with something based on free > > software. Just like they are doing for the binary plugs in the > > openjdk libraries. It is just what people like best, having (and > > creating) a full set of free tools. > > > > And in the long run it is also the most pragmatic solution since > > given enough time there will be some reason to want to change or > > adapt such a harness. Maybe it actually has a bug! Or it is > > missing some feature (and you can be sure that day will come the > > more you rely on it). > > > > Cheers, > > > > Mark From dan at fabulich.com Sun Jul 8 06:24:02 2007 From: dan at fabulich.com (Dan Fabulich) Date: Sat, 7 Jul 2007 23:24:02 -0700 (Pacific Daylight Time) Subject: JavaSE 7 build 15 is available at the openjdk.java.net website In-Reply-To: <467C24A6.1070908@sun.com> References: <467B5513.30509@sun.com> <1182502239.6707.3.camel@dijkstra.wildebeest.org> <467BE76A.5030408@sun.com> <467C24A6.1070908@sun.com> Message-ID: Sadly, the plugs for build 15 still don't include t2k.lib, so build 15 still won't build on Windows. What's the word? Should I expect this in build 16? Is this file still caught in a legal snag? -Dan Kelly O'Hair wrote: > > We ran into a legal snag for fixing this in Build 14. The changes were > all ready, so it will be in Build 15 for sure. > Sorry about that. > > -kto > > Dan Fabulich wrote: >> >> The Windows binary plugs for build 14 still don't include t2k.lib, a >> critical missing file required to build on Windows. The t2k.lib bug >> remains open. >> >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6555215 >> >> I know Kelly's working on this... Maybe I got too excited when I saw that a >> new build was available. :-) >> >> http://mail.openjdk.java.net/pipermail/build-dev/2007-June/000075.html >> >> Wouldn't it make sense at this point to just withdraw the Windows binary >> plugs until working plugs are available or become unnecessary? >> >> -Dan > From Dmitri.Trembovetski at Sun.COM Sun Jul 8 06:47:05 2007 From: Dmitri.Trembovetski at Sun.COM (Dmitri Trembovetski) Date: Sat, 07 Jul 2007 23:47:05 -0700 Subject: JavaSE 7 build 15 is available at the openjdk.java.net website In-Reply-To: References: <467B5513.30509@sun.com> <1182502239.6707.3.camel@dijkstra.wildebeest.org> <467BE76A.5030408@sun.com> <467C24A6.1070908@sun.com> Message-ID: <46908869.8060701@Sun.COM> Hopefully the plug won't be needed soon - the fix for the t2k replacement by freetype in OpenJDK build is under code review now. It will probably not make it into the next build, though. Thanks, Dmitri Java2D Team Dan Fabulich wrote: > > Sadly, the plugs for build 15 still don't include t2k.lib, so build 15 > still won't build on Windows. > > What's the word? Should I expect this in build 16? Is this file still > caught in a legal snag? > > -Dan > > Kelly O'Hair wrote: > >> >> We ran into a legal snag for fixing this in Build 14. The changes were >> all ready, so it will be in Build 15 for sure. >> Sorry about that. >> >> -kto >> >> Dan Fabulich wrote: >>> >>> The Windows binary plugs for build 14 still don't include t2k.lib, a >>> critical missing file required to build on Windows. The t2k.lib bug >>> remains open. >>> >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6555215 >>> >>> I know Kelly's working on this... Maybe I got too excited when I saw >>> that a new build was available. :-) >>> >>> http://mail.openjdk.java.net/pipermail/build-dev/2007-June/000075.html >>> >>> Wouldn't it make sense at this point to just withdraw the Windows >>> binary plugs until working plugs are available or become unnecessary? >>> >>> -Dan >> > From casey.s.marshall at gmail.com Sun Jul 8 19:10:47 2007 From: casey.s.marshall at gmail.com (Casey Marshall) Date: Sun, 8 Jul 2007 12:10:47 -0700 Subject: Enabling free JSSE Message-ID: Hi. I'm just posting this note that I've implemented some missing bits needed by the JSSE provider in OpenJDK, and now IcedTea (which is using a combination of GNU Classpath's crypto algorithms and Sun's SSL provider) can make SSL connections. This implements the KeyGenerator algorithms SunTlsPrf, etc. The files are here: http://icedtea.classpath.org/hg/icedtea/file/5465e5a55631/jce/gnu/ java/security/icedtea/ I don't know what Sun's plans are for the missing pieces of the PKCS11 provider (where these missing algorithms were), but I'll still offer my implementation to OpenJDK just the same. Thanks. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2435 bytes Desc: not available URL: From Jonathan.Gibbons at Sun.COM Mon Jul 9 14:04:36 2007 From: Jonathan.Gibbons at Sun.COM (Jonathan Gibbons) Date: Mon, 09 Jul 2007 07:04:36 -0700 Subject: Harness source availability; was: Re: JavaSE 7 build 15 is available at the openjdk.java.net website In-Reply-To: <468E7A1C.3030501@sun.com> References: <468D9018.80903@sun.com> <1183711974.3651.45.camel@dijkstra.wildebeest.org> <468E7A1C.3030501@sun.com> Message-ID: <7B431F1E-5C46-4E87-872E-4D1B25C2DCF7@sun.com> Mark, Most of the source code for jtreg is public, because jtreg is based upon JavaTest, available in open source as "JT Harness" on java.net. However, I agree that "most" doesn't quite cut it :-) The primary reason that we have not yet released the rest of the jtreg source code is a perceived lack of demand (your email is the first interest I have seen) and as always, a lack of resources, which together have lowered the priority on this work. -- Jonathan Gibbons On Jul 6, 2007, at 10:21 AM, David Herron wrote: > Mark Wielaard wrote: >> BTW. When will the source code for jtreg be released? >> >> Cheers, >> >> Mark > > Hi Mark, > > I cannot answer about jtreg source code release, that's a question > for others to answer. But I am curious for some data which will > help with a proposal I'm due to make next week. > > Is it required, from your perspective, that the harness source be > available? If so, why? > > I think there's no legal requirement .. that an open source test > can be executed by a binary-only harness so long as there's license > compatibility allowing for this. > > The impending proposal I'm due to make is about release of some > tests from the quality team. There are various considerations > under which we are likely to release those tests using a harness > that's used by the quality team and to keep our cost low the > proposal is to release this harness as a binary, just as jtreg has > been released as a binary. It would help me to understand your > thinking regarding a binary harness. > > - David Herron > > From neugens at limasoftware.net Mon Jul 9 14:35:36 2007 From: neugens at limasoftware.net (Mario Torre) Date: Mon, 09 Jul 2007 16:35:36 +0200 Subject: Harness source availability; was: Re: JavaSE 7 build 15 is available at the openjdk.java.net website In-Reply-To: <7B431F1E-5C46-4E87-872E-4D1B25C2DCF7@sun.com> References: <468D9018.80903@sun.com> <1183711974.3651.45.camel@dijkstra.wildebeest.org> <468E7A1C.3030501@sun.com> <7B431F1E-5C46-4E87-872E-4D1B25C2DCF7@sun.com> Message-ID: <1183991736.4402.5.camel@nirvana.limasoftware.net> Il giorno lun, 09/07/2007 alle 07.04 -0700, Jonathan Gibbons ha scritto: > However, I agree that "most" doesn't quite cut it :-) The primary > reason that we have not yet released the rest of the jtreg source > code is a perceived lack of demand (your email is the first interest > I have seen) and as always, a lack of resources, which together have > lowered the priority on this work. > > -- Jonathan Gibbons Hi Jonathan! I think the "perceived lack of demand" was just that, perceived. Of course, I can only speak for myself, but I guess that many of us consider the tests as part of the code, that's why no one showed explicit interest before. As for the lack of resources, I guess that this have to solved inside Sun, but of course, if there is anything we can do, just shot :) Mario -- Lima Software - http://www.limasoftware.net/ GNU Classpath Developer - http://www.classpath.org/ Fedora Ambassador - http://fedoraproject.org/wiki/MarioTorre Jabber: neugens at jabber.org 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 Jonathan.Gibbons at Sun.COM Mon Jul 9 16:43:01 2007 From: Jonathan.Gibbons at Sun.COM (Jonathan Gibbons) Date: Mon, 09 Jul 2007 09:43:01 -0700 Subject: Harness source availability; was: Re: JavaSE 7 build 15 is available at the openjdk.java.net website In-Reply-To: <1183991736.4402.5.camel@nirvana.limasoftware.net> References: <468D9018.80903@sun.com> <1183711974.3651.45.camel@dijkstra.wildebeest.org> <468E7A1C.3030501@sun.com> <7B431F1E-5C46-4E87-872E-4D1B25C2DCF7@sun.com> <1183991736.4402.5.camel@nirvana.limasoftware.net> Message-ID: <97C59134-F9E7-4E32-8829-D1D78E47854F@Sun.COM> Mario, Thank you for your interest; I will adjust our internal priorities accordingly. -- Jonathan On Jul 9, 2007, at 7:35 AM, Mario Torre wrote: > Il giorno lun, 09/07/2007 alle 07.04 -0700, Jonathan Gibbons ha > scritto: > >> However, I agree that "most" doesn't quite cut it :-) The primary >> reason that we have not yet released the rest of the jtreg source >> code is a perceived lack of demand (your email is the first interest >> I have seen) and as always, a lack of resources, which together have >> lowered the priority on this work. >> >> -- Jonathan Gibbons > > Hi Jonathan! > > I think the "perceived lack of demand" was just that, perceived. Of > course, I can only speak for myself, but I guess that many of us > consider the tests as part of the code, that's why no one showed > explicit interest before. As for the lack of resources, I guess that > this have to solved inside Sun, but of course, if there is anything we > can do, just shot :) > > Mario > > -- > Lima Software - http://www.limasoftware.net/ > GNU Classpath Developer - http://www.classpath.org/ > Fedora Ambassador - http://fedoraproject.org/wiki/MarioTorre > Jabber: neugens at jabber.org > 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/ From hwadechandler-openjdk at yahoo.com Tue Jul 10 05:44:07 2007 From: hwadechandler-openjdk at yahoo.com (hwadechandler-openjdk at yahoo.com) Date: Mon, 9 Jul 2007 22:44:07 -0700 (PDT) Subject: Apache Open Letter, JCK, etc Message-ID: <725472.92826.qm@web33802.mail.mud.yahoo.com> All, I have been asking on the Apache lists about the JCK and the issues which keep them from being able to distribute their JRE or JDK to end users without the users being liable for patent infringement etc. I have been asking Sun guys associated with NB. I'm not sure I understand the issue here and nobody so far can tell me much. Anyways, the Apache person who wrote me back says they can't give me a copy of the license to review which they are talking about. Supposedly it affects an end user using a Harmony runtime. They say the TCK/JCK license restricts a tested/certified JRE being used by an end user. Can I get a copy of the JCK license (license only) which I can review? Who does one need to talk to about this? I'm just trying to figure this out. According to what I have been directly e-mail the JCK license affects users who use a certified JRE/JDK, and something in the license some how limits the field of use for an end user of a certified runtime or development kit. Does anyone know if this is true? Just a member of different Java projects here...including NetBeans. Thanks, Wade ================== Wade Chandler Software Engineer and Developer Netbeans Community and Dream Team Member: http://wiki.netbeans.org/wiki/view/NetBeansDreamTeam Check out Netbeans at: http://www.netbeans.org From ernad.husremovic at sigma-com.net Fri Jul 13 10:40:20 2007 From: ernad.husremovic at sigma-com.net (Ernad Husremovic) Date: Fri, 13 Jul 2007 12:40:20 +0200 (CEST) Subject: openjdk firefox java plugin, java web start Message-ID: <12089507.2561184323220000.JavaMail.root@zimbra-1.sigma-com.net> When we can expect openjdk firefox plugin ? As we know, there is no appropriate linux amd64 plugin support. On my ubuntu/amd64 box, I shoud install manually firefox32 to run (sun) java applets. For Java web start, there is workaround with installing 32bit java packages. What are possible directions regarding this issue(s) ? To be honest, I am quite confused with Sun decisions. There is promotion of javafx technology on one side, and no good solution for core technologies on the other side needed for javafx. Regards, Ernad From mark at klomp.org Fri Jul 13 11:21:51 2007 From: mark at klomp.org (Mark Wielaard) Date: Fri, 13 Jul 2007 13:21:51 +0200 Subject: openjdk firefox java plugin, java web start In-Reply-To: <12089507.2561184323220000.JavaMail.root@zimbra-1.sigma-com.net> References: <12089507.2561184323220000.JavaMail.root@zimbra-1.sigma-com.net> Message-ID: <1184325712.3632.41.camel@dijkstra.wildebeest.org> Hi Ernad, On Fri, 2007-07-13 at 12:40 +0200, Ernad Husremovic wrote: > When we can expect openjdk firefox plugin ? > As we know, there is no appropriate linux amd64 plugin support. > On my ubuntu/amd64 box, I shoud install manually firefox32 to run (sun) java applets. > For Java web start, there is workaround with installing 32bit java packages. > What are possible directions regarding this issue(s) ? The only effort that I know of is trying to integrate the GNU Classpath webplugin code with the generic appletviewer as found in openjdk: http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=38 Since gcjwebplugin already works with most variants of GNU/Linux mozilla-like browsers on all architectures that GNU Classpath/gcj is available on that would automagically get you amd64 support. As far as I know Sun has not given any indication if/when the old, proprietary (encumbered?) plugin code would be released under the GPL. Cheers, Mark From mark at klomp.org Sat Jul 21 10:27:23 2007 From: mark at klomp.org (Mark Wielaard) Date: Sat, 21 Jul 2007 12:27:23 +0200 Subject: JavaSE 7 build 16 is available at the openjdk.java.net website In-Reply-To: <46A14522.5000907@Sun.COM> References: <46A14522.5000907@Sun.COM> Message-ID: <1185013643.2863.28.camel@unknown-00-16-41-12-b2-a9.lan> On Fri, 2007-07-20 at 16:28 -0700, Xiomara.Jayasena at Sun.COM wrote: > The OpenJDK source, Compiler source and Jtreg binary for the promoted > JavaSE 7 build b16 is available under the openjdk > http://openjdk.java.net website under Source Code (direct link to > bundles: http://download.java.net/openjdk/jdk7 ) > > The OpenJDK sources are also available at the subversion repository > http://openjdk.dev.java.net/source/browse/openjdk Cool, thanks. For those looking for the changes in this release look at: http://download.java.net/jdk7/changes/jdk7-b16.html Could something like that, or a summary, be included in release announcements? Is there a list of issues being worked on for b17? The read-only mercurial mirror on icedtea.classpath.org did auto update, but we have some domain troubles at the moment (yeah, the domain expired without anybody noticing, woops...). So for now you will have to use the emergency host name icedtea.classpath.berkeleysignal.com it will just work with an already cloned repository: $ hg pull http://icedtea.classpath.berkeleysignal.com/hg/openjdk/ $ hg update 174 files updated, 0 files merged, 2 files removed, 0 files unresolved Cheers, Mark From gnu_andrew at member.fsf.org Tue Jul 24 21:46:50 2007 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Tue, 24 Jul 2007 22:46:50 +0100 Subject: JavaSE 7 build 15 is available at the openjdk.java.net website In-Reply-To: <468E746A.6070806@redhat.com> References: <468D9018.80903@sun.com> <468E746A.6070806@redhat.com> Message-ID: <200707242246.56944.gnu_andrew@member.fsf.org> On Friday 06 July 2007 17:57, Francis Kung wrote: > Hi, > > > The OpenJDK source, Compiler source and Jtreg binary for the promoted > > JavaSE 7 build b15 is available under the openjdk > > https://openjdk.dev.java.net website under Source Code (direct link to > > bundles: http://download.java.net/openjdk/jdk7 ) > > I am seeing a build failure with this release: > > openjdk/hotspot/src/cpu/i486/vm/assembler_i486.hpp:161: error: extra > qualification ?Address::? on member ?Address? > > Applying this patch fixes the issue: > http://icedtea.classpath.org/hg/icedtea/diff/f37ba6246a75/patches/icedtea-b >uildfix.patch > > Cheers, > Francis I'm also seeing a failure with b15 on amd64, both building it via IcedTea and running the downloadable build. # Internal Error (relocInfo_amd64.cpp:67), pid=914, tid=1076017504 # Error: ShouldNotReachHere() It occurs from just running 'java' and the rest of the build fails because HotSpot can't be used to build j2se. I've filed a bug report with the full hs_err file details. This also still occurs with b16. Cheers, -- Andrew :-) Help end the Java Trap! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From aph at redhat.com Wed Jul 25 10:59:42 2007 From: aph at redhat.com (Andrew Haley) Date: Wed, 25 Jul 2007 11:59:42 +0100 Subject: JavaSE 7 build 15 is available at the openjdk.java.net website In-Reply-To: <200707242246.56944.gnu_andrew@member.fsf.org> References: <468D9018.80903@sun.com> <468E746A.6070806@redhat.com> <200707242246.56944.gnu_andrew@member.fsf.org> Message-ID: <18087.11550.48871.902237@zebedee.pink> Andrew John Hughes writes: > On Friday 06 July 2007 17:57, Francis Kung wrote: > > Hi, > > > > > The OpenJDK source, Compiler source and Jtreg binary for the promoted > > > JavaSE 7 build b15 is available under the openjdk > > > https://openjdk.dev.java.net website under Source Code (direct link to > > > bundles: http://download.java.net/openjdk/jdk7 ) > > > > I am seeing a build failure with this release: > > > > openjdk/hotspot/src/cpu/i486/vm/assembler_i486.hpp:161: error: extra > > qualification ?Address::? on member ?Address? > > > > Applying this patch fixes the issue: > > http://icedtea.classpath.org/hg/icedtea/diff/f37ba6246a75/patches/icedtea-buildfix.patch > > > > Cheers, > > Francis > > I'm also seeing a failure with b15 on amd64, both building it via IcedTea and > running the downloadable build. > > # Internal Error (relocInfo_amd64.cpp:67), pid=914, tid=1076017504 > # Error: ShouldNotReachHere() > > It occurs from just running 'java' and the rest of the build fails because > HotSpot can't be used to build j2se. I've filed a bug report with the full > hs_err file details. URL, please. > This also still occurs with b16. This is a similar problem to my Assembler::check_relocation patch, and I suspect it's kernel dependent. On later kernels, entry points for some syscalls require a 64-bit offset, so the usual "call foo" form of an instruction doesn't work. Instead, you have to do mov addr64, %r10 call *%r10 The logic that generates the 64-bit call is here: void MacroAssembler::call(AddressLiteral entry) { if (reachable(entry)) { Assembler::call_literal(entry.target(), entry.rspec()); } else { lea(rscratch1, entry); Assembler::call(rscratch1); } } So, Relocation::pd_call_destination needs to be modified to cope with this. It's fairly easy to fix if you can debug the fault, but hard otherwise. You just have to add the pattern above to the if..else chain. You might like to put a breakpoint on MacroAssembler::call(AddressLiteral) to see what function is triggering this. Andrew. -- Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK Registered in England and Wales No. 3798903 From mark at klomp.org Wed Jul 25 14:57:15 2007 From: mark at klomp.org (Mark Wielaard) Date: Wed, 25 Jul 2007 16:57:15 +0200 Subject: JavaSE 7 build 15 is available at the openjdk.java.net website In-Reply-To: <18087.11550.48871.902237@zebedee.pink> References: <468D9018.80903@sun.com> <468E746A.6070806@redhat.com> <200707242246.56944.gnu_andrew@member.fsf.org> <18087.11550.48871.902237@zebedee.pink> Message-ID: <1185375436.3597.36.camel@dijkstra.wildebeest.org> On Wed, 2007-07-25 at 11:59 +0100, Andrew Haley wrote: > > I'm also seeing a failure with b15 on amd64, both building it via IcedTea and > > running the downloadable build. > > > > # Internal Error (relocInfo_amd64.cpp:67), pid=914, tid=1076017504 > > # Error: ShouldNotReachHere() > > > > It occurs from just running 'java' and the rest of the build fails because > > HotSpot can't be used to build j2se. I've filed a bug report with the full > > hs_err file details. > > URL, please. Matthias Klose reported it also at: http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=51 "x86_64-linux-gnu, Internal Error" And there seems to be an equivalent bug in the sun bugdatabase: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6578245 "Internal Error (relocInfo_amd64.cpp:67)" Cheers, Mark From James.Melvin at Sun.COM Wed Jul 25 15:25:30 2007 From: James.Melvin at Sun.COM (James.Melvin at Sun.COM) Date: Wed, 25 Jul 2007 11:25:30 -0400 Subject: JavaSE 7 build 15 is available at the openjdk.java.net website In-Reply-To: <1185375436.3597.36.camel@dijkstra.wildebeest.org> References: <468D9018.80903@sun.com> <468E746A.6070806@redhat.com> <200707242246.56944.gnu_andrew@member.fsf.org> <18087.11550.48871.902237@zebedee.pink> <1185375436.3597.36.camel@dijkstra.wildebeest.org> Message-ID: <46A76B6A.1000204@Sun.COM> > And there seems to be an equivalent bug in the sun bugdatabase: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6578245 > "Internal Error (relocInfo_amd64.cpp:67)" The internal Sun bug report indicates this is resolves in JDK7 b16, which is now available. FYI, Jim Mark Wielaard wrote: > On Wed, 2007-07-25 at 11:59 +0100, Andrew Haley wrote: >> > I'm also seeing a failure with b15 on amd64, both building it via IcedTea and >> > running the downloadable build. >> > >> > # Internal Error (relocInfo_amd64.cpp:67), pid=914, tid=1076017504 >> > # Error: ShouldNotReachHere() >> > >> > It occurs from just running 'java' and the rest of the build fails because >> > HotSpot can't be used to build j2se. I've filed a bug report with the full >> > hs_err file details. >> >> URL, please. > > Matthias Klose reported it also at: > http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=51 > "x86_64-linux-gnu, Internal Error" > > And there seems to be an equivalent bug in the sun bugdatabase: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6578245 > "Internal Error (relocInfo_amd64.cpp:67)" > > Cheers, > > Mark > From David.Holmes at Sun.COM Thu Jul 26 00:20:47 2007 From: David.Holmes at Sun.COM (David Holmes - Sun Microsystems) Date: Thu, 26 Jul 2007 10:20:47 +1000 Subject: JavaSE 7 build 15 is available at the openjdk.java.net website In-Reply-To: <46A76B6A.1000204@Sun.COM> References: <468D9018.80903@sun.com> <468E746A.6070806@redhat.com> <200707242246.56944.gnu_andrew@member.fsf.org> <18087.11550.48871.902237@zebedee.pink> <1185375436.3597.36.camel@dijkstra.wildebeest.org> <46A76B6A.1000204@Sun.COM> Message-ID: <46A7E8DF.3070809@sun.com> The report was just updated to b17. David Holmes James.Melvin at Sun.COM said the following on 26/07/07 01:25 AM: > > And there seems to be an equivalent bug in the sun bugdatabase: > > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6578245 > > "Internal Error (relocInfo_amd64.cpp:67)" > > The internal Sun bug report indicates this is resolves in JDK7 b16, > which is now available. > > FYI, > Jim > > > Mark Wielaard wrote: >> On Wed, 2007-07-25 at 11:59 +0100, Andrew Haley wrote: >>> > I'm also seeing a failure with b15 on amd64, both building it via >>> IcedTea and > running the downloadable build. >>> > > # Internal Error (relocInfo_amd64.cpp:67), pid=914, >>> tid=1076017504 >>> > # Error: ShouldNotReachHere() >>> > > It occurs from just running 'java' and the rest of the build >>> fails because > HotSpot can't be used to build j2se. I've filed a >>> bug report with the full > hs_err file details. >>> >>> URL, please. >> >> Matthias Klose reported it also at: >> http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=51 >> "x86_64-linux-gnu, Internal Error" >> >> And there seems to be an equivalent bug in the sun bugdatabase: >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6578245 >> "Internal Error (relocInfo_amd64.cpp:67)" >> >> Cheers, >> >> Mark >> From Bradford.Wetmore at Sun.COM Thu Jul 26 01:26:48 2007 From: Bradford.Wetmore at Sun.COM (Brad Wetmore) Date: Wed, 25 Jul 2007 18:26:48 -0700 Subject: Java Crypto Encumberance Update. Message-ID: <46A7F858.7090401@sun.com> Good morning/afternoon/evening/night, Here's a quick update on our efforts to remove the cryptographic encumbrances from the Java SE code base, and thus finally open source the crypto framework and the Sun providers (SunJCE, PKCS11, MSCAPI). We have cleared our concerns with the various stakeholders (legal, export, mgmt, etc), and began merging the JCE and Java SE code bases last week. This includes opening the PKCS11/MSCAPI bulk cryptographic routines also. Assuming we don't get pulled in too many different directions or hit any major snags, we should have this code ready by mid-Sept. I know this code has been eagerly anticipated, so thanks for your patience. We had quite a few items to resolve. Thanks, Brad From robilad at kaffe.org Thu Jul 26 12:32:27 2007 From: robilad at kaffe.org (Dalibor Topic) Date: Thu, 26 Jul 2007 14:32:27 +0200 Subject: svn repo url on web site pointing to docs instead of sources Message-ID: <46A8945B.9010802@kaffe.org> hi, the example given in https://openjdk.dev.java.net/source/browse/openjdk/ svn checkout https://openjdk.dev.java.net/svn/openjdk/trunk openjdk --username username only checks out the documentation, but not the source code. To check out the source code, the example should read svn checkout https://openjdk.dev.java.net/svn/openjdk/jdk/trunk openjdk --username username I can't find the page in the SVN for www pages, so I don't know where to send the patch for that one. cheers, dalibor topic From Karen.Kinnear at Sun.COM Thu Jul 26 15:56:51 2007 From: Karen.Kinnear at Sun.COM (Karen Kinnear) Date: Thu, 26 Jul 2007 11:56:51 -0400 Subject: JavaSE 7 build 15 is available at the openjdk.java.net website In-Reply-To: <46A76B6A.1000204@Sun.COM> References: <468D9018.80903@sun.com> <468E746A.6070806@redhat.com> <200707242246.56944.gnu_andrew@member.fsf.org> <18087.11550.48871.902237@zebedee.pink> <1185375436.3597.36.camel@dijkstra.wildebeest.org> <46A76B6A.1000204@Sun.COM> Message-ID: <46A8C443.6080007@sun.com> Mark, This was actually resolved in b17, sorry for the confusion. hope this helps, Karen James.Melvin at Sun.COM wrote: > > And there seems to be an equivalent bug in the sun bugdatabase: > > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6578245 > > "Internal Error (relocInfo_amd64.cpp:67)" > > The internal Sun bug report indicates this is resolves in JDK7 b16, > which is now available. > > FYI, > Jim > > > Mark Wielaard wrote: > >> On Wed, 2007-07-25 at 11:59 +0100, Andrew Haley wrote: >> >>> > I'm also seeing a failure with b15 on amd64, both building it via >>> IcedTea and > running the downloadable build. >>> > > # Internal Error (relocInfo_amd64.cpp:67), pid=914, >>> tid=1076017504 >>> > # Error: ShouldNotReachHere() >>> > > It occurs from just running 'java' and the rest of the build >>> fails because > HotSpot can't be used to build j2se. I've filed a >>> bug report with the full > hs_err file details. >>> >>> URL, please. >> >> >> Matthias Klose reported it also at: >> http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=51 >> "x86_64-linux-gnu, Internal Error" >> >> And there seems to be an equivalent bug in the sun bugdatabase: >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6578245 >> "Internal Error (relocInfo_amd64.cpp:67)" >> >> Cheers, >> >> Mark >> From robilad at kaffe.org Thu Jul 26 19:11:43 2007 From: robilad at kaffe.org (Dalibor Topic) Date: Thu, 26 Jul 2007 21:11:43 +0200 Subject: Java Crypto Encumberance Update. In-Reply-To: <46A7F858.7090401@sun.com> References: <46A7F858.7090401@sun.com> Message-ID: <46A8F1EF.40801@kaffe.org> Brad Wetmore wrote: > > Good morning/afternoon/evening/night, > > Here's a quick update on our efforts to remove the cryptographic > encumbrances from the Java SE code base, and thus finally open source > the crypto framework and the Sun providers (SunJCE, PKCS11, MSCAPI). > > We have cleared our concerns with the various stakeholders (legal, > export, mgmt, etc), and began merging the JCE and Java SE code bases > last week. This includes opening the PKCS11/MSCAPI bulk cryptographic > routines also. > > Assuming we don't get pulled in too many different directions or hit any > major snags, we should have this code ready by mid-Sept. > > I know this code has been eagerly anticipated, so thanks for your > patience. We had quite a few items to resolve. > Thanks, Brad, that's very good news. cheers, dalibor topic From betelgeuse at gentoo.org Thu Jul 26 22:40:02 2007 From: betelgeuse at gentoo.org (=?UTF-8?B?UGV0dGVyaSBSw6R0eQ==?=) Date: Fri, 27 Jul 2007 01:40:02 +0300 Subject: JavaSE 7 build 15 is available at the openjdk.java.net website In-Reply-To: <46A8C443.6080007@sun.com> References: <468D9018.80903@sun.com> <468E746A.6070806@redhat.com> <200707242246.56944.gnu_andrew@member.fsf.org> <18087.11550.48871.902237@zebedee.pink> <1185375436.3597.36.camel@dijkstra.wildebeest.org> <46A76B6A.1000204@Sun.COM> <46A8C443.6080007@sun.com> Message-ID: <46A922C2.9080402@gentoo.org> Karen Kinnear kirjoitti: > Mark, > > This was actually resolved in b17, sorry for the confusion. > > hope this helps, > Karen > I don't see b17 in http://download.java.net/openjdk/jdk7/ Regards, Petteri -- Gentoo/Java project lead -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature URL: From Peter.Lawrence at Sun.COM Thu Jul 26 23:07:10 2007 From: Peter.Lawrence at Sun.COM (Peter Lawrence) Date: Thu, 26 Jul 2007 16:07:10 -0700 Subject: source search tool for jdk ??? Message-ID: <46A9291E.3080104@Sun.COM> are there any web-based source code search tools for looking up Java classes/methods/etc within the jdk, like there are for Solaris, that can tell you where something is defined, and where it is used, and lets you click to the source code ? thanks, Pete Lawrence. From Peter.Lawrence at Sun.COM Thu Jul 26 23:12:33 2007 From: Peter.Lawrence at Sun.COM (Peter Lawrence) Date: Thu, 26 Jul 2007 16:12:33 -0700 Subject: -agentlib:foobar.so problems Message-ID: <46A92A61.2030206@Sun.COM> does anyone know how to get a jvmti plugin to work ? I wrote one, but I can't get the jvm to load it... > java -agentlib:jitsyms.so fib Error occurred during initialization of VM Could not find agent library on the library path or in the local directory: jitsyms.so > ls -l jitsyms.so -rwxr-xr-x 1 peterl archperf 7232 Jul 25 12:22 jitsyms.so > nm jitsyms.so | grep Agent_OnLoad [66] | 2024| 224|FUNC |GLOB |0 |8 |Agent_OnLoad thanks, Pete Lawrence. From Bradford.Wetmore at Sun.COM Thu Jul 26 23:26:59 2007 From: Bradford.Wetmore at Sun.COM (Brad Wetmore) Date: Thu, 26 Jul 2007 16:26:59 -0700 Subject: source search tool for jdk ??? In-Reply-To: <46A9291E.3080104@Sun.COM> References: <46A9291E.3080104@Sun.COM> Message-ID: <46A92DC3.2050404@sun.com> > are there any web-based source code search tools for looking up > Java classes/methods/etc within the jdk, like there are for Solaris, > that can tell you where something is defined, and where it is used, > and lets you click to the source code ? Have you looked at OpenGrok? http://www.opensolaris.org/os/project/opengrok/ To see it in action on the opensolaris codebase: http://cvs.opensolaris.org/source/ FILE FORMATS OpenGrok can grok various program file formats like C, C++, Shell Scripts like ksh, sh, Perl, Java, Java Class files, JAR files, ELF files, troff man pages, file archives like Zip, Gzip, BZip2, Tar and meta language files like XML, SGML or HTML. Brad From Tim.Bell at Sun.COM Thu Jul 26 23:41:27 2007 From: Tim.Bell at Sun.COM (Tim Bell) Date: Thu, 26 Jul 2007 16:41:27 -0700 Subject: -agentlib:foobar.so problems In-Reply-To: <46A92A61.2030206@Sun.COM> References: <46A92A61.2030206@Sun.COM> Message-ID: <46A93127.5030106@sun.com> Peter Lawrence wrote: >> java -agentlib:jitsyms.so fib > Error occurred during initialization of VM > Could not find agent library on the library path or in the local > directory: jitsyms.so Set up LD_LIBRARY_PATH on Solaris/Linux, or PATH on Windows so your library will be discovered during load time. For more information, take a look here: The JVM Tool Interface (JVM TI): How VM Agents Work http://java.sun.com/developer/technicalArticles/J2SE/jvm_ti/ Search for the section titled "Native Library Loading". HTH - Tim From mr at sun.com Fri Jul 27 03:54:22 2007 From: mr at sun.com (Mark Reinhold) Date: Thu, 26 Jul 2007 20:54:22 -0700 Subject: source search tool for jdk ??? In-Reply-To: bradford.wetmore@sun.com; Thu, 26 Jul 2007 16:26:59 PDT; <46A92DC3.2050404@sun.com> Message-ID: <20070727035422.30EF6B351@callebaut.niobe.net> > Date: Thu, 26 Jul 2007 16:26:59 -0700 > From: bradford.wetmore at sun.com > Peter Lawrence wrote: >> are there any web-based source code search tools for looking up >> Java classes/methods/etc within the jdk, like there are for Solaris, >> that can tell you where something is defined, and where it is used, >> and lets you click to the source code ? > > Have you looked at OpenGrok? > > http://www.opensolaris.org/os/project/opengrok/ I suspect that maybe Peter was asking if such a tool has been deployed for OpenJDK, not whether such a tool simply exists. At any rate, we've experimented with OpenGrok a bit and we do intend to deploy it for OpenJDK in the not-too-distant future. - Mark From mr at sun.com Fri Jul 27 04:07:41 2007 From: mr at sun.com (Mark Reinhold) Date: Thu, 26 Jul 2007 21:07:41 -0700 Subject: svn repo url on web site pointing to docs instead of sources In-Reply-To: robilad@kaffe.org; Thu, 26 Jul 2007 14:32:27 +0200; <46A8945B.9010802@kaffe.org> Message-ID: <20070727040741.C0153B351@callebaut.niobe.net> > Date: Thu, 26 Jul 2007 14:32:27 +0200 > From: Dalibor Topic > the example given in https://openjdk.dev.java.net/source/browse/openjdk/ > > svn checkout https://openjdk.dev.java.net/svn/openjdk/trunk openjdk > --username username > > only checks out the documentation, In particular, it only checks out the old openjdk.dev.java.net web content, which has been superseded by openjdk.java.net for everything except... svn. > but not the source code. To check out > the source code, the example should read > > svn checkout https://openjdk.dev.java.net/svn/openjdk/jdk/trunk > openjdk --username username > > I can't find the page in the SVN for www pages, so I don't know where to > send the patch for that one. Thanks for pointing this out. Unfortunately we have essentially no control over the content of that example text. It's provided by the underlying CollabNet infrastructure, which assumes that everything interesting will be under the top-level trunk directory. (Well, I suppose we could implement some disgusting javascript hack to rewrite the text in the box... ugh.) If this really is a problem for people we could consider rearranging the top-level structure of the svn repository, though that would break some existing downstream trees such as mjw's svn-driven hg mirror [1]. - Mark [1] http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2007-June/000102.html From Raghu.Nair at Sun.COM Fri Jul 27 04:09:10 2007 From: Raghu.Nair at Sun.COM (Raghu Nair) Date: Fri, 27 Jul 2007 09:39:10 +0530 Subject: -agentlib:foobar.so problems In-Reply-To: <46A93127.5030106@sun.com> References: <46A92A61.2030206@Sun.COM> <46A93127.5030106@sun.com> Message-ID: <46A96FE6.4050905@sun.com> Hello Peter, You can open Java Control Panel and select Java Tab and in Java Runtime Parameters value enter -Djava.library.path="Location of jitsyms.so" Thanks, Raghu Tim Bell wrote: > Peter Lawrence wrote: > >>> java -agentlib:jitsyms.so fib >> Error occurred during initialization of VM >> Could not find agent library on the library path or in the local >> directory: jitsyms.so > > Set up LD_LIBRARY_PATH on Solaris/Linux, or PATH on Windows so > your library will be discovered during load time. > > For more information, take a look here: > > The JVM Tool Interface (JVM TI): How VM Agents Work > http://java.sun.com/developer/technicalArticles/J2SE/jvm_ti/ > > Search for the section titled "Native Library Loading". > > HTH - Tim From mark at klomp.org Fri Jul 27 06:12:40 2007 From: mark at klomp.org (Mark Wielaard) Date: Fri, 27 Jul 2007 08:12:40 +0200 Subject: svn repo url on web site pointing to docs instead of sources In-Reply-To: <20070727040741.C0153B351@callebaut.niobe.net> References: <20070727040741.C0153B351@callebaut.niobe.net> Message-ID: <1185516761.3588.5.camel@dijkstra.wildebeest.org> Hi Mark, On Thu, 2007-07-26 at 21:07 -0700, Mark Reinhold wrote: > If this really is a problem for people we could consider rearranging the > top-level structure of the svn repository, though that would break some > existing downstream trees such as mjw's svn-driven hg mirror [1]. It is confusing. I know my first big disappointment (at javaone :) when trying to check it all out and only finding the web content and not the sources immediately. But people probably figure it out pretty quickly. Still I would expect it to become a faq (and I know my first mistake was then to replace /trunk with /jdk which gives you both the tags and the trunk which might be a bit much). Don't worry about the mirror, we figure something out for it to make it work on any new location it has to slurp from. Cheers, Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From robilad at kaffe.org Fri Jul 27 11:00:09 2007 From: robilad at kaffe.org (Dalibor Topic) Date: Fri, 27 Jul 2007 13:00:09 +0200 Subject: svn repo url on web site pointing to docs instead of sources In-Reply-To: <20070727040741.C0153B351@callebaut.niobe.net> References: <20070727040741.C0153B351@callebaut.niobe.net> Message-ID: <46A9D039.8070909@kaffe.org> Mark Reinhold wrote: > In particular, it only checks out the old openjdk.dev.java.net web > content, which has been superseded by openjdk.java.net for everything > except... svn. > > Ah, yikes, I didn't notice that, thanks for the warning. Should patches to docs go to web-discuss? >> Unfortunately we have essentially no control over the content of that >> example text. It's provided by the underlying CollabNet infrastructure, >> which assumes that everything interesting will be under the top-level >> trunk directory. >> >> (Well, I suppose we could implement some disgusting javascript hack to >> rewrite the text in the box... ugh.) >> >> Can't we squeeze in an additional page between that one and the main page describing the repository layout and how to get to the bits and pieces? cheers, dalibor topic From mr at sun.com Fri Jul 27 18:08:46 2007 From: mr at sun.com (Mark Reinhold) Date: Fri, 27 Jul 2007 11:08:46 -0700 Subject: svn repo url on web site pointing to docs instead of sources In-Reply-To: robilad@kaffe.org; Fri, 27 Jul 2007 13:00:09 +0200; <46A9D039.8070909@kaffe.org> Message-ID: <20070727180846.6D8CDB34D@callebaut.niobe.net> > Date: Fri, 27 Jul 2007 13:00:09 +0200 > From: Dalibor Topic > Mark Reinhold wrote: >> In particular, it only checks out the old openjdk.dev.java.net web >> content, which has been superseded by openjdk.java.net for everything >> except... svn. > > Ah, yikes, I didn't notice that, thanks for the warning. Should patches > to docs go to web-discuss? Depends on what you want to patch. Changes to specific Group or Project pages should go to the appropriate Moderator. Use web-discuss for the rest. > Can't we squeeze in an additional page between that one and the main > page describing the repository layout and how to get to the bits and > pieces? Yes, but then people'd have to remember not to pay attention to the incorrect text on the actual svn page. It sounds like we should look into restructuring the svn top-level. Right now we have: /branches ; empty /jdk/tags/jdk7-bnn /trunk/{control,hotspot,j2se,...} /tags ; empty /trunk/www ; old web content We could change this to: /branches ; empty /tags/jdk7/bnn /trunk/jdk7 ; was jdk/trunk /www ; old web content Make sense? (I've taken the opportunity to rename "jdk" to "jdk7" in order to make it clear that it's the code for jdk7 rather than some earlier release, which has also confused some people.) - Mark From langel at redhat.com Fri Jul 27 18:23:25 2007 From: langel at redhat.com (Lillian Angel) Date: Fri, 27 Jul 2007 14:23:25 -0400 Subject: Window Decorations do not work on x86_64 Message-ID: <46AA381D.3050703@redhat.com> Hi, On 64-bit platforms, when running a graphical Java program, there are no window decorations displayed. There is no title bar, and the title of the window is not displayed. This problem can be reproduced with any of the OpenJDK bundles released thus far. Is it in the process of being fixed? A bug report has been filed with Sun sometime ago, but it has not yet been approved. It has also been filed here: http://iced-tea.org/bugzilla/show_bug.cgi?id=37 Cheers, Lillian -------------- next part -------------- A non-text attachment was scrubbed... Name: langel.vcf Type: text/x-vcard Size: 303 bytes Desc: not available URL: From robilad at kaffe.org Fri Jul 27 22:59:47 2007 From: robilad at kaffe.org (Dalibor Topic) Date: Sat, 28 Jul 2007 00:59:47 +0200 Subject: svn repo url on web site pointing to docs instead of sources In-Reply-To: <20070727180846.6D8CDB34D@callebaut.niobe.net> References: <20070727180846.6D8CDB34D@callebaut.niobe.net> Message-ID: <46AA78E3.4050506@kaffe.org> Mark Reinhold wrote: > It sounds like we should look into restructuring the svn top-level. > Right now we have: > > /branches ; empty > /jdk/tags/jdk7-bnn > /trunk/{control,hotspot,j2se,...} > /tags ; empty > /trunk/www ; old web content > > We could change this to: > > /branches ; empty > /tags/jdk7/bnn > /trunk/jdk7 ; was jdk/trunk > /www ; old web content > > Make sense? > Makes sense to me. cheers, dalibor topic From Xiomara.Jayasena at Sun.COM Sat Jul 28 02:33:08 2007 From: Xiomara.Jayasena at Sun.COM (Xiomara Jayasena) Date: Fri, 27 Jul 2007 19:33:08 -0700 Subject: svn repo url on web site pointing to docs instead of sources In-Reply-To: <46AA78E3.4050506@kaffe.org> References: <20070727180846.6D8CDB34D@callebaut.niobe.net> <46AA78E3.4050506@kaffe.org> Message-ID: <46AAAAE4.4050003@sun.com> Dalibor Topic wrote: > Mark Reinhold wrote: >> It sounds like we should look into restructuring the svn top-level. >> Right now we have: >> >> /branches ; empty >> /jdk/tags/jdk7-bnn >> /trunk/{control,hotspot,j2se,...} >> /tags ; empty >> /trunk/www ; old web content >> >> We could change this to: >> >> /branches ; empty >> /tags/jdk7/bnn >> /trunk/jdk7 ; was jdk/trunk >> /www ; old web content >> >> Make sense? >> > > Makes sense to me. I'll restructure it for the next build. -Xiomara > > cheers, > dalibor topic From Anthony.Petrov at Sun.COM Sat Jul 28 08:26:20 2007 From: Anthony.Petrov at Sun.COM (Anthony Petrov) Date: Sat, 28 Jul 2007 12:26:20 +0400 Subject: Window Decorations do not work on x86_64 In-Reply-To: <46AA381D.3050703@redhat.com> References: <46AA381D.3050703@redhat.com> Message-ID: <46AAFDAC.9090405@sun.com> Hi Lillian, Could you tell what window manager you're using when you observe this behavior? Did you try running under Metacity? Is the bug still reproducible then? -- best regards, Anthony On 7/27/2007 10:23 PM Lillian Angel wrote: > Hi, > > On 64-bit platforms, when running a graphical Java program, there are no > window decorations displayed. There is no title bar, and the title of > the window is not displayed. This problem can be reproduced with any of > the OpenJDK bundles released thus far. > > Is it in the process of being fixed? A bug report has been filed with > Sun sometime ago, but it has not yet been approved. It has also been > filed here: http://iced-tea.org/bugzilla/show_bug.cgi?id=37 > > > Cheers, > Lillian > From langel at redhat.com Mon Jul 30 13:40:07 2007 From: langel at redhat.com (Lillian Angel) Date: Mon, 30 Jul 2007 09:40:07 -0400 Subject: Window Decorations do not work on x86_64 In-Reply-To: <46AAFDAC.9090405@sun.com> References: <46AA381D.3050703@redhat.com> <46AAFDAC.9090405@sun.com> Message-ID: <46ADEA37.4060201@redhat.com> Anthony Petrov wrote: > Hi Lillian, > > Could you tell what window manager you're using when you observe this > behavior? Did you try running under Metacity? Is the bug still > reproducible then? This was tested under Metacity and it is still a bug. Thanks, Lillian -------------- next part -------------- A non-text attachment was scrubbed... Name: langel.vcf Type: text/x-vcard Size: 269 bytes Desc: not available URL: From fkung at redhat.com Mon Jul 30 14:49:29 2007 From: fkung at redhat.com (Francis Kung) Date: Mon, 30 Jul 2007 10:49:29 -0400 Subject: Window Decorations do not work on x86_64 In-Reply-To: <46ADEA37.4060201@redhat.com> References: <46AA381D.3050703@redhat.com> <46AAFDAC.9090405@sun.com> <46ADEA37.4060201@redhat.com> Message-ID: <46ADFA79.2000602@redhat.com> Hi, >> Could you tell what window manager you're using when you observe this >> behavior? Did you try running under Metacity? Is the bug still >> reproducible then? > > This was tested under Metacity and it is still a bug. I just tested this against an old build I had lying around (b12, I believe) and this error does not occur. I have, however, noticed it in at least the last two releases, so it seems to be a regression somewhere between b12 and b15. Regards, Francis From Kelly.Ohair at Sun.COM Mon Jul 30 16:29:04 2007 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Mon, 30 Jul 2007 09:29:04 -0700 Subject: A little progress report on Mercurial and build/source infrastructure changes Message-ID: <46AE11D0.6040709@sun.com> Re: A little progress report on Mercurial and build/source infrastructure changes I thought I would take some time to list a few of the up and coming changes with regards to Open JDK builds and source structure. I don't want anyone blogging that we are keeping secrets from everyone. ;^) We are converting OpenJDK to Mercurial but it's taking longer than I had planned. There is a long list of issues we are trying to clear up internally, some in the area of the keeping the legal eagles happy, and others just major cleanups we want to do before starting out in a fresh new world of Mercurial. We have used TeamWare for over 10 years (or longer?), so internally this is a huge change for the JDK developers, and the fact that we will be externally exposing our Mercurial repositories makes us nervous and very careful. To anyone downloading source bundles, this impact should be minimal, but the Mercurial conversion will cause many files to get moved around. In the process of converting to Mercurial there will also be some basic build infrastructure changes. So fair warning, things will be changing. Internally we deal with many TeamWare workspaces, the big 2 primary ones have historically been j2se and hotspot. These 2 workspaces do contain some of what we are calling "closed" sources. The goal is to minimize these closed parts of the workspaces, either by opening these files up where possible, or replacing them. That will take time and will happen over the long term, perhaps faster once we get public Mercurial repositories out in the open. The current plan is that we would continue to keep components like hotspot in a separate repository, and we are currently looking at separating out parts of the existing j2se workspace into new repositories where it makes sense. You may see a "langtools" repository that contains just javac/javah/javadoc/apt, and you may see an "ee" repository that contains much of the Java EE contribution to the OpenJDK. These two have been chosen because they are large chunks of the j2se files that get delivered to more than just the JDK, and can be built and run with just the BOOTJDK (no dependence on JDK7 apis or a running JDK7). The build procedure becomes much simplier once the "langtools" get separated out. e.g. (just a prediction) 1. Build langtools with BOOTJDK 2. Build hotspot with langtools javac and BOOTJDK and C/C++ compilers 3. Build ee with langtools javac and BOOTJDK 4. Build the rest of the j2se with ee, hotspot, langtools javac and BOOTJDK and C/C++ compilers 5. Repeat 1-4 with this new JDK7 (which hasn't run yet) as the BOOTJDK In step 4 one of the big changes will be that we won't need to run what we are building as it happens now, that would be done in step 5. This should make cross development easier, and certainly simplifies the build process from my perspective. The "rest of j2se" and the current "control" files may become the primary "jdk" repository, and the hotspot, langtools, and ee repositories may be nested inside this jdk repository as nested repositories (TeamWare doesn't allow nesting, but Mercurial does). Each repository should be rather independent in terms of developers. Many people have suggested breaking up the j2se even further, but we won't be doing that initially. There are some serious issues with regards to the JDK7 runtime dependencies that needs to be taken into account with each separated component. Don't expect this to happen overnight, the current internal transition to Mercurial is scheduled for roughly Oct2007, and our dates have slipped once already. We have made great progress on the "langtools" separation and are now getting started on the "ee" separation. Many other smaller to medium sized details remain to be dealt with, but we are progressing. I hope this helps explain the current state. Now back to work. ;^) -kto From langel at redhat.com Mon Jul 30 20:26:38 2007 From: langel at redhat.com (Lillian Angel) Date: Mon, 30 Jul 2007 16:26:38 -0400 Subject: Window Decorations do not work on x86_64 In-Reply-To: <46AE09F2.9070605@redhat.com> References: <46AA381D.3050703@redhat.com> <46AAFDAC.9090405@sun.com> <46ADEA37.4060201@redhat.com> <46AE09F2.9070605@redhat.com> Message-ID: <46AE497E.9030702@redhat.com> Kyle Galloway wrote: > Lillian Angel wrote: >> Anthony Petrov wrote: >>> Hi Lillian, >>> >>> Could you tell what window manager you're using when you observe this >>> behavior? Did you try running under Metacity? Is the bug still >>> reproducible then? >> >> This was tested under Metacity and it is still a bug. > Sun accepted this bug this morning as bug 6586752. > > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6586752 This problem was narrowed down to a regression between b14 and b15. The patch causing the problem has been uploaded here: http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=37 Though, we are still trying to determine what part of this patch is the cause. Lillian From fkung at redhat.com Tue Jul 31 13:55:29 2007 From: fkung at redhat.com (Francis Kung) Date: Tue, 31 Jul 2007 09:55:29 -0400 Subject: Window Decorations do not work on x86_64 In-Reply-To: <46AE497E.9030702@redhat.com> References: <46AA381D.3050703@redhat.com> <46AAFDAC.9090405@sun.com> <46ADEA37.4060201@redhat.com> <46AE09F2.9070605@redhat.com> <46AE497E.9030702@redhat.com> Message-ID: <46AF3F51.2050908@redhat.com> Hi everyone, >>>> Could you tell what window manager you're using when you observe >>>> this behavior? Did you try running under Metacity? Is the bug still >>>> reproducible then? >>> >>> This was tested under Metacity and it is still a bug. >> Sun accepted this bug this morning as bug 6586752. >> >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6586752 > > > This problem was narrowed down to a regression between b14 and b15. The > patch causing the problem has been uploaded here: > http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=37 > > Though, we are still trying to determine what part of this patch is the > cause. I've found the specific area that causes this regression; it was the change in XPanelPeer.java. I've attached the relevant b14->b15 diff; if you revert that patch then window decorations appear once again. Regards, Francis -------------- next part -------------- A non-text attachment was scrubbed... Name: b14-15-solaris-awt.diff Type: text/x-patch Size: 3633 bytes Desc: not available URL: From Anthony.Petrov at Sun.COM Tue Jul 31 15:56:42 2007 From: Anthony.Petrov at Sun.COM (Anthony Petrov) Date: Tue, 31 Jul 2007 19:56:42 +0400 Subject: Window Decorations do not work on x86_64 In-Reply-To: <46AF3F51.2050908@redhat.com> References: <46AA381D.3050703@redhat.com> <46AAFDAC.9090405@sun.com> <46ADEA37.4060201@redhat.com> <46AE09F2.9070605@redhat.com> <46AE497E.9030702@redhat.com> <46AF3F51.2050908@redhat.com> Message-ID: <46AF5BBA.2030403@sun.com> Thank you Francis! On 7/31/2007 5:55 PM Francis Kung wrote: > I've found the specific area that causes this regression; it was the > change in XPanelPeer.java. I've attached the relevant b14->b15 diff; if > you revert that patch then window decorations appear once again. We'll take care of the problem and revise the fix that caused this regression. -- best regards, Anthony From Phil.Race at Sun.COM Tue Jul 31 21:39:19 2007 From: Phil.Race at Sun.COM (Phil Race) Date: Tue, 31 Jul 2007 14:39:19 -0700 Subject: encumbrances update Message-ID: <46AFAC07.6060608@sun.com> I just want to give a quick update on the state of one the 2D encumbrances to a broader audience than the 2D and font mailing lists, since the state of encumbrances are generally of broad interest. Igor Nekrestyanov just put back into what will be b17 the first version of the code that replaces using the T2K font rasteriser with freetype. This should be be out on openjdk.java.net in a few days. It is believed to build and work on all platform combinations : windows, linux, solaris, 32 and 64 bit, but testing has focused on the 32 bit versions. Whilst removing the encumbrance, it does add the requirement that you have freetype around. That is, at this time, we chose not to include sources for a specific freetype since we think most distros will want to link against the platform one. If the build detects a compatible freetype in /usr/lib it will just link against that. But if needed you can provide your own by setting ALT_FREETYPE_LIB_PATH, in which case ALT_FREETYPE_HEADERS_PATH should also be set. The build docs have been updated with this information. We have only tested against recent freetypes : 2.3.0 and later. So there's some work to do there to see what the actual minimum requirements are. If you have an earlier version you want to try, you may need to bypass the sanity check. Please try it out, and let us know of any suggestions for improvement etc by communicating on http://mail.openjdk.java.net/mailman/listinfo/font-scaler-dev And on a related note, Alexey Menkov is making changes which separate out the encumbered Java Sound code from the unemcumbered parts. This basically slims down the binary plug to just those parts that need to be in it, making it easier to replace. Hopefully that will be in an openjdk drop in about two weeks. I expect Alexey have more to say on this on the sound mailing lists : http://mail.openjdk.java.net/mailman/listinfo/audio-engine-dev http://mail.openjdk.java.net/pipermail/sound-dev/ -Phil. From robilad at kaffe.org Tue Jul 31 22:10:00 2007 From: robilad at kaffe.org (Dalibor Topic) Date: Wed, 01 Aug 2007 00:10:00 +0200 Subject: encumbrances update In-Reply-To: <46AFAC07.6060608@sun.com> References: <46AFAC07.6060608@sun.com> Message-ID: <46AFB338.20207@kaffe.org> Phil Race wrote: > > I just want to give a quick update on the state of one the 2D encumbrances > to a broader audience than the 2D and font mailing lists, since the > state of encumbrances are generally of broad interest. Thank you for the update, Phil, it's very appreciated. > Igor Nekrestyanov just put back into what will be b17 the first version > of the > code that replaces using the T2K font rasteriser with freetype. > This should be be out on openjdk.java.net in a few days. I assume b17 == next Friday? > Whilst removing the encumbrance, it does add the requirement > that you have freetype around. That is, at this time, we > chose not to include sources for a specific freetype since > we think most distros will want to link against the platform one. Great, thank you for that feature. > And on a related note, Alexey Menkov is making changes which > separate out the encumbered Java Sound code from the unemcumbered parts. > This basically slims down the binary plug to just those parts that > need to be in it, making it easier to replace. Hopefully that > will be in an openjdk drop in about two weeks. I expect Alexey > have more to say on this on the sound mailing lists : > http://mail.openjdk.java.net/mailman/listinfo/audio-engine-dev > http://mail.openjdk.java.net/pipermail/sound-dev/ That's some very good news, too. I assume that would be b18, and I guess that's two weeks after b17? cheers, dalibor topic From Phil.Race at Sun.COM Tue Jul 31 22:32:46 2007 From: Phil.Race at Sun.COM (Phil Race) Date: Tue, 31 Jul 2007 15:32:46 -0700 Subject: encumbrances update In-Reply-To: <46AFB338.20207@kaffe.org> References: <46AFAC07.6060608@sun.com> <46AFB338.20207@kaffe.org> Message-ID: <46AFB88E.30703@sun.com> Dalibor Topic wrote: > Phil Race wrote: >> >> I just want to give a quick update on the state of one the 2D >> encumbrances >> to a broader audience than the 2D and font mailing lists, since the >> state of encumbrances are generally of broad interest. > > Thank you for the update, Phil, it's very appreciated. > >> Igor Nekrestyanov just put back into what will be b17 the first >> version of the >> code that replaces using the T2K font rasteriser with freetype. >> This should be be out on openjdk.java.net in a few days. > > I assume b17 == next Friday? I think that's right. Thursday the bits are built and sanity checked. Friday they get pushed out. BTW in answer to Ted Neward: I am not sure if the svn repository will be updated before then. I don't know the details of that. > >> Whilst removing the encumbrance, it does add the requirement >> that you have freetype around. That is, at this time, we >> chose not to include sources for a specific freetype since >> we think most distros will want to link against the platform one. > > Great, thank you for that feature. > >> And on a related note, Alexey Menkov is making changes which >> separate out the encumbered Java Sound code from the unemcumbered parts. >> This basically slims down the binary plug to just those parts that >> need to be in it, making it easier to replace. Hopefully that >> will be in an openjdk drop in about two weeks. I expect Alexey >> have more to say on this on the sound mailing lists : >> http://mail.openjdk.java.net/mailman/listinfo/audio-engine-dev >> http://mail.openjdk.java.net/pipermail/sound-dev/ > > That's some very good news, too. I assume that would be b18, and I guess > that's two weeks after b17? > Yes, I am guessing here .. and that's my guess/hope. We seem to be on a two week build cycle at the moment. -phil, > cheers, > dalibor topic