Re: Does OpenJDK statically link the C++ runtime?
On 10:41 Wed 04 Jan , Andrew Haley wrote: On 01/04/2012 06:16 AM, John Von Seggern wrote: Way back in a bug report for Java 1.4, I found this note: We statically link the C++ runtime in JDK and enabled linker script to hide symbols from libstdc++ and other internal symbols. --http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4694590 Does OpenJDK continue to take this approach? Yes it does, but if you're using Linux be aware that most Linux distros patch this out, AFAIK. I'm not sure it even needs patching (though we do in IcedTea6). Setting STATIC_CXX=false should be enough (it defaults to true). Andrew. -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 signature.asc Description: Digital signature
Re: Does OpenJDK statically link the C++ runtime?
On 20:43 Wed 04 Jan , John Von Seggern wrote: Kelly, Thanks for taking the time to answer my question. This information is very helpful. So in general, doing static linking is a bad idea and should not be done lightly, if ever. The most obvious issue for me is security. If a security flaw appears in libstdc++ (or whatever library is linked statically), you have to rebuild to fix it. So the JDK has to have a security update due to one of its dependencies. As I've been looking into these issues, I've encountered developers who advise against dynamically loading any C++ code. For example, a coworker referred me to this article: http://www.trilithium.com/johan/2005/06/static-libstdc/ If you don't want to do all that reading, the key quotes are: 1. C++ ABI changes have been introduced with every major release of GCC 2. code compiled against different ABIs is simply not binary compatible. 3. a fairly workable compromise is to link all C++ code into an executable while using dynamically loaded C libraries only. 4. for this to work reliably you must not use dynamically loaded C++ code As I understand it, Sun took a similar approach for JDK4. A lot of this depends on development model. In a FOSS model, the source is available so anyone can perform a rebuild. Hence, if they upgrade their compiler, they can simply rebuild its dependencies. GNU/Linux is provided in distributions which means that each part of the stack is under the control of the same entity. So they know if a gcc upgrade is performed and to do a mass rebuild of all packages (usually for a new release). This also shakes out build problems with that new compiler. A lot of the work IcedTea (http://icedtea.classpath.org/) has done with OpenJDK relates to making it work well in this kind of environment. In a proprietary model, which OpenJDK's build system is designed around, the user is provided with a blob and has to cross their fingers that it runs. If it doesn't, all they can do is go back to the provider and complain. Hence, it is in the provider's interest to make that blob compatible with as many systems as possible. This is done by statically linking libraries and is also the reason you'll find copies of system libraries (libpng, libjpeg, zlib, lcms) in the OpenJDK tree as well as libraries like Gtk+ (for the look and feel) being opened dynamically. The aim of all that is to minimise dependencies and make the binary self-contained, but it means that if any part of the stack has a security issue, a rebuild is necessary. Such a blob is always going to be safer in terms of compatibility as all the parts are in the same box. This is the model followed by applications on Windows and Mac OS platforms, and leads to issues such as DLL hell with dynamically linked bundled libraries, as several applications all bring their own copies of the same library but different versions. -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 signature.asc Description: Digital signature
Re: Xm/Motif for OpenJDK build?
On 09:11 Wed 09 Nov , Florian Weimer wrote: * Srinivas Ramakrishna: Sorry for a rather naive question. I am building openjdk (6) from scratch for the first time and am running into an issue when building the AWT classes because of not finding the relevant Motif header files at the expected locations on my system (ubuntu/x64). I think these headers are plain Xt, not Motif. Here's the minimal list of build dependencies I ended up with: ant, ant-optional, cpio, file, gawk, libasound2-dev, libcups2-dev, libfreetype6-dev, libx11-dev, libxext-dev, libxi-dev, libxrender-dev, libxt-dev, libxtst-dev, m4, openjdk-6-jdk, openjdk-drops, procps, unzip, x11proto-input-dev, zip, This list is for building OpenJDK 7 on a derivative of Debian squeeze, but Ubuntu is probably similar. But he asked about 6, not 7. And 6 does require the Motif headers still. Works with OpenMotif. -- Florian Weimerfwei...@bfk.de BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 signature.asc Description: Digital signature
Re: hg: build-infra/jdk7: Jaxws actually depends on jaxp, this becomes obvious when compiling
On 14:28 Fri 14 Oct , fredrik.ohrst...@oracle.com wrote: Changeset: 984f119f2ea7 Author:ohrstrom Date: 2011-10-14 16:36 +0200 URL: http://hg.openjdk.java.net/build-infra/jdk7/rev/984f119f2ea7 Jaxws actually depends on jaxp, this becomes obvious when compiling with a boot jdk that does not have jaxp in its boot class path. ! Makefile Yeah, I found this with IcedTea bootstrapping; see patches/boot/jaxp-dependency.patch in IcedTea7. There are a lot of implicit assumptions throughout the build that a complete Oracle JDK will be available (i.e one with com.sun.* and sun.* classes). -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 signature.asc Description: Digital signature
Re: Improving source drops documentation
On 13:52 Wed 12 Oct , Fredrik Öhrström wrote: 2011/10/12 Dr Andrew John Hughes ahug...@redhat.com: FWIW, I recently did exactly that in IcedTea because I'm sick of all the problems this drop solution causes. This has cut things down from needing five tarballs (jaxp + jaxws repositories + three drop zips) to two with everything in. Should someone really want to build from the tarballs, they can just delete the sources. The sources must be added to the jaxp/jaxws repositores. In fact I have done that already in the build-infra forest. Yes, same in the IcedTea forest e.g. http://hg.openjdk.java.net/icedtea/jdk7/jaxws/rev/c608b38af726 I don't see why touching the files is a problem; surely all changesets have to pass review and any that attempt to alter this files would just not do so? What am I missing? It suppose it is a matter of educating sustaining engineering that fixes to jaxp and jaxws has to go through the upstream repositories. A bit of software to prevent messing this up would help, but is not immediately needed. I still fail to see why such changes would be approved in the first place. It sounds like a software solution is being used to paper over a social one. //Fredrik -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07
Re: Build Infrastructure changes
On 18:25 Wed 03 Aug , Kelly O'Hair wrote: FYI... If you are interested in the jdk8 build infrastructure changes coming down the pipe, I invite you to join the build-infra-dev alias: http://mail.openjdk.java.net/pipermail/build-infra-dev/2011-August/29.html I expect this work to get started and moving soon with Fredrik as the primary contributor, the only catch is that I will be on vacation Aug 9-21 and the openjdk mail system seems to be refusing to send email to Fredrik. Hopefully I'll resolve Fredrik's email issue very soon. The autoconf setup may borrow ideas/patterns from the IcedTea project, and I want to give credit to that team for that work. Thanks. I'd hope we could actually use some of the IcedTea work in OpenJDK. I don't think doing that will be so much a technical issue; I doubt you're going to test for libraries any differently and could probably start using more system ones. However, there is a legal issue with OpenJDK contributions requiring the OCA. Please send questions to the build-infra-dev alias. -kto -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37
Re: Different javac options for explicitly and automatically compiled files
On 16:02 Mon 01 Aug , Jonathan Gibbons wrote: On 08/01/2011 02:55 PM, Dr Andrew John Hughes wrote: On 11:07 Mon 01 Aug , Alexandre Boulgakov wrote: Hello Kelly, Do you know the answer to this one? Thanks, Sasha On 7/29/2011 11:37 AM, Alexandre Boulgakov wrote: Hello, I am working on removing the javac -Xlint warnings from java.net.*. After removing these warnings, I would like to turn on javac's -Werror flag in make/java/net/Makefile. However, it seems that the javac task in make/java/net/Makefile has to automatically compile some dependencies (not listed in the makefile, presumably inferred by the compiler from the sourcepath) which have not had warnings fixed yet (sun.net.idn.*, com.sun.security.ntlm.*). Is there some way to have the -Werror flag only apply to explicitly specified source files, but not to the ones that javac pulls in automatically? It sounds to me like there's a bug there; those files should be being dealt with earlier in the build or as part of java/net/Makefile. Regrettably, there are circularities in JDK :-( If they aren't implictly compiled from the source tree, then presumably classes from the bootstrap runtime library will be used if present, which could cause all sorts of issues. No. The Makefiles should be set so that the bootstrap runtime library is overridden with -bootclasspath, meaning that the compilation will fail if the classes are not available to javac in source or compiled form. Then where is it going to get these classes if -implicit:none is used to stop them being compiled from source? Thanks, Sasha -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37
Re: Allow HotSpot to build on Linux 3.0+
On 15:02 Thu 28 Jul , Mark Wielaard wrote: On Thu, 2011-07-28 at 08:32 -0400, Keith McGuigan wrote: This appears to remove support for version 2.7. Is that intentional? There has never been a 2.7 kernel. 2.6.39.3 is the last before the 3.0 series. https://secure.wikimedia.org/wikipedia/en/wiki/Linux_kernel#Version_numbering Yes, it was intentional. As Mark says, it never existed and I guess never will now. I assume it was added as future proofing, but Linus went and messed that up by going to 3.0... ;-) -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37
Re: Allow HotSpot to build on Linux 3.0+
On 09:17 Thu 28 Jul , Keith McGuigan wrote: Ok, thanks. Code looks good to me then. Ok, can I push this or do you still need to do this via JPRT? Either way, I need a bug ID please. -- - Keith On Jul 28, 2011, at 9:02 AM, Mark Wielaard wrote: On Thu, 2011-07-28 at 08:32 -0400, Keith McGuigan wrote: This appears to remove support for version 2.7. Is that intentional? There has never been a 2.7 kernel. 2.6.39.3 is the last before the 3.0 series. https://secure.wikimedia.org/wikipedia/en/wiki/ Linux_kernel#Version_numbering -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37
Regression in OpenJDK8 Makefiles
Hi, Can someone please tell me why: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cf4edfcd7119 reverted my earlier fix: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/80368890a2a0 without any discussion? The correct fix would have been to bump the boot source language/target class versions to 7, not erase the lines altogether. -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37
Re: Regression in OpenJDK8 Makefiles
On 11:58 Wed 27 Jul , Kelly O'Hair wrote: On Jul 27, 2011, at 11:04 AM, Dr Andrew John Hughes wrote: Hi, Can someone please tell me why: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cf4edfcd7119 reverted my earlier fix: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/80368890a2a0 without any discussion? My apologies, the webrev should have been made public. The correct fix would have been to bump the boot source language/target class versions to 7, not erase the lines altogether. Unfortunately, that did not work with jdk7 as a boot Why was this? I don't understand why anything would fail with javac -source 7 -target 7 over just javac. , and jdk6 won't work as a boot jdk soon anyway. Well, yes I assumed this patch was related to moving to OpenJDK7 as the minimum bootstrap JDK. Since we will be requiring a jdk7 as the boot jdk, I did not feel it was needed to even specify this. Anything compiled with the boot javac technically doesn't care what the source/target is, or should, and the class files created just need to work with the boot jdk, and should not be shipped as part of the jdk8 being built. When I looked at the Makefiles, there was no comment as to why we even had to set the -source or -target options when using the boot javac at all. My conclusion was that it was unnecessary, and deleting these lines made 'jdk7 as boot' work. If that was wrong I apologize, why does this matter? It means that we are depending on whatever defaults the bootstrap javac uses rather than being explicit. In most cases, that might not cause a problem but I know I've run into problems with this and I think it better to be safe than sorry, as you don't know what the bootstrap javac is or what its default is. If we expect the bootstrap javac to produce java 7 class files, it should be set explicitly: http://blogs.oracle.com/darcy/entry/build_advice_set_source_target I think I've hit it mostly with using ecj as the bootstrap javac, but it couldcause an issue during development if the bootstrap javac started producing 1.8 code by default but the VM used wasn't capable of handling it. Unlikely maybe, but I think it's better to have this set explicitly and just avoid such issues altogether. -kto -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37
Re: Regression in OpenJDK8 Makefiles
On 17:12 Wed 27 Jul , Kelly O'Hair wrote: On Jul 27, 2011, at 4:28 PM, Dr Andrew John Hughes wrote: On 11:58 Wed 27 Jul , Kelly O'Hair wrote: On Jul 27, 2011, at 11:04 AM, Dr Andrew John Hughes wrote: Hi, Can someone please tell me why: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cf4edfcd7119 reverted my earlier fix: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/80368890a2a0 without any discussion? My apologies, the webrev should have been made public. The correct fix would have been to bump the boot source language/target class versions to 7, not erase the lines altogether. Unfortunately, that did not work with jdk7 as a boot Why was this? I don't understand why anything would fail with javac -source 7 -target 7 over just javac. Basically, we never really know what the BOOT javac will accept. I was referring more to the actual build failure when you tried this. If we're requiring 7 support as a minimum for bootstrapping, surely we know it will support this. I assume that if we use the default for javac, that the BOOT java can run them. This is the assumption that has not always held in my experience. Being explicit means that a newer javac can be used with an older VM. snip... If the BOOT jdk was jdk8, I would want these sources built for jdk8 and run with a jdk8, it should just work. This seems to contradict what you're saying about the files ending up in the image. Why does it matter if they use the minimum supported version? Presumably an OpenJDK8 VM will be able to run 1.7 class files. But an OpenJDK7 VM wouldn't be able to run 1.8 class files if these are the default produced by the bootstrap javac. -kto -kto -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37
Re: Help me to build openjdk on my machine
On 11:24 Sun 10 Jul , Erik Trimble wrote: Folks, PPC isn't a currently supported architecture for OpenJDK - that is, no one has contributed any code to support it. I do know of several proprietary ports, but that doesn't help. :-) I don't even remember the last time it was potentially supported (I'm pretty sure that PPC never was supported in the OpenJDK project). To put in more bluntly, no one has built OpenJDK on PPC here at Oracle for a *very* long time, and I don't know of any Open port anywhere else. It certainly would be nice for someone to come forward with a port of Hotspot to the PPC/Power architecture, as the Freescale stuff (in particular) is becoming very popular for embedded work. Now that IBM is part of OpenJDK, maybe they'll be interested? (who knows) FYI - Zero the architecture, is for a zero-assembly version of Hotspot (that is, a Hotspot version with as little architecture-specific customizations as possible). If I were porting Hotspot, I'd start with the Zero codebase, and work from there. But that's just me. -Erik Debian provides PPC GNU/Linux builds, presumably using Zero: http://packages.debian.org/squeeze/openjdk-6-jdk -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37
Re: prebuild Oracle VM appliance
On 09:59 Wed 15 Jun , Andrew Haley wrote: On 14/06/11 22:22, Sebastian Sickelmann wrote: i had done a contribution to openjdk7 and remembered it was very hard to setup all the build thinks. Now a want to make some new contributions and i struggle again with the build setup. How about a prebuild Oracle VM appliance for openjdk development (at least for the linux-setup). I will get it working without such a appliance but i think it can be a solution to lower the entry-hurdle in openjdk contribution. Perhaps so. I used to find OpenJDK hard to build, but now only the pesky bundles that you have to download present any problems. I'll be interested to find out what other problems a prebuilt VM needs to solve. Andrew. Which 'pesky bundles' are you referring to? I'm not aware of any being required for OpenJDK at present. -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37
Re: Boot JDK used with jdk7 builds
On 08:57 Fri 03 Jun , Kelly O'Hair wrote: The documented Boot JDK to be used when building JDK7 repositories is JDK6 Update 18, as listed here http://hg.openjdk.java.net/jdk7/build/raw-file/tip/README-builds.html#MBE However, as many people know, JDK releases newer than JDK6u18 should always work, and some older ones can work too. Variations in build dependencies can sometimes create unwanted differences between builds by different developers or build systems, so our tendency is to minimize these variations, but by doing so, we run a risk that we don't see what does not work. If you have any incidents where particular JDKs can or cannot be used as the Boot JDK for JDK7, please let us know. -kto And OpenJDK6 works. Is there any reason this is not recommended rather than a proprietary product? -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37
Re: Build Infrastructure Project
On 13:11 Fri 20 May , Kelly O'Hair wrote: We now have a Build Infrastructure project! Register for email at: http://mail.openjdk.java.net/mailman/listinfo/build-infra-dev The repos will be at: http://hg.openjdk.java.net/build-infra/jdk7 But I haven't been able to populate them just yet, having access issues. Once the repos are primed, I hope this can get moving quickly because I want to expose what can be done to the builds in terms of turnaround improvements etc. -kto Hi Kelly, Sorry if I missed this already, but what is the purpose of this new project? I thought we already had build-dev... -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37
Re: Build portability: enable or disable warnings
On 07:20 Fri 20 May , David Holmes wrote: Dr Andrew John Hughes said the following on 05/20/11 06:24: On 09:47 Thu 19 May , David Holmes wrote: Dr Andrew John Hughes said the following on 05/19/11 05:29: On 08:35 Mon 16 May , Kelly O'Hair wrote: snip The -Werror option is a blessing and a curse. I find it highly commendable that teams (like hotspot) have taken a 'no warnings allowed' approach to their code base, more teams should do this. Given the critical nature of a VM in the JDK, it only makes sense to take all precautions in verifying the code is correct. I find it quite interesting that the one situation where -Werror is used is where it's likely to hit the most difficulties. The HotSpot code is compiled by three different compilers (gcc and whatever is used on Solaris and Windows) and the version of these used can vary considerably, as the system C++ compiler is unrelated to the JDK. Hotspot only uses -Werror with gcc. And its use predates the sudden plethora of compiler versions now used to build OpenJDK. In prior times the build compiler for a given release was set in stone so we knew what warnings (and bugs!) to expect. Welcome to OpenJDK. You can't expect everyone compiling a FOSS project to use one true compiler and no other. Sorry. That's just the reality, and it's why we now have to reassess/amend these earlier choices. I was simply stating the history. Ah, ok. It read to me as if you expected this to still be possible. snip It does. I'm unclear how anything you say here is different to the situation with C/C++ compilers producing new warnings in new versions. I'm unclear what point you are trying to make about javac. javac produces new warnings because new language features cause new potential issues. There are no new features in C/C++ (compiler-specific extensions ignored), the compilers just get more pedantic about what they complain about. My point was just that it's interesting that it's HotSpot, which is subject to the most variance in compilers (and thus the warnings produced) that opts to have -Werror on by default. The Java code doesn't, yet the compiler for it is actually developed as part of the OpenJDK code base. It's not going to see the same kind of problem where someone installs the new version of the system compiler and gets new warnings, so -Werror behaviour with Java code would be much more stable. I don't think all javac warnings are down to new language features and, having most warnings turned off and not causing errors, means that more warnings build up as new code is written. If anything, OpenJDK is leading the way with support for these new language features, so you'd expect it to adopt them in its own codebase. As is, we're still getting warnings resulting from features introduced in 2004. Practical realities - there were no resources, for example, to go and change every single class that used a collection type in 1.4.2 and so generated a raw type warning once generics were added in 5. These things sometimes get cleaned up when other work is occurring in an area. Also note that in many cases javac warnings are disappearing because @SuppressWarnings is being applied to the code. I understand that. It actually makes for some pretty good low hanging fruit for external contributors to OpenJDK IMHO. It's akin to the janitoral work done on Linux if you're familiar with that. I did find it worrying that there was an active desire to use new OpenJDK7 language features throughout the codebase (despite the bootstrapping problems this can cause), yet these 1.5 issues remain. David - I think comparing C/C++ compiler warnings with javac compiler warnings is like comparing apples and elephants. David - -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37
Re: Build Infrastructure Project
On 16:12 Fri 20 May , Kelly O'Hair wrote: On May 20, 2011, at 3:36 PM, Dr Andrew John Hughes wrote: On 13:11 Fri 20 May , Kelly O'Hair wrote: We now have a Build Infrastructure project! Register for email at: http://mail.openjdk.java.net/mailman/listinfo/build-infra-dev The repos will be at: http://hg.openjdk.java.net/build-infra/jdk7 But I haven't been able to populate them just yet, having access issues. Once the repos are primed, I hope this can get moving quickly because I want to expose what can be done to the builds in terms of turnaround improvements etc. -kto Hi Kelly, Sorry if I missed this already, but what is the purpose of this new project? Once I can get the build-infra repos primed, hopefully you will see what we are doing. I don't expect this project to last past the final jdk8 efforts, it's a sandbox for us to experiment and stabilize build changes. The big goal is to make builds faster, orders of magnitude faster, with some major makefile re-writing and organization. An additional goal is to try and make building easier, but that part of it is mostly directed at the Solaris and Windows builds, Linux isn't that hard (in my opinion :). The reason for the project is that this will be major build changes, and we will need to experiment and share our work as quickly as possible, and openly as possible. Once the changes prove to be stable and acceptable, then we will deal with the transition to jdk8, and leave the jdk7 changes for potentially being included into jdk7u2, but jdk8 is our primary target. One sub-project will be BuildDeps which will try and address how the build dependencies are identified and how local installs are automated. Haven't much detail on that yet. The major sub-project will be a re-write of the Makefiles to remove the deeply nested Makefiles, correct the target dependencies, allow for make -j N to work reliably, share common make logic, paralyze the javac compilations, etc. Pretty drastic stuff, but if we can indeed make the builds orders of magnitude faster, we hope people will welcome the changes. Hopefully Fredrik and Erik will chime in for clarification when I mis-state things. We are looking to turn around some of this work very quickly, so it's an E ticket ride if you want to watch or join in (http://en.wikipedia.org/wiki/E_ticket). ;^) -kto This sounds great and long overdue. I'd be happy to be involved if possible. IcedTea currently has to force make -j1 on the OpenJDK build... :-( -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37
Re: Build portability: enable or disable warnings
On 10:32 Thu 19 May , Alan Bateman wrote: David Holmes wrote: : In contrast, there are basically two Java compilers in general use (javac and ecj) and one is part of OpenJDK. Yet, the Java code does not have -Werror enabled by default and there are a mass of warnings there as a result. I don't understand the point you are making here. Does javac even have a -Werror? The bulk of javac warnings stem from legacy code being compiled under newer compilers with new language features - the resulting code is not erroneous hence only a warning is issued. I think comparing C/C++ compiler warnings with javac compiler warnings is like comparing apples and elephants. Yes, javac has -Werror and the build has JAVAC_WARNINGS_FATAL to turn it on. I just checked my recent build of the jdk7/jdk7 forest and javac emits a total of 9 warnings (7 are unsafe usages of varargs methods and the other two are unreachable catch clauses). That isn't a lot but javac doesn't have many warnings enabled by default. A nice project for someone would be to change the build to -Werror by default and gradually crank up the warnings listed by -Xlint. javac is generally a good citizen. I was thinking of jdk code. I have built with JAVAC_MAX_WARNINGS=true on a number of occasions and it's only recently (thanks to a few fixes from myself) that it's actually been able to complete the build, due to some Makefiles turning on Werror separately. I expect with JAVAC_WARNINGS_FATAL as well we wouldn't get past CORBA. I do think having a switch to turn on everything but serial and deprecated warnings would be a more achievable goal, and would help get rid of the remaining 1.5 stuff. -Alan. -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37
Re: Build portability: enable or disable warnings
On 07:25 Mon 16 May , Erik Trimble wrote: On 5/16/2011 6:03 AM, Andrew Haley wrote: On 05/16/2011 12:08 PM, Dalibor Topic wrote: The reason I'm asking is that I'm wondering if this is something we should expect to crop up in different parts of the code base, or whether it's a one off due to some specific thing some distros chose to do different from each other. That's hard to say. It certainly could crop in other parts of the code base, and I'm surprised it doesn't happen regularly. I'm rather appalled that distros do this kind of thing, TBH. Andrew. Just so I understand this - you're saying that by running *just* the 'gcc' command on different linux systems, that actually implies that gcc gets invoked with some set of flags already set? And, that there's no way to just invoke vanilla gcc ? If so, that's, ah, mindboggling (not in a good way)... Maybe I'm misreading what you said, but I don't find it mindboggling that an application would have default settings for certain options. That's basically what we're talking about here. If a warning can be either on or off, then one of these two has to be a default for that exact situation when the user does just say gcc and doesn't specify whether they want the warning or not. A number of distros change the defaults of gcc in order to produce more warnings, as some can point to real security issues. This runs afoul of HotSpot's use of -Werror which presumably assumes the default set of warnings used by a certain version of gcc. I think the appropriate solution to this is, as Andrew suggests, to make explicit our preference for that warning rather than relying on the implicit defaults. -- Erik Trimble Java System Support Mailstop: usca22-123 Phone: x17195 Santa Clara, CA Timezone: US/Pacific (GMT-0800) -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37
Re: Request for review: always generate java-rmi.cgi
On 17:32 Tue 10 May , Kelly O'Hair wrote: I'm a little reluctant to accept this, I'm not sure what the full ramifications are. But I think we want it. Is this in OpenJDK6 now? OpenJDK6 changes have to go through 7 first, so no. But it's been in IcedTea6 since before there were even OpenJDK Mercurial repositories and thus in all the OpenJDK6 builds actually deployed to users. -kto -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37
Re: hg: jdk7/build/jdk: 7043684: Update man pages for JDK 7 tools
On 15:31 Wed 11 May , bhavesh.pa...@sun.com wrote: Changeset: 42c22d5a2cd0 Author:bpatel Date: 2011-05-11 08:30 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/42c22d5a2cd0 7043684: Update man pages for JDK 7 tools Reviewed-by: skannan ! src/linux/doc/man/appletviewer.1 ! src/linux/doc/man/apt.1 ! src/linux/doc/man/extcheck.1 ! src/linux/doc/man/idlj.1 ! src/linux/doc/man/jar.1 ! src/linux/doc/man/jarsigner.1 ! src/linux/doc/man/java.1 ! src/linux/doc/man/javac.1 ! src/linux/doc/man/javadoc.1 ! src/linux/doc/man/javah.1 ! src/linux/doc/man/javap.1 ! src/linux/doc/man/javaws.1 ! src/linux/doc/man/jconsole.1 ! src/linux/doc/man/jdb.1 ! src/linux/doc/man/jhat.1 ! src/linux/doc/man/jinfo.1 ! src/linux/doc/man/jmap.1 ! src/linux/doc/man/jps.1 ! src/linux/doc/man/jrunscript.1 ! src/linux/doc/man/jsadebugd.1 ! src/linux/doc/man/jstack.1 ! src/linux/doc/man/jstat.1 ! src/linux/doc/man/jstatd.1 + src/linux/doc/man/jvisualvm.1 ! src/linux/doc/man/keytool.1 ! src/linux/doc/man/native2ascii.1 ! src/linux/doc/man/orbd.1 ! src/linux/doc/man/pack200.1 ! src/linux/doc/man/policytool.1 ! src/linux/doc/man/rmic.1 ! src/linux/doc/man/rmid.1 ! src/linux/doc/man/rmiregistry.1 ! src/linux/doc/man/schemagen.1 ! src/linux/doc/man/serialver.1 ! src/linux/doc/man/servertool.1 ! src/linux/doc/man/tnameserv.1 ! src/linux/doc/man/unpack200.1 ! src/linux/doc/man/wsgen.1 ! src/linux/doc/man/wsimport.1 ! src/linux/doc/man/xjc.1 ! src/solaris/doc/sun/man/man1/appletviewer.1 ! src/solaris/doc/sun/man/man1/apt.1 ! src/solaris/doc/sun/man/man1/extcheck.1 ! src/solaris/doc/sun/man/man1/idlj.1 ! src/solaris/doc/sun/man/man1/jar.1 ! src/solaris/doc/sun/man/man1/jarsigner.1 ! src/solaris/doc/sun/man/man1/java.1 ! src/solaris/doc/sun/man/man1/javac.1 ! src/solaris/doc/sun/man/man1/javadoc.1 ! src/solaris/doc/sun/man/man1/javah.1 ! src/solaris/doc/sun/man/man1/javap.1 ! src/solaris/doc/sun/man/man1/javaws.1 ! src/solaris/doc/sun/man/man1/jconsole.1 ! src/solaris/doc/sun/man/man1/jdb.1 ! src/solaris/doc/sun/man/man1/jhat.1 ! src/solaris/doc/sun/man/man1/jinfo.1 ! src/solaris/doc/sun/man/man1/jmap.1 ! src/solaris/doc/sun/man/man1/jps.1 ! src/solaris/doc/sun/man/man1/jrunscript.1 ! src/solaris/doc/sun/man/man1/jsadebugd.1 ! src/solaris/doc/sun/man/man1/jstack.1 ! src/solaris/doc/sun/man/man1/jstat.1 ! src/solaris/doc/sun/man/man1/jstatd.1 + src/solaris/doc/sun/man/man1/jvisualvm.1 ! src/solaris/doc/sun/man/man1/keytool.1 ! src/solaris/doc/sun/man/man1/native2ascii.1 ! src/solaris/doc/sun/man/man1/orbd.1 ! src/solaris/doc/sun/man/man1/pack200.1 ! src/solaris/doc/sun/man/man1/policytool.1 ! src/solaris/doc/sun/man/man1/rmic.1 ! src/solaris/doc/sun/man/man1/rmid.1 ! src/solaris/doc/sun/man/man1/rmiregistry.1 ! src/solaris/doc/sun/man/man1/schemagen.1 ! src/solaris/doc/sun/man/man1/serialver.1 ! src/solaris/doc/sun/man/man1/servertool.1 ! src/solaris/doc/sun/man/man1/tnameserv.1 ! src/solaris/doc/sun/man/man1/unpack200.1 ! src/solaris/doc/sun/man/man1/wsgen.1 ! src/solaris/doc/sun/man/man1/wsimport.1 ! src/solaris/doc/sun/man/man1/xjc.1 Where was this reviewed? Are there no sources for these files? AFAIK, 'jvisualvm' is not part of OpenJDK. -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37
Re: Request for review: always generate java-rmi.cgi
On 21:09 Wed 11 May , Dmitry Samersoff wrote: Omair, CR 7043921 . It need someone from jdk team to integrate it. Omair has commit rights so he can just push it now. -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37
Re: Request for review: do not use --sync with df during sanity check
On 18:14 Wed 04 May , Kelly O'Hair wrote: On May 4, 2011, at 5:42 PM, Dr Andrew John Hughes wrote: 7042040: Remove disk space sanity check Ok, if http://cr.openjdk.java.net/~andrew/sync/webrev.02/ looks ok, I'll push it to the build tree. Files: jdk/make/common/shared/Defs-versions.gmk jdk/make/common/shared/Sanity-Settings.gmk Define and refer to REQUIRED_FREE_SPACE Those lines should be deleted too. Otherwise looks fine. Try http://cr.openjdk.java.net/~andrew/sync/webrev.03/ I'm not sure how much longer we can accept non-critical changes for jdk7. The approval process is getting stricter, and my tendency is to avoid all changes to jdk7 from now on, unless it is really critical or urgent. Mostly because I hate red-tape. ;^) Me too. As OpenJDK8 repositories still aren't available [1], doesn't this mean OpenJDK is effectively closed for business for at least the next three months? -kto 1. http://mail.openjdk.java.net/pipermail/gb-discuss/2011-April/000110.html -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37
Re: Request for review: do not use --sync with df during sanity check
On 17:35 Wed 04 May , Omair Majid wrote: Hi, Can someone please review the following webrev? http://cr.openjdk.java.net/~omajid/webrevs/no-sync/01/ It modifies the sanity check (under linux) to use df without --sync when it computes the free space. This is what is done in the solaris case. The accuracy gained by using --sync is probably not worth the performance loss caused by flushing disk buffers. The patch was originally written by Andrew John Hughes (ahug...@redhat.com) and we have had this in icedtea6 for almost a year now. Thanks, Omair Let's see if you do better than I did... http://mail.openjdk.java.net/pipermail/build-dev/2010-June/003056.html -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37
Re: Request for review: do not use --sync with df during sanity check
On 15:37 Wed 04 May , David Katleman wrote: Would be interesting to know the original objection to Andrew's change last year. If there was one, it never reached me either publicly or otherwise. The archives show no responses. Absent that, I see no reason this could not be removed and the change looks fine. When originally implemented 10+ years ago, disk space was considerably smaller, as were buffers, so an accurate count was more relevant. Today multiple builds on the same disk are fairly common, making the check itself even less useful. Add to that, the information being gathered is just for a WARNING, the build will continue, regardless. Hardly the need for exacting accuracy, especially since the df information is then compared to static estimates of how much space a build will consume. Dave (katleman) This is my thinking too. I'm happy to extend the fix to just get rid of the check altogether if that seems appropriate. I'll need a bug ID for this. -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37
Re: Request for review: do not use --sync with df during sanity check
On 16:27 Wed 04 May , Kelly O'Hair wrote: I agree we should toss the check. I'll need a bug ID for this. 7042040: Remove disk space sanity check Ok, if http://cr.openjdk.java.net/~andrew/sync/webrev.02/ looks ok, I'll push it to the build tree. -kto -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37
Re: Fwd: Heads up, new jaxp source drop
On 09:23 Mon 02 May , Fredrik Öhrström wrote: Thanks! But I am of the strong opinion that the jaxp and jaxws source code should be committed into the jaxp/jaxws repositories when drops are made. //Fredrik +1 -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37
Re: Heads up, new jaxp source drop
On 08:40 Mon 02 May , Kelly O'Hair wrote: There has been a request for essentially that, more transparency on these sources. The downloads are also painful, I know. The issue with these sources is that they are effectively 'generated sources', transformed from master sources maintained elsewhere. Having them in the repository is too tempting for many developers, changing them either purposely or by accident. I need a mechanism that keeps these sources protected from any change except when being updated by a new delivery from the jaxp team (or jaxws). There already is a mechanism... it's called don't approve such commits. It's especially a problem when it comes to security fixes and the 'fix' is to change one URL to another. -kto -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37
Re: After the last update
On 14:27 Wed 27 Apr , Frédéric Le Mouël wrote: cd linux_i486_compiler1/product ./test_gamma java full version 1.6.0_24-b07 Using java runtime at: /opt/sun-jdk-1.6.0.24/jre java version 1.6.0_24 Java(TM) SE Runtime Environment (build 1.6.0_24-b07) ^^^ This bit isn't OpenJDK. -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37
Re: hg: jdk7/deploy/langtools: 19 new changesets
Is it necessary to have all these posted to build-dev? There doesn't seem to be any work going on, just merging as far as I can see. Shouldn't this be on its own deploy-dev list? As far as I'm aware, the deploy team don't do any OpenJDK work anyway. On 01:30 Wed 09 Mar , igor.nekrestya...@oracle.com wrote: Changeset: c6cb387190ee Author:jjg Date: 2011-02-09 14:04 -0800 URL: http://hg.openjdk.java.net/jdk7/deploy/langtools/rev/c6cb387190ee 7016750: tools/javac/nio/CompileTest failing in nightly test Reviewed-by: mcimadamore ! test/tools/javac/nio/compileTest/CompileTest.java Changeset: 3ce4e1a07e92 Author:jjg Date: 2011-02-09 14:10 -0800 URL: http://hg.openjdk.java.net/jdk7/deploy/langtools/rev/3ce4e1a07e92 7010792: remove bad debugging method from javac Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/parser/Scanner.java Changeset: bfa59f3e84bd Author:jjg Date: 2011-02-09 18:26 -0800 URL: http://hg.openjdk.java.net/jdk7/deploy/langtools/rev/bfa59f3e84bd 7018447: langtools launcher template fails if tools run from their own directory Reviewed-by: jjg Contributed-by: daniel.sm...@oracle.com ! src/share/bin/launcher.sh-template Changeset: a19b1f4f23c9 Author:jjg Date: 2011-02-10 14:24 -0800 URL: http://hg.openjdk.java.net/jdk7/deploy/langtools/rev/a19b1f4f23c9 7018098: CacheFSInfo persists too long Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/file/CacheFSInfo.java ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java + test/tools/javac/file/T7018098.java Changeset: 747a7601b6d6 Author:jjg Date: 2011-02-10 14:27 -0800 URL: http://hg.openjdk.java.net/jdk7/deploy/langtools/rev/747a7601b6d6 7018452: langtools not buildable on Mac Reviewed-by: ohair ! make/build.xml Changeset: e0c16199b2e0 Author:jjg Date: 2011-02-10 15:05 -0800 URL: http://hg.openjdk.java.net/jdk7/deploy/langtools/rev/e0c16199b2e0 6485027: javac incorrectly handles relative paths in manifest classpath Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/file/Paths.java ! test/tools/javac/Paths/Class-Path.sh + test/tools/javac/Paths/Class-Path2.sh ! test/tools/javac/Paths/Diagnostics.sh Changeset: bfeed79c70aa Author:jjg Date: 2011-02-11 17:10 -0800 URL: http://hg.openjdk.java.net/jdk7/deploy/langtools/rev/bfeed79c70aa 6505047: javax.lang.model.element.Element.getEnclosingElement() doesn't return null for type parameter Reviewed-by: darcy + test/tools/javac/processing/model/element/TestTypeParameter.java Changeset: ef6c66215a93 Author:jjg Date: 2011-02-14 14:27 -0800 URL: http://hg.openjdk.java.net/jdk7/deploy/langtools/rev/ef6c66215a93 7008433: Minor copyright changes Reviewed-by: jjg Contributed-by: kelly.oh...@oracle.com ! test/tools/javac/4917091/Test255.java ! test/tools/javac/4917091/Test256a.java ! test/tools/javac/4917091/Test256b.java Changeset: 351027202f60 Author:mcimadamore Date: 2011-02-15 11:49 + URL: http://hg.openjdk.java.net/jdk7/deploy/langtools/rev/351027202f60 7017664: Add listeners infrastracture to javac scopes Summary: Add listeners to javac scopes, added CompoundScope and correct invalidation logic for ImplementationCache Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Scope.java ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Check.java + test/tools/javac/scope/7017664/CompoundScopeTest.java + test/tools/javac/scope/7017664/ImplementationCacheTest.java Changeset: fa0e4e1916f4 Author:mcimadamore Date: 2011-02-15 11:51 + URL: http://hg.openjdk.java.net/jdk7/deploy/langtools/rev/fa0e4e1916f4 7017104: improve error reporting for uncaught/undeclared exceptions from try-with-resources Summary: twr should generate better error message when uncaught exceptions are thrown by implicit call of close() method Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Flow.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! test/tools/javac/TryWithResources/ResourceInterface.out ! test/tools/javac/TryWithResources/TwrFlow.out + test/tools/javac/diags/examples/UnreportedExceptionImplicitClose.java Changeset: 846d6644bb70 Author:lana Date: 2011-02-15 08:35 -0800 URL: http://hg.openjdk.java.net/jdk7/deploy/langtools/rev/846d6644bb70 Merge Changeset: 0c24826853b2 Author:dlsmith Date: 2011-02-16 10:27 -0800 URL: http://hg.openjdk.java.net/jdk7/deploy/langtools/rev/0c24826853b2 6990136: Cleanup use of Type.clone() Summary: Introduced factory methods in class Types which can be used rather than clone(). Reviewed-by: jjg, mcimadamore !
Re: Need reviewer: CC_VER checks on compiler options
On 14:33 Thu 21 Apr , Kelly O'Hair wrote: This started out as an annoyance around the use of -Wno-clobber on Linux when the gcc might not support it. Turned into fixing several CC_VER checks in the makefiles: 7038711: Fix CC_VER checks for compiler options, fix use of -Wno-clobber http://cr.openjdk.java.net/~ohair/openjdk7/jdk7-build-ccver/webrev/ -kto Is there a reason for keeping this static linking at all? -ifeq ($(CC_VER_MAJOR), 3) -OTHER_LDFLAGS += -static-libgcc +ifeq ($(CC_MAJORVER),3) + OTHER_LDFLAGS += -static-libgcc -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37
Re: Need reviewer: Exceptions to mapfile rule on shared libraries
On 15:14 Fri 15 Apr , Phil Race wrote: For jpeg its something we could consider for JDK 8 although I think its been called libjpeg since JDK 1.0 without apparent problems. But you use an in-tree libjpeg (at least at present). Having the option of linking against a system libjpeg at compile time would mean -o libjpeg.so -l jpeg, with two different libjpegs. -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37
Re: Building open-jdk7 en gentoo
On 11:41 Tue 19 Apr , Kelly O'Hair wrote:
I imagine there are probably hundreds of variable names that if set in the
environment,
could impact the build, on purpose or by accident :^(.
We do check for JAVA_HOME and LD_LIBRARY_PATH.
Is JAVAC some kind of typical or standard environment variable that people
set?
I've never seen any use of the name JAVAC in the environment.
If it's a common use, then yes, maybe a sanity check is in order.
I hit this problem a lot with Gentoo and OpenJDK in the early days. IcedTea
unsets
JAVAC for this reason. I have no idea why Gentoo sets the variable. It is
pretty
much alone among GNU/Linux distros in doing so and I have no idea why it does.
Then
again, daily Gentoo usage involves a lot more Java building than on regular
distros
as Java packages are built from source.
The actual issue is completely broken use of JAVAC from the environment by the
OpenJDK
build (lovely old CORBA in particular). Instead of replacing:
javac ${OPTS} @files
with
${JAVAC} ${OPTS} @files
it uses
${JAVAC} @files
which is clearly going to break the build as things like the classpath are
being lost.
A sanity check is probably a good first start, but maybe fixing the build to
use it properly
might be useful long term. I have no idea why the build is trying to use it to
begin with,
except maybe a genuine namespace collision.
Sorry for not reporting this way back. I was hitting it before I was working
on IcedTea/OpenJDK
full time and before there was anything like the community there is now around
this project.
-kto
On Apr 19, 2011, at 4:53 AM, Frédéric Le Mouël wrote:
Hi all,
I just succeed in compiling open-jdk7 on a Linux gentoo.
FYI, after fighting a bit, I had to unset JAVAC environment variable
to let it compile. I think that this checking should be done
in the sanity makefile target.
My two cents,
FLM.
--
Frédéric Le Mouël, Associate Professor | Phone: (+33|0)4 72 43 64 22
INRIA Amazones Team / CITI Laboratory | Fax : (+33|0)4 72 43 62 27
INSA Lyon - Claude Chappe Building | Room : 235
6 avenue des Arts | frederic.le-mo...@insa-lyon.fr
F-69621 Villeurbanne Cedex, France | http://citi.insa-lyon.fr/~flemouel
--
Andrew :)
Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)
Support Free Java!
Contribute to GNU Classpath and IcedTea
http://www.gnu.org/software/classpath
http://icedtea.classpath.org
PGP Key: F5862A37 (https://keys.indymedia.org/)
Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37
Re: openJDK7 build fails on 64bit cblfs linux
On 18:03 Sat 16 Apr , luxInteg wrote: snip... What kind of Linux is this? This is blfs linux built by compiling sources from scratch. BLFS has instructions on building IcedTea6 which uses OpenJDK6 here: http://www.linuxfromscratch.org/blfs/view/cvs/general/icedtea6.html -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37
Re: Need reviewer: Exceptions to mapfile rule on shared libraries
On 16:18 Tue 12 Apr , Kelly O'Hair wrote: On Apr 12, 2011, at 3:58 PM, Dr Andrew John Hughes wrote: On 13:46 Tue 12 Apr , Kelly O'Hair wrote: Some shared libraries do not have and will not have mapfiles, at least for now, we give these an exception to the mapfile check (which just issues a warning). 7033957: Library built without a mapfile: libxinerama.so http://cr.openjdk.java.net/~ohair/openjdk7/jdk7-build-mapfile-warning-sparc/webrev/ -kto On a related note, is it wise to have these libraries using the same names as system libraries? libxinerama is the same as libXinerama with the exception of case. I believe the JDK also has a libjpeg which is identically named to the system install. Could it not be libjxinerama.so, libjavajpeg.so or some such? I'll CC Phil. Given the age of these libraries, I'm very hesitant to change the names. As far as library naming in general, I can see your point, but I'm not sure we could change them now. Maybe in JDK8? But not after some discussions on what the impact might be. :^( Yes, I wasn't expecting anything immediate, but I thought the topic needed raising. It's something I've been musing on. My particular concern is things like libjpeg where we'd like to have the option to link against the system install instead. IcedTea currently has a mass of dlopen/sym call additions to support a system libjpeg that I don't really fancy trying to upstream. I think having the library calling libjpeg.so might be a barrier to just linking at compile-time, but I have yet to try it. -kto Thanks, -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37
Re: Need reviewer: Exceptions to mapfile rule on shared libraries
On 13:46 Tue 12 Apr , Kelly O'Hair wrote: Some shared libraries do not have and will not have mapfiles, at least for now, we give these an exception to the mapfile check (which just issues a warning). 7033957: Library built without a mapfile: libxinerama.so http://cr.openjdk.java.net/~ohair/openjdk7/jdk7-build-mapfile-warning-sparc/webrev/ -kto On a related note, is it wise to have these libraries using the same names as system libraries? libxinerama is the same as libXinerama with the exception of case. I believe the JDK also has a libjpeg which is identically named to the system install. Could it not be libjxinerama.so, libjavajpeg.so or some such? -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37
Re: Avoid certain functions in C/C++
On 08:50 Wed 06 Apr , Kelly O'Hair wrote: Just an FYI... Anyone working with C/C++ should be well aware of the functions we should be avoiding: http://hub.opensolaris.org/bin/view/Community+Group+security/funclist Microsoft has used the term banned and has a much more extensive list: http://msdn.microsoft.com/en-us/library/bb288454.aspx Unfortunately, we often cannot use the recommended replacements unless we know that the replacement is available on all platforms, however, some are fairly obvious, like using snprintf instead of sprintf. Functions like sprintf, vsprintf, strcat, strcpy, access, chmod, chown, lchown, chdir, ... all have know issues or have caused too many common mistakes over the years, we need to avoid the use of these functions. Thanks for the list. That'll surely prove a useful reference. Have you considered using autoconf in OpenJDK? It was pretty much designed for just this scenario (checking the availability of functions). -kto -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37
Re: [PATCH REVIEW]: Include Shark code in the build again
On 20:15 Thu 31 Mar , David Holmes wrote: Dr Andrew John Hughes said the following on 03/31/11 06:31: On 09:42 Wed 30 Mar , Kelly O'Hair wrote: On Mar 30, 2011, at 9:26 AM, Dr Andrew John Hughes wrote: This change (arrived at by both myself and Gary Benson separately): http://cr.openjdk.java.net/~gbenson/zero-shark-fixes-04-1/ fixes the issue by adding Shark back into the mix. Kelly, can you approve these build changes? Looks fine to me. Thanks, so now I just need a HotSpot dev to give it a bug ID and push it through their JPRT thing... 7032775 filed ... working on the push Thanks David. David -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37
Re: [PATCH REVIEW]: Include Shark code in the build again
On 09:42 Wed 30 Mar , Kelly O'Hair wrote: On Mar 30, 2011, at 9:26 AM, Dr Andrew John Hughes wrote: This change (arrived at by both myself and Gary Benson separately): http://cr.openjdk.java.net/~gbenson/zero-shark-fixes-04-1/ fixes the issue by adding Shark back into the mix. Kelly, can you approve these build changes? Looks fine to me. Thanks, so now I just need a HotSpot dev to give it a bug ID and push it through their JPRT thing... --- Although overall, I don't understand why someone used so many := assignments. I usually reserve := for special assignments that require a shell or complex evaluation. The := forces an expansion of the right side on the spot, so any later changes to the variables used on the right will have no impact on your variable. In Makefiles, that's usually what you don't want, but I suppose there are cases where that is expected. By using := all the time, you have created a specific order dependency on the variables, but whatever, ... I've never really used := either, and I see your point, but that's not really something to change in this changeset :-) -kto -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37
Re: How to check out the openjdk source code from the mercurial repositories
On 08:43 Tue 15 Mar , Kelly O'Hair wrote: On Mar 15, 2011, at 2:05 AM, Steve Poole wrote: A singular process that everyone uses? Good Luck with that. I think that is called herding cats. :^) Sorry, I've been doing this too long, if there is a variation on doing development and one person finds it productive for them, they will use it. Sorry - I was not being clear.I meant that you must have one singular process that is the agreed official process. If someone decides to do something different that's ok - provided they understand that they have to take their lumps when and if they cause a break in the main build or cause testcases to fail. The important point I was trying to make is that the process used by contributors must always work. In my opinion the best way to achieve that is to ensure it's in use day by day. Ah, yes we have the official Release Engineering build system and tool requirements. But it's more in the form of a list of versions and fairly controlled build systems used by Release Engineering to perform the nightly, weekly promoted, and final product builds. The makefiles have sanity checks to try and police these versions and will issue warning messages when what you are using differs, and fatal sanity errors there is a high risk of a bad build or build failures given the version of some component. I think he means not so much your RE processes, but the method documented in the build documentation. These sanity rules were relaxed quite a bit when we open sourced due to the larger variety of build systems and compiler versions being used out there. There is no ./configure mechanism and no 'download and install' scripts that install all the specific tools needed to do a build, partially because solving this problem for all the Windows, Solaris, and Linux systems was not easy. Linux is easy in this regard, Solaris a bit harder, Windows is well... tricky. :^( We did that already. It's called IcedTea. -kto -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37
Re: Request for review: Build changes in preparation for SE-Embedded support
On 07:59 Wed 16 Mar , David Holmes wrote: Hi Andrew, See inline ... Dr Andrew John Hughes said the following on 03/16/11 07:43: On 18:05 Tue 15 Mar , David Holmes wrote: BUILD_CLIENT_ONLY: http://cr.openjdk.java.net/~dholmes/jdk-bco/webrev/ Provides support for building a JDK for which only the client VM is required and/or available. Essentially avoids copying any server components and creates a jvm.cfg file that aliases -server to -client. If BUILD_CLIENT_ONLY is selected on a 64-bit build then a sanity warning is issued. (This is only a warning because you can actually build 64-bit client Hotspot, it just isn't supported and you can't directly build it in a full JDK build without hacking a couple of Makefiles). There still seem to be some odd whitespace changes in this one. Otherwise, looks sensible. emacs reported odd whitespace (space+Tab) in one of the makefiles so I fixed it. Ok. I'd suggest keeping such changes separate, but you probably don't want to file a CR just for this... --- Cross-compilation support: http://cr.openjdk.java.net/~dholmes/jdk-crosscomp/webrev/ Basic support for cross-compilation, plus flags/settings etc for basic ARM and PPC support in the shared open code. Cross-compilation works as follows: - you must set the ALT_COMPILER_PATH and ALT_OPENWIN_HOME to point to your cross-compiler (you'll also need freetype configured correctly) What is ALT_OPENWIN_HOME? And why should using the cross-compilation build mean that 'X11 headers are not under /usr/include'? Why 'OPENWIN' and not 'X11'? OPENWIN_HOME/ALT_OPENWIN_HOME are the variables used to control where to find the graphics includes and libraries. These are pre-existing build variables (though part of the AWT update forward ports some changes from JDK6 that replaces hard-wired paths with use of these variables). When cross-compiling you need to use the graphics headers that are part of your cross-compilation toolset, not those on your build system (some compilers will even warn you if you do use the system ones). OPENWIN is a legacy name from the old Solaris/SunOS graphics stack: http://en.wikipedia.org/wiki/OpenWindows Ok, so it's a legacy name for X11 that means something to Solaris users :-) - CROSS_COMPILE_ARCH should be set to the architecture you are building for eg ARM, PPC - EXTRA_CFLAGS can be used to pass cross-compilation specific compile options - HOST_CC is a compiler that can produces binaries that can run on the build host (used in a few parts of the JDK build). This defaults to gcc on Linux but must be explicitly set elsewhere - Some build features such as freetype-check and binary-file-verification are disabled as they don't apply when cross-compiling Rest seems ok. Thanks! Once I have Kelly's ok I'll create the CRs and get this pushed ASAP. David - The above will form the basis of the documentation for these changes, but as it seems the docs live in a different repository (???) I'll need to file a separate CR etc for that. Thanks for the reviews. Kelly: I will need to push these via TL not BUILD due to various dependencies. However I also need the module changes to propagate from BUILD to TL before doing so. :( David Holmes Java SE Embedded Group -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37
Re: JDK8 Preliminary Repository Layout
On 19:27 Wed 09 Mar , Phil Race wrote: Andrew, Whilst almost everything you wrote is something I agree with (like getting jcheck out there, not adding additional build tools/complexity), the one thing I quite like right now comes up here I'd like to keep is the separate repos. Its not just hotspot, but I've been working on JDK for a long time now, since before there was a hotspot and last year I built hotspot for the first time, and even then only because I was working on the VS2010 compiler upgrade. So I like that hotspot and jaxp/jaxws can be pre-built and pulled from an import JDK in a way that doesn't slow down my builds, bloat the source I need to pull via hg etc etc. Well HotSpot is one thing I think works well as a separate repository. It allows us to have a stable branch for OpenJDK6 for example. The only real thing that stops it being independent is the servicability agent, which, IME, would be better held in the JDK. That would also mean that the existing rules for building java classes could be used, rather than reinventing it all in the HotSpot makefiles as at present. Likewise, I think langtools works as a separate entity. The other three (corba, jaxp, jaxws) only really exist separately because no-one on the OpenJDK project takes care of them. JAXP and JAXWS get irregular build drops, but I don't think I've seen anything more than build fixes for CORBA. They would be less work if maintaining in the JDK directory as they'd share the build infrastructure. They are hardly huge (unlike HotSpot vs. JDK) and there are dependencies between the JDK and these. I probably should provide some context. During this week, I've been looking at getting OpenJDK bootstrapping well when OpenJDK is not the bootstrap JDK (i.e. sun.* and com.sun.* classes are not available). To cut a long story short, it's a week later and I'm still only at HotSpot. So far, I've found dependencies in all but JAXP that mean that the build has to be patched to reference other repositories (mainly JDK but also langtools in one case). JAXWS has to be able to find com.sun.net.httpserver, annotation/javadoc classes and the JAXP classes, while CORBA needs the sun.tools stuff and HotSpot needs com.sun.jdi for the servicability agent. Now you may think this isn't relevant and expect people to just use OpenJDK to build. Well, this also becomes a problem if one of these APIs changes. You're building stuff in CORBA, JAXWS and HotSpot against a different API than the one they will eventually run against, hiding issues which could be exposed at build time until run time. I've already run across one place where this is true. HotSpot builds the servicability agent with -source 1.4 -target 1.4. Why? Because of incompatibilies between its implementation and the com.sun.jdi interfaces which require ComparableT not Comparable. Maybe this doesn't matter to people who want to pull a full forest but its great for those working on specific components. Which I believe is most developers. It's hard to generalise, especially with an open source project. These mailing lists show that there will be quite a few newbies who follow the build guides and try downloading the entire forest. As was mentioned elsewhere in this discussion, the tarballs would be better for this scenario as you don't really need the repos unless you're going to create a patch (and even then, there are ways to do that without them). My concern isn't the pull, but simply what makes best sense in terms of maintenance, both of the code and the build system. Having independent repositories also means duplicate build code and cross-repo dependencies. With HotSpot and langtools it makes sense as you have independent entities (the VM and javac et. al.). I don't think it makes sense with code that has to then be imported into the JDK build. -phil. On 3/9/2011 4:48 PM, Dr Andrew John Hughes wrote: On 18:32 Tue 08 Mar , Kelly O'Hair wrote: First, if we talk about the mercurial forests, it has nothing to do with the Mercurial Forest Extension. What we really have is a set of nested repositories, sometimes called our forest of repositories. This email is just about the actual layout of the repositories for jdk8. The initial thinking at this time is that the openjdk8 open forest will look very much like openjdk7: openjdk8/ corba/ jaxp/ jaxws/ jdk/ hotspot/ langtools/ 7 repositories total. Cloned from the openjdk7 repos so we will have all the openjdk7 history in the openjdk8 repositories. Just for discussion sake, not that you can see what is behind the closed curtains, we are considering changing the closed overlay a little, from the current jdk7 (bold is a closed repo): jdk7/ corba/ deploy/ jaxp/ jaxws/ jdk/ src/closed/ test/closed make/closed/ hotspot/ src
Re: How to check out the openjdk source code from the mercurial repositories
On 06:40 Fri 11 Mar , David Holmes wrote: Fredrik Öhrström said the following on 03/10/11 20:22: I think it is important that a recent stock mercurial install can check out the full openjdk with a single clone command. I.e. you should not have to install special extensions just to get the source code. That's a bit of a leading/loaded question ;-) There are several ways this can be solved. But before we dive into discussions on the possible alternatives, I would like to see who else think it is a good idea. Stepping up a level, an initial download of openjdk need not involve using mercurial at all. You can simply download a stable snapshot as a tar file; This makes much more sense as a starting point for new users over having to handle Mercurial and checkouts. It works fine if you just want to _use_ the latest and greatest, not hack on it. or download an install script that will do whatever is necessary behind the scenes to get a complete openjdk. I don't know how that would work. I guess IcedTea comes close to this idea in that it detects the needed settings for the build, rather than them all having to be passed as make variables. Personally I'd like to see that include the basic build tools as well - in which case I don't care about special extensions as I just get a working toolkit. What do you mean by this? Can you give an example? I think in the scheme of things the process of getting the source code for the openjdk is the easiest part of the process. Depending on your platform setting up mercurial so that you could do that single clone command may be a far greater problem. And setting up the build environment an order of magnitude greater again. Clearly, comments from people outside of Oracle are the most important! Clearly. :) Well as a person outside Oracle, I'd agree that getting a checkout is the least of my problems. Configuring builds and fixing bugs is a much greater problem than having to write a few extra 'hg clone' commands to get a full checkout. It's just a matter of using a for loop or cobbling together a shell script as Kelly has done. Trivial stuff for anyone planning to build or hack on OpenJDK. Cheers, David (When the source is checked out, then there can be mercurial extensions in the checked out source code for example jcheck that assists in sanity tests before committing. So this does not limit the actual extensions used later. Only that we should not improve on the versioning part of mercurial.) jcheck is server-side. It needs to be released as Free Software not so we can all run it but so we can see what the heck it's doing and fix issues with it. //Fredrik -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37
Re: Preliminary request for review: 7025066 Build system changes to support SE Embedded integration
On 17:35 Thu 10 Mar , David Holmes wrote: Dr Andrew John Hughes said the following on 03/10/11 10:26: On 22:09 Wed 09 Mar , David Holmes wrote: My original reply does not seem to have made it to build-dev. I've updated the webrev again to accommodate openjdk builds that set REDUCED_JRE and/or REDUCED_HEADLESS_JRE. The main changes are: Another problem with these webrevs is that you don't know if someone changed it. Neither do you then have any history of what went before. Sorry, this was just a preliminary RFR so I didn't set up the webrev versioning. My issue was more a personal distaste for webrevs than anything you did wrong. I just find it much easier if everything is in the e-mail and can be commented on inline rather than on some website that has to be loaded up in a separate window and can change or even disappear. It's especially true for big patches like this, where you really need to break the patch down in the mail. I'm looking into a new structure where the JAVASE_EMBEDDED stuff is factored out into Defs-embedded.gmk and Release-embedded.gmk. This will relegate the reduced-jre targets to being relevant to embedded only and anyone not interested just doesn't look in those files. My fear is not so much Makefile clutter as that untested options can bit rot. People make modifications in one area and these unused options are missed. That's actually more likely if you squirrel it away in a separate file. I'm also looking at breaking this into three components - build-client-only (if I can't somehow hide that in the embedded bits) - basic cross compilation support - SE-Embedded support (including things like COMPRESS_JARS and ZIP_CAN_USE_MMAP) Stay tuned. Thanks again for the feedback. Thanks. David - don't try to run freetypecheck when cross-compiling - delete build of freetypecheck from make/tools/Makefile as Sanity.gmk will build if needed These sound sensible changes. We've run into similar issues with the freetype test in IcedTea too. - for OpenJDK builds leave the JRE fonts alone (the Lucida fonts that we don't delete are not part of OpenJDK) Ah, that solves what I just explained in my last reply. David - David Holmes said the following on 03/09/11 09:33: Andrew, Dr Andrew John Hughes said the following on 03/09/11 03:24: On 10:51 Tue 08 Mar , David Holmes wrote: Just to clarify for people, BUILD_CLIENT_ONLY refers to building the client VM only. Some of these variables should be documented in the top level README-builds.html file, but that can be done under a separate CR if necessary. What happens if there is no client VM e.g. x86_64? If you are not building a client-only configuration then you should not set BUILD_CLIENT_ONLY. It's main purpose is to not attempt to copy lib/arch/server/*.so files into the JRE/JDK image when they don't exist. But what if someone does? Will the sanity check not catch this? If you specify BUILD_CLIENT_ONLY then you are telling the build system to not try and copy/define anything pertaining to the server VM. Whether or not you've built a server VM in such circumstances is irrelevant and certainly not a fatal error requiring a sanity check (I'm not even sure the sanity check can tell). I can certainly refactor into general flags, however applying those flags to all parts of the JDK build process that might want to use them is out-of-scope for what I am trying to achieve here (I just won't have time to do this and go through a myriad of builds and test runs). I'd also prefer not to create multiple changesets, which implies multiple CRs. I can't easily test these things in isolation, and individual changesets would require complete build/test cycles that I again do not have time to perform. I can see the issue with it taking more time, but committing the patch in its current form is unfair on others who now have a more convoluted build system to deal with (and it's already bad to start with) and no gain from the patch. The intent is that anyone not setting any of the new build variables will be unaffected by these changes. They may benefit from the basic cross-compilation support, and the ability to produce a client-only JRE/JDK. Does the revised structure improve things from your perspective? Does your employer not allocate sufficient time to do the best work you can on such changes? We all have schedules and deadlines to meet. These changes have been percolating for sometime now and my window for getting them out is quite narrow. My problem is exacerbated by the fact that JDK7 is a fast moving target at the moment and so I'm continually having to merge changes, update things that break my build, and go through the rebuild cycle again to verify things. Hence I want to try and push things through in one hit
Re: Preliminary request for review: 7025066 Build system changes to support SE Embedded integration
On 09:33 Wed 09 Mar , David Holmes wrote: Andrew, Dr Andrew John Hughes said the following on 03/09/11 03:24: On 10:51 Tue 08 Mar , David Holmes wrote: Just to clarify for people, BUILD_CLIENT_ONLY refers to building the client VM only. Some of these variables should be documented in the top level README-builds.html file, but that can be done under a separate CR if necessary. What happens if there is no client VM e.g. x86_64? If you are not building a client-only configuration then you should not set BUILD_CLIENT_ONLY. It's main purpose is to not attempt to copy lib/arch/server/*.so files into the JRE/JDK image when they don't exist. But what if someone does? Will the sanity check not catch this? If you specify BUILD_CLIENT_ONLY then you are telling the build system to not try and copy/define anything pertaining to the server VM. Whether or not you've built a server VM in such circumstances is irrelevant and certainly not a fatal error requiring a sanity check (I'm not even sure the sanity check can tell). I'm not saying it should define anything with respect to the server VM, merely that x86_64 (and possibly other platforms in future) and BUILD_CLIENT_ONLY are incompatible and the sanity check could catch this with an arch check. I can certainly refactor into general flags, however applying those flags to all parts of the JDK build process that might want to use them is out-of-scope for what I am trying to achieve here (I just won't have time to do this and go through a myriad of builds and test runs). I'd also prefer not to create multiple changesets, which implies multiple CRs. I can't easily test these things in isolation, and individual changesets would require complete build/test cycles that I again do not have time to perform. I can see the issue with it taking more time, but committing the patch in its current form is unfair on others who now have a more convoluted build system to deal with (and it's already bad to start with) and no gain from the patch. The intent is that anyone not setting any of the new build variables will be unaffected by these changes. They may benefit from the basic cross-compilation support, and the ability to produce a client-only JRE/JDK. It also means that someone will need to regularly maintain the settings created by these new variables. I think it's more likely that this work would be tested and maintained by others if individual options were available without requesting an entirely different build. This is especially the case with JAVASE_EMBEDDED as I'm not sure what that even equates to (except some future Oracle product). Does the revised structure improve things from your perspective? I'm not sure what 'revised structure' you're referring to. Does your employer not allocate sufficient time to do the best work you can on such changes? We all have schedules and deadlines to meet. These changes have been percolating for sometime now and my window for getting them out is quite narrow. My problem is exacerbated by the fact that JDK7 is a fast moving target at the moment and so I'm continually having to merge changes, update things that break my build, and go through the rebuild cycle again to verify things. Hence I want to try and push things through in one hit (in actuality several other changes that are more stand-alone have already been broken off from this). Yes, we're all subject to the fast development pace of OpenJDK7, but I guess that will start to slow down when OpenJDK8 forks off. I would have thought committing stuff in small chunks was more amenable to this situation, as there is less chance of something disrupting it while you're working on it and you can get it in the codebase quicker. Has this been tested on an OpenJDK build at all? It also seems to create a fonts.dir file with fonts that aren't part of OpenJDK. No, not OpenJDK. I have done a regular JDK build, but not OpenJDK. And I have not attempted to test things like BUILD_CLIENT_ONLY outside of a JAVASE_EMBEDDED build. With regard to the fonts, my understanding is that we simply define a subset of the fonts used in the regular JDK. I have no idea how such fonts get shipped nor whether they are part of the OpenJDK or only Oracle's JDK. An OpenJDK build definitely needs to be performed before this is committed, as I think it may break the build or, at the very least, create references to non-existent fonts. I have no problem doing an OpenJDK build on this, I will attempt an OpenJDK build that uses all of the new flags except for actually defining JAVASE_EMBEDDED. That said I still don't understand the font issue. We delete a bunch of fonts and then create a fonts.dir file that refers to the set of fonts we didn't delete. Are these fonts not present in an OpenJDK build? I can make that part conditional
Re: JDK8 Preliminary Repository Layout
On 18:32 Tue 08 Mar , Kelly O'Hair wrote:
First, if we talk about the mercurial forests, it has nothing to do with the
Mercurial Forest Extension.
What we really have is a set of nested repositories, sometimes called our
forest of repositories.
This email is just about the actual layout of the repositories for jdk8.
The initial thinking at this time is that the openjdk8 open forest will look
very much like openjdk7:
openjdk8/
corba/
jaxp/
jaxws/
jdk/
hotspot/
langtools/
7 repositories total. Cloned from the openjdk7 repos so we will have all the
openjdk7 history in the openjdk8 repositories.
Just for discussion sake, not that you can see what is behind the closed
curtains, we are considering changing
the closed overlay a little, from the current jdk7 (bold is a closed repo):
jdk7/
corba/
deploy/
jaxp/
jaxws/
jdk/
src/closed/
test/closed
make/closed/
hotspot/
src/closed/
test/closed
install/
langtools/
pubs/
To something a little simplier like:
jdk8/
corba/
deploy/
jaxp/
jaxws/
jdk/
closed/{src,test,make}
hotspot/
closed/{src,test,make}
install/
langtools/
pubs/
The existence of these closed repos should not be a surprise, and it should
have no impact on the openjdk itself.
We are just trying to consolidate and have fewer repositories. Just thought
it might be of interest.
Not surprised. Also don't really care where you put them as I don't seem to
have them either way ;-)
What I would ask is do the projects get this as well? Specifially, I'd like an
icedtea/jdk8 at the same time please.
But back to the openjdk8 forest.
Other ideas were considered:
* Folding jaxp/jaxws into the root or jdk8/jdk repo
Sounds good. jdk8/jdk would make more sense as jaxws depends on some classes
that are in the jdk
tree (com.sun.net.httpserver) and we could then get rid of the Ant junk. It
would be good to have
the code there too so we can once again track changes. The recent security
issue was a nightmare
due to the unavailability of the source code.
* Separating out the jdk demos from the jdk repo to a separate demos
repository
Makes sense. Having an option to disable them would be a good first step.
* Separating out the client (awt/swing/etc) code from the jdk repo into a
separate repo
Why would we want to do this? IME, there are lots of interdependencies with
the other code and
this would make the build a nightmare.
* Updating the corba sources changing it to an ant build
Please, no! These Ant builds are already a nightmare and an order of magniture
harder to debug than
the Makefiles. Why you want to require a build system that requires an entire
JDK setup (possibly
bringing another into the mix beyond the bootstrap JDK) is beyond me.
What would make much more sense is to just add corba into the jdk tree. It
actually requires sun.tools
classes to compile rmic anyway so it would make much more sense there.
Hey, I'd just make it all one repository as they all interdepend on each other,
but the HotSpot folks
probably wouldn't like that... ;-) Moving the HotSpot servicability agent
into the JDK, where the
interfaces it uses lives, might be a good idea though. I'm currently working
on a patch which fixes
up a mismatch between the HotSpot SA implementation and the interfaces in the
JDK which has existed
for who knows how long (it's certainly in OpenJDK6)...
None of this seemed urgent to do out of the gate, or delay getting a
preliminary jdk8 layout defined.
No, I agree with that. Splitting off OpenJDK8 already seems overdue.
I know there is some interest in pulling the actual jaxp/jaxws sources back
into their repos, that will
be discussed separately, we have multiple issues with that, but I am well
aware of the pains that the
source drop zip files have created.
The problem is less technical and more social; there is no obvious way to
interact with the JAXP and JAXWS
side of things. We just get these zips of code with no idea of what changes
are in there or why.
Basically, they shouldn't work either like they do now or did before, but like
everything else in OpenJDK
with visible commits. Hey, maybe we could even have some mailing list
discussion if we're very lucky...
As always, we would like to get comments, or additional ideas.
Separate topics:
* Forest Extension and it's replacement
Do we really need one? Current status quo (get_source.sh) works fine.
* Mercurial server update to 1.8 or newer
I guess this is related to the forest issue.
* BuildTest system [1]
* Open bug tracking system [2]
You missed off open sourcing that jcheck thing... that's the biggest problem I
have with
the Mercurial server. :-)
-kto
[1]
Re: Preliminary request for review: 7025066 Build system changes to support SE Embedded integration
On 10:51 Tue 08 Mar , David Holmes wrote: Andrew, Many thanks for the feedback: Dr Andrew John Hughes said the following on 03/08/11 04:30: On 09:39 Mon 07 Mar , Kelly O'Hair wrote: General comments: * Could this not be broken up into smaller changesets to make it easier to review and catch regressions? In theory probably, in practice, not really. Please see below. * There seem to be some whitespace changes that shouldn't be there. e.g. - sane-msvcrt_path \ + sane-msvcrt_path \ This will all be double-checked before the push. Just to clarify for people, BUILD_CLIENT_ONLY refers to building the client VM only. Some of these variables should be documented in the top level README-builds.html file, but that can be done under a separate CR if necessary. What happens if there is no client VM e.g. x86_64? If you are not building a client-only configuration then you should not set BUILD_CLIENT_ONLY. It's main purpose is to not attempt to copy lib/arch/server/*.so files into the JRE/JDK image when they don't exist. But what if someone does? Will the sanity check not catch this? I think if this patch introduces it, the documentation should be part of this patch. Definitely. The Library.gmk file seems like it is just a leftover debugging echo? This was Kelly's comment, but yes it is a _very_ useful debugging echo that I suggest leaving in. The Release.gmk file needs a major overhaul. :^( I'm wondering if the various things being added here could have their own separate functionality flags, rather than JAVASE_EMBEDDED, have COMPRESS_JARS=true/false, REDUCED_JRE=true/false, then have one place where JAVASE_EMBEDDED turns on what it wants? Strongly agree with this. It would make more sense to have these sort of changes introduced by separate changesets and then have this change set them for the JAVASE_EMBEDDED build. In particular, COMPRESS_JARS was something I had planned on fixing. To Kelly's list, I'd add BUILD_ALSA and LIBZIP_CAN_USE_MMAP (mentioned below). This would make this work far more generally useful than it is at present. I can certainly refactor into general flags, however applying those flags to all parts of the JDK build process that might want to use them is out-of-scope for what I am trying to achieve here (I just won't have time to do this and go through a myriad of builds and test runs). I'd also prefer not to create multiple changesets, which implies multiple CRs. I can't easily test these things in isolation, and individual changesets would require complete build/test cycles that I again do not have time to perform. I can see the issue with it taking more time, but committing the patch in its current form is unfair on others who now have a more convoluted build system to deal with (and it's already bad to start with) and no gain from the patch. Does your employer not allocate sufficient time to do the best work you can on such changes? Has this been tested on an OpenJDK build at all? It also seems to create a fonts.dir file with fonts that aren't part of OpenJDK. No, not OpenJDK. I have done a regular JDK build, but not OpenJDK. And I have not attempted to test things like BUILD_CLIENT_ONLY outside of a JAVASE_EMBEDDED build. With regard to the fonts, my understanding is that we simply define a subset of the fonts used in the regular JDK. I have no idea how such fonts get shipped nor whether they are part of the OpenJDK or only Oracle's JDK. An OpenJDK build definitely needs to be performed before this is committed, as I think it may break the build or, at the very least, create references to non-existent fonts. Thanks again, David -kto On Mar 7, 2011, at 2:14 AM, David Holmes wrote: http://cr.openjdk.java.net/~dholmes/7025066/webrev/ The SE-Embedded product is a combination of open and closed sources. To allow SE-Embedded to be built from standard OpenJDK sources we need to apply a number of changes to the SE 7 build system: - support for building the hotspot client compiler only (hotspot already supports this, this is the JDK side of things) - support for doing cross-compilation (Linux only) - minimal support for ARM/PPC architectures in the open code that currently only knows about x86 and sparc - SE-Embedded specific build settings and targets (specifically the headful and headless reduced JRE images) --- These changes are obviously primarily for Oracle's benefit, but some aspects may be use of externally as well. The hope is that these changes won't have an adverse affect on any downstream OpenJDK builders, but until I get feedback on that I won't know. Thanks, David Holmes SE Embedded Team -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath
Re: Preliminary request for review: 7025066 Build system changes to support SE Embedded integration
On 09:39 Mon 07 Mar , Kelly O'Hair wrote: General comments: * Could this not be broken up into smaller changesets to make it easier to review and catch regressions? * There seem to be some whitespace changes that shouldn't be there. e.g. - sane-msvcrt_path \ + sane-msvcrt_path \ Just to clarify for people, BUILD_CLIENT_ONLY refers to building the client VM only. Some of these variables should be documented in the top level README-builds.html file, but that can be done under a separate CR if necessary. What happens if there is no client VM e.g. x86_64? I think if this patch introduces it, the documentation should be part of this patch. The Library.gmk file seems like it is just a leftover debugging echo? Looks like the Program.gmk file should be sharing the LD_RUNPATH_EXTRAS logic somehow, I originally was trying to isolate all the $ORIGIN option setting to one place, oh well, not your issue. You have actually cleanup some of these linker settings, so thanks for that. The Release.gmk file needs a major overhaul. :^( I'm wondering if the various things being added here could have their own separate functionality flags, rather than JAVASE_EMBEDDED, have COMPRESS_JARS=true/false, REDUCED_JRE=true/false, then have one place where JAVASE_EMBEDDED turns on what it wants? Strongly agree with this. It would make more sense to have these sort of changes introduced by separate changesets and then have this change set them for the JAVASE_EMBEDDED build. In particular, COMPRESS_JARS was something I had planned on fixing. To Kelly's list, I'd add BUILD_ALSA and LIBZIP_CAN_USE_MMAP (mentioned below). This would make this work far more generally useful than it is at present. Like the BUILD_CLIENT_ONLY setting. Just thoughts. But I'm ok with what you have, just cringing a little whenever the file Release.gmk gets more added to it. :^( In Defs-control.gmk you have a line with just error ...some message not exactly sure what you are expecting here. You also use USE_ONLY_BOOTDIR_TOOLS?=true and I have avoided ?=. The reason is that it assigns the variable if it hasn't been defined, not if it was defined to be empty or expands to empty. Between ?= and ifdef/ifndef, it gets pretty confusing what defined means, and I've been favoring using just ifeq ($(USE_ONLY_BOOTDIR_TOOLS),) as the best way to ask if a variable will expand to nothing, which is usually the real question in most situations. I have only used ifeq($(origin X),defined) when a variable being explicitly defined to an empty value needed to be allowed, and this ?= effectively uses ifeq($(origin X),defined). A little nit picking, sorry. In make/common/shared/Defs.gmk, you define HOST_CC and have another error line. I'd rather not have the check in this file, but we should just define HOST_CC if not defined, and have HOST_CC checked in Sanity.gmk in a special embedded sanity check where you verify all embedded requirements you might have. We should probably also add some of these embedded variables added to Sanity-Settings.gmk so we can see the settings when 'make sanity' is run. Sanity.gmk changes completely turns off the compiler version check, if you really want to do this, perhaps the better approach is to put this sanity check in a ifdef REQUIRED_CC_VER and then have you not define that variable in Defs-versions.gmk? If you are saying you want NO required version, then not defining the REQUIRED_* variables seems like a good idea. In java/zip/Makefile maybe we need a LIBZIP_CAN_USE_MMAP functionality option here? Then embedded wouldn't even need to be mentioned here. In Version.java.template You have added a Java (TM) line, I think that needs to go. You should add that in via the makefile somehow but I don't think it belongs in an OpenJDK build. Has this been tested on an OpenJDK build at all? It also seems to create a fonts.dir file with fonts that aren't part of OpenJDK. -kto On Mar 7, 2011, at 2:14 AM, David Holmes wrote: http://cr.openjdk.java.net/~dholmes/7025066/webrev/ The SE-Embedded product is a combination of open and closed sources. To allow SE-Embedded to be built from standard OpenJDK sources we need to apply a number of changes to the SE 7 build system: - support for building the hotspot client compiler only (hotspot already supports this, this is the JDK side of things) - support for doing cross-compilation (Linux only) - minimal support for ARM/PPC architectures in the open code that currently only knows about x86 and sparc - SE-Embedded specific build settings and targets (specifically the headful and headless reduced JRE images) --- These changes are obviously primarily for Oracle's benefit, but some aspects may be use of externally as well. The hope is that these changes won't have an adverse affect on any downstream OpenJDK builders, but until I
Re: Installation of man page for proprietary javaws
On 17:28 Wed 23 Feb , Dr Andrew John Hughes wrote: On 08:26 Tue 22 Feb , Kelly O'Hair wrote: On Feb 22, 2011, at 5:42 AM, Dr Andrew John Hughes wrote: On 12:54 Tue 22 Feb , Alan Bateman wrote: Dr Andrew John Hughes wrote: It seems that the OpenJDK build installs a man page for javaws, yet there is no javaws implementation in OpenJDK. http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=633 This only happens on 32-bit platforms, hence why I've never seen it myself. I've posted a webrev: http://cr.openjdk.java.net/~andrew/javaws/webrev.01/ which disables the installation when building OpenJDK. If you don't need this man page for the proprietary installation either, we could instead just get rid of the man pages and the appropriate lines in the Makefile. Thoughts? Probably a small oversight that just wasn't noticed before. It's taken me this long to notice it. If you build on a 64-bit platform, you're not going to see it. It seems distros have been silently deleting it for a while without bothering to tell upstream :-( I've created a bug to track it: 7021314: Build should not install javaws man page Great. Thanks. I'll await Kelly's review. Looks ok to me. -kto The changes in the webrev look right solution to me but I'll leave it to Kelly to review. -Alan. -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 Thanks Alan Kelly. Pushed: http://hg.openjdk.java.net/jdk7/build/jdk/rev/5e09deee1967 -- Clearly this woke someone up on the deployment team: http://hg.openjdk.java.net/jdk7/deploy/jdk/rev/7931291bc5d3 ;-) -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37
Re: Installation of man page for proprietary javaws
On 08:26 Tue 22 Feb , Kelly O'Hair wrote: On Feb 22, 2011, at 5:42 AM, Dr Andrew John Hughes wrote: On 12:54 Tue 22 Feb , Alan Bateman wrote: Dr Andrew John Hughes wrote: It seems that the OpenJDK build installs a man page for javaws, yet there is no javaws implementation in OpenJDK. http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=633 This only happens on 32-bit platforms, hence why I've never seen it myself. I've posted a webrev: http://cr.openjdk.java.net/~andrew/javaws/webrev.01/ which disables the installation when building OpenJDK. If you don't need this man page for the proprietary installation either, we could instead just get rid of the man pages and the appropriate lines in the Makefile. Thoughts? Probably a small oversight that just wasn't noticed before. It's taken me this long to notice it. If you build on a 64-bit platform, you're not going to see it. It seems distros have been silently deleting it for a while without bothering to tell upstream :-( I've created a bug to track it: 7021314: Build should not install javaws man page Great. Thanks. I'll await Kelly's review. Looks ok to me. -kto The changes in the webrev look right solution to me but I'll leave it to Kelly to review. -Alan. -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 Thanks Alan Kelly. Pushed: http://hg.openjdk.java.net/jdk7/build/jdk/rev/5e09deee1967 -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37
Re: Commit responsibilities and Lines of Defense
On 00:00 Tue 22 Feb , Bradford Wetmore wrote: Kelly just wrote: It's not clear...and slightly augmented by the openjdk bugzilla. I think Andrew was referring to http://bugs.openjdk.java.net. I was. I'm not sure what else the phrase OpenJDK bug database would refer to. There were several bug systems mentioned in Kelly's post, and are used in varying ways for JDK: Sun's internal bug database Bug parade (bugs.sun.com) which seeds from that system Oracle's internal bug database Bugzilla I just wanted to make sure we were talking about the same system. Ok, always best to clarify things. I don't tend to think of the first three as related to OpenJDK; in fact, until this e-mail, I thought they were all one and the same thing... (well, the first two anyway). That's where we are now. bugs.o.j.n is still the place to submit/track patches, and I expect data from that bugzilla instance will be migrated to the new system. I never got the impression that the Bugzilla instance was only intended for stage 1 and http://openjdk.java.net/groups/web/bugzilla.html doesn't read like that either: 'Goal To produce a Bugzilla instance in which OpenJDK contributions, bugs and RFEs can be submitted, tracked, and modified by people both internal and external to Sun.' Is that goal no longer valid? What you stated was the full goal, but as enumerated in the Phases section, the deployment steps were first to track patches, then expand to the general bug tracking solution for OpenJDK, then connect to Sun's internal database. It didn't get further than stage 1 before those major factors came into play, and things got put on hold until our new Oracle environment was understood. This bugzilla instance was set up to track patch contributions until a more permanent bug tracking solution could be developed/deployed. I composed that sentence poorly. The more permanent solution was to extend/expand the bugzilla instance to do OpenJDK bug tracking. It was not only intended for stage 1. I was not clear about that, and my apologies. Ok, sounds like we are on the same page after all :-) (and we did a poor job of watching over the bugzilla system, sorry). The expectation was that patch submissions should be made visible by the submitter and discussed on the project team's mailing list. I don't remember this ever being made clear. We tried to describe it in the contributions page: http://openjdk.java.net/contribute/ 2. Discuss your intended change ... 3. Submit a patch When your change is ready, create a new bug report in the OpenJDK Bugzilla system. ... Use attachments to your bug report to convey the following: All the Bugzilla page says is: 'The primary goal of this phase is to further open our development processes, and prevent submissions from getting lost in the mailing list archives' We probably could have reiterated the above here on this page also. Yes. I'm trying to see this as someone just approaching the project (perhaps just to patch one issue), rather than an established member of the community. From that perspective, it seems odd that putting my patch in Bugzilla would not be enough. I don't see how having discussion in two different places helps. I guess that's why the database wasn't a success. bugs.o.j.n was not supposed to track bugs, although some people submitted bugs without patches, and which obviously didn't gain much visibility. I should have said not supposed to track bugs *yet*. I can see how that was interpreted. Yeah. Each page of the bugzilla instance does contain the following header: During the initial rollout phase, this site will only be accepting and tracking patch contributions to the OpenJDK 6 and 7 forests. Until the remainder of the site is ready, please continue to file normal bug reports via http://bugs.sun.com/bugdatabase/index.jsp. Regular bug reports filed here during the rollout period will be summarily closed. In phase 1, yes. I don't think it was ever intended that this would be its only remit. Again, the Bugzilla group page says: 'During later phases of this project, we will be linking the Bugzilla instance with Bugtraq' I think we can all agree that the Bugzilla setup suffered from the Oracle merger happening and didn't evolve as was originally planned. I am in complete agreement. Now that the efforts for bug tracking have been restarted, I'm encouraging that the effort be staffed with folks who can focus solely on this project. Let's not try and revise history by pretending it was only ever intended to be a patch repository. A misunderstanding, my apologies for not making that clearer. No problem. It did seem odd coming from someone who was involved in
Installation of man page for proprietary javaws
It seems that the OpenJDK build installs a man page for javaws, yet there is no javaws implementation in OpenJDK. http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=633 This only happens on 32-bit platforms, hence why I've never seen it myself. I've posted a webrev: http://cr.openjdk.java.net/~andrew/javaws/webrev.01/ which disables the installation when building OpenJDK. If you don't need this man page for the proprietary installation either, we could instead just get rid of the man pages and the appropriate lines in the Makefile. Thoughts? -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37
Re: Installation of man page for proprietary javaws
On 12:54 Tue 22 Feb , Alan Bateman wrote: Dr Andrew John Hughes wrote: It seems that the OpenJDK build installs a man page for javaws, yet there is no javaws implementation in OpenJDK. http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=633 This only happens on 32-bit platforms, hence why I've never seen it myself. I've posted a webrev: http://cr.openjdk.java.net/~andrew/javaws/webrev.01/ which disables the installation when building OpenJDK. If you don't need this man page for the proprietary installation either, we could instead just get rid of the man pages and the appropriate lines in the Makefile. Thoughts? Probably a small oversight that just wasn't noticed before. It's taken me this long to notice it. If you build on a 64-bit platform, you're not going to see it. It seems distros have been silently deleting it for a while without bothering to tell upstream :-( I've created a bug to track it: 7021314: Build should not install javaws man page Great. Thanks. I'll await Kelly's review. The changes in the webrev look right solution to me but I'll leave it to Kelly to review. -Alan. -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37
Re: Commit responsibilities and Lines of Defense
On 18:29 Fri 18 Feb , Kelly O'Hair wrote: On Feb 18, 2011, at 4:29 PM, Dr Andrew John Hughes wrote: On 14:09 Fri 18 Feb , Kelly O'Hair wrote: snip But there have been some roadblocks for the open source community. It has been observed (for a long time now) that: * The Mercurial jcheck extension needs to be open sourced Funnily enough, I just mentioned that in my reply to your mail about the jdk6 changesets... :-) Hopefully we will hear some good news on this soon. That'd be good. * The bug tracking system needs to be completely open Definitely. Making OpenJDK bug DB IDs usable in changesets would be a good start (probably involves jcheck...) I'll have to punt on that, someone else is working on it, but the intent is to have a completely open bug tracking system that also allows us link it with the internal Oracle bug tracking system. Once we have that defined, jcheck can be adjusted to use those numbers or IDs. I don't think all the details are worked out. I'll see if I can ping someone to make some of the planning more public. So this is going to be yet another system? What will happen to the existing pretty much unused OpenJDK bug database? * We need an open build and test system for the OpenJDK developers who don't have access to all the systems This is especially important for Windows as I have no idea if anything I do breaks it and no way of doing builds on it. I expect the same to be true when Mac OS appears as a target. Yup. The number of platforms is going up, which makes it even more important. snip How much can be opened? Currently the parts that can't be opened that I can think of off the top of my head: * Closed builds or builds that include both the open changes and the private Oracle repositories for JDK7 * Certain VM tests that are publicly available, like SPEC benchmarks * Certain VM tests that are Oracle private, but have been historically run to verify VM stability * Some closed jdk regression tests, security and otherwise The first two mainly sound like things that matter to Oracle. Breaking Oracle's proprietary product is not ideal, but something only really Oracle can deal with and not the rest of the community. I presume the SPEC benchmarks would catch performance degradations; this would be useful, but not too helpful if you can't make the results public. I don't see how either could ever be made public so I think it's best to keep them separate from the open system. The latter two also need to be kept separate to begin with, but I hope Oracle will be able to make these open at some point in the future. The general feeling is that we would not allow people to login to these systems, but we could provide complete specifications on what systems we are using. Providing systems for OpenJDK people to access is not something we are thinking about. Internally, it's rare that the exact same systems used like this are needed by the developer. My preference is that other than the above items, any developer should be able to build and test themselves on their platform, via the Makefiles in the repositories, e.g. make all test. And for the most part, the BAT system would just repeat the same procedures the developer can do on many other systems and in a distributed fashion for fast turnaround. Will any OpenJDK developer be able to submit a job to this system? If not, then it again creates a reliance on Oracle developers as we already have with the Oracle bug DB and the JPRT system. From my stand point, I'd much rather we had the system completely open with those tests that can be made so, with appropriate direction in how to improve things and fill in the holes. A bit like OpenJDK and the 'plugs'. Improving that is achievable, and expanding the range of open tests would be some good low-hanging fruit for the OpenJDK project. It would also establish a good set of JDK tests that can be used elsewhere. This is what we tried to do with Mauve (http://sourceware.org/mauve/). I would like to include mauve tests as part of the testing, if we can fit it in. That's be great. I agree open tests are preferred. As I say, I don't see much point in anything else. What use are tests we can't discuss? How can we even trust their results? Working with proprietary tests doesn't really help. It doesn't tell me anything if a test passes if I don't know what that test is; I don't know what exactly is being tested and whether I should trust the test at all. I already have some experience of working with such tests via the TCK and it's been much more of a hinderance than a help, especially when we can't openly discuss tests and their results. If I can't get a commit into OpenJDK because some test I can't look at is failing, it's just going to make me
Re: Commit responsibilities and Lines of Defense
On 18:08 Mon 21 Feb , Kelly O'Hair wrote: On Feb 21, 2011, at 1:33 PM, Dr Andrew John Hughes wrote: snip So this is going to be yet another system? What will happen to the existing pretty much unused OpenJDK bug database? It's not clear. The old Sun bugtraq system was closed but we had some ability to expose information. The Oracle bug system is very closed, so the requirements have changed with regards to how the open and closed interact together. Before we mostly worked with Sun bugtraq, some public exposure, and slightly augmented by the openjdk bugzilla. (and we did a poor job of watching over the bugzilla system, sorry). In the future it may be more that everyone is using the open system (whatever that is), and only augmented by the closed system when needed. Bottom line is that this is a good thing for the open side, but I have no idea what that open system will be at this time. It's a plan for a plan, and in progress. I think when this gets rolled out, other than perhaps people not liking the particular implementation that might get picked, the open world will be better off because it will be THE default bug tracking system. So I take it the previous democratic choice of Bugzilla may be ignored? Of course I have to clarify, The views expressed in this email are my own and do not necessarily reflect the views of Oracle. snip... I think if any of these tests become issues, we can address it then. Like I said, it may be this event that triggers the discussion on what we should be doing in terms of opening up a test, or not requiring a test be run. I'd rather the proprietary tests weren't part of the open system to begin with. Waiting until they cause a problem and then waiting for that problem to be resolved is an issue we can foresee now and could easily sidestep by not including proprietary tests. snip... The primary tests we would run to start with the jdk repository would be the regression tests in the repository, at least that's what I was thinking. Adding in mauve might be next? The VM tests used are the trickier ones. That sounds good. Merely doing builds, never mind tests, on platforms such as Windows, Solaris and Mac OS X will be an advantage. To be completely upfront, there is a catch, it's not clear to me whether the actual built bits can be returned yet, in amm os-arch cases. That's a legal issue I need to resolve. I don't have a problem with it, but I need to make sure it's ok. So initially, all you might get back are the build logs and a success/failure indication, I'll work on the getting the built bits back, but no promises. From my perspective, I'm happy if it builds and we don't get regressions. The resulting binaries for a system I don't have anyway aren't much use :-) I imagine there will be some desire for them from other corners though. Will OpenJDK6 also be covered by this scheme? At the moment, results for it are of greater value for most people than those for the unreleased OpenJDK7. I'll allow for OpenJDK6, but we may need to play with what the configurations are for building and testing, e.g. the os-arch-compiler combinations to build and test. Yes, I guess that's to be expected. Of course I have to clarify, again ;^) The views expressed in this email are my own and do not necessarily reflect the views of Oracle. -kto Thanks for working on this, -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37
Re: Commit responsibilities and Lines of Defense
On 18:26 Mon 21 Feb , Brad Wetmore wrote: Definitely. Making OpenJDK bug DB IDs usable in changesets would be a good start (probably involves jcheck...) I'll have to punt on that, someone else is working on it, but the intent is to have a completely open bug tracking system that also allows us link it with the internal Oracle bug tracking system. Once we have that defined, jcheck can be adjusted to use those numbers or IDs. I don't think all the details are worked out. I'll see if I can ping someone to make some of the planning more public. So this is going to be yet another system? What will happen to the existing pretty much unused OpenJDK bug database? Kelly just wrote: It's not clear...and slightly augmented by the openjdk bugzilla. I think Andrew was referring to http://bugs.openjdk.java.net. I was. I'm not sure what else the phrase OpenJDK bug database would refer to. This bugzilla instance was set up to track patch contributions until a more permanent bug tracking solution could be developed/deployed. That's where we are now. bugs.o.j.n is still the place to submit/track patches, and I expect data from that bugzilla instance will be migrated to the new system. I never got the impression that the Bugzilla instance was only intended for stage 1 and http://openjdk.java.net/groups/web/bugzilla.html doesn't read like that either: 'Goal To produce a Bugzilla instance in which OpenJDK contributions, bugs and RFEs can be submitted, tracked, and modified by people both internal and external to Sun.' Is that goal no longer valid? (and we did a poor job of watching over the bugzilla system, sorry). The expectation was that patch submissions should be made visible by the submitter and discussed on the project team's mailing list. I don't remember this ever being made clear. All the Bugzilla page says is: 'The primary goal of this phase is to further open our development processes, and prevent submissions from getting lost in the mailing list archives' I don't see how having discussion in two different places helps. I guess that's why the database wasn't a success. bugs.o.j.n was not supposed to track bugs, although some people submitted bugs without patches, and which obviously didn't gain much visibility. In phase 1, yes. I don't think it was ever intended that this would be its only remit. Again, the Bugzilla group page says: 'During later phases of this project, we will be linking the Bugzilla instance with Bugtraq' To quote Kelly:*The views expressed in this email are my own and do not necessarily reflect the views of Oracle.* Brad I think we can all agree that the Bugzilla setup suffered from the Oracle merger happening and didn't evolve as was originally planned. Let's not try and revise history by pretending it was only ever intended to be a patch repository. We can use it as a lesson. If the new bug database proves unhelpful, it will see the same level of usage as this one. Making decisions without open consultation with the OpenJDK community would not be a good start. I look forward to things being brought out into the open instead. Thanks, -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37
Re: Commit responsibilities and Lines of Defense
On 14:09 Fri 18 Feb , Kelly O'Hair wrote: Excuse the long email, sometimes it can't be avoided. I much prefer long e-mails, especially ones with good news like this, to things happening behind closed doors :-) I've been asked to try and start up some discussions around how the OpenJDK development community can function better with regards to developer processes and what many of us call Lines of Defense or how we protect our repositories from changes that cause regressions. (Not sure who coined the phrase Lines of Defense, I will assume it is open source. ;^) This information is intended for anyone actually planning on making OpenJDK changes and getting them integrated, so serious code committers only please, if that isn't you, this email is probably not for you. Keep in mind that this is just an email, not concrete, so if you have any questions or suggestions, let's discuss it. Mercurial is primary to working on the OpenJDK and understanding how this all works: * Mercurial - Learn the basics from http://hgbook.red-bean.com/read/ * Understand how OpenJDK uses Mercurial from http://openjdk.java.net/guide/repositories.html If you are unfamiliar with Mercurial, making sense of this may be difficult. Certainly there are other aspects to whether making a change is appropriate or approved in various forums, that's assumed here. Once the decision has been made to make a change, now what? So what do I consider the Lines of Defense? * Fix: The developer, the author of the change, working in cooperation with other team members * Check: The developer doing a build and test, verifying the change fixes what it should and creates no regressions * Review: The reviewer, the second set of eyes that can always help catch mistakes * Commit: The actual changeset verifications as to authors, bug tracking linking, review verification (e.g. jcheck) * Coverage: Use of a developer build and test system that can automate and verify the changes over a larger list of platforms and tests * Push: Controlled access to the team repositories and emails on changes so that the teams know what was pushed in * Monitoring: Continuous or nightly build and test of the team repositories, prior to the team integration process * Integration: The integrator, who does double and triple checks on all of the above * Master Checks: Continuous or nightly build and test of the master repositories, prior to build promotions * Promotion: Release Engineering and the promotion process, the community at large letting us know when we messed up * Testing: Major testing of a promoted build by our QE department At each line of defense, we have an opportunity to catch mistakes or re-consider what we are doing. Once a developer does the Push of a changeset, the pipeline has been primed and the change will eventually get integrated into the master repositories, unless something goes wrong, i.e. we catch a mistake. If something does go wrong, it depends on when and where the mistake was found but the goal is to always protect the Master repositories from bad or poison changesets. So since I'm talking to the just the developers now (I assume the pointy haired managers have become bored at this point and stopped reading :^) how do we make it easy for all OpenJDK developers to get from Fix to Push. We can make the Check easier and that's a separate project, mostly isolated to the repositories themselves, and understanding what testing is required of developers. We can always improve the Review over and above the current http://cr.openjdk.java.net/ webrev storage. But there have been some roadblocks for the open source community. It has been observed (for a long time now) that: * The Mercurial jcheck extension needs to be open sourced Funnily enough, I just mentioned that in my reply to your mail about the jdk6 changesets... :-) * The bug tracking system needs to be completely open Definitely. Making OpenJDK bug DB IDs usable in changesets would be a good start (probably involves jcheck...) * We need an open build and test system for the OpenJDK developers who don't have access to all the systems This is especially important for Windows as I have no idea if anything I do breaks it and no way of doing builds on it. I expect the same to be true when Mac OS appears as a target. We are working on it. And of course you have heard that before, but we are, really. It's that last item that involves myself and a group of Oracle engineers in Stockholm, hopefully we can come up with a solution that works for everybody. I have tentatively named it BAT for Build And Test, but it is just in the infancy stage, nothing official yet. But we would like some input. The intent would be to accept repository paths, tips, and changeset bundles
Re: Reviewer needed: building langtools on a Mac
On 16:38 Thu 10 Feb , Gary Meyer wrote: On Feb 9, 2011, at 6:48 PM, Jonathan Gibbons wrote: Build folk, The following fix should make it possible to (again) build langtools on a Mac. Dan Smith reports: - When building the GenStubs in OS X, the Java 6 tools classes are in classes.jar, and this shadows $build.bootstrap.dir, which appears in the classpath. This can be fixed with -Xbootclasspath/p. Webrev here: http://cr.openjdk.java.net/~jjg/7018452/webrev/ -- Jon I don't know if you will accept me as a code reviewer, but I'm the Java Build Engineer at Apple. These code diffs look good to me. Gary. ~~~ Gary Meyer Java Software Build Engineer gary.me...@apple.com Hi Gary, Personally, I think it's great that someone who knows the platform has checked over this patch. More formally, for the commit, I think it depends on if Oracle gave you an OpenJDK username yet :-) AFAIK, the 'Reviewed-by' field in commits has to contain OpenJDK usernames. See the (incomplete) developer's guide at http://openjdk.java.net/guide/producingChangeset.html This may or may not be checked by the jcheck extension Oracle run on commits. Given it's proprietary, we really don't know what it does. Jon, FWIW, I also think the patch looks fine. Hope that helps, -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37
Re: Reviewer needed: building langtools on a Mac
On 07:57 Fri 11 Feb , Jonathan Gibbons wrote: On 02/11/2011 07:09 AM, Dr Andrew John Hughes wrote: On 16:38 Thu 10 Feb , Gary Meyer wrote: On Feb 9, 2011, at 6:48 PM, Jonathan Gibbons wrote: Build folk, The following fix should make it possible to (again) build langtools on a Mac. Dan Smith reports: - When building the GenStubs in OS X, the Java 6 tools classes are in classes.jar, and this shadows $build.bootstrap.dir, which appears in the classpath. This can be fixed with -Xbootclasspath/p. Webrev here: http://cr.openjdk.java.net/~jjg/7018452/webrev/ -- Jon I don't know if you will accept me as a code reviewer, but I'm the Java Build Engineer at Apple. These code diffs look good to me. Gary. ~~~ Gary Meyer Java Software Build Engineer gary.me...@apple.com Hi Gary, Personally, I think it's great that someone who knows the platform has checked over this patch. More formally, for the commit, I think it depends on if Oracle gave you an OpenJDK username yet :-) AFAIK, the 'Reviewed-by' field in commits has to contain OpenJDK usernames. See the (incomplete) developer's guide at http://openjdk.java.net/guide/producingChangeset.html This may or may not be checked by the jcheck extension Oracle run on commits. Given it's proprietary, we really don't know what it does. Jon, FWIW, I also think the patch looks fine. Hope that helps, Andrew, Gary, Note that Kelly asked recently that all build changes should be reviewed by members of the build team. So while is it always acceptable to have additional reviewers, we do need Kelly or someone else in the build group to verify the change too. http://mail.openjdk.java.net/pipermail/build-dev/2011-February/004034.html In this case, Kelly has already approved the change and the changeset has been pushed. http://mail.openjdk.java.net/pipermail/compiler-dev/2011-February/002851.html -- Jon Yes, I saw that post, but hadn't appreciated the ramifications yet. Is there anyone else on the build team but Kelly? While the idea is good in theory, I foresee a potential bottleneck here. -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37
Re: Need reviewer: ant 1.7.1 or newer needed
On 19:45 Tue 08 Feb , Rinaldo DiGiorgio wrote: On Feb 8, 2011, at 7:34 PM, Kelly O'Hair wrote: I take that back. Welcome rinaldo to the OpenJDK commit list! I will put you down as a reviewer. I didn't think you had the OpenJDK ID yet. Thanks -- never expected to be here from initial position I came in on. Just received it this morning. I hope I never put back to the wrong repository. :) Mark R has a new process and alias for getting access, once you send to it you get an invitation to join. Response was very fast and you get a nice form to fill out. Is this new process documented somewhere? Rinaldo -kto On Feb 8, 2011, at 4:17 PM, Kelly O'Hair wrote: I did not know that an ant 1.7.3 even existed. Thanks for the review. But I still need a second reviewer. -kto On Feb 8, 2011, at 4:02 PM, Rinaldo DiGiorgio wrote: Looks good to me. It also worked with 1.7.3 On Feb 8, 2011, at 7:00 PM, Kelly O'Hair wrote: Need reviewer: ant 1.7.1 or newer needed This changes the minimum required ant version to 1.7.1 and also makes it a fatal sanity error to try and use anything older. The ant 1.7.1 release was done in July 2008 and is a well known stable ant release. 7016976: Documentation for required ant version on JDK7 builds on Solaris 10 and Solaris 11 http://cr.openjdk.java.net/~ohair/openjdk7/jdk7-build-ant171/webrev/ -kto P.S. Ant binary bundles can be found at http://archive.apache.org/dist/ant/binaries/ -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37
Re: Need reviewer: ant 1.7.1 or newer needed
On 12:34 Wed 09 Feb , Rinaldo DiGiorgio wrote:
has a new process
and alias for getting access, once you send to it you get an invitation to
join.
Response was very fast and you get a nice form to fill out.
Is this new process documented somewhere?
I may have confused things. I was looking for the process to be enabled
for submitting changes with a JDK username. I missed the following
paragraph at
http://openjdk.java.net/guide/producingChangeset.html#jdkUserName
I mailed my JDK username to keys(at)openjdk.java.net and there was a reply
with an
invitation.
Screen shot attached below may not appear to mailing list recipients. You
can also find it by going to
paragraph with Generating an SSH Key as the header.
I know how to commit once I have a username. I thought you meant there was now
a process
for getting such a username. The only one I've known in the past is 'ask mr'
;-)
Rinaldo
Rinaldo
-kto
On Feb 8, 2011, at 4:17 PM, Kelly O'Hair wrote:
I did not know that an ant 1.7.3 even existed.
Thanks for the review. But I still need a second reviewer.
-kto
On Feb 8, 2011, at 4:02 PM, Rinaldo DiGiorgio wrote:
Looks good to me. It also worked with 1.7.3
On Feb 8, 2011, at 7:00 PM, Kelly O'Hair wrote:
Need reviewer: ant 1.7.1 or newer needed
This changes the minimum required ant version to 1.7.1 and also makes
it a fatal sanity error
to try and use anything older.
The ant 1.7.1 release was done in July 2008 and is a well known stable
ant release.
7016976: Documentation for required ant version on JDK7 builds on
Solaris 10 and Solaris 11
http://cr.openjdk.java.net/~ohair/openjdk7/jdk7-build-ant171/webrev/
-kto
P.S. Ant binary bundles can be found at
http://archive.apache.org/dist/ant/binaries/
--
Andrew :)
Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)
Support Free Java!
Contribute to GNU Classpath and IcedTea
http://www.gnu.org/software/classpath
http://icedtea.classpath.org
PGP Key: F5862A37 (https://keys.indymedia.org/)
Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37
--
Andrew :)
Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)
Support Free Java!
Contribute to GNU Classpath and IcedTea
http://www.gnu.org/software/classpath
http://icedtea.classpath.org
PGP Key: F5862A37 (https://keys.indymedia.org/)
Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37
Re: corrupt messages in build logs
On 16:43 Wed 02 Feb , Kelly O'Hair wrote: On Feb 2, 2011, at 1:56 PM, Jonathan Gibbons wrote: Some messages in the build logs are getting corrupted, perhaps because of parallism. For example, ../../../src/plugin/solaris/jvm_natives/server.c:2031: warning: cast to pointer from integer of different ../../../../src/share/native/sun/security/ec/impl/ec2_163.c:59: warning: ignoring #pragma i ../../../src/plugin/solaris/jvm_natives/native.c:165: warning: type defaults to 'int' in declaration of 'getAw ../../../../src/plugin/solaris/nscore/JavaPluginFactory5.cpp:47: warning: /localtools/linux/gcc29/usr/bin/gcc -O2 -fPIC -DCC_NOEX -W -Wall -Wno-unused -Wno-parentheses -fno-omit-frame-pointer - D_LITTLE_ENDIAN -I../../../../src/plugin/solaris/nscore - I../../../../src/plugin/solaris/nscore/../common -I/HUDSON/workspace/ jdk7-2-build-linux-i586-product/jdk7/build/linux-i586/tmp/ -I/HUDSON/ workspace/jdk7-2-build-linux-i586-product/jdk7/build/linux-i586/tmp/ deploy/headers/plugin -I../../../../src/plugin/solaris/common - I../../../../src/plugin/share/jpiapi -I../../../../src/plugin/ solaris/nscore/../nsstub -I/HUDSON/workspace/jdk7-2-build-linux-i586- product/jdk7/jdk/make/../src/solaris/javavm/export -I/HUDSON/ workspace/jdk7-2-build-linux-i586-product/jdk7/jdk/make/../src/share/ javavm/export -D_GNU_SOURCE -DXP_UNIX -DNO_XEMBED_MOZILLA -DSVR4 - DPLUGIN_NODOTVERSION=\170\ -DPLUGIN_VERSION=\1.7.0\ -DVERSION= \1.7.0-ea-b122\ -DRELEASE=\1.7.0-ea\ -DARCH=\i586\ -Di586 - DLIBARCH=\i386\ -B /localtools/linux/gcc29/usr/bin//../lib/gcc- lib/ -I /localtools/linux/gcc29/usr/bin//../lib/gcc-lib/i386-redhat- linux/egcs-2.9*/include -DRAPTOR_API -DNEW_STREAMING_API -DXP_UNIX - DLINUX -c -o /HUDSON/workspace/jdk7-2-build-linux-i586-product/jdk7/ build/linux-i586/tmp/deploy/plugin/javaplugin_nscp_gcc29/obj/ QueueRunnable.o ../../../../src/plugin/solaris/nscore/ QueueRunnable.cpp Is this known and/or fixable? This is due to the 'make -j 4 *.o' that happens when the sharedly library is built. I though GNU make did a better job on keeping the messages grouped with the compile line, but maybe not. I haven't seen an issue with this from GNU make before, but isn't the above log on Solaris rather than GNU/Linux? It also doesn't look like OpenJDK to me. It may have to echo out the compile line first. Not sure it can be fixed easily. Maybe build with ALT_PARALLEL_COMPILE_JOBS=1 Nice and slow... ;-) -kto -- Jon -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37
Re: Can't find jaxp-1_4_5-dev.zip
On 19:33 Mon 24 Jan , Mark Wielaard wrote: Hi, On Mon, January 24, 2011 18:00, Andrew Haley wrote: On 01/24/2011 04:54 PM, Kelly O'Hair wrote: http://download.java.net/jaxp/1.4.5/dev/jaxp-1_4_5-dev.zip TVM, I made sure to place a copy in the icedtea drops backup dir just in case: http://icedtea.classpath.org/download/drops/ Thanks; I was planning to do that as well but seems you beat me to it :-) -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint = F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
Re: Need reviewer: Remove SKIP_OPENJDK_BUILD
On 16:46 Wed 05 Jan , Kelly O'Hair wrote: Need reviewer: Remove SKIP_OPENJDK_BUILD Now that the binary plugs are gone, this logic doesn't make much sense. 7009969: Remove SKIP_OPENJDK_BUILD from top Makefile http://cr.openjdk.java.net/~ohair/openjdk7/jdk7-build-skip-openjdk/webrev/ -kto Looks like a sensible cleanup to me. Do we know if anyone ever even used this option? What did it do? -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint = F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
Re: A More FHS-Compliant JDK Install
On 11:48 Tue 04 Jan , Andrew Haley wrote: On 01/03/2011 03:09 AM, Lussier, Denis wrote: I too like the idea that the version of OpenJDK that comes pre-built with your Linux distro is pre-installed and just works. But... I wonder how/if the Linux Distro's will configure simultaneously with JDK6 JDK7 when they are both mainstream. Hopefully, the usual Java backwards compatibility will be maintained, so mostly it won't matter. However, the packages may be installed side-by-side, with a symlink for the global default. Like this example from Fedora 13: /usr/bin/java -- /etc/alternatives/java -- /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/bin/java I can't yet comment on whether distros will choose to allow multiple JDKs, though: just that there is no strong technical reason that forbids it. Andrew. IME, most distributions already have at least two JDKs: gcj and IcedTea6/OpenJDK6. Adding IcedTea7/OpenJDK7 to the pile wouldn't be any different, just more work to support. I foresee both being provided for a while until 7 really takes off. I'd also like to see 7 start being made available as distro packages once it branches away and mainstream development moves to 8. There's an opportunity there for a lot more testing than was seen through the previous proprietary release preparation process. -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint = F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
Re: Need reviewer: OpenJDK7 Copyright year updates
On 15:50 Tue 28 Dec , Kelly O'Hair wrote: These changes are only adding the year 2010, to the copyright for files modified in 2010. The first year should be preserved. The pattern YEAR1, YEAR2, in the Oracle copyright line is the equivalent of the old Sun copyright year range YEAR1-YEAR2. So if the file originally was created in 1995, and was last modified in 2010, it should say 1995, 2010,. Not sure I understand your question. Rebranding sources isn't something that generates too many smiles. :^( I read John's comment as he was expecting something like: (C) 1995 Sun Microsystems (C) 2010 Oracle rather than changing the top one to Oracle and expanding the range. But of course, Oracle now owns the Sun copyrights so the 1995, 2010 Oracle copyright is valid. -kto On Dec 28, 2010, at 2:50 PM, John Yeary wrote: Hello Kelly, Shouldn't the original copyrights remain in place? I see there are changes that remove Sun and replace it with Oracle on files from 1995. I would expect that code with changes should include the additional copyright for 2010. Sincerely, John Yeary On Tue, Dec 28, 2010 at 4:37 PM, Kelly O'Hair kelly.oh...@oracle.com wrote: Need reviewer: OpenJDK7 2010 copyright year changes Any sources changed in 2010 need to have their copyright year adjusted. Script used is in the top repository at make/scripts/ update_copyright_year.sh. It finds all changesets created in 2010 and verifies that any sources with copyrights mention 2010 adding it if necessary. 6962318: Update copyright year http://cr.openjdk.java.net/~ohair/openjdk7/jdk7-build-copyright/ webrev/ The webrev tool created some false 'file adds', not sure whether this is a webrev bug or a /bin/sh problem on Solaris, but these changes only impact the Copyright line. Easiest to just view the 'hg diff -U 0' results for each repository impacted: root: http://cr.openjdk.java.net/~ohair/openjdk7/jdk7-build-copyright/diffs.jdk7-build-copyright.txt corba: http://cr.openjdk.java.net/~ohair/openjdk7/jdk7-build-copyright/diffs.corba.txt jaxp: http://cr.openjdk.java.net/~ohair/openjdk7/jdk7-build-copyright/diffs.jaxp.txt jaxws: http://cr.openjdk.java.net/~ohair/openjdk7/jdk7-build-copyright/diffs.jaxws.txt langtools: http://cr.openjdk.java.net/~ohair/openjdk7/jdk7-build-copyright/diffs.langtools.txt jdk: http://cr.openjdk.java.net/~ohair/openjdk7/jdk7-build-copyright/diffs.jdk.txt This does not include hotspot. I'll be asking the hotspot team to deal with that separately. I know this is a mindless and tedious review. Sorry. -kto -- John Yeary -- http://javaevangelist.blogspot.com http://www.johnyeary.com Far better it is to dare mighty things, to win glorious triumphs, even though checkered by failure, than to take rank with those poor spirits who neither enjoy much nor suffer much, because they live in the gray twilight that knows not victory nor defeat. -- Theodore Roosevelt -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint = F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
Re: Need reviewer: OpenJDK7 binary plug logic removal
On 09:56 Thu 23 Dec , Andrew Haley wrote: On 12/23/2010 05:32 AM, David Holmes wrote: Kelly O'Hair said the following on 12/23/10 11:51: Need reviewer: OpenJDK7 binary plug logic removal 7008723: Remove binary plugs creation and use from openjdk http://cr.openjdk.java.net/~ohair/openjdk7/jdk7-build-plug-removal/webrev/ Looks nicely eradicated to me. Surprised how far it's tentacles spread ... Indeed. This patch surely is worthy of a little celebration. Begone, binary plugs, never again to darken our doors... Andrew. Looks good to me too. Good to see the jdk7 README finally being updated :-) -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint = F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
Re: Need reviewers and comments: 6989472: Provide simple jdk identification information in the install image
On 14:19 Wed 22 Dec , Kelly O'Hair wrote: On Dec 22, 2010, at 9:09 AM, Dr Andrew John Hughes wrote: On 16:29 Tue 21 Dec , Kelly O'Hair wrote: I'm back with another stab at a webrev and modified proposal. 6989472: Provide simple jdk identification information in the install image http://cr.openjdk.java.net/~ohair/openjdk7/jdk7-build-eclipse/webrev/ The above change creates a small text file called release at the top of the jdk or jre install image with some very basic values about that install image. For example, on Solaris 10 X86 the file would contain the 4 lines: JAVA_VERSION=1.7.0 OS_NAME=SunOS OS_VERSION=5.10 OS_ARCH=i586 They are not properties and don't look like properties. But they are available as system properties already; os.arch, os.name, os.version and java.version. So why do you need this file? To do sanity checks on jdk images before you try and run them. Ah so, for example, you'd parse this, say 'hey we're actually running on GNU/Linux' and not use it? Sounds like it could be useful in some circumstances, but I think the HotSpot solution you mention below will be more generally applicable. Are you planning to look at this too? -kto It doesn't contain trademark names or company names. It unfortunately does not identify the specific VM, but it does provide some basic information about what the jdk image is and where it can be used. To solve the original Eclipse issue really requires a similar file delivered by the VMs shipped with the JDK. That will need to be pursued with a different CR. -kto -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint = F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint = F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
Re: hotspot build problems
On 07:24 Fri 10 Dec , Per Bothner wrote: On 12/10/2010 12:36 AM, Vikram Aroskar wrote: not a hotspot or build issue. NFS problem in releasing file locks. please move all your workspace and build output directory to local machine harddisk and try again. I'm quite sure that's not it. I have never installed or setup NFS on this laptop - and I installed Fedora 14 from scratch on it recently. On 12/10/2010 07:10 AM, Dr Andrew John Hughes wrote: Easiest thing to try is to set ALT_OUTPUTDIR to a directory on a local disk. I've not had problems with having the source on NFS but I always build to a local disk. The log file shows: ALT_OUTPUTDIR=/home/bothner/Java/jdk7/build/linux-i586/hotspot/outputdir which is local. Ah ok, I just went on Vikram's comment from the last mail without actually studying any logs. I'll try disabling SELinux and see if that makes a difference. I've built OpenJDK on Fedora in the past (and we regularly do to create the RPMs). As I recall, SELinux was an issue previously (Andrew Haley may know more on this), but AFAIK I have it turned on and haven't experienced problems. In fact, there are SELinux workarounds in hotspot/make/linux/makefiles/vm.make. -- --Per Bothner per.both...@oracle.com p...@bothner.com http://per.bothner.com/ -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint = F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
Re: Need reviewers and comments: 6989472: Provide simple jdk identification information in the install image
On 14:44 Mon 29 Nov , Kelly O'Hair wrote: Need reviewers and comments: 6989472: Provide simple jdk identification information in the install image http://cr.openjdk.java.net/~ohair/openjdk7/jdk_release/webrev/ With JDK6 Updates we purposely resisted many rebranding changes that could impacted customers, however at one point we had accidently changed the Windows DLL/EXE COMPANY value thinking that no one would be looking at it. We were wrong and this change cause Eclipse failures, so we are looking for a solution, see: https://bugs.eclipse.org/bugs/show_bug.cgi?id=321390 So we went back and change JDK6 Updates back the way it was, and learned a valuable lesson. But we have and will change JDK7 in this regard, so we wanted a better way for an app to know what it had it's hands on without using platform specific information in the binary files. The above change creates a small text file called jdk.release at the top of the install image with some basic values that could help direct any app using the jdk in constructing a command line or even being assured that this jdk install image will even work on your existing system. In the Eclipse case it was looking for Sun, but I suspect it really wanted to know if the VM was Hotspot because I think it was trying to set a Hotspot specific PermGen option. In any case I think this jdk.release file should provide the necessary answers in the future. The make variable COMPANY_NAME determines the vendor name during a build, so a Linux 64bit build from a make command line like: make COMPANY_NAME=Test Company Name should result in a jdk.release file that looks something like: os.name = Linux os.version = 2.6 os.arch = amd64 java.vendor = Test Company Name java.version = 1.7.0-internal java.vm.vendor = Test Company Name java.vm.name = Hotspot(TM) java.vm.version = 20.0-b02 A formal Oracle jdk7 EA build on Linux 64bit should look something like: os.name = Linux os.version = 2.6 os.arch = amd64 java.vendor = Oracle Corporation java.version = 1.7.0-ea java.vm.vendor = Oracle Corporation java.vm.name = Hotspot(TM) java.vm.version = 20.0-b02 Comments are welcome. Although, polite constructive comments are probably more what I'd like to see. ;^) -kto So what happens if a build does not set COMPANY_NAME? There won't always be an appropriate value for this. Given this is aimed mainly at the Eclipse hackers, have they been notified of this addition? I agree with the previous comment that it should use the standard '.properties' extension and be standardised for cross-JDK usage. Of course, that's only useful if the JSR concerned is actually available under terms which will allow their use with FOSS. I believe this is still not the case with most JSRs. -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint = F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
Re: Fwd: Binary plugs download
On 15:08 Mon 29 Nov , Dalibor Topic wrote: On 11/26/10 3:54 PM, Andrew Haley wrote: On 11/26/2010 02:48 PM, Dalibor Topic wrote: Hm. It's been a long time since I heard of anyone use the binary plugs for anything. Certainly neither regular OpenJDK builds nor IcedTea builds do. So if they just serve to confuse people to assume they are in some way necessary, maybe we should just remove them from the download site for good. Any objections? Why bother? People sometimes want to check out and build old versions. Constant one time effort that saves non-constant amount of time down the road answering questions about binary plugs, as well as time space spent generating them, and so on. Sounds a very good idea to me. If someone really wants to use old versions of OpenJDK7 (given public OpenJDK6 builds have never needed them to my knowledge), they can use an old release of IcedTea rather than these plugs. cheers, dalibor topic -- Oracle http://www.oracle.com Dalibor Topic | Java F/OSS Ambassador Phone: +494023646738 tel:+494023646738 | | | Mobile: +491772664192 tel:+491772664192 Oracle Java Platform Group ORACLE Deutschland B.V. Co. KG | Nagelsweg 55 | 20097 Hamburg ORACLE Deutschland B.V. Co. KG Hauptverwaltung: Riesstr. 25, D-80992 München Registergericht: Amtsgericht München, HRA 95603 Komplementärin: ORACLE Deutschland Verwaltung B.V. Rijnzathe 6, 3454PV De Meern, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Geschäftsführer: Jürgen Kunz, Marcel van de Molen, Alexander van der Ven Green Oracle http://www.oracle.com/commitment Oracle is committed to developing practices and products that help protect the environment -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint = F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
Re: PowerPC build ???
On 09:38 Thu 25 Nov , Mark Wielaard wrote: On Wed, 2010-11-24 at 20:39 -0600, kevin diggs wrote: This question is a little ... weird ... but ... Is the thought of trying to build your sdk with gcj ... heresy (sp?). If not please give me ... your thought as to whether it has any chance of working. I would think that if it is for compiles and the like ... it might work ... Not weird at all! This is exactly what the IcedTea project set out to do. Make OpenJDK bootstrap using only free tools. Since GCJ is the main free java implementation already available on GNU/Linux that is what it has used. http://icedtea.classpath.org/ And still does use. Pretty much every commit I do to IcedTea is proceeded by a full bootstrap using gcj (4.5.1 at present). Also, what is in this binary plug? Am I completely wasting my time since I don't have this? Any chance of getting a powerpc binary plug (or access to the source so one can be built)? And this is one other goal of IcedTea, make sure there are no binary plugs necessary by providing free software replacements. IcedTea provided binary plug replacements in the past, but neither OpenJDK6 or OpenJDK7 have needed them for a long time. The documentation for 7 is outdated in this respect. There are multiple ways towards getting a powerpc port. One is using the Zero interpreter, which has (almost) zero architecture specific (assembly) code. Another is using Shark, which uses LLVM to generate code. Both of these extend the Hotspot runtime. http://icedtea.classpath.org/wiki/ZeroSharkFaq Another way is replacing the Hotspot runtime with one of the free ones already ported to other architectures (but using the rest of the tools and core libraries), like can be done with Cacao. http://c1.complang.tuwien.ac.at/cacaowiki/OpenJDK I'd recommend CACAO if you want something that runs at a decent speed. Zero is good if you want something for which binaries have passed the TCK, but, being intepreted, it's slow. Shark should ideally provide the best of both worlds (it's a JIT and has passed the TCK), but not sure how much usage it's seen so far. It's still relatively new, and has the provisos Gary mentioned on ppc. Both are fully integrated into the IcedTea build process, so in theory it is just a hg clone http://icedtea.classpath.org/hg/icedtea6 cd icedtea6 ./configure make away. (In practice you probably have to give some configure options like --with-additional-vms=cacao,shark. See ./configure --help for more.) Please use --enable-cacao to use the CACAO VM, --enable-shark to build with Shark or --enable-zero to build with Zero, as documented in the INSTALL file. Where possible these extensions are also pushed into OpenJDK proper. Shark Zero are both upstream in OpenJDK6 these days. But you need IcedTea if you want a web plugin or web start support. Cheers, -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint = F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
Re: Need reviewer: NONFCS_BUILD_INFO to add to the non-fcs version string
On 11:36 Wed 24 Nov , Kelly O'Hair wrote: Dang... just shoot me now. :^( Try this: http://cr.openjdk.java.net/~ohair/openjdk7/nonfcs-version/webrev/ Sorry about that. Looks ok to me. I assume the motivation is so that MILESTONE doesn't have to be duplicated in setting JPRT_BUILD_VERSION? You can instead now just set NONFCS_BUILD_INFO to replace the autogenerated user/date stuff without getting rid of MILESTONE. -kto On Nov 24, 2010, at 11:28 AM, Mark Wielaard wrote: On Wed, 2010-11-24 at 11:19 -0800, Kelly O'Hair wrote: I need a reviewer for this change: 6987107: Add NONFCS_BUILD_INFO variable to add to but not modify MILESTONE in version string http://javaweb.sfbay.sun.com/~ohair/webrevs/jdk7/nonfcs-version/webrev/ Bit hard to review if the host isn't reachable :) Could you just attach the patch to your email, or post it on some publicly reachable machine? Thanks, Mark -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint = F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
Re: alsa-sane-headers sanity check broken
On 22:15 Mon 22 Nov , Patrick Reinhart wrote:
Am 22.11.10 22:09, schrieb Dr Andrew John Hughes:
I'm quite puzzled as to how this hasn't been spotted before now, but I
tried to build jdk7/jdk7 today (b118 from hg), using exactly the same
script as I usually do, and immediately failed due to a missing
separator in the jdk Sanity.gmk Makefile:
make[1]: Entering directory
`/home/andrew/projects/openjdk/upstream/build/jdk/make'
/home/andrew/projects/openjdk/upstream/build/jdk/make/common/shared/Sanity.gmk:1392:
*** missing separator (did you mean TAB instead of 8 spaces?). Stop.
make[1]: Leaving directory
`/home/andrew/projects/openjdk/upstream/build/jdk/make'
I've just confirmed it's also broken in the build tree and the icedtea tree
also fails (which is where I first hit the error).
It seems the sane-alsa-headers target is completely broken. What's puzzling
is the changes occur in:
http://hg.openjdk.java.net/jdk7/jdk7/jdk/rev/30bf00392b6d
changeset: 914:30bf00392b6d
parent: 796:d8eb2738db6b
user:ohair
date:Sat Jan 31 17:31:21 2009 -0800
summary: 6799141: Build with --hash-style=both so that binaries can
work on SuSE 10
which is nearly two years old.
I managed to make some headway:
* The target uses a mix of tabs and spaces. Replacing with all tabs gets
things further.
* The next issue is fixed by changing $${alsa_version) to $${alsa_version}.
It then fails because we have a conditional structured as:
if [ $(ALSA_CHECK) != same -a $(ALSA_CHECK) != newer ] ; then \
...
fi \
else \
...
fi
There seems to be an if statement missing as, otherwise, having
REQUIRED_ALSA_VERSION
defined always results in an error. I assume there should be a top level
if statement,
similar to the @if [ -f $(ALSA_VERSION_CHECK) ]; removed by this
changeset. This would
also explain why the if block is printed when usually such things are
silent.
Anyone care to enlighten us as to the missing if statement? I'd also love
to know how
this has only just started biting me now.
Thanks,
Hi Andrew,
See my statement and correcting diff
http://mail.openjdk.java.net/pipermail/build-dev/2010-November/003578.html
when I tried to get the build running under Fedora 14...
Regards Patrick
Yes, as described in my original e-mail, I've already made those changes.
I don't believe the final else block is redundant. An if check seems to be
missing, which
is further reinforced if you take a look at other checks in the file and the
CheckVersions macro;
we should be looking for ALSA_CHECK being missing.
I've posted a webrev here: http://cr.openjdk.java.net/~andrew/build/webrev.07/
which contains corrected indenting, the alsa_version fix and the additional if
test.
Kelly, does this look ok to push? If so, can I have a bug ID for it?
Thanks,
--
Andrew :)
Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)
Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net
PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint = F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
Re: alsa-sane-headers sanity check broken
On 14:06 Mon 22 Nov , Kelly O'Hair wrote:
On Nov 22, 2010, at 1:53 PM, Dr Andrew John Hughes wrote:
On 22:15 Mon 22 Nov , Patrick Reinhart wrote:
Am 22.11.10 22:09, schrieb Dr Andrew John Hughes:
I'm quite puzzled as to how this hasn't been spotted before now,
but I
tried to build jdk7/jdk7 today (b118 from hg), using exactly the
same
script as I usually do, and immediately failed due to a missing
separator in the jdk Sanity.gmk Makefile:
make[1]: Entering directory `/home/andrew/projects/openjdk/
upstream/build/jdk/make'
/home/andrew/projects/openjdk/upstream/build/jdk/make/common/
shared/Sanity.gmk:1392: *** missing separator (did you mean TAB
instead of 8 spaces?). Stop.
make[1]: Leaving directory `/home/andrew/projects/openjdk/upstream/
build/jdk/make'
I've just confirmed it's also broken in the build tree and the
icedtea tree
also fails (which is where I first hit the error).
It seems the sane-alsa-headers target is completely broken.
What's puzzling
is the changes occur in:
http://hg.openjdk.java.net/jdk7/jdk7/jdk/rev/30bf00392b6d
changeset: 914:30bf00392b6d
parent: 796:d8eb2738db6b
user:ohair
date:Sat Jan 31 17:31:21 2009 -0800
summary: 6799141: Build with --hash-style=both so that
binaries can work on SuSE 10
which is nearly two years old.
I managed to make some headway:
* The target uses a mix of tabs and spaces. Replacing with all
tabs gets things further.
* The next issue is fixed by changing $${alsa_version) to $$
{alsa_version}.
It then fails because we have a conditional structured as:
if [ $(ALSA_CHECK) != same -a $(ALSA_CHECK) != newer ] ;
then \
...
fi \
else \
...
fi
There seems to be an if statement missing as, otherwise, having
REQUIRED_ALSA_VERSION
defined always results in an error. I assume there should be a
top level if statement,
similar to the @if [ -f $(ALSA_VERSION_CHECK) ]; removed by this
changeset. This would
also explain why the if block is printed when usually such things
are silent.
Anyone care to enlighten us as to the missing if statement? I'd
also love to know how
this has only just started biting me now.
Thanks,
Hi Andrew,
See my statement and correcting diff
http://mail.openjdk.java.net/pipermail/build-dev/2010-November/003578.html
when I tried to get the build running under Fedora 14...
Regards Patrick
Yes, as described in my original e-mail, I've already made those
changes.
I don't believe the final else block is redundant. An if check
seems to be missing, which
is further reinforced if you take a look at other checks in the file
and the CheckVersions macro;
we should be looking for ALSA_CHECK being missing.
I've posted a webrev here:
http://cr.openjdk.java.net/~andrew/build/webrev.07/
which contains corrected indenting, the alsa_version fix and the
additional if test.
Kelly, does this look ok to push? If so, can I have a bug ID for it?
Looks fine. Feel free to push.
7000225: Sanity check on sane-alsa-headers is broken
Thank you. I filed the bug last week I think, just been so busy
lately. :^(
-kto
Thanks,
--
Andrew :)
Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)
Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net
PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint = F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
Done.
Thanks,
--
Andrew :)
Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)
Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net
PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint = F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
Re: alsa-sane-headers sanity check broken
On 15:17 Mon 22 Nov , Kelly O'Hair wrote:
Been scratching my head on this one.
Another error is in the target sane-gcc-compiler, same kind of thing.
Turns out this one was Solaris only, and the older version of GNU make
seemed to be silent (3.78.1)
but the newer one (3.81) complained about a missing TAB character.
Our RE teams use the older GNU make 3.78.1, I've been trying to
advance (if you want to
call it that) to 3.81, or even 3.82 if possible, but it's not been as
easy as originally planned
due to the issues with Windows, MKS, and escaped quotes in rules. But
3.82 may have a fix
for this.
Could we be using a different GNU make version on some of these Linux
systems?
I think a move from 3.81 to 3.82 may have trigged the issue here. I'm
don't know if Fedora 14 also upgrades to that version, but it sounds
likely. I presume it simply wasn't been evaluated before, given there
are three bugs and two of these, the variable expansion and the
conditional, are being evaluated by the shell. My guess would be that
it simply regarded the target as empty due to the spacing and thus it
was trivially satisfied.
-kto
On Nov 22, 2010, at 2:33 PM, David Holmes wrote:
Any enlightenment on how this only just started happening? Has the
alsa check been disabled previously?
David
Kelly O'Hair said the following on 11/23/10 08:06:
On Nov 22, 2010, at 1:53 PM, Dr Andrew John Hughes wrote:
On 22:15 Mon 22 Nov , Patrick Reinhart wrote:
Am 22.11.10 22:09, schrieb Dr Andrew John Hughes:
I'm quite puzzled as to how this hasn't been spotted before now,
but I
tried to build jdk7/jdk7 today (b118 from hg), using exactly the
same
script as I usually do, and immediately failed due to a missing
separator in the jdk Sanity.gmk Makefile:
make[1]: Entering directory `/home/andrew/projects/openjdk/
upstream/build/jdk/make'
/home/andrew/projects/openjdk/upstream/build/jdk/make/common/
shared/Sanity.gmk:1392: *** missing separator (did you mean TAB
instead of 8 spaces?). Stop.
make[1]: Leaving directory `/home/andrew/projects/openjdk/
upstream/build/jdk/make'
I've just confirmed it's also broken in the build tree and the
icedtea tree
also fails (which is where I first hit the error).
It seems the sane-alsa-headers target is completely broken.
What's puzzling
is the changes occur in:
http://hg.openjdk.java.net/jdk7/jdk7/jdk/rev/30bf00392b6d
changeset: 914:30bf00392b6d
parent: 796:d8eb2738db6b
user:ohair
date:Sat Jan 31 17:31:21 2009 -0800
summary: 6799141: Build with --hash-style=both so that
binaries can work on SuSE 10
which is nearly two years old.
I managed to make some headway:
* The target uses a mix of tabs and spaces. Replacing with all
tabs gets things further.
* The next issue is fixed by changing $${alsa_version) to $$
{alsa_version}.
It then fails because we have a conditional structured as:
if [ $(ALSA_CHECK) != same -a $(ALSA_CHECK) !=
newer ] ; then \
...
fi \
else \
...
fi
There seems to be an if statement missing as, otherwise, having
REQUIRED_ALSA_VERSION
defined always results in an error. I assume there should be a
top level if statement,
similar to the @if [ -f $(ALSA_VERSION_CHECK) ]; removed by
this changeset. This would
also explain why the if block is printed when usually such
things are silent.
Anyone care to enlighten us as to the missing if statement? I'd
also love to know how
this has only just started biting me now.
Thanks,
Hi Andrew,
See my statement and correcting diff
http://mail.openjdk.java.net/pipermail/build-dev/2010-November/003578.html
when I tried to get the build running under Fedora 14...
Regards Patrick
Yes, as described in my original e-mail, I've already made those
changes.
I don't believe the final else block is redundant. An if check
seems to be missing, which
is further reinforced if you take a look at other checks in the
file and the CheckVersions macro;
we should be looking for ALSA_CHECK being missing.
I've posted a webrev here:
http://cr.openjdk.java.net/~andrew/build/webrev.07/
which contains corrected indenting, the alsa_version fix and the
additional if test.
Kelly, does this look ok to push? If so, can I have a bug ID for it?
Looks fine. Feel free to push.
7000225: Sanity check on sane-alsa-headers is broken
Thank you. I filed the bug last week I think, just been so busy
lately. :^(
-kto
Thanks,
--
Andrew :)
Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)
Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net
PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint = F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
--
Andrew :)
Free Java
Re: Field of use
On 18 November 2010 12:44, Jonathan Tripathy jon...@abpni.co.uk wrote: Hi Everyone, Does the OpenJDK project have any Field of Use restrictions? Are kiosk/set top box style installation allowed? Thanks http://openjdk.java.net/legal/ -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
Re: no gcj-jdk + no ecj + building openjdk
On 09:27 Thu 18 Nov , Mark Wielaard wrote: On Thu, 2010-11-18 at 11:31 +0530, ramakanth varala wrote: My target is to get openjdk build for target board (ARM) . In the process i thought i would build openjdk first to my host machine i.e of fedora 8. Fedora 8 is very outdated (3 years old). Although IcedTea (7) has been bootstrapped on it, it isn't maintained anymore. You might have better luck if you update to a more modern version (Fedora 14 is the latest). Iam confused of lot of things here 1) what is icedtea ? IcedTea is a fully free Java Runtime and Development Environment. Build upon OpenJDK extended with developer, user and web browser tools like an Applet viewer, Java Webstart (LiveConnect and JNLP) support and VisualVM, a lightweight profiler and troubleshooting tool. Bootstraps with and provides alternative runtimes, tools and class library support for Java and Java-like environments, like the Zero interpreter, Shark JIT, GCJ native compiler, GNU Classpath core libraries and Cacao. See http://icedtea.classpath.org/ Zero Shark are now part of OpenJDK. 2) How is icedtea related to openjdk? OpenJDK is a free reference implementation for the Java Standard Edition Developer Kit. Includes an execution environment, development tools and a class library for the Java programming language. IcedTea extends this. Notably, IcedTea is required for plugin and Web Start support. The packages in most distros which claim to be OpenJDK are actually IcedTea. An easy way to check is to see if a plugin and javaws binary are included. I haven't heard of any distros shipping OpenJDK as supplied upstream. 3) can i build this for the arm board ? Yes, it should natively build on an arm board. But that might be slow, so you might want to cross-compile... 4) can you point me to proper documentation where i can get a clear picture of cross-compilation to arm? See http://icedtea.classpath.org/wiki/CrossCompileFaq I'm not sure how up-to-date this document is. It does have noticeable typos. There should be support for ARM in IcedTea via Zero, Shark and the ARM assembler port (I'm not sure of the maintenance level of the latter). The best advice is probably to give it a try and go on IRC if you hit problems. I believe Xerces (xranby) does regular ARM builds and is usually online in #openjdk on the OFTC network. Cheers, Mark -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint = F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
Re: no gcj-jdk + no ecj + building openjdk
On 09:30 Wed 17 Nov , Gary Benson wrote: Hi Ramakanth, It looks like you're using IcedTea, so I'm copying in distro-pkg-dev which is the mailing list most IcedTea stuff is discussed on. It also looks like you're using Fedora 8, which is very old. I'm not saying you won't be able to do a build, but you'll likely run into problems that upgrading would solve. So unless there you have a very compelling reason to stick on Fedora 8 I would suggest upgrading to the latest as your first step. In answer to your question, ecj is the Java compiler from Eclipse, and it's the Java compiler used by jdk-gcj-compat. You do need an existing JDK to build OpenJDK, and jdk-gcj-compat is probably the only free one available for Fedora 8. Cheers, Gary Ramakanth Varala wrote: Hello all, Iam trying to build openjdk for my fedora plat form . i like to build openjdk without ecj ( i guess this is eclipse related and eclipse IDE is not needed ) ecj is a java compiler and you need a Java compiler to build IcedTea. It does come from the Eclipse IDE but you don't need any of the IDE installed to use it. It's a command-line tool. On Fedora 8, I believe you should have the option of either installing java-1.5.0-gcj (recommended) or java-1.7.0-icedtea. Using the latter will require building with the --with-openjdk flag. The simplest option, however, is probably just to upgrade to a newer version of Fedora and perform 'yum install java-1.6.0-openjdk'. Currently iam getting the error as below . checking for distribution package version... none checking build identification... Built on Fedora release 8 (Werewolf) (Wed Nov 17 12:03:35 IST 2010) checking for a GCJ JDK home directory... configure: error: A GCJ JDK home directory could not be found. can any body help me in this. regards -- http://gbenson.net/ -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint = F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
Re: Java2Demo and com/sun/image missing from OpenJDK7 clone
On 9 November 2010 17:41, Pete Brunet peter.bru...@oracle.com wrote: I notice that com/sun/image is missing from my OpenJDK7 clone, i.e. it's not in the classes directory or the rt.jar files in the two image directores (jre and jdk). Also the demo itself isn't in the OpenJDK7 tree. Both the demo and the com/sun/image directory /are/ in the binaries installed with the latest 117 installer, i.e. jdk-7-ea-bin-b117-windows-i586-04_nov_2010.exe. Pete As far as I understand that, the binaries provided by Oracle are from a proprietary JDK7 code base (and hence have proprietary licensing). Oracle don't produce OpenJDK binaries. -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
Re: Bootstrap javac cannot be compiled using earlier JDK7 versions
On 20 October 2010 13:07, Andreas Kohn andreas.k...@fredhopper.com wrote: Hi, I wanted to update my local JDK7 build, and stumbled across a problem when building with a JDK7 from ~2010-09-10: build-bootstrap-javac: [javac] Compiling 78 source files to /local/andreask-nonbackup/jdk7/build/linux-amd64/langtools/build/bootstrap/classes [javac] /local/andreask-nonbackup/jdk7/langtools/src/share/classes/com/sun/tools/javac/nio/JavacPathFileManager.java:372: method does not override or implement a method from a supertype [javac] @Override [javac] ^ [javac] 1 error The full output up to that point is attached. This was a completely fresh fclone of the jdk7 forest (e8ebdf41b9c0) to rule out any local modifications. Is this error expected? I just commented the @Override so I could build. I'm a bit wondering how this bootstrap can work with a JDK6, but I didn't try that yet. What is /usr/java/openjdk-current/bin/javac ? What does /usr/java/openjdk-current/bin/java -version give? Regards, -- Andreas -- Never attribute to malice that which can be adequately explained by stupidity. -- Hanlon's Razor Building Control linux amd64 1.7.0-internal all build started: 10-10-20 09:17 Build Machine Information: build machine = tiamaria.ams.fredhopper.com Build Directory Structure: CWD = /local/andreask-nonbackup/jdk7 TOPDIR = . LANGTOOLS_TOPDIR = ./langtools JAXP_TOPDIR = ./jaxp JAXWS_TOPDIR = ./jaxws CORBA_TOPDIR = ./corba HOTSPOT_TOPDIR = ./hotspot JDK_TOPDIR = ./jdk Build Directives: BUILD_LANGTOOLS = true BUILD_JAXP = true BUILD_JAXWS = true BUILD_CORBA = true BUILD_HOTSPOT = true BUILD_JDK = true DEBUG_CLASSFILES = DEBUG_BINARIES = Hotspot Settings: HOTSPOT_BUILD_JOBS = HOTSPOT_OUTPUTDIR = /local/andreask-nonbackup/jdk7/build/linux-amd64/hotspot/outputdir HOTSPOT_EXPORT_PATH = /local/andreask-nonbackup/jdk7/build/linux-amd64/hotspot/import Bootstrap Settings: BOOTDIR = /usr/java/openjdk-current ALT_BOOTDIR = /usr/java/openjdk-current BOOT_VER = 1.7.0 [requires at least 1.6] OUTPUTDIR = /local/andreask-nonbackup/jdk7/build/linux-amd64 ALT_OUTPUTDIR = /local/andreask-nonbackup/jdk7/build/linux-amd64 ABS_OUTPUTDIR = /local/andreask-nonbackup/jdk7/build/linux-amd64 Build Tool Settings: SLASH_JAVA = /NOT-SET ALT_SLASH_JAVA = VARIANT = OPT JDK_DEVTOOLS_DIR = /NOT-SET/devtools ALT_JDK_DEVTOOLS_DIR = ANT_HOME = /local/home/andreask/modules/apache-ant-1.7.1 UNIXCOMMAND_PATH = /bin/ ALT_UNIXCOMMAND_PATH = COMPILER_PATH = /usr/bin/ ALT_COMPILER_PATH = DEVTOOLS_PATH = /usr/bin/ ALT_DEVTOOLS_PATH = UNIXCCS_PATH = /usr/ccs/bin/ ALT_UNIXCCS_PATH = USRBIN_PATH = /usr/bin/ ALT_USRBIN_PATH = COMPILER_NAME = GCC4 COMPILER_VERSION = GCC4 CC_VER = 4.4.4 [requires at least 4.3.0] ZIP_VER = 2.31 [requires at least 2.2] UNZIP_VER = 5.52 [requires at least 5.12] ANT_VER = 1.7.1 [requires at least 1.6.3] TEMPDIR = /local/andreask-nonbackup/jdk7/build/linux-amd64/tmp Build Directives: OPENJDK = true USE_HOTSPOT_INTERPRETER_MODE = PEDANTIC = DEV_ONLY = true NO_DOCS = NO_IMAGES = TOOLS_ONLY = INSANE = COMPILE_APPROACH = parallel PARALLEL_COMPILE_JOBS = 2 ALT_PARALLEL_COMPILE_JOBS = FASTDEBUG = COMPILER_WARNINGS_FATAL = false COMPILER_WARNING_LEVEL = INCREMENTAL_BUILD = false CC_HIGHEST_OPT = CC_HIGHER_OPT = CC_LOWER_OPT = CXXFLAGS = -O2 -fPIC -DCC_NOEX -W -Wall -Wno-unused -Wno-parentheses -fno-omit-frame-pointer -D_LITTLE_ENDIAN CFLAGS = -O2 -fno-strict-aliasing -fPIC -W -Wall -Wno-unused -Wno-parentheses -pipe -fno-omit-frame-pointer -D_LITTLE_ENDIAN BOOT_JAVA_CMD = /usr/java/openjdk-current/bin/java -XX:-PrintVMOptions -XX:+UnlockDiagnosticVMOptions -XX:-LogVMOutput -Xmx896m -Xms128m -XX:PermSize=32m -XX:MaxPermSize=160m BOOT_JAVAC_CMD = /usr/java/openjdk-current/bin/javac -J-XX:ThreadStackSize=1536 -J-XX:-PrintVMOptions -J-XX:+UnlockDiagnosticVMOptions -J-XX:-LogVMOutput -J-Xmx896m -J-Xms128m -J-XX:PermSize=32m -J-XX:MaxPermSize=160m -encoding ascii -source 6 -target 6 -XDignore.symbol.file=true BOOT_JAR_CMD = /usr/java/openjdk-current/bin/jar BOOT_JARSIGNER_CMD = /usr/java/openjdk-current/bin/jarsigner JAVAC_CMD = /usr/java/openjdk-current/bin/javac -J-XX:ThreadStackSize=1536 -J-XX:-PrintVMOptions -J-XX:+UnlockDiagnosticVMOptions -J-XX:-LogVMOutput -J-Xmx896m -J-Xms128m -J-XX:PermSize=32m -J-XX:MaxPermSize=160m -source 7 -target 7 -encoding ascii -Xbootclasspath:/local/andreask-nonbackup/jdk7/build/linux-amd64/classes JAVAH_CMD = /usr/java/openjdk-current/bin/javah -bootclasspath /local/andreask-nonbackup/jdk7/build/linux-amd64/classes JAVADOC_CMD = /usr/java/openjdk-current/bin/javadoc -J-XX:-PrintVMOptions -J-XX:+UnlockDiagnosticVMOptions -J-XX:-LogVMOutput
Re: static linking of libgcc on linux ?
On 21 September 2010 07:33, Martin Buchholz marti...@google.com wrote:
This appears to be another case where the hotspot and jdk repo makefiles
differ.
hotspot does:
# statically link libgcc and/or libgcc_s, libgcc does not exist before
gcc-3.x.
ifneq (${CC_VER_MAJOR}, 2)
STATIC_LIBGCC += -static-libgcc
endif
making it look like the jdk repo makefile is in error.
I continue to be surprised that with all the strange fiddling with
linker flags (use of -static-libgcc is not encouraged), that jdk
binaries have such a high degree of binary compatibility.
I would imagine this static linking is to aid binary compatibility,
allowing Oracle to ship
binaries which work with different versions of gcc and glibc (which I
believe is also statically linked)
than that it is built against.
I wonder if it's worth disabling such linking on distributions. Would
it lead to a significant reduction in footprint?
Martin
On Sun, Sep 19, 2010 at 23:02, David Holmes david.hol...@oracle.com wrote:
In the j2se/jdk repo make/common/Defs-linux.gmk contains this old code:
#
# -static-libgcc is a gcc-3 flag to statically link libgcc, gcc-2.9x always
# statically link libgcc but will print a warning with the flag. We don't
# want the warning, so check gcc version first.
#
CC_VER_MAJOR := $(shell $(CC) -dumpversion | $(SED) 's/egcs-//' | $(CUT)
-d'.' -f1)
ifeq ($(CC_VER_MAJOR), 3)
OTHER_LDFLAGS += -static-libgcc
endif
Now we build with gcc 4 we actually don't set -static-libgcc. Can someone
comment on the correctness of this - should we instead be checking for
ifneq ($(CC_VER_MAJOR), 2) ?
Thanks,
David Holmes
--
Andrew :-)
Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)
Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net
PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
Re: Review Request: Final Shark buildsystem piece
On 18 August 2010 09:53, Gary Benson gben...@redhat.com wrote: Christian Thalinger wrote: On Tue, 2010-08-17 at 13:51 -0700, Kelly O'Hair wrote: I had assumed this was a file in the hotspot repo, but it's actually in the top repo. Feel free to push this change into the tl forest, or whereever you pushed it's cohort changeset. Gary, do you need a new CR? -- Christian Yes please :) Cheers, Gary -- http://gbenson.net/ I think it would make more sense to use '6976186: Integrate Shark' again, so the commits are easily associated as part of the same bug. This is used for both the HotSpot and JDK chunks. -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
Re: Review Request: Final Shark buildsystem piece
On 24 August 2010 13:18, Dr Andrew John Hughes ahug...@redhat.com wrote: On 18 August 2010 09:53, Gary Benson gben...@redhat.com wrote: Christian Thalinger wrote: On Tue, 2010-08-17 at 13:51 -0700, Kelly O'Hair wrote: I had assumed this was a file in the hotspot repo, but it's actually in the top repo. Feel free to push this change into the tl forest, or whereever you pushed it's cohort changeset. Gary, do you need a new CR? -- Christian Yes please :) Cheers, Gary -- http://gbenson.net/ I think it would make more sense to use '6976186: Integrate Shark' again, so the commits are easily associated as part of the same bug. This is used for both the HotSpot and JDK chunks. -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 Pushed: http://hg.openjdk.java.net/jdk7/tl/rev/1fbed32d2ddd -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
Re: Review request: Shark buildsystem changes
On 13 August 2010 16:58, Kelly O'Hair kelly.oh...@oracle.com wrote: On Aug 13, 2010, at 1:49 AM, Gary Benson wrote: Dalibor Topic wrote: On 8/12/10 10:58 PM, Kelly O'Hair wrote: There isn't a document but I'm happy to write one if you'd like, either as a section of README-builds.html or a file in it's own right. Shall I do that? Adding a section to the README-builds.html file on ZERO/SHARK builds seems like a good idea to me. Agreed. Cool, I'll do that. May I push the other changes in the meantime? The hotspot change will need to go through the hotspot team somehow, you need to send an email to hotspot-dev on that one. All hotspot changes need to go through their integration procedures. Ok. The equivalent top-level change for Zero was reviewed by you and Tim: changeset: 134:608937d41381 parent: 131:2c88089b6e1c user:gbenson date:Thu Oct 15 13:26:17 2009 +0100 files: make/hotspot-rules.gmk description: 6891677: java/build integrate zero assembler JDK changes Summary: Build changes for the Zero assembler port Reviewed-by: ohair, tbell so I guess that's why Gary posted the Shark ones here. We are currently discussing whether we want to continue using the jdk7/build forest, and instead use the jdk7/tl forest for build changes. No final decision has been made, but I see no issue with this change going to either one. Is it possible for you to push the jdk change into the jdk7/tl/jdk repo? Done on Gary's behalf: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/0cdd73548292 -kto Cheers, Gary -- http://gbenson.net/ -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
