From kelly.ohair at sun.com Thu May 1 02:37:11 2008 From: kelly.ohair at sun.com (kelly.ohair at sun.com) Date: Thu, 01 May 2008 02:37:11 +0000 Subject: hg: jdk7/build: 6563616: Clarify instructions for unpacking openjdk binary "plug"; ... Message-ID: <20080501023711.4134127B0C@hg.openjdk.java.net> Changeset: 0f440f3321f5 Author: ohair Date: 2008-04-30 19:35 -0700 URL: http://hg.openjdk.java.net/jdk7/build/rev/0f440f3321f5 6563616: Clarify instructions for unpacking openjdk binary "plug" 6611685: Incorrect link to CA certs info from build README 6682167: Add cygwin faq to README-builds.html Reviewed-by: xdono ! README-builds.html From kelly.ohair at sun.com Thu May 1 02:45:37 2008 From: kelly.ohair at sun.com (kelly.ohair at sun.com) Date: Thu, 01 May 2008 02:45:37 +0000 Subject: hg: jdk7/build/jdk: 6695553: Cleanup GPLv2+SPL legal notices in hat sources Message-ID: <20080501024558.3ED8027B13@hg.openjdk.java.net> Changeset: d70a63c92b49 Author: ohair Date: 2008-04-30 17:34 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/d70a63c92b49 6695553: Cleanup GPLv2+SPL legal notices in hat sources Summary: Just correcting the legal notices on the HAT sources. Reviewed-by: alanb ! src/share/classes/com/sun/tools/hat/Main.java ! src/share/classes/com/sun/tools/hat/build.xml ! src/share/classes/com/sun/tools/hat/internal/model/AbstractJavaHeapObjectVisitor.java ! src/share/classes/com/sun/tools/hat/internal/model/ArrayTypeCodes.java ! src/share/classes/com/sun/tools/hat/internal/model/HackJavaValue.java ! src/share/classes/com/sun/tools/hat/internal/model/JavaBoolean.java ! src/share/classes/com/sun/tools/hat/internal/model/JavaByte.java ! src/share/classes/com/sun/tools/hat/internal/model/JavaChar.java ! src/share/classes/com/sun/tools/hat/internal/model/JavaClass.java ! src/share/classes/com/sun/tools/hat/internal/model/JavaDouble.java ! src/share/classes/com/sun/tools/hat/internal/model/JavaField.java ! src/share/classes/com/sun/tools/hat/internal/model/JavaFloat.java ! src/share/classes/com/sun/tools/hat/internal/model/JavaHeapObject.java ! src/share/classes/com/sun/tools/hat/internal/model/JavaHeapObjectVisitor.java ! src/share/classes/com/sun/tools/hat/internal/model/JavaInt.java ! src/share/classes/com/sun/tools/hat/internal/model/JavaLazyReadObject.java ! src/share/classes/com/sun/tools/hat/internal/model/JavaLong.java ! src/share/classes/com/sun/tools/hat/internal/model/JavaObject.java ! src/share/classes/com/sun/tools/hat/internal/model/JavaObjectArray.java ! src/share/classes/com/sun/tools/hat/internal/model/JavaObjectRef.java ! src/share/classes/com/sun/tools/hat/internal/model/JavaShort.java ! src/share/classes/com/sun/tools/hat/internal/model/JavaStatic.java ! src/share/classes/com/sun/tools/hat/internal/model/JavaThing.java ! src/share/classes/com/sun/tools/hat/internal/model/JavaValue.java ! src/share/classes/com/sun/tools/hat/internal/model/JavaValueArray.java ! src/share/classes/com/sun/tools/hat/internal/model/ReachableExcludes.java ! src/share/classes/com/sun/tools/hat/internal/model/ReachableExcludesImpl.java ! src/share/classes/com/sun/tools/hat/internal/model/ReachableObjects.java ! src/share/classes/com/sun/tools/hat/internal/model/ReferenceChain.java ! src/share/classes/com/sun/tools/hat/internal/model/Root.java ! src/share/classes/com/sun/tools/hat/internal/model/Snapshot.java ! src/share/classes/com/sun/tools/hat/internal/model/StackFrame.java ! src/share/classes/com/sun/tools/hat/internal/model/StackTrace.java ! src/share/classes/com/sun/tools/hat/internal/oql/OQLEngine.java ! src/share/classes/com/sun/tools/hat/internal/oql/OQLException.java ! src/share/classes/com/sun/tools/hat/internal/oql/OQLQuery.java ! src/share/classes/com/sun/tools/hat/internal/oql/ObjectVisitor.java ! src/share/classes/com/sun/tools/hat/internal/parser/FileReadBuffer.java ! src/share/classes/com/sun/tools/hat/internal/parser/HprofReader.java ! src/share/classes/com/sun/tools/hat/internal/parser/MappedReadBuffer.java ! src/share/classes/com/sun/tools/hat/internal/parser/PositionDataInputStream.java ! src/share/classes/com/sun/tools/hat/internal/parser/PositionInputStream.java ! src/share/classes/com/sun/tools/hat/internal/parser/ReadBuffer.java ! src/share/classes/com/sun/tools/hat/internal/parser/Reader.java ! src/share/classes/com/sun/tools/hat/internal/server/AllClassesQuery.java ! src/share/classes/com/sun/tools/hat/internal/server/AllRootsQuery.java ! src/share/classes/com/sun/tools/hat/internal/server/ClassQuery.java ! src/share/classes/com/sun/tools/hat/internal/server/FinalizerObjectsQuery.java ! src/share/classes/com/sun/tools/hat/internal/server/FinalizerSummaryQuery.java ! src/share/classes/com/sun/tools/hat/internal/server/HistogramQuery.java ! src/share/classes/com/sun/tools/hat/internal/server/HttpReader.java ! src/share/classes/com/sun/tools/hat/internal/server/InstancesCountQuery.java ! src/share/classes/com/sun/tools/hat/internal/server/InstancesQuery.java ! src/share/classes/com/sun/tools/hat/internal/server/OQLHelp.java ! src/share/classes/com/sun/tools/hat/internal/server/OQLQuery.java ! src/share/classes/com/sun/tools/hat/internal/server/ObjectQuery.java ! src/share/classes/com/sun/tools/hat/internal/server/PlatformClasses.java ! src/share/classes/com/sun/tools/hat/internal/server/QueryHandler.java ! src/share/classes/com/sun/tools/hat/internal/server/QueryListener.java ! src/share/classes/com/sun/tools/hat/internal/server/ReachableQuery.java ! src/share/classes/com/sun/tools/hat/internal/server/RefsByTypeQuery.java ! src/share/classes/com/sun/tools/hat/internal/server/RootStackQuery.java ! src/share/classes/com/sun/tools/hat/internal/server/RootsQuery.java ! src/share/classes/com/sun/tools/hat/internal/util/ArraySorter.java ! src/share/classes/com/sun/tools/hat/internal/util/Comparer.java ! src/share/classes/com/sun/tools/hat/internal/util/CompositeEnumeration.java ! src/share/classes/com/sun/tools/hat/internal/util/Misc.java ! src/share/classes/com/sun/tools/hat/internal/util/VectorSorter.java ! src/share/classes/com/sun/tools/hat/resources/hat.js From Jonathan.Gibbons at Sun.COM Sat May 3 00:04:14 2008 From: Jonathan.Gibbons at Sun.COM (Jonathan Gibbons) Date: Fri, 02 May 2008 17:04:14 -0700 Subject: jtreg on jdk download pages Message-ID: <481BABFE.70907@sun.com> Build folk, Now that jtreg 4 has made it out the door and has its own download pages, we should presumably update or remove the jtreg links from the download pages for JDK 6 and JDK 7, for future builds. If someone really wants 3.2.2_03, they can still get it from the download page for earlier builds. -- Jon From Xiomara.Jayasena at Sun.COM Sat May 3 00:18:39 2008 From: Xiomara.Jayasena at Sun.COM (Xiomara Jayasena) Date: Fri, 02 May 2008 17:18:39 -0700 Subject: jtreg on jdk download pages In-Reply-To: <481BABFE.70907@sun.com> References: <481BABFE.70907@sun.com> Message-ID: On May 2, 2008, at 5:04 PM, Jonathan Gibbons wrote: > Build folk, > > Now that jtreg 4 has made it out the door and has its own download > pages, we should presumably update or remove the jtreg links from > the download pages for JDK 6 and JDK 7, for future builds. Right, that is what we'll do as you and I discussed. -Xiomara > If someone really wants 3.2.2_03, they can still get it from the > download page for earlier builds. > > -- Jon > From linuxhippy at gmail.com Fri May 9 10:45:47 2008 From: linuxhippy at gmail.com (Clemens Eisserer) Date: Fri, 9 May 2008 12:45:47 +0200 Subject: Howto re-compile ony parts? Message-ID: <194f62550805090345r6e149996w757960c8a34a0f48@mail.gmail.com> Hello, Is it possible to re-compile only certain parts of the JDK? I would like to only re-compile the native AWT part on Unix, because a whole "make" takes always several minutes :-/ Thank you in advance, lg Clemens From Dmitri.Trembovetski at Sun.COM Fri May 9 14:11:38 2008 From: Dmitri.Trembovetski at Sun.COM (Dmitri Trembovetski) Date: Fri, 09 May 2008 07:11:38 -0700 Subject: Howto re-compile ony parts? In-Reply-To: <194f62550805090345r6e149996w757960c8a34a0f48@mail.gmail.com> References: <194f62550805090345r6e149996w757960c8a34a0f48@mail.gmail.com> Message-ID: <48245B9A.30009@Sun.COM> Depending on what you want to recompile, you'll need to cd to a particular directory and run gnumake from there. For awt/2d, the directories are make/sun/awt make/sun/xawt Mostly the latter. Thanks, Dmitri Clemens Eisserer wrote: > Hello, > > Is it possible to re-compile only certain parts of the JDK? > I would like to only re-compile the native AWT part on Unix, because a > whole "make" takes always several minutes :-/ > > Thank you in advance, lg Clemens From Weijun.Wang at Sun.COM Fri May 9 14:21:25 2008 From: Weijun.Wang at Sun.COM (Max (Weijun) Wang) Date: Fri, 09 May 2008 22:21:25 +0800 Subject: Howto re-compile ony parts? In-Reply-To: <48245B9A.30009@Sun.COM> References: <194f62550805090345r6e149996w757960c8a34a0f48@mail.gmail.com> <48245B9A.30009@Sun.COM> Message-ID: <0C390054-70D8-4BD8-B86C-1C842A5FF829@sun.com> BTW, if your previous full build is the whole OpenJDK instead of only the JDK part (I mean jdk7/Makefile instead of jdk7/jdk/make/ Makefile), you need to set ALT_OUTPUTDIR to jdk7/build/{platform}. Otherwise, the partial make's default OUTPUTDIR is jdk7/jdk/build/ {platform} Hope I explain it clearly. Max On May 9, 2008, at 10:11 PM, Dmitri Trembovetski wrote: > > Depending on what you want to recompile, you'll need to cd > to a particular directory and run gnumake from there. > > For awt/2d, the directories are > make/sun/awt > make/sun/xawt > Mostly the latter. > > Thanks, > Dmitri > > > Clemens Eisserer wrote: >> Hello, >> Is it possible to re-compile only certain parts of the JDK? >> I would like to only re-compile the native AWT part on Unix, >> because a >> whole "make" takes always several minutes :-/ >> Thank you in advance, lg Clemens From Kelly.Ohair at Sun.COM Fri May 9 16:58:44 2008 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Fri, 09 May 2008 09:58:44 -0700 Subject: Howto re-compile ony parts? In-Reply-To: <194f62550805090345r6e149996w757960c8a34a0f48@mail.gmail.com> References: <194f62550805090345r6e149996w757960c8a34a0f48@mail.gmail.com> Message-ID: <482482C4.8030702@sun.com> A common pattern people use during development (shell based) is to: 1. Either build the complete OpenJDK and save that as the import JDK or download a complete jdk7 to use as the import jdk. Point the env variable ALT_JDK_IMPORT_PATH at that jdk image. 2. Build the jdk area once: cd jdk/make && gnumake This populates jdk/build/* 3. Repeatedly edit sources and cd jdk/make/LOWERLEVEL && gnumake -OR- gnumake clean LOWERLEVEL could be java/awt or jpda/back or whatever Running jdk/build/*/bin/java should use the classes in the jdk/build/*/classes directory (no rt.jar or tools.jar). Those IDE savy people might instead swap step 3 with using a NetBeans project that is specific to some part of the jdk, like swing, etc. The various teams will need to tell you what the LOWERLEVEL directories are that you need to build. Historically this incremental or selective build can get into trouble, depends on the LOWERLEVEL you pick. But if you have problems let people know. -kto Clemens Eisserer wrote: > Hello, > > Is it possible to re-compile only certain parts of the JDK? > I would like to only re-compile the native AWT part on Unix, because a > whole "make" takes always several minutes :-/ > > Thank you in advance, lg Clemens From linuxhippy at gmail.com Sat May 10 16:15:38 2008 From: linuxhippy at gmail.com (Clemens Eisserer) Date: Sat, 10 May 2008 18:15:38 +0200 Subject: Howto re-compile ony parts? In-Reply-To: <482482C4.8030702@sun.com> References: <194f62550805090345r6e149996w757960c8a34a0f48@mail.gmail.com> <482482C4.8030702@sun.com> Message-ID: <194f62550805100915n1ac276bex9f8e256fb285ba40@mail.gmail.com> Hi, Thanks a lot for helping. It still does not work, this is what I did: 1.) build the entire OpenJDK including corba, ... 2.) cd jdk/make/sun/xawt 3.) export ALT_JDK_IMPORT_PATH=../../../../build/linux-i586/ 4.) make ARCH_DATA_MODEL=32 However after the X11-wrapper-classes are generated and compilation actually starts, I get tons of messages like: # Running javac: /home/ce/Programme/jdk1.7.0b25/bin/javac -J-XX:ThreadStackSize=768 -J-client -J-Xmx896m -J-Xms128m -J-XX:PermSize=32m -J-XX:MaxPermSize=160m -source 1.5 -target 5 -encoding ascii -Xbootclasspath:../../../build/linux-i586/classes -sourcepath ../../../build/linux-i586/gensrc:../../../src/solaris/classes:../../../src/share/classes -d ../../../build/linux-i586/classes @../../../build/linux-i586/tmp/sun/sun.awt.X11/xawt/.classes.list ../../../src/share/classes/java/nio/charset/Charset.java:28: cannot find symbol symbol : class ByteBuffer location: package java.nio import java.nio.ByteBuffer; ......... Any idea what could be wrong? For now its not such a big problem, because the till the full build reaches the files I work on takes only about ~2min after which I simply can abort the make process. 2.) I encountered another strange problem: I tried to add another native blit-method to X11PMBlitBgLoops.c, however the JVM refuses to resolv the additional native method. These are the steps I did: 1.) Add native method to X11PMBlitLoops.c: JNIEXPORT void JNICALL Java_sun_java2d_x11_X11PMBlitLoops_dummy (JNIEnv *env, jobject joSelf) { printf("Hallo vom Dummy :)" ); fflush(stdout); } 2.) Add method-"handle" to java-side: public native void dummy(); 3.) Clean existing object-file and shared libraries, re-compile using make, copy libawt/libmawt to an unchanged JDK, and running with Eclipse overriding XBootclass to Eclipse's compiled classes (this allows me to develop and run in eclipse). The strange thing is, if I modify an existing function like Java_sun_java2d_x11_X11PMBlitLoops_nativeBlit the changes reflect immediatly, so the code is compiled correctly and also loaded by the JVM. Also the dummy-method is in xawt/libmawt.so: 000245c0 l F .text 00000036 Java_sun_java2d_x11_X11PMBlitLoops_dummy However, when I try to call it from the java-side I still get: Exception in thread "AWT-EventQueue-0" java.lang.UnsatisfiedLinkError: sun.java2d.x11.X11PMBlitLoops.dummy()V at sun.java2d.x11.X11PMBlitLoops.dummy(Native Method) at sun.java2d.x11.X11PMBlitLoops.Blit(X11PMBlitLoops.java:150) The original problem I had was that I tried to create a new native function called nativeRenderBlit, just as a starting point to tinker on. The JVM always throws an UnsatisfiedLinkError, however if I rename nativeRenderBlit to nativeBlit which does already exist and rename the existing one to something else, everything works as expected (well at least my code gets called ;) ). Any idea whats going wrong here? I am totally puzzled :-/ Could the problem be that the JVM still somehow looks into rt.jar although bootclasspath is set to workspace/XRender/bin - and finds no definition of dummy() in the "old" X11PMBlitLoops contained in rt.jar? Thanks a lot, lg Clemens 2008/5/9 Kelly O'Hair : > > A common pattern people use during development (shell based) > is to: > > 1. Either build the complete OpenJDK and save that as the import JDK > or download a complete jdk7 to use as the import jdk. > Point the env variable ALT_JDK_IMPORT_PATH at that jdk image. > > 2. Build the jdk area once: > cd jdk/make && gnumake > This populates jdk/build/* > > 3. Repeatedly edit sources and > cd jdk/make/LOWERLEVEL && gnumake -OR- gnumake clean > LOWERLEVEL could be java/awt or jpda/back or whatever > Running jdk/build/*/bin/java should use the classes in the > jdk/build/*/classes directory (no rt.jar or tools.jar). > > Those IDE savy people might instead swap step 3 with using a NetBeans > project that is specific to some part of the jdk, like swing, etc. > > The various teams will need to tell you what the LOWERLEVEL directories > are that you need to build. > > Historically this incremental or selective build can get into trouble, > depends on the LOWERLEVEL you pick. But if you have problems let people > know. > > -kto > > Clemens Eisserer wrote: >> >> Hello, >> >> Is it possible to re-compile only certain parts of the JDK? >> I would like to only re-compile the native AWT part on Unix, because a >> whole "make" takes always several minutes :-/ >> >> Thank you in advance, lg Clemens > From Igor.Nekrestyanov at Sun.COM Sat May 10 16:47:14 2008 From: Igor.Nekrestyanov at Sun.COM (Igor Nekrestyanov) Date: Sat, 10 May 2008 20:47:14 +0400 Subject: Howto re-compile ony parts? In-Reply-To: <194f62550805100915n1ac276bex9f8e256fb285ba40@mail.gmail.com> References: <194f62550805090345r6e149996w757960c8a34a0f48@mail.gmail.com> <482482C4.8030702@sun.com> <194f62550805100915n1ac276bex9f8e256fb285ba40@mail.gmail.com> Message-ID: <4825D192.2020702@sun.com> Not sure why you want to override ALT_JDK_IMPORT_PATH. I do not think this is needed but i am not sure if it can do any harm. I think you may need to set ALT_OUTPUTDIR to $YOUR_OPENJDK_WS/build/linux-i586. Otherwise partial make runs from jdk subdirectory will actually use $YOUR_OPENJDK_WS/jdk/build/linux-i586 and obviously full build is not there. I have not looked into unresolved function issue in detail. Just a wild guess - have you added new function to mapfile in the xawt make directory? -igor Clemens Eisserer wrote: > Hi, > > Thanks a lot for helping. > > It still does not work, this is what I did: > 1.) build the entire OpenJDK including corba, ... > 2.) cd jdk/make/sun/xawt > 3.) export ALT_JDK_IMPORT_PATH=../../../../build/linux-i586/ > 4.) make ARCH_DATA_MODEL=32 > > However after the X11-wrapper-classes are generated and compilation > actually starts, I get tons of messages like: > # Running javac: > /home/ce/Programme/jdk1.7.0b25/bin/javac -J-XX:ThreadStackSize=768 > -J-client -J-Xmx896m -J-Xms128m -J-XX:PermSize=32m > -J-XX:MaxPermSize=160m -source 1.5 -target 5 -encoding ascii > -Xbootclasspath:../../../build/linux-i586/classes -sourcepath > ../../../build/linux-i586/gensrc:../../../src/solaris/classes:../../../src/share/classes > -d ../../../build/linux-i586/classes > @../../../build/linux-i586/tmp/sun/sun.awt.X11/xawt/.classes.list > ../../../src/share/classes/java/nio/charset/Charset.java:28: cannot find symbol > symbol : class ByteBuffer > location: package java.nio > import java.nio.ByteBuffer; > ......... > > Any idea what could be wrong? For now its not such a big problem, > because the till the full build reaches the files I work on takes only > about ~2min after which I simply can abort the make process. > > 2.) I encountered another strange problem: > I tried to add another native blit-method to X11PMBlitBgLoops.c, > however the JVM refuses to resolv the additional native method. > > These are the steps I did: > 1.) Add native method to X11PMBlitLoops.c: > > JNIEXPORT void JNICALL > Java_sun_java2d_x11_X11PMBlitLoops_dummy > (JNIEnv *env, jobject joSelf) > { > printf("Hallo vom Dummy :)" ); > fflush(stdout); > } > > 2.) Add method-"handle" to java-side: > public native void dummy(); > > 3.) Clean existing object-file and shared libraries, re-compile using > make, copy libawt/libmawt to an unchanged JDK, and running with > Eclipse overriding XBootclass to Eclipse's compiled classes (this > allows me to develop and run in eclipse). > > The strange thing is, if I modify an existing function like > Java_sun_java2d_x11_X11PMBlitLoops_nativeBlit the changes reflect > immediatly, so the code is compiled correctly and also loaded by the > JVM. > Also the dummy-method is in xawt/libmawt.so: > 000245c0 l F .text 00000036 > Java_sun_java2d_x11_X11PMBlitLoops_dummy > > However, when I try to call it from the java-side I still get: > Exception in thread "AWT-EventQueue-0" java.lang.UnsatisfiedLinkError: > sun.java2d.x11.X11PMBlitLoops.dummy()V > at sun.java2d.x11.X11PMBlitLoops.dummy(Native Method) > at sun.java2d.x11.X11PMBlitLoops.Blit(X11PMBlitLoops.java:150) > > The original problem I had was that I tried to create a new native > function called nativeRenderBlit, just as a starting point to tinker > on. > The JVM always throws an UnsatisfiedLinkError, however if I rename > nativeRenderBlit to nativeBlit which does already exist and rename the > existing one to something else, everything works as expected (well at > least my code gets called ;) ). > > Any idea whats going wrong here? I am totally puzzled :-/ > > Could the problem be that the JVM still somehow looks into rt.jar > although bootclasspath is set to workspace/XRender/bin - and finds no > definition of dummy() in the "old" X11PMBlitLoops contained in rt.jar? > > Thanks a lot, lg Clemens > > 2008/5/9 Kelly O'Hair : > >> A common pattern people use during development (shell based) >> is to: >> >> 1. Either build the complete OpenJDK and save that as the import JDK >> or download a complete jdk7 to use as the import jdk. >> Point the env variable ALT_JDK_IMPORT_PATH at that jdk image. >> >> 2. Build the jdk area once: >> cd jdk/make && gnumake >> This populates jdk/build/* >> >> 3. Repeatedly edit sources and >> cd jdk/make/LOWERLEVEL && gnumake -OR- gnumake clean >> LOWERLEVEL could be java/awt or jpda/back or whatever >> Running jdk/build/*/bin/java should use the classes in the >> jdk/build/*/classes directory (no rt.jar or tools.jar). >> >> Those IDE savy people might instead swap step 3 with using a NetBeans >> project that is specific to some part of the jdk, like swing, etc. >> >> The various teams will need to tell you what the LOWERLEVEL directories >> are that you need to build. >> >> Historically this incremental or selective build can get into trouble, >> depends on the LOWERLEVEL you pick. But if you have problems let people >> know. >> >> -kto >> >> Clemens Eisserer wrote: >> >>> Hello, >>> >>> Is it possible to re-compile only certain parts of the JDK? >>> I would like to only re-compile the native AWT part on Unix, because a >>> whole "make" takes always several minutes :-/ >>> >>> Thank you in advance, lg Clemens >>> From martinrb at google.com Sat May 10 16:50:01 2008 From: martinrb at google.com (Martin Buchholz) Date: Sat, 10 May 2008 09:50:01 -0700 Subject: Howto re-compile ony parts? In-Reply-To: <194f62550805100915n1ac276bex9f8e256fb285ba40@mail.gmail.com> References: <194f62550805090345r6e149996w757960c8a34a0f48@mail.gmail.com> <482482C4.8030702@sun.com> <194f62550805100915n1ac276bex9f8e256fb285ba40@mail.gmail.com> Message-ID: <1ccfd1c10805100950g948fc02ve8d88c28b6c989d8@mail.gmail.com> Unfortunately, incremental builds by running make in subdirectories have historically been quite unreliable, and it has never been highest priority to fix them. Developers often do (at least in the jdk repository) - try incremental build; it might work... - else back off to rebuilding everything; cd jdk/make; make clobber all You could try to fix all of the subdirectory makefiles, but that's an enormous job. For bonus points, you could try to fix the architecture of the recursive makes themselves using the ideas in "Recursive Make Considered Harmful" http://miller.emu.id.au/pmiller/books/rmch/ Martin On Sat, May 10, 2008 at 9:15 AM, Clemens Eisserer wrote: > Hi, > > Thanks a lot for helping. > > It still does not work, this is what I did: > 1.) build the entire OpenJDK including corba, ... > 2.) cd jdk/make/sun/xawt > 3.) export ALT_JDK_IMPORT_PATH=../../../../build/linux-i586/ > 4.) make ARCH_DATA_MODEL=32 From aph at redhat.com Sat May 10 16:57:35 2008 From: aph at redhat.com (Andrew Haley) Date: Sat, 10 May 2008 17:57:35 +0100 Subject: Howto re-compile ony parts? In-Reply-To: <1ccfd1c10805100950g948fc02ve8d88c28b6c989d8@mail.gmail.com> References: <194f62550805090345r6e149996w757960c8a34a0f48@mail.gmail.com> <482482C4.8030702@sun.com> <194f62550805100915n1ac276bex9f8e256fb285ba40@mail.gmail.com> <1ccfd1c10805100950g948fc02ve8d88c28b6c989d8@mail.gmail.com> Message-ID: <4825D3FF.2020401@redhat.com> Martin Buchholz wrote: > Unfortunately, incremental builds by running make in subdirectories > have historically been quite unreliable, and it has never been highest priority > to fix them. Developers often do (at least in the jdk repository) > - try incremental build; it might work... > - else back off to rebuilding everything; > cd jdk/make; make clobber all > > You could try to fix all of the subdirectory makefiles, but that's an > enormous job. > For bonus points, you could try to fix the architecture of the > recursive makes themselves > using the ideas in "Recursive Make Considered Harmful" > http://miller.emu.id.au/pmiller/books/rmch/ Mmm. Surely if anyone is going to hack on the makefiles the first thing to do is to fix the dependencies so that "make -j" works properly. Andrew. From linuxhippy at gmail.com Sat May 10 17:05:50 2008 From: linuxhippy at gmail.com (Clemens Eisserer) Date: Sat, 10 May 2008 19:05:50 +0200 Subject: Howto re-compile ony parts? In-Reply-To: <4825D192.2020702@sun.com> References: <194f62550805090345r6e149996w757960c8a34a0f48@mail.gmail.com> <482482C4.8030702@sun.com> <194f62550805100915n1ac276bex9f8e256fb285ba40@mail.gmail.com> <4825D192.2020702@sun.com> Message-ID: <194f62550805101005m32cfad2l517213174746ab6e@mail.gmail.com> Hi, > Not sure why you want to override ALT_JDK_IMPORT_PATH. I do not think this > is needed > but i am not sure if it can do any harm. > > I think you may need to set ALT_OUTPUTDIR to > $YOUR_OPENJDK_WS/build/linux-i586. > Otherwise partial make runs from jdk subdirectory will actually use > $YOUR_OPENJDK_WS/jdk/build/linux-i586 and obviously full build is not there. Thanks for the hint. It seems everything compiles fine now, however when it comes to linking ld complains it cannot find "-lawt": build/linux-i586/lib/i386 -Wl,-soname=libmawt.so -lXtst -lXi -ljava -L/home/ce/OpenJDK7/build/linux-i586/lib/i386/server -ljvm -lc /usr/bin/ld: cannot find -lawt collect2: ld gab 1 als Ende-Status zur?ck make: *** [/home/ce/OpenJDK7/build/linux-i586/lib/i386/xawt/libmawt.so] Fehler 1 However getting this to work is really low priority ;) > I have not looked into unresolved function issue in detail. Just a wild > guess - have you added new function to > mapfile in the xawt make directory? Thank you many many times for this, I don't know how long further I would have searched without this information. What is this file good for and how is it used during the build? Thanks a lot, lg Clemens From Kelly.Ohair at Sun.COM Sat May 10 18:43:41 2008 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Sat, 10 May 2008 11:43:41 -0700 Subject: Howto re-compile ony parts? In-Reply-To: <4825D3FF.2020401@redhat.com> References: <194f62550805090345r6e149996w757960c8a34a0f48@mail.gmail.com> <482482C4.8030702@sun.com> <194f62550805100915n1ac276bex9f8e256fb285ba40@mail.gmail.com> <1ccfd1c10805100950g948fc02ve8d88c28b6c989d8@mail.gmail.com> <4825D3FF.2020401@redhat.com> Message-ID: <4825ECDD.2080801@sun.com> We already use 'make -j' when building the .o files, and the dependencies should be ok for the .o files. So for native compilations I don't think we have a problem. But with Java building, it's not clear 'make -j' is the answer or will even work. First, a .java can create multiple .class files, and second all the javac builds read and write to the classes directory. If a bunch of javac compilations were done in parallel I don't think it would be a pretty sight. In general, make and java compilation has always been complicated or non-robust to say the least. Most people don't realize that compiling an explicit list of sources can sometimes compile more than that, and that often the output directory is also used in the classpath as an input directory. You might think this is a bad idea, but it's done, has been for some time. There are multiple possibilities for improving the javac compile time, but doing it via make is not on my list. We would like to look into javamake (soon to be open sourced) http://www.experimentalstuff.com/Technologies/JavaMake/index.html which does the right thing in terms of incremental builds. It could be used with ant, or run directly from the makefiles. And the javac team may be looking into actually paralizing the internals of javac soon, which would help without changing any build procedures. -kto Andrew Haley wrote: > Martin Buchholz wrote: >> Unfortunately, incremental builds by running make in subdirectories >> have historically been quite unreliable, and it has never been highest priority >> to fix them. Developers often do (at least in the jdk repository) >> - try incremental build; it might work... >> - else back off to rebuilding everything; >> cd jdk/make; make clobber all >> >> You could try to fix all of the subdirectory makefiles, but that's an >> enormous job. >> For bonus points, you could try to fix the architecture of the >> recursive makes themselves >> using the ideas in "Recursive Make Considered Harmful" >> http://miller.emu.id.au/pmiller/books/rmch/ > > Mmm. Surely if anyone is going to hack on the makefiles the first thing > to do is to fix the dependencies so that "make -j" works properly. > > Andrew. From Jonathan.Gibbons at Sun.COM Sat May 10 21:17:12 2008 From: Jonathan.Gibbons at Sun.COM (Jonathan Gibbons) Date: Sat, 10 May 2008 14:17:12 -0700 Subject: Howto re-compile ony parts? In-Reply-To: <4825ECDD.2080801@sun.com> References: <194f62550805090345r6e149996w757960c8a34a0f48@mail.gmail.com> <482482C4.8030702@sun.com> <194f62550805100915n1ac276bex9f8e256fb285ba40@mail.gmail.com> <1ccfd1c10805100950g948fc02ve8d88c28b6c989d8@mail.gmail.com> <4825D3FF.2020401@redhat.com> <4825ECDD.2080801@sun.com> Message-ID: <3084C8A8-63E2-48E5-8F73-B2F8BDBB1C31@sun.com> Kelly, As well as looking into parallelizing (parts of) javac, javac can also provide all the dependency info you need if you know how to get it. (Hint: this means writing code.) I'm hoping to write up a description of how to do this sooner rather than later. With the right code, you could make a very simple wrapper for javac that would accurately compile the correct subset of files that needed to be compiled. -- Jon On May 10, 2008, at 11:43 AM, Kelly O'Hair wrote: > We already use 'make -j' when building the .o files, and the > dependencies > should be ok for the .o files. So for native compilations I don't > think we have a problem. > > But with Java building, it's not clear 'make -j' is the answer or will > even work. > First, a .java can create multiple .class files, and second all the > javac builds read and write to the classes directory. > If a bunch of javac compilations were done in parallel I don't think > it would be a pretty sight. In general, make and java compilation > has always been complicated or non-robust to say the least. > > Most people don't realize that compiling an explicit list of sources > can sometimes compile more than that, and that often the output > directory > is also used in the classpath as an input directory. > You might think this is a bad idea, but it's done, has been for some > time. > > There are multiple possibilities for improving the javac compile time, > but doing it via make is not on my list. > We would like to look into javamake (soon to be open sourced) > http://www.experimentalstuff.com/Technologies/JavaMake/index.html > which does the right thing in terms of incremental builds. > It could be used with ant, or run directly from the makefiles. > > And the javac team may be looking into actually paralizing the > internals > of javac soon, which would help without changing any build procedures. > > -kto > > Andrew Haley wrote: >> Martin Buchholz wrote: >>> Unfortunately, incremental builds by running make in subdirectories >>> have historically been quite unreliable, and it has never been >>> highest priority >>> to fix them. Developers often do (at least in the jdk repository) >>> - try incremental build; it might work... >>> - else back off to rebuilding everything; >>> cd jdk/make; make clobber all >>> >>> You could try to fix all of the subdirectory makefiles, but that's >>> an >>> enormous job. >>> For bonus points, you could try to fix the architecture of the >>> recursive makes themselves >>> using the ideas in "Recursive Make Considered Harmful" >>> http://miller.emu.id.au/pmiller/books/rmch/ >> Mmm. Surely if anyone is going to hack on the makefiles the first >> thing >> to do is to fix the dependencies so that "make -j" works properly. >> Andrew. From Igor.Nekrestyanov at Sun.COM Sun May 11 05:49:27 2008 From: Igor.Nekrestyanov at Sun.COM (Igor Nekrestyanov) Date: Sun, 11 May 2008 09:49:27 +0400 Subject: Howto re-compile ony parts? In-Reply-To: <194f62550805101005m32cfad2l517213174746ab6e@mail.gmail.com> References: <194f62550805090345r6e149996w757960c8a34a0f48@mail.gmail.com> <482482C4.8030702@sun.com> <194f62550805100915n1ac276bex9f8e256fb285ba40@mail.gmail.com> <4825D192.2020702@sun.com> <194f62550805101005m32cfad2l517213174746ab6e@mail.gmail.com> Message-ID: <482688E7.80907@sun.com> >> Not sure why you want to override ALT_JDK_IMPORT_PATH. I do not think this >> is needed >> but i am not sure if it can do any harm. >> >> I think you may need to set ALT_OUTPUTDIR to >> $YOUR_OPENJDK_WS/build/linux-i586. >> Otherwise partial make runs from jdk subdirectory will actually use >> $YOUR_OPENJDK_WS/jdk/build/linux-i586 and obviously full build is not there. >> > Thanks for the hint. > It seems everything compiles fine now, however when it comes to > linking ld complains it cannot find "-lawt": > > build/linux-i586/lib/i386 -Wl,-soname=libmawt.so -lXtst -lXi -ljava > -L/home/ce/OpenJDK7/build/linux-i586/lib/i386/server -ljvm -lc > /usr/bin/ld: cannot find -lawt > collect2: ld gab 1 als Ende-Status zur?ck > make: *** [/home/ce/OpenJDK7/build/linux-i586/lib/i386/xawt/libmawt.so] Fehler 1 > > However getting this to work is really low priority ;) > Command you pasted is truncated and it is hard to tell what is going on here. Send me full log for incremental build and i'll check if i have any further ideas. BTW, is libawt.so present in your build tree? You may also try to run make from make/java/awt but i am not sure if it will help. >> I have not looked into unresolved function issue in detail. Just a wild >> guess - have you added new function to >> mapfile in the xawt make directory? >> > Thank you many many times for this, I don't know how long further I > would have searched without this information. > What is this file good for and how is it used during the build? > I believe mapfiles are used to defines set of methods to be exported from shared library. Perhaps, you may grep build log file for mapfile name to see how this is done exactly (do not have linux build here and have not checked log myself). My understanding of why we use this is following. Symbol tables for all methods from the library are large and explicit control on set of exported methods is workaround to reduce library file size (and size has impact on memory footprint, download footprint, startup time, etc.). -igor > Thanks a lot, lg Clemens > From Phil.Race at Sun.COM Sun May 11 15:21:31 2008 From: Phil.Race at Sun.COM (Phil Race) Date: Sun, 11 May 2008 08:21:31 -0700 Subject: Howto re-compile ony parts? In-Reply-To: <482688E7.80907@sun.com> References: <194f62550805090345r6e149996w757960c8a34a0f48@mail.gmail.com> <482482C4.8030702@sun.com> <194f62550805100915n1ac276bex9f8e256fb285ba40@mail.gmail.com> <4825D192.2020702@sun.com> <194f62550805101005m32cfad2l517213174746ab6e@mail.gmail.com> <482688E7.80907@sun.com> Message-ID: <48270EFB.4060705@sun.com> Igor Nekrestyanov wrote: >>> >> Thank you many many times for this, I don't know how long further I >> would have searched without this information. >> What is this file good for and how is it used during the build? >> > I believe mapfiles are used to defines set of methods to be exported > from shared library. > Perhaps, you may grep build log file for mapfile name to see how this > is done exactly > (do not have linux build here and have not checked log myself). > > My understanding of why we use this is following. > Symbol tables for all methods from the library are large and explicit > control on set of exported methods > is workaround to reduce library file size (and size has impact on > memory footprint, download footprint, startup time, etc.). > I don't know how much it helps any of these but the principal reason has always been to avoid potential name space clashes. For the most part the only symbols that need to be exported are the names of JNI methods. ie the entry points from Java code into native. -phil. From Igor.Nekrestyanov at Sun.COM Sun May 11 15:44:47 2008 From: Igor.Nekrestyanov at Sun.COM (Igor Nekrestyanov) Date: Sun, 11 May 2008 19:44:47 +0400 Subject: Howto re-compile ony parts? In-Reply-To: <48270EFB.4060705@sun.com> References: <194f62550805090345r6e149996w757960c8a34a0f48@mail.gmail.com> <482482C4.8030702@sun.com> <194f62550805100915n1ac276bex9f8e256fb285ba40@mail.gmail.com> <4825D192.2020702@sun.com> <194f62550805101005m32cfad2l517213174746ab6e@mail.gmail.com> <482688E7.80907@sun.com> <48270EFB.4060705@sun.com> Message-ID: <4827146F.8070802@sun.com> Thanks Phil! I just found similar explanation in the jdk\make\common\Makefile-vers.gmk # # Makefile for linking with mapfiles. # # NOTE: Not using a mapfile will expose all your extern functions and # extern data symbols as part of your interface, so unless your # extern names are safe from being mistaken as names from other # libraries, you better use a mapfile, or use a unique naming # convention on all your extern symbols. # # The mapfile will establish versioning by defining the exported interface. # # The mapfile can also force certain .o files or elf sections into the # the different segments of the resulting library/program image. # # The macro FILES_m can contain any number of mapfiles. # However, it seems to be used on Linux/Solaris only (everything inside is under ifder solaris/linux) and this puzzle me a bit. So, it seems if name clashing is primary reason we should be protecting from this on Windows too. -igor Phil Race wrote: > Igor Nekrestyanov wrote: >>>> >>> Thank you many many times for this, I don't know how long further I >>> would have searched without this information. >>> What is this file good for and how is it used during the build? >>> >> I believe mapfiles are used to defines set of methods to be exported >> from shared library. >> Perhaps, you may grep build log file for mapfile name to see how this >> is done exactly >> (do not have linux build here and have not checked log myself). >> >> My understanding of why we use this is following. >> Symbol tables for all methods from the library are large and explicit >> control on set of exported methods >> is workaround to reduce library file size (and size has impact on >> memory footprint, download footprint, startup time, etc.). >> > I don't know how much it helps any of these but the principal reason > has always been to avoid > potential name space clashes. For the most part the only symbols that > need to be exported are > the names of JNI methods. ie the entry points from Java code into native. > > -phil. > From Phil.Race at Sun.COM Sun May 11 15:58:45 2008 From: Phil.Race at Sun.COM (Phil Race) Date: Sun, 11 May 2008 08:58:45 -0700 Subject: Howto re-compile ony parts? In-Reply-To: <4827146F.8070802@sun.com> References: <194f62550805090345r6e149996w757960c8a34a0f48@mail.gmail.com> <482482C4.8030702@sun.com> <194f62550805100915n1ac276bex9f8e256fb285ba40@mail.gmail.com> <4825D192.2020702@sun.com> <194f62550805101005m32cfad2l517213174746ab6e@mail.gmail.com> <482688E7.80907@sun.com> <48270EFB.4060705@sun.com> <4827146F.8070802@sun.com> Message-ID: <482717B5.9090601@sun.com> Igor Nekrestyanov wrote: > Thanks Phil! > > I just found similar explanation in the jdk\make\common\Makefile-vers.gmk > .... > However, it seems to be used on Linux/Solaris only (everything inside > is under ifder solaris/linux) and this puzzle me a bit. > So, it seems if name clashing is primary reason we should be > protecting from this on Windows too. > > - I believe its the default behaviour on windows to not export symbols. So this isn't needed and the magic "JNIEXPORT JNICALL" at the top of each of the JNI fn declarations expands into what is needed to force the export : jni_md.h:#define JNIEXPORT __declspec(dllexport) -phil. From Kelly.Ohair at Sun.COM Sun May 11 17:21:52 2008 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Sun, 11 May 2008 10:21:52 -0700 Subject: Howto re-compile ony parts? In-Reply-To: <482717B5.9090601@sun.com> References: <194f62550805090345r6e149996w757960c8a34a0f48@mail.gmail.com> <482482C4.8030702@sun.com> <194f62550805100915n1ac276bex9f8e256fb285ba40@mail.gmail.com> <4825D192.2020702@sun.com> <194f62550805101005m32cfad2l517213174746ab6e@mail.gmail.com> <482688E7.80907@sun.com> <48270EFB.4060705@sun.com> <4827146F.8070802@sun.com> <482717B5.9090601@sun.com> Message-ID: <48272B30.4070808@sun.com> Yes, Windows defaults it's DLL symbols to be private, you must explicitly 'export' them with statements in the source, or using the command line 'export' options. With Solaris/Linux and the Elf binary file format, there are two symbol tables in the .so library, the normal symbol table section .symtab and the dynamic symbol table .dynsym used at runtime. By default all extern symbols or GLOBAL symbols will be in both, opening up the door for anyone to find or use any symbol. The mapfile manipulates what goes into what symbol table and also can control what goes into other runtime Elf sections of a .so or a.out file. On Solaris, mapfiles are required to limit the list of extern symbols to just those that are publicly documented/supported and also 'version' the library. Linux may call these mapfiles 'version scripts'. Note that a .symtab is needed at runtime, and if you 'strip' your .so file the .symtab is removed and your .so is much smaller, only the .dynsym sections is needed at runtime. However, not having a .symtab makes debugging and stack traces pretty useless. -kto Phil Race wrote: > Igor Nekrestyanov wrote: >> Thanks Phil! >> >> I just found similar explanation in the jdk\make\common\Makefile-vers.gmk >> .... > >> However, it seems to be used on Linux/Solaris only (everything inside >> is under ifder solaris/linux) and this puzzle me a bit. >> So, it seems if name clashing is primary reason we should be >> protecting from this on Windows too. >> >> - > I believe its the default behaviour on windows to not export symbols. So > this isn't needed and the > magic "JNIEXPORT JNICALL" at the top of each of the JNI fn > declarations expands > into what is needed to force the export : > jni_md.h:#define JNIEXPORT __declspec(dllexport) > > -phil. > From Kelly.Ohair at Sun.COM Sun May 11 17:24:49 2008 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Sun, 11 May 2008 10:24:49 -0700 Subject: Howto re-compile ony parts? In-Reply-To: <48272B30.4070808@sun.com> References: <194f62550805090345r6e149996w757960c8a34a0f48@mail.gmail.com> <482482C4.8030702@sun.com> <194f62550805100915n1ac276bex9f8e256fb285ba40@mail.gmail.com> <4825D192.2020702@sun.com> <194f62550805101005m32cfad2l517213174746ab6e@mail.gmail.com> <482688E7.80907@sun.com> <48270EFB.4060705@sun.com> <4827146F.8070802@sun.com> <482717B5.9090601@sun.com> <48272B30.4070808@sun.com> Message-ID: <48272BE1.9010604@sun.com> Kelly O'Hair wrote: > Yes, Windows defaults it's DLL symbols to be private, you must explicitly > 'export' them with statements in the source, or using the command line > 'export' options. > > With Solaris/Linux and the Elf binary file format, there are two symbol > tables in the .so library, the normal symbol table section .symtab and the > dynamic symbol table .dynsym used at runtime. By default all extern > symbols or > GLOBAL symbols will be in both, opening up the door for anyone to find or > use any symbol. The mapfile manipulates what goes into what symbol table > and also can control what goes into other runtime Elf sections of a .so > or a.out file. On Solaris, mapfiles are required to limit the list of > extern symbols to just those that are publicly documented/supported and > also 'version' the library. > Linux may call these mapfiles 'version scripts'. > > Note that a .symtab is needed at runtime, and if you 'strip' your .so file ^^^^^^^ NOT needed :^{ -kto > the .symtab is removed and your .so is much smaller, only the .dynsym > sections is needed at runtime. However, not having a .symtab makes > debugging > and stack traces pretty useless. > > -kto > > > Phil Race wrote: >> Igor Nekrestyanov wrote: >>> Thanks Phil! >>> >>> I just found similar explanation in the >>> jdk\make\common\Makefile-vers.gmk >>> .... >> >>> However, it seems to be used on Linux/Solaris only (everything inside >>> is under ifder solaris/linux) and this puzzle me a bit. >>> So, it seems if name clashing is primary reason we should be >>> protecting from this on Windows too. >>> >>> - >> I believe its the default behaviour on windows to not export symbols. >> So this isn't needed and the >> magic "JNIEXPORT JNICALL" at the top of each of the JNI fn >> declarations expands >> into what is needed to force the export : >> jni_md.h:#define JNIEXPORT __declspec(dllexport) >> >> -phil. >> From aph at redhat.com Mon May 12 11:10:37 2008 From: aph at redhat.com (Andrew Haley) Date: Mon, 12 May 2008 12:10:37 +0100 Subject: Howto re-compile ony parts? In-Reply-To: <4825ECDD.2080801@sun.com> References: <194f62550805090345r6e149996w757960c8a34a0f48@mail.gmail.com> <482482C4.8030702@sun.com> <194f62550805100915n1ac276bex9f8e256fb285ba40@mail.gmail.com> <1ccfd1c10805100950g948fc02ve8d88c28b6c989d8@mail.gmail.com> <4825D3FF.2020401@redhat.com> <4825ECDD.2080801@sun.com> Message-ID: <482825AD.8020009@redhat.com> Kelly O'Hair wrote: > We already use 'make -j' when building the .o files, and the dependencies > should be ok for the .o files. So for native compilations I don't > think we have a problem. That's interesting; it certainly didn't used to work. I'll try again. > But with Java building, it's not clear 'make -j' is the answer or will > even work. > First, a .java can create multiple .class files, and second all the > javac builds read and write to the classes directory. > If a bunch of javac compilations were done in parallel I don't think > it would be a pretty sight. In general, make and java compilation > has always been complicated or non-robust to say the least. Yes, I gathered that. > Most people don't realize that compiling an explicit list of sources > can sometimes compile more than that, and that often the output directory > is also used in the classpath as an input directory. > You might think this is a bad idea, but it's done, has been for some time. It's a bad idea. :-) > There are multiple possibilities for improving the javac compile time, > but doing it via make is not on my list. Fair enough. One thing that would be of huge benefit is the ability to distribute compilation, a la distcc. Please don't do anything that might restrict building to a single box. Andrew. From gnu_andrew at member.fsf.org Mon May 12 11:56:47 2008 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Mon, 12 May 2008 12:56:47 +0100 Subject: Howto re-compile ony parts? In-Reply-To: <482825AD.8020009@redhat.com> References: <194f62550805090345r6e149996w757960c8a34a0f48@mail.gmail.com> <482482C4.8030702@sun.com> <194f62550805100915n1ac276bex9f8e256fb285ba40@mail.gmail.com> <1ccfd1c10805100950g948fc02ve8d88c28b6c989d8@mail.gmail.com> <4825D3FF.2020401@redhat.com> <4825ECDD.2080801@sun.com> <482825AD.8020009@redhat.com> Message-ID: <17c6771e0805120456g20041be5nf0913563d9956cf@mail.gmail.com> 2008/5/12 Andrew Haley : > Kelly O'Hair wrote: > > We already use 'make -j' when building the .o files, and the dependencies > > should be ok for the .o files. So for native compilations I don't > > think we have a problem. > > That's interesting; it certainly didn't used to work. I'll try again. > It didn't work with OpenJDK 6 this time last month. That's why I added support for ALT_PARALLEL_COMPILE_JOBS and HOTSPOT_BUILD_JOBS. -- Andrew :-) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From Kelly.Ohair at Sun.COM Mon May 12 15:53:51 2008 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Mon, 12 May 2008 08:53:51 -0700 Subject: Howto re-compile ony parts? In-Reply-To: <17c6771e0805120456g20041be5nf0913563d9956cf@mail.gmail.com> References: <194f62550805090345r6e149996w757960c8a34a0f48@mail.gmail.com> <482482C4.8030702@sun.com> <194f62550805100915n1ac276bex9f8e256fb285ba40@mail.gmail.com> <1ccfd1c10805100950g948fc02ve8d88c28b6c989d8@mail.gmail.com> <4825D3FF.2020401@redhat.com> <4825ECDD.2080801@sun.com> <482825AD.8020009@redhat.com> <17c6771e0805120456g20041be5nf0913563d9956cf@mail.gmail.com> Message-ID: <4828680F.8040307@sun.com> The ALT_PARALLEL_COMPILE_JOBS=N is just for the native library builds in the jdk repository, and it effectively just does a 'make -j N *.o' which is safe, worked pretty well, and sped things up. But it is only done on a per library basis. The HOTSPOT_BUILD_JOBS=N is for hotspot only and I don't have many details on this one, it's been around for a long time. As I understand it, this is more of a top level 'make -j N'. FYI... The hotspot builds are much more cpu intensive than the jdk builds, and hotspot builds behave more like a traditional C++ project. But the jdk builds tend to be more disk intensive, many more files involved and more bits created during a build. When building the jdk, using local disk space or even /tmp will make builds considerably faster. -kto Andrew John Hughes wrote: > 2008/5/12 Andrew Haley : >> Kelly O'Hair wrote: >> > We already use 'make -j' when building the .o files, and the dependencies >> > should be ok for the .o files. So for native compilations I don't >> > think we have a problem. >> >> That's interesting; it certainly didn't used to work. I'll try again. >> > > It didn't work with OpenJDK 6 this time last month. That's why I > added support for ALT_PARALLEL_COMPILE_JOBS and > HOTSPOT_BUILD_JOBS. > From Kelly.Ohair at Sun.COM Mon May 12 16:00:35 2008 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Mon, 12 May 2008 09:00:35 -0700 Subject: Howto re-compile ony parts? In-Reply-To: <482825AD.8020009@redhat.com> References: <194f62550805090345r6e149996w757960c8a34a0f48@mail.gmail.com> <482482C4.8030702@sun.com> <194f62550805100915n1ac276bex9f8e256fb285ba40@mail.gmail.com> <1ccfd1c10805100950g948fc02ve8d88c28b6c989d8@mail.gmail.com> <4825D3FF.2020401@redhat.com> <4825ECDD.2080801@sun.com> <482825AD.8020009@redhat.com> Message-ID: <482869A3.6060705@sun.com> Andrew Haley wrote: > Kelly O'Hair wrote: ... >> There are multiple possibilities for improving the javac compile time, >> but doing it via make is not on my list. > > Fair enough. One thing that would be of huge benefit is the ability to > distribute compilation, a la distcc. Please don't do anything that might > restrict building to a single box. I don't think I would ever do anything to restrict that, but I'm also not convinced that it would help the jdk building, which is so disk heavy. The speed of the disk is everything to a jdk build, and distributed usually means slower disk access. Again, I'd never rule it out, but some little voice in my head is telling me that it's not a CPU resource issue as much as a big disk bits dance. :^( -kto From John.Rose at Sun.COM Tue May 13 04:49:57 2008 From: John.Rose at Sun.COM (John Rose) Date: Mon, 12 May 2008 21:49:57 -0700 Subject: Howto re-compile ony parts? In-Reply-To: <4828680F.8040307@sun.com> References: <194f62550805090345r6e149996w757960c8a34a0f48@mail.gmail.com> <482482C4.8030702@sun.com> <194f62550805100915n1ac276bex9f8e256fb285ba40@mail.gmail.com> <1ccfd1c10805100950g948fc02ve8d88c28b6c989d8@mail.gmail.com> <4825D3FF.2020401@redhat.com> <4825ECDD.2080801@sun.com> <482825AD.8020009@redhat.com> <17c6771e0805120456g20041be5nf0913563d9956cf@mail.gmail.com> <4828680F.8040307@sun.com> Message-ID: On May 12, 2008, at 8:53 AM, Kelly O'Hair wrote: > The HOTSPOT_BUILD_JOBS=N is for hotspot only and I don't have many > details > on this one, it's been around for a long time. As I understand it, > this is more of a top level 'make -j N'. Yes. It is the environmental input to adjust-mflags.sh ; see the comments in that file. -- John -------------- next part -------------- An HTML attachment was scrubbed... URL: From ted at tedneward.com Tue May 13 17:25:12 2008 From: ted at tedneward.com (Ted Neward) Date: Tue, 13 May 2008 10:25:12 -0700 Subject: FW: ATL headers and libraries? Message-ID: <049501c8b51e$4ed61b40$ec8251c0$@com> Kelly, et al? Should we just wait with the attempted port until this (see below) happens? Or do we want to try and actively remove the dependencies on ATL/MFC from the Hotspot code? Ted Neward Java, .NET, XML Services Consulting, Teaching, Speaking, Writing HYPERLINK "http://www.tedneward.com"http://www.tedneward.com From: Herb Sutter [mailto:hsutter at microsoft.com] Sent: Tuesday, May 13, 2008 4:08 AM To: Ted Neward Subject: RE: ATL headers and libraries? Unfortunately, no, there is no way to get to ATL and/or MFC without buying VS Std/Pro/etc. (of course, you can get those through your MSDN subscription, etc.) For the future, though, the plan is to ship both ATL and MFC (x86, I believe) in VC++ Express at some point. Herb From: Ted Neward [mailto:ted at tedneward.com] Sent: Monday, May 12, 2008 12:23 PM To: Herb Sutter Subject: ATL headers and libraries? Can you tell me (or put me in touch with somebody who can) if it?s possible to get a hold of the ATL and/or MFC headers and libraries without buying Visual Studio Standard/Professional/Enterprise/etc? I have a client who?s looking to see if they can use just VC++ Express to maintain some code that uses ATL and MFC. Ted Neward Java, .NET, XML Services Consulting, Teaching, Speaking, Writing HYPERLINK "http://www.tedneward.com"http://www.tedneward.com No virus found in this outgoing message. Checked by AVG. Version: 7.5.524 / Virus Database: 269.23.15/1426 - Release Date: 5/10/2008 11:12 AM No virus found in this incoming message. Checked by AVG. Version: 7.5.524 / Virus Database: 269.23.15/1426 - Release Date: 5/10/2008 11:12 AM No virus found in this outgoing message. Checked by AVG. Version: 7.5.524 / Virus Database: 269.23.16/1430 - Release Date: 5/13/2008 7:31 AM -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kelly.Ohair at Sun.COM Tue May 13 18:23:43 2008 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Tue, 13 May 2008 11:23:43 -0700 Subject: FW: ATL headers and libraries? In-Reply-To: <049501c8b51e$4ed61b40$ec8251c0$@com> References: <049501c8b51e$4ed61b40$ec8251c0$@com> Message-ID: <4829DCAF.3090707@sun.com> Does the hotspot sources have a ATL/MFC dependence? -kto Ted Neward wrote: > Kelly, et al? > > > > Should we just wait with the attempted port until this (see below) > happens? Or do we want to try and actively remove the dependencies on > ATL/MFC from the Hotspot code? > > > > Ted Neward > > Java, .NET, XML Services > > Consulting, Teaching, Speaking, Writing > > http://www.tedneward.com > > > > *From:* Herb Sutter [mailto:hsutter at microsoft.com] > *Sent:* Tuesday, May 13, 2008 4:08 AM > *To:* Ted Neward > *Subject:* RE: ATL headers and libraries? > > > > Unfortunately, no, there is no way to get to ATL and/or MFC without > buying VS Std/Pro/etc. (of course, you can get those through your MSDN > subscription, etc.) > > > > For the future, though, the plan is to ship both ATL and MFC (x86, I > believe) in VC++ Express at some point. > > > > Herb > > > > > > *From:* Ted Neward [mailto:ted at tedneward.com] > *Sent:* Monday, May 12, 2008 12:23 PM > *To:* Herb Sutter > *Subject:* ATL headers and libraries? > > > > Can you tell me (or put me in touch with somebody who can) if it?s > possible to get a hold of the ATL and/or MFC headers and libraries > without buying Visual Studio Standard/Professional/Enterprise/etc? I > have a client who?s looking to see if they can use just VC++ Express to > maintain some code that uses ATL and MFC. > > > > Ted Neward > > Java, .NET, XML Services > > Consulting, Teaching, Speaking, Writing > > http://www.tedneward.com > > > > > > No virus found in this outgoing message. > Checked by AVG. > Version: 7.5.524 / Virus Database: 269.23.15/1426 - Release Date: > 5/10/2008 11:12 AM > > > > No virus found in this incoming message. > Checked by AVG. > Version: 7.5.524 / Virus Database: 269.23.15/1426 - Release Date: > 5/10/2008 11:12 AM > > > No virus found in this outgoing message. > Checked by AVG. > Version: 7.5.524 / Virus Database: 269.23.16/1430 - Release Date: > 5/13/2008 7:31 AM > From Kelly.Ohair at Sun.COM Tue May 13 23:37:51 2008 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Tue, 13 May 2008 16:37:51 -0700 Subject: Runing findbugs Message-ID: <482A264F.2070301@sun.com> I'm currently looking at how we could possible include a run of findbugs in the build process, but my conclusion right now is that we cannot do it by default, it takes way to long to run findbugs over everything. (>12hrs). But I could add some minor support to the Makefiles to allow someone to run findbugs on specific classes/packages, using a command line like this: findbugs -textui -maxHeap 1024 -javahome /YOUR/jdk1.6.0 -sortByClass \ -onlyAnalyze "IMPORT_SPEC" -html -output report.html \ CLASSES_DIRECTORY_OR_JAR For example, after I have built the jdk, you could run findbugs over just the java.lang.* classes: findbugs -textui -maxHeap 1024 -javahome /opt/java/jdk1.6.0 -sortByClass \ -onlyAnalyze "java.lang.*" -html -output report.html \ build/solaris-i586/classes Ideally you want a fully populated classes directory or jar file so that it can analyze all the classes properly. (Note: using java.lang.* does not include the classes in the nested packages). But people could just run the findbugs GUI and do the same thing, or better yet, run the findbugs modules in the NetBeans IDE or Eclipse IDE. So I'm at a loss as to whether I should include anything in the makefiles for this at all. Maybe I was premature in adding findbugs as a build dependence on the jdk and it should just be removed? Any ideas out there? Or comments? -kto From Jonathan.Gibbons at Sun.COM Tue May 13 23:53:15 2008 From: Jonathan.Gibbons at Sun.COM (Jonathan Gibbons) Date: Tue, 13 May 2008 16:53:15 -0700 Subject: Runing findbugs In-Reply-To: <482A264F.2070301@sun.com> References: <482A264F.2070301@sun.com> Message-ID: Kelly, I think that running findbugs on different segments of JDK and publishing histograms of the results on the OpenJDK Quality pages would be a fine idea, but unless we can get engineers to sign up to reducing bugs found by findbugs, the histograms would be somewhat boring. -- Jon On May 13, 2008, at 4:37 PM, Kelly O'Hair wrote: > > I'm currently looking at how we could possible include a run of > findbugs > in the build process, but my conclusion right now is that we cannot > do it > by default, it takes way to long to run findbugs over everything. > (>12hrs). > > But I could add some minor support to the Makefiles to allow someone > to > run findbugs on specific classes/packages, using a command line like > this: > > findbugs -textui -maxHeap 1024 -javahome /YOUR/jdk1.6.0 - > sortByClass \ > -onlyAnalyze "IMPORT_SPEC" -html -output report.html \ > CLASSES_DIRECTORY_OR_JAR > > For example, after I have built the jdk, you could run findbugs over > just > the java.lang.* classes: > > findbugs -textui -maxHeap 1024 -javahome /opt/java/jdk1.6.0 - > sortByClass \ > -onlyAnalyze "java.lang.*" -html -output report.html \ > build/solaris-i586/classes > > Ideally you want a fully populated classes directory or jar file so > that it can analyze all the classes properly. > (Note: using java.lang.* does not include the classes in the nested > packages). > > But people could just run the findbugs GUI and do the same thing, or > better > yet, run the findbugs modules in the NetBeans IDE or Eclipse IDE. > > So I'm at a loss as to whether I should include anything in the > makefiles > for this at all. Maybe I was premature in adding findbugs as a build > dependence > on the jdk and it should just be removed? > > Any ideas out there? Or comments? > > -kto > > > From Weijun.Wang at Sun.COM Tue May 13 23:53:36 2008 From: Weijun.Wang at Sun.COM (Max (Weijun) Wang) Date: Wed, 14 May 2008 07:53:36 +0800 Subject: Runing findbugs In-Reply-To: <482A264F.2070301@sun.com> References: <482A264F.2070301@sun.com> Message-ID: <545E6B33-78B8-4930-9234-AD54BC7184EF@sun.com> Since it takes so long time, how about the release engineer running it once after every build and post the result to openjdk.java.net? Hope some people would read it and send us fixes. Max On May 14, 2008, at 7:37 AM, Kelly O'Hair wrote: > > I'm currently looking at how we could possible include a run of > findbugs > in the build process, but my conclusion right now is that we cannot > do it > by default, it takes way to long to run findbugs over everything. > (>12hrs). > > But I could add some minor support to the Makefiles to allow > someone to > run findbugs on specific classes/packages, using a command line > like this: > > findbugs -textui -maxHeap 1024 -javahome /YOUR/jdk1.6.0 - > sortByClass \ > -onlyAnalyze "IMPORT_SPEC" -html -output report.html \ > CLASSES_DIRECTORY_OR_JAR > > For example, after I have built the jdk, you could run findbugs > over just > the java.lang.* classes: > > findbugs -textui -maxHeap 1024 -javahome /opt/java/jdk1.6.0 - > sortByClass \ > -onlyAnalyze "java.lang.*" -html -output report.html \ > build/solaris-i586/classes > > Ideally you want a fully populated classes directory or jar file so > that it can analyze all the classes properly. > (Note: using java.lang.* does not include the classes in the nested > packages). > > But people could just run the findbugs GUI and do the same thing, > or better > yet, run the findbugs modules in the NetBeans IDE or Eclipse IDE. > > So I'm at a loss as to whether I should include anything in the > makefiles > for this at all. Maybe I was premature in adding findbugs as a > build dependence > on the jdk and it should just be removed? > > Any ideas out there? Or comments? > > -kto > > > From Peter.Kessler at Sun.COM Wed May 14 00:02:21 2008 From: Peter.Kessler at Sun.COM (Peter B. Kessler) Date: Tue, 13 May 2008 17:02:21 -0700 Subject: Runing findbugs In-Reply-To: <482A264F.2070301@sun.com> References: <482A264F.2070301@sun.com> Message-ID: <482A2C0D.5060306@Sun.COM> If you've figured out where to run such a checker, can we run pscan on our native sources? Last time I checked, it took 3 seconds to run on a local copy of HotSpot (and found some things that I fixed). I did try it on all the native code in the JDK, but I forget how long it took. It wasn't long, though. It would be great to have a place to keep a list of such checkers. ... peter Kelly O'Hair wrote: > > I'm currently looking at how we could possible include a run of findbugs > in the build process, but my conclusion right now is that we cannot do it > by default, it takes way to long to run findbugs over everything. (>12hrs). > > But I could add some minor support to the Makefiles to allow someone to > run findbugs on specific classes/packages, using a command line like this: > > findbugs -textui -maxHeap 1024 -javahome /YOUR/jdk1.6.0 -sortByClass \ > -onlyAnalyze "IMPORT_SPEC" -html -output report.html \ > CLASSES_DIRECTORY_OR_JAR > > For example, after I have built the jdk, you could run findbugs over just > the java.lang.* classes: > > findbugs -textui -maxHeap 1024 -javahome /opt/java/jdk1.6.0 > -sortByClass \ > -onlyAnalyze "java.lang.*" -html -output report.html \ > build/solaris-i586/classes > > Ideally you want a fully populated classes directory or jar file so > that it can analyze all the classes properly. > (Note: using java.lang.* does not include the classes in the nested > packages). > > But people could just run the findbugs GUI and do the same thing, or better > yet, run the findbugs modules in the NetBeans IDE or Eclipse IDE. > > So I'm at a loss as to whether I should include anything in the makefiles > for this at all. Maybe I was premature in adding findbugs as a build > dependence > on the jdk and it should just be removed? > > Any ideas out there? Or comments? > > -kto > > > From Joe.Darcy at Sun.COM Wed May 14 00:06:15 2008 From: Joe.Darcy at Sun.COM (Joseph D. Darcy) Date: Tue, 13 May 2008 17:06:15 -0700 Subject: Runing findbugs In-Reply-To: <545E6B33-78B8-4930-9234-AD54BC7184EF@sun.com> References: <482A264F.2070301@sun.com> <545E6B33-78B8-4930-9234-AD54BC7184EF@sun.com> Message-ID: <482A2CF7.2000407@sun.com> I agree that having results of findbugs (and other checkers) as one of the results of the build would be a good idea. -Joe Max (Weijun) Wang wrote: > Since it takes so long time, how about the release engineer running it > once after every build and post the result to openjdk.java.net? Hope > some people would read it and send us fixes. > > Max > > On May 14, 2008, at 7:37 AM, Kelly O'Hair wrote: >> >> I'm currently looking at how we could possible include a run of findbugs >> in the build process, but my conclusion right now is that we cannot do it >> by default, it takes way to long to run findbugs over everything. >> (>12hrs). >> >> But I could add some minor support to the Makefiles to allow someone to >> run findbugs on specific classes/packages, using a command line like >> this: >> >> findbugs -textui -maxHeap 1024 -javahome /YOUR/jdk1.6.0 -sortByClass \ >> -onlyAnalyze "IMPORT_SPEC" -html -output report.html \ >> CLASSES_DIRECTORY_OR_JAR >> >> For example, after I have built the jdk, you could run findbugs over just >> the java.lang.* classes: >> >> findbugs -textui -maxHeap 1024 -javahome /opt/java/jdk1.6.0 >> -sortByClass \ >> -onlyAnalyze "java.lang.*" -html -output report.html \ >> build/solaris-i586/classes >> >> Ideally you want a fully populated classes directory or jar file so >> that it can analyze all the classes properly. >> (Note: using java.lang.* does not include the classes in the nested >> packages). >> >> But people could just run the findbugs GUI and do the same thing, or >> better >> yet, run the findbugs modules in the NetBeans IDE or Eclipse IDE. >> >> So I'm at a loss as to whether I should include anything in the makefiles >> for this at all. Maybe I was premature in adding findbugs as a build >> dependence >> on the jdk and it should just be removed? >> >> Any ideas out there? Or comments? >> >> -kto >> >> >> > From David.Herron at Sun.COM Wed May 14 00:11:07 2008 From: David.Herron at Sun.COM (David Herron) Date: Tue, 13 May 2008 17:11:07 -0700 Subject: Runing findbugs In-Reply-To: References: <482A264F.2070301@sun.com> Message-ID: <482A2E1B.5070901@sun.com> As the Quality group lead - I would be happy to have more quality metrics like findbugs results to publish on the site. If we did publish those results I'd want to tie it to an effort to find community members to reduce the number of findbugs warnings. And, um, it would be nice to have a parallel community effort to reduce the number of compiler warnings ;-) Another thing which would be useful is support for easily running a comparison of findbugs results between two builds. One way this could be used is to screen submissions of new code.. you'd have findbugs results for the trunk, and you'd have findbugs results for an individuals workspace, and you could compare them and see if the developer is introducing new warnings and/or removing warnings. But .. ah.. a 12 hr time to generate a set of findbugs results doesn't sound scalable for this purpose..? Asking RE to produce findbugs results for each promoted build might help but would that skew their machine resource requirements? Kelly, you asked about having findbugs as a build requirement. I think it's not fitting as a hard build requirement. But I do think there should be a findbugs build target and having findbugs in your environment would be a requirement for that target but otherwise not required. - David Herron Jonathan Gibbons wrote: > Kelly, > > I think that running findbugs on different segments of JDK and > publishing histograms of the results on the OpenJDK Quality pages > would be a fine idea, but unless we can get engineers to sign up to > reducing bugs found by findbugs, the histograms would be somewhat boring. > > -- Jon > > > On May 13, 2008, at 4:37 PM, Kelly O'Hair wrote: > >> >> I'm currently looking at how we could possible include a run of findbugs >> in the build process, but my conclusion right now is that we cannot >> do it >> by default, it takes way to long to run findbugs over everything. >> (>12hrs). >> >> But I could add some minor support to the Makefiles to allow someone to >> run findbugs on specific classes/packages, using a command line like >> this: >> >> findbugs -textui -maxHeap 1024 -javahome /YOUR/jdk1.6.0 -sortByClass \ >> -onlyAnalyze "IMPORT_SPEC" -html -output report.html \ >> CLASSES_DIRECTORY_OR_JAR >> >> For example, after I have built the jdk, you could run findbugs over >> just >> the java.lang.* classes: >> >> findbugs -textui -maxHeap 1024 -javahome /opt/java/jdk1.6.0 >> -sortByClass \ >> -onlyAnalyze "java.lang.*" -html -output report.html \ >> build/solaris-i586/classes >> >> Ideally you want a fully populated classes directory or jar file so >> that it can analyze all the classes properly. >> (Note: using java.lang.* does not include the classes in the nested >> packages). >> >> But people could just run the findbugs GUI and do the same thing, or >> better >> yet, run the findbugs modules in the NetBeans IDE or Eclipse IDE. >> >> So I'm at a loss as to whether I should include anything in the >> makefiles >> for this at all. Maybe I was premature in adding findbugs as a build >> dependence >> on the jdk and it should just be removed? >> >> Any ideas out there? Or comments? >> >> -kto >> >> >> > From Kelly.Ohair at Sun.COM Wed May 14 00:21:19 2008 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Tue, 13 May 2008 17:21:19 -0700 Subject: Runing findbugs In-Reply-To: <482A2C0D.5060306@Sun.COM> References: <482A264F.2070301@sun.com> <482A2C0D.5060306@Sun.COM> Message-ID: <482A307F.2060006@sun.com> Jeez, I can't even spell running right... :^{ The pscan site seems to be dead: http://www.striker.ottawa.on.ca/~aland/pscan/ Anybody know what the new public site is for pscan? --- As to when to run findbugs, my conclusion is that the only time you can run it is after the entire jdk is built, otherwise findbugs cannot do the proper analysis. So even though you only want to analyze one package, you need all the classes it uses, which is more work to figure out than just running findbugs after the classes directory is fully populated. The performance of findbugs seems to be really slow, it starts out ok, 30-50% cpu usage, but slowly crawls up to 900Mb in process size and starts getting down to 2-4% cpu usage (using prstat). I suspect I need to use a machine with more RAM. Or a DTrace expert to inspect the process and find out what it's doing. ;^) pscan could probably be run anytime I assume, although with hotspot that may be after makeDeps is run? I really like the idea of these kind of scanners being run regularly, and all the time if possible, but not if they take 12+ hours. :^( -kto Peter B. Kessler wrote: > If you've figured out where to run such a checker, can we run > pscan on our native sources? Last time I checked, it took 3 > seconds to run on a local copy of HotSpot (and found some things > that I fixed). I did try it on all the native code in the JDK, > but I forget how long it took. It wasn't long, though. It would > be great to have a place to keep a list of such checkers. > > ... peter > > Kelly O'Hair wrote: >> >> I'm currently looking at how we could possible include a run of findbugs >> in the build process, but my conclusion right now is that we cannot do it >> by default, it takes way to long to run findbugs over everything. >> (>12hrs). >> >> But I could add some minor support to the Makefiles to allow someone to >> run findbugs on specific classes/packages, using a command line like >> this: >> >> findbugs -textui -maxHeap 1024 -javahome /YOUR/jdk1.6.0 -sortByClass \ >> -onlyAnalyze "IMPORT_SPEC" -html -output report.html \ >> CLASSES_DIRECTORY_OR_JAR >> >> For example, after I have built the jdk, you could run findbugs over just >> the java.lang.* classes: >> >> findbugs -textui -maxHeap 1024 -javahome /opt/java/jdk1.6.0 >> -sortByClass \ >> -onlyAnalyze "java.lang.*" -html -output report.html \ >> build/solaris-i586/classes >> >> Ideally you want a fully populated classes directory or jar file so >> that it can analyze all the classes properly. >> (Note: using java.lang.* does not include the classes in the nested >> packages). >> >> But people could just run the findbugs GUI and do the same thing, or >> better >> yet, run the findbugs modules in the NetBeans IDE or Eclipse IDE. >> >> So I'm at a loss as to whether I should include anything in the makefiles >> for this at all. Maybe I was premature in adding findbugs as a build >> dependence >> on the jdk and it should just be removed? >> >> Any ideas out there? Or comments? >> >> -kto >> >> >> > From Kelly.Ohair at Sun.COM Wed May 14 00:39:47 2008 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Tue, 13 May 2008 17:39:47 -0700 Subject: Runing findbugs In-Reply-To: <482A2E1B.5070901@sun.com> References: <482A264F.2070301@sun.com> <482A2E1B.5070901@sun.com> Message-ID: <482A34D3.7020809@sun.com> David Herron wrote: > As the Quality group lead - I would be happy to have more quality > metrics like findbugs results to publish on the site. If we did publish > those results I'd want to tie it to an effort to find community members > to reduce the number of findbugs warnings. And, um, it would be nice to > have a parallel community effort to reduce the number of compiler > warnings ;-) > > Another thing which would be useful is support for easily running a > comparison of findbugs results between two builds. One way this could > be used is to screen submissions of new code.. you'd have findbugs > results for the trunk, and you'd have findbugs results for an > individuals workspace, and you could compare them and see if the > developer is introducing new warnings and/or removing warnings. > > But .. ah.. a 12 hr time to generate a set of findbugs results doesn't > sound scalable for this purpose..? Asking RE to produce findbugs > results for each promoted build might help but would that skew their > machine resource requirements? > > Kelly, you asked about having findbugs as a build requirement. I think > it's not fitting as a hard build requirement. But I do think there > should be a findbugs build target and having findbugs in your > environment would be a requirement for that target but otherwise not > required. But using the findbugs GUI or findbugs plugins (NetBeans/Eclipse) is a much better user experience than the command line. The textual output of findbugs is not something that is easy to understand and connect up to the source, the html output is better with the links and better source information. The findbugs errors are usually a bit more complicated than your typical javac error, not exactly sure how to describe it. It's the GUI interfaces and the IDE's in particular that seem to be the best findbugs analysis experience, in my opinion. -kto > > - David Herron > > > Jonathan Gibbons wrote: >> Kelly, >> >> I think that running findbugs on different segments of JDK and >> publishing histograms of the results on the OpenJDK Quality pages >> would be a fine idea, but unless we can get engineers to sign up to >> reducing bugs found by findbugs, the histograms would be somewhat boring. >> >> -- Jon >> >> >> On May 13, 2008, at 4:37 PM, Kelly O'Hair wrote: >> >>> >>> I'm currently looking at how we could possible include a run of findbugs >>> in the build process, but my conclusion right now is that we cannot >>> do it >>> by default, it takes way to long to run findbugs over everything. >>> (>12hrs). >>> >>> But I could add some minor support to the Makefiles to allow someone to >>> run findbugs on specific classes/packages, using a command line like >>> this: >>> >>> findbugs -textui -maxHeap 1024 -javahome /YOUR/jdk1.6.0 -sortByClass \ >>> -onlyAnalyze "IMPORT_SPEC" -html -output report.html \ >>> CLASSES_DIRECTORY_OR_JAR >>> >>> For example, after I have built the jdk, you could run findbugs over >>> just >>> the java.lang.* classes: >>> >>> findbugs -textui -maxHeap 1024 -javahome /opt/java/jdk1.6.0 >>> -sortByClass \ >>> -onlyAnalyze "java.lang.*" -html -output report.html \ >>> build/solaris-i586/classes >>> >>> Ideally you want a fully populated classes directory or jar file so >>> that it can analyze all the classes properly. >>> (Note: using java.lang.* does not include the classes in the nested >>> packages). >>> >>> But people could just run the findbugs GUI and do the same thing, or >>> better >>> yet, run the findbugs modules in the NetBeans IDE or Eclipse IDE. >>> >>> So I'm at a loss as to whether I should include anything in the >>> makefiles >>> for this at all. Maybe I was premature in adding findbugs as a build >>> dependence >>> on the jdk and it should just be removed? >>> >>> Any ideas out there? Or comments? >>> >>> -kto >>> >>> >>> >> From Jonathan.Gibbons at Sun.COM Wed May 14 00:51:11 2008 From: Jonathan.Gibbons at Sun.COM (Jonathan Gibbons) Date: Tue, 13 May 2008 17:51:11 -0700 Subject: Runing findbugs In-Reply-To: <482A34D3.7020809@sun.com> References: <482A264F.2070301@sun.com> <482A2E1B.5070901@sun.com> <482A34D3.7020809@sun.com> Message-ID: <96DC6AD0-FA41-450F-9EEC-94A381C91698@Sun.COM> Kelly, There are two ways to use findbugs. It would be good to have a batch run of findbugs per build with the goal of publishing metrics. Separately, developers should be encouraged to run findbugs however works best for them, to get their findbug count down. -- Jon On May 13, 2008, at 5:39 PM, Kelly O'Hair wrote: > > > David Herron wrote: >> As the Quality group lead - I would be happy to have more quality >> metrics like findbugs results to publish on the site. If we did >> publish those results I'd want to tie it to an effort to find >> community members to reduce the number of findbugs warnings. And, >> um, it would be nice to have a parallel community effort to reduce >> the number of compiler warnings ;-) >> Another thing which would be useful is support for easily running a >> comparison of findbugs results between two builds. One way this >> could be used is to screen submissions of new code.. you'd have >> findbugs results for the trunk, and you'd have findbugs results for >> an individuals workspace, and you could compare them and see if the >> developer is introducing new warnings and/or removing warnings. >> But .. ah.. a 12 hr time to generate a set of findbugs results >> doesn't sound scalable for this purpose..? Asking RE to produce >> findbugs results for each promoted build might help but would that >> skew their machine resource requirements? >> Kelly, you asked about having findbugs as a build requirement. I >> think it's not fitting as a hard build requirement. But I do think >> there should be a findbugs build target and having findbugs in your >> environment would be a requirement for that target but otherwise >> not required. > > But using the findbugs GUI or findbugs plugins (NetBeans/Eclipse) > is a much better user experience than the command line. > > The textual output of findbugs is not something that is easy to > understand and connect up to the source, the html output is better > with the links and better source information. > The findbugs errors are usually a bit more complicated than your > typical javac error, not exactly sure how to describe it. > > It's the GUI interfaces and the IDE's in particular that seem to > be the best findbugs analysis experience, in my opinion. > > -kto > >> - David Herron >> Jonathan Gibbons wrote: >>> Kelly, >>> >>> I think that running findbugs on different segments of JDK and >>> publishing histograms of the results on the OpenJDK Quality pages >>> would be a fine idea, but unless we can get engineers to sign up >>> to reducing bugs found by findbugs, the histograms would be >>> somewhat boring. >>> >>> -- Jon >>> >>> >>> On May 13, 2008, at 4:37 PM, Kelly O'Hair wrote: >>> >>>> >>>> I'm currently looking at how we could possible include a run of >>>> findbugs >>>> in the build process, but my conclusion right now is that we >>>> cannot do it >>>> by default, it takes way to long to run findbugs over everything. >>>> (>12hrs). >>>> >>>> But I could add some minor support to the Makefiles to allow >>>> someone to >>>> run findbugs on specific classes/packages, using a command line >>>> like this: >>>> >>>> findbugs -textui -maxHeap 1024 -javahome /YOUR/jdk1.6.0 - >>>> sortByClass \ >>>> -onlyAnalyze "IMPORT_SPEC" -html -output report.html \ >>>> CLASSES_DIRECTORY_OR_JAR >>>> >>>> For example, after I have built the jdk, you could run findbugs >>>> over just >>>> the java.lang.* classes: >>>> >>>> findbugs -textui -maxHeap 1024 -javahome /opt/java/jdk1.6.0 - >>>> sortByClass \ >>>> -onlyAnalyze "java.lang.*" -html -output report.html \ >>>> build/solaris-i586/classes >>>> >>>> Ideally you want a fully populated classes directory or jar file so >>>> that it can analyze all the classes properly. >>>> (Note: using java.lang.* does not include the classes in the >>>> nested packages). >>>> >>>> But people could just run the findbugs GUI and do the same thing, >>>> or better >>>> yet, run the findbugs modules in the NetBeans IDE or Eclipse IDE. >>>> >>>> So I'm at a loss as to whether I should include anything in the >>>> makefiles >>>> for this at all. Maybe I was premature in adding findbugs as a >>>> build dependence >>>> on the jdk and it should just be removed? >>>> >>>> Any ideas out there? Or comments? >>>> >>>> -kto >>>> >>>> >>>> >>> From martinrb at google.com Wed May 14 01:18:24 2008 From: martinrb at google.com (Martin Buchholz) Date: Tue, 13 May 2008 18:18:24 -0700 Subject: Runing findbugs In-Reply-To: <482A264F.2070301@sun.com> References: <482A264F.2070301@sun.com> Message-ID: <1ccfd1c10805131818k265ff3e4k5c905d156af0a357@mail.gmail.com> It looks like you want the -auxclasspath flag to findbugs. See http://findbugs.sourceforge.net/manual/ch11.html (I haven't actually tried this myself) Martin On Tue, May 13, 2008 at 4:37 PM, Kelly O'Hair wrote: > > I'm currently looking at how we could possible include a run of findbugs > in the build process, but my conclusion right now is that we cannot do it > by default, it takes way to long to run findbugs over everything. (>12hrs). > > But I could add some minor support to the Makefiles to allow someone to > run findbugs on specific classes/packages, using a command line like this: > > findbugs -textui -maxHeap 1024 -javahome /YOUR/jdk1.6.0 -sortByClass \ > -onlyAnalyze "IMPORT_SPEC" -html -output report.html \ > CLASSES_DIRECTORY_OR_JAR > > For example, after I have built the jdk, you could run findbugs over just > the java.lang.* classes: > > findbugs -textui -maxHeap 1024 -javahome /opt/java/jdk1.6.0 -sortByClass \ > -onlyAnalyze "java.lang.*" -html -output report.html \ > build/solaris-i586/classes > > Ideally you want a fully populated classes directory or jar file so > that it can analyze all the classes properly. > (Note: using java.lang.* does not include the classes in the nested > packages). From Peter.Kessler at Sun.COM Wed May 14 05:07:53 2008 From: Peter.Kessler at Sun.COM (Peter B. Kessler) Date: Tue, 13 May 2008 22:07:53 -0700 Subject: Runing findbugs In-Reply-To: <482A307F.2060006@sun.com> References: <482A264F.2070301@sun.com> <482A2C0D.5060306@Sun.COM> <482A307F.2060006@sun.com> Message-ID: <482A73A9.8000700@Sun.COM> It's possible that it got folded into -Wformat on recent gcc's. That's fine for the platforms (and bits of source) we compile with gcc, but it would be nice if we could check all our code. ... peter Kelly O'Hair wrote: > Jeez, I can't even spell running right... :^{ > > The pscan site seems to be dead: > http://www.striker.ottawa.on.ca/~aland/pscan/ > Anybody know what the new public site is for pscan? > > --- > > As to when to run findbugs, my conclusion is that the only time you > can run it is after the entire jdk is built, otherwise findbugs cannot > do the proper analysis. So even though you only want to analyze one > package, you need all the classes it uses, which is more work to figure > out than just running findbugs after the classes directory is fully > populated. The performance of findbugs seems to be really slow, it > starts out ok, 30-50% cpu usage, but slowly crawls up to 900Mb in > process size and starts getting down to 2-4% cpu usage (using prstat). > I suspect I need to use a machine with more RAM. Or a DTrace expert > to inspect the process and find out what it's doing. ;^) > > pscan could probably be run anytime I assume, although with hotspot > that may be after makeDeps is run? > > I really like the idea of these kind of scanners being run regularly, > and all the time if possible, but not if they take 12+ hours. :^( > > -kto > > > Peter B. Kessler wrote: >> If you've figured out where to run such a checker, can we run >> pscan on our native sources? Last time I checked, it took 3 >> seconds to run on a local copy of HotSpot (and found some things >> that I fixed). I did try it on all the native code in the JDK, >> but I forget how long it took. It wasn't long, though. It would >> be great to have a place to keep a list of such checkers. >> >> ... peter >> >> Kelly O'Hair wrote: >>> >>> I'm currently looking at how we could possible include a run of findbugs >>> in the build process, but my conclusion right now is that we cannot >>> do it >>> by default, it takes way to long to run findbugs over everything. >>> (>12hrs). >>> >>> But I could add some minor support to the Makefiles to allow someone to >>> run findbugs on specific classes/packages, using a command line like >>> this: >>> >>> findbugs -textui -maxHeap 1024 -javahome /YOUR/jdk1.6.0 -sortByClass \ >>> -onlyAnalyze "IMPORT_SPEC" -html -output report.html \ >>> CLASSES_DIRECTORY_OR_JAR >>> >>> For example, after I have built the jdk, you could run findbugs over >>> just >>> the java.lang.* classes: >>> >>> findbugs -textui -maxHeap 1024 -javahome /opt/java/jdk1.6.0 >>> -sortByClass \ >>> -onlyAnalyze "java.lang.*" -html -output report.html \ >>> build/solaris-i586/classes >>> >>> Ideally you want a fully populated classes directory or jar file so >>> that it can analyze all the classes properly. >>> (Note: using java.lang.* does not include the classes in the nested >>> packages). >>> >>> But people could just run the findbugs GUI and do the same thing, or >>> better >>> yet, run the findbugs modules in the NetBeans IDE or Eclipse IDE. >>> >>> So I'm at a loss as to whether I should include anything in the >>> makefiles >>> for this at all. Maybe I was premature in adding findbugs as a build >>> dependence >>> on the jdk and it should just be removed? >>> >>> Any ideas out there? Or comments? >>> >>> -kto >>> >>> >>> >> From lars.westergren at gmail.com Wed May 14 06:33:43 2008 From: lars.westergren at gmail.com (Lars Westergren) Date: Wed, 14 May 2008 08:33:43 +0200 Subject: Runing findbugs In-Reply-To: <482A2E1B.5070901@sun.com> References: <482A264F.2070301@sun.com> <482A2E1B.5070901@sun.com> Message-ID: <7cf9cdd90805132333n285c6a2bja8e086591e8483b4@mail.gmail.com> > If we did publish those > results I'd want to tie it to an effort to find community members to reduce > the number of findbugs warnings. I for one would be happy to contribute to that. Cheers, Lars From Dmitri.Trembovetski at Sun.COM Wed May 14 16:05:15 2008 From: Dmitri.Trembovetski at Sun.COM (Dmitri Trembovetski) Date: Wed, 14 May 2008 09:05:15 -0700 Subject: Runing findbugs In-Reply-To: <482A2C0D.5060306@Sun.COM> References: <482A264F.2070301@sun.com> <482A2C0D.5060306@Sun.COM> Message-ID: <482B0DBB.8020502@Sun.COM> We can also run lint on solaris. Thanks, Dmitri Peter B. Kessler wrote: > If you've figured out where to run such a checker, can we run > pscan on our native sources? Last time I checked, it took 3 > seconds to run on a local copy of HotSpot (and found some things > that I fixed). I did try it on all the native code in the JDK, > but I forget how long it took. It wasn't long, though. It would > be great to have a place to keep a list of such checkers. > > ... peter > > Kelly O'Hair wrote: >> >> I'm currently looking at how we could possible include a run of findbugs >> in the build process, but my conclusion right now is that we cannot do it >> by default, it takes way to long to run findbugs over everything. >> (>12hrs). >> >> But I could add some minor support to the Makefiles to allow someone to >> run findbugs on specific classes/packages, using a command line like >> this: >> >> findbugs -textui -maxHeap 1024 -javahome /YOUR/jdk1.6.0 -sortByClass \ >> -onlyAnalyze "IMPORT_SPEC" -html -output report.html \ >> CLASSES_DIRECTORY_OR_JAR >> >> For example, after I have built the jdk, you could run findbugs over just >> the java.lang.* classes: >> >> findbugs -textui -maxHeap 1024 -javahome /opt/java/jdk1.6.0 >> -sortByClass \ >> -onlyAnalyze "java.lang.*" -html -output report.html \ >> build/solaris-i586/classes >> >> Ideally you want a fully populated classes directory or jar file so >> that it can analyze all the classes properly. >> (Note: using java.lang.* does not include the classes in the nested >> packages). >> >> But people could just run the findbugs GUI and do the same thing, or >> better >> yet, run the findbugs modules in the NetBeans IDE or Eclipse IDE. >> >> So I'm at a loss as to whether I should include anything in the makefiles >> for this at all. Maybe I was premature in adding findbugs as a build >> dependence >> on the jdk and it should just be removed? >> >> Any ideas out there? Or comments? >> >> -kto >> >> >> > From marco at mtsystems.ch Wed May 14 17:31:12 2008 From: marco at mtsystems.ch (Marco Trudel) Date: Wed, 14 May 2008 19:31:12 +0200 Subject: Windows XP: openjdk 7 b26, InstallShield issues Message-ID: <482B21E0.4060601@mtsystems.ch> Hey all I'm compiling openjdk on Windows XP. I get a working jdk, despite the sparse documentation. The problem is that the compilation aborts somewhere around the latest steps when trying to create the InstallShield setup. It seems that this openjdk version requires InstallShield DevStudio 9 which is no longer available and extremely expensive. InstallShield 2008 does not work. So my question: Is there a way to skip this step? I actually don't even want the installer and surely don't want to pay for InstallShield (I was happy to see the progress from MKS to Cygwin only to find out that another commercial product is required now). I tried setting BUILD_INSTALL=false, but this creates another compilation error. thanks Marco From Igor.Nekrestyanov at Sun.COM Wed May 14 17:50:17 2008 From: Igor.Nekrestyanov at Sun.COM (Igor Nekrestyanov) Date: Wed, 14 May 2008 21:50:17 +0400 Subject: Windows XP: openjdk 7 b26, InstallShield issues In-Reply-To: <482B21E0.4060601@mtsystems.ch> References: <482B21E0.4060601@mtsystems.ch> Message-ID: <482B2659.7060708@sun.com> Hi Marco, please post your build log here. Otherwise it is difficult to understand what exactly happened in your case. -igor Marco Trudel wrote: > Hey all > > I'm compiling openjdk on Windows XP. I get a working jdk, despite the > sparse documentation. The problem is that the compilation aborts > somewhere around the latest steps when trying to create the > InstallShield setup. > It seems that this openjdk version requires InstallShield DevStudio 9 > which is no longer available and extremely expensive. InstallShield > 2008 does not work. > So my question: Is there a way to skip this step? I actually don't > even want the installer and surely don't want to pay for InstallShield > (I was happy to see the progress from MKS to Cygwin only to find out > that another commercial product is required now). > > I tried setting BUILD_INSTALL=false, but this creates another > compilation error. > > > thanks > Marco From marco at mtsystems.ch Wed May 14 18:03:49 2008 From: marco at mtsystems.ch (Marco Trudel) Date: Wed, 14 May 2008 20:03:49 +0200 Subject: Windows XP: openjdk 7 b26, InstallShield issues In-Reply-To: <482B2659.7060708@sun.com> References: <482B21E0.4060601@mtsystems.ch> <482B2659.7060708@sun.com> Message-ID: <482B2985.5030405@mtsystems.ch> Hey Igor Igor Nekrestyanov wrote: > Hi Marco, > > please post your build log here. > Otherwise it is difficult to understand what exactly happened in your case. Well, there's actually no problem to look at. I just don't have the correct InstallShield version and also don't want to have it. But well, maybe it gives you some useful information: - No InstallShield or wrong version (2008): At the step "c:/windows/system32/wscript.exe path_to_openjdk_out_dir/tmp/ishield/regular/jrefile.vbs" this alert pops up: Windows Scripting Host, Can't create Object "ISWiAutomation.ISWiProject" - Adapting the two Defs-windows.gmk that create "ISWiAutomation.ISWiProject" to create "ISWiAuto14.ISWiProject" (the one for InstallShield 2008), this compilation error occurs: make javaone_transforms make[7]: Entering directory `/cygdrive/d/programming/_workspace/openjdk-7-b26/openjdk-7-b26-src/install/make/installer/bundles/windows/ishield/jre' /usr/bin/mv d:/programming/_workspace/openjdk-7-b26/openjdk-7-b26/tmp/ishield/regular/jre-image d:/programming/_workspace/openjdk-7-b26/openjdk-7-b26/tmp/ishield/regular/jre-image.mv rm -f -r d:/programming/_workspace/openjdk-7-b26/openjdk-7-b26/tmp/ishield/regular/jre/jre/transform/javaone/ /usr/bin/mkdir -p d:/programming/_workspace/openjdk-7-b26/openjdk-7-b26/tmp/ishield/regular/jre/jre/transform/javaone/ rm -f d:/programming/_workspace/openjdk-7-b26/openjdk-7-b26/tmp/ishield/regular/jre.ism C:/WINDOWS/system32/wscript.exe d:/programming/_workspace/openjdk-7-b26/openjdk-7-b26/tmp/ishield/regular/jrefile.vbs /usr/bin/cp /cygdrive/d/programming/_workspace/openjdk-7-b26/openjdk-7-b26-src/install/make/installer/bundles/windows/ishield/jre/../javaad1028.ibd d:/programming/_workspace/openjdk-7-b26/openjdk-7-b26/tmp/ishield/regular/javaad.ibd c:/Programme/InstallShield/System/ISCmdBld.exe -s -p d:/programming/_workspace/openjdk-7-b26/openjdk-7-b26/tmp/ishield/regular/jre.ism -r "iftw" -c COMP make[7]: [javaone_transforms] Error 1 (ignored) The build continues, but because the installer has not been created, the following MsiTran.Exe call fails and compilation aborts. You can take a look at what's going on in openjdk-7-b26-src\install\make\installer\bundles\windows\ishield\jre\Makefile line 260 to 270. Hope that helps Marco > -igor > > Marco Trudel wrote: >> Hey all >> >> I'm compiling openjdk on Windows XP. I get a working jdk, despite the >> sparse documentation. The problem is that the compilation aborts >> somewhere around the latest steps when trying to create the >> InstallShield setup. >> It seems that this openjdk version requires InstallShield DevStudio 9 >> which is no longer available and extremely expensive. InstallShield >> 2008 does not work. >> So my question: Is there a way to skip this step? I actually don't >> even want the installer and surely don't want to pay for InstallShield >> (I was happy to see the progress from MKS to Cygwin only to find out >> that another commercial product is required now). >> >> I tried setting BUILD_INSTALL=false, but this creates another >> compilation error. >> >> >> thanks >> Marco > From marco at mtsystems.ch Wed May 14 18:20:53 2008 From: marco at mtsystems.ch (Marco Trudel) Date: Wed, 14 May 2008 20:20:53 +0200 Subject: Windows XP: openjdk 7 b26, InstallShield issues In-Reply-To: <482B2B80.4060504@sun.com> References: <482B21E0.4060601@mtsystems.ch> <482B2659.7060708@sun.com> <482B2985.5030405@mtsystems.ch> <482B2B80.4060504@sun.com> Message-ID: <482B2D85.3080905@mtsystems.ch> Hey Phil Phil Race wrote: > Where exactly did you download this from? > Can you point me to the exact web page or bundle? I assume you're talking about my openjdk bundle. It's the one from http://openjdk.java.net/ -> source bundle. Isn't this the current official release? thanks Marco > -phil. > > Marco Trudel wrote: >> Hey Igor >> >> Igor Nekrestyanov wrote: >>> Hi Marco, >>> >>> please post your build log here. >>> Otherwise it is difficult to understand what exactly happened in your >>> case. >> >> Well, there's actually no problem to look at. I just don't have the >> correct InstallShield version and also don't want to have it. But >> well, maybe it gives you some useful information: >> >> - No InstallShield or wrong version (2008): >> >> At the step "c:/windows/system32/wscript.exe >> path_to_openjdk_out_dir/tmp/ishield/regular/jrefile.vbs" this alert >> pops up: Windows Scripting Host, Can't create Object >> "ISWiAutomation.ISWiProject" >> >> - Adapting the two Defs-windows.gmk that create >> "ISWiAutomation.ISWiProject" to create "ISWiAuto14.ISWiProject" (the >> one for InstallShield 2008), this compilation error occurs: >> >> make javaone_transforms >> make[7]: Entering directory >> `/cygdrive/d/programming/_workspace/openjdk-7-b26/openjdk-7-b26-src/install/make/installer/bundles/windows/ishield/jre' >> >> /usr/bin/mv >> d:/programming/_workspace/openjdk-7-b26/openjdk-7-b26/tmp/ishield/regular/jre-image >> d:/programming/_workspace/openjdk-7-b26/openjdk-7-b26/tmp/ishield/regular/jre-image.mv >> >> rm -f -r >> d:/programming/_workspace/openjdk-7-b26/openjdk-7-b26/tmp/ishield/regular/jre/jre/transform/javaone/ >> >> /usr/bin/mkdir -p >> d:/programming/_workspace/openjdk-7-b26/openjdk-7-b26/tmp/ishield/regular/jre/jre/transform/javaone/ >> >> rm -f >> d:/programming/_workspace/openjdk-7-b26/openjdk-7-b26/tmp/ishield/regular/jre.ism >> >> C:/WINDOWS/system32/wscript.exe >> d:/programming/_workspace/openjdk-7-b26/openjdk-7-b26/tmp/ishield/regular/jrefile.vbs >> >> /usr/bin/cp >> /cygdrive/d/programming/_workspace/openjdk-7-b26/openjdk-7-b26-src/install/make/installer/bundles/windows/ishield/jre/../javaad1028.ibd >> d:/programming/_workspace/openjdk-7-b26/openjdk-7-b26/tmp/ishield/regular/javaad.ibd >> >> c:/Programme/InstallShield/System/ISCmdBld.exe -s -p >> d:/programming/_workspace/openjdk-7-b26/openjdk-7-b26/tmp/ishield/regular/jre.ism >> -r "iftw" -c COMP >> make[7]: [javaone_transforms] Error 1 (ignored) >> >> The build continues, but because the installer has not been created, >> the following MsiTran.Exe call fails and compilation aborts. >> >> You can take a look at what's going on in >> openjdk-7-b26-src\install\make\installer\bundles\windows\ishield\jre\Makefile >> line 260 to 270. >> >> >> Hope that helps >> Marco >> >>> -igor >>> >>> Marco Trudel wrote: >>>> Hey all >>>> >>>> I'm compiling openjdk on Windows XP. I get a working jdk, despite >>>> the sparse documentation. The problem is that the compilation aborts >>>> somewhere around the latest steps when trying to create the >>>> InstallShield setup. >>>> It seems that this openjdk version requires InstallShield DevStudio >>>> 9 which is no longer available and extremely expensive. >>>> InstallShield 2008 does not work. >>>> So my question: Is there a way to skip this step? I actually don't >>>> even want the installer and surely don't want to pay for >>>> InstallShield (I was happy to see the progress from MKS to Cygwin >>>> only to find out that another commercial product is required now). >>>> >>>> I tried setting BUILD_INSTALL=false, but this creates another >>>> compilation error. >>>> >>>> >>>> thanks >>>> Marco >>> >> From Phil.Race at Sun.COM Wed May 14 18:29:29 2008 From: Phil.Race at Sun.COM (Phil Race) Date: Wed, 14 May 2008 11:29:29 -0700 Subject: Windows XP: openjdk 7 b26, InstallShield issues In-Reply-To: <482B2D85.3080905@mtsystems.ch> References: <482B21E0.4060601@mtsystems.ch> <482B2659.7060708@sun.com> <482B2985.5030405@mtsystems.ch> <482B2B80.4060504@sun.com> <482B2D85.3080905@mtsystems.ch> Message-ID: <482B2F89.5030404@sun.com> OK, I think I understand what happened after asking around. You downloaded an incorrect bundle. A corrected bundle was uploaded yesterday I think. You should discard the one you have and replace it with the new one. That should resolve the issue. -phil. Marco Trudel wrote: > Hey Phil > > Phil Race wrote: >> Where exactly did you download this from? >> Can you point me to the exact web page or bundle? > > I assume you're talking about my openjdk bundle. It's the one from > http://openjdk.java.net/ -> source bundle. Isn't this the current > official release? > > > thanks > Marco > >> -phil. >> >> Marco Trudel wrote: >>> Hey Igor >>> >>> Igor Nekrestyanov wrote: >>>> Hi Marco, >>>> >>>> please post your build log here. >>>> Otherwise it is difficult to understand what exactly happened in >>>> your case. >>> >>> Well, there's actually no problem to look at. I just don't have the >>> correct InstallShield version and also don't want to have it. But >>> well, maybe it gives you some useful information: >>> >>> - No InstallShield or wrong version (2008): >>> >>> At the step "c:/windows/system32/wscript.exe >>> path_to_openjdk_out_dir/tmp/ishield/regular/jrefile.vbs" this alert >>> pops up: Windows Scripting Host, Can't create Object >>> "ISWiAutomation.ISWiProject" >>> >>> - Adapting the two Defs-windows.gmk that create >>> "ISWiAutomation.ISWiProject" to create "ISWiAuto14.ISWiProject" (the >>> one for InstallShield 2008), this compilation error occurs: >>> >>> make javaone_transforms >>> make[7]: Entering directory >>> `/cygdrive/d/programming/_workspace/openjdk-7-b26/openjdk-7-b26-src/install/make/installer/bundles/windows/ishield/jre' >>> >>> /usr/bin/mv >>> d:/programming/_workspace/openjdk-7-b26/openjdk-7-b26/tmp/ishield/regular/jre-image >>> d:/programming/_workspace/openjdk-7-b26/openjdk-7-b26/tmp/ishield/regular/jre-image.mv >>> >>> rm -f -r >>> d:/programming/_workspace/openjdk-7-b26/openjdk-7-b26/tmp/ishield/regular/jre/jre/transform/javaone/ >>> >>> /usr/bin/mkdir -p >>> d:/programming/_workspace/openjdk-7-b26/openjdk-7-b26/tmp/ishield/regular/jre/jre/transform/javaone/ >>> >>> rm -f >>> d:/programming/_workspace/openjdk-7-b26/openjdk-7-b26/tmp/ishield/regular/jre.ism >>> >>> C:/WINDOWS/system32/wscript.exe >>> d:/programming/_workspace/openjdk-7-b26/openjdk-7-b26/tmp/ishield/regular/jrefile.vbs >>> >>> /usr/bin/cp >>> /cygdrive/d/programming/_workspace/openjdk-7-b26/openjdk-7-b26-src/install/make/installer/bundles/windows/ishield/jre/../javaad1028.ibd >>> d:/programming/_workspace/openjdk-7-b26/openjdk-7-b26/tmp/ishield/regular/javaad.ibd >>> >>> c:/Programme/InstallShield/System/ISCmdBld.exe -s -p >>> d:/programming/_workspace/openjdk-7-b26/openjdk-7-b26/tmp/ishield/regular/jre.ism >>> -r "iftw" -c COMP >>> make[7]: [javaone_transforms] Error 1 (ignored) >>> >>> The build continues, but because the installer has not been created, >>> the following MsiTran.Exe call fails and compilation aborts. >>> >>> You can take a look at what's going on in >>> openjdk-7-b26-src\install\make\installer\bundles\windows\ishield\jre\Makefile >>> line 260 to 270. >>> >>> >>> Hope that helps >>> Marco >>> >>>> -igor >>>> >>>> Marco Trudel wrote: >>>>> Hey all >>>>> >>>>> I'm compiling openjdk on Windows XP. I get a working jdk, despite >>>>> the sparse documentation. The problem is that the compilation >>>>> aborts somewhere around the latest steps when trying to create the >>>>> InstallShield setup. >>>>> It seems that this openjdk version requires InstallShield DevStudio >>>>> 9 which is no longer available and extremely expensive. >>>>> InstallShield 2008 does not work. >>>>> So my question: Is there a way to skip this step? I actually don't >>>>> even want the installer and surely don't want to pay for >>>>> InstallShield (I was happy to see the progress from MKS to Cygwin >>>>> only to find out that another commercial product is required now). >>>>> >>>>> I tried setting BUILD_INSTALL=false, but this creates another >>>>> compilation error. >>>>> >>>>> >>>>> thanks >>>>> Marco >>>> >>> > > From bram.somers at skynet.be Wed May 14 19:13:35 2008 From: bram.somers at skynet.be (Bram Somers) Date: Wed, 14 May 2008 21:13:35 +0200 Subject: Building on ubuntu 8.04 Message-ID: <482B39DF.3030507@skynet.be> Dear all, I've tried building jdk7 on Ubuntu 8.04. I'm aware of the problems with sh/dash and I remove sh and made a symlink of sh to bash, so normally I shouldn't get this error anymore: jdk7/build/openjdk_full_debug/gensrc/java/nio/charset/CharsetEncoder.java:142: cannot find symbol symbol : class $replType$ location: class java.nio.charset.CharsetEncoder private $replType$ replacement; ^ /home/bsomers/workspaces/openjdk/jdk7/build/openjdk_full_debug/gensrc/java/nio/charset/CharsetEncoder.java:185: cannot find symbol symbol : class $replType$ location: class java.nio.charset.CharsetEncoder $replType$ replacement) ^ /home/bsomers/workspaces/openjdk/jdk7/build/openjdk_full_debug/gensrc/java/nio/charset/CharsetEncoder.java:246: cannot find symbol symbol : class $replType$ location: class java.nio.charset.CharsetEncoder public final $replType$ replacement() { ^ /home/bsomers/workspaces/openjdk/jdk7/build/openjdk_full_debug/gensrc/java/nio/charset/CharsetEncoder.java:275: cannot find symbol symbol : class $replType$ location: class java.nio.charset.CharsetEncoder public final CharsetEncoder replaceWith($replType$ newReplacement) { ^ /home/bsomers/workspaces/openjdk/jdk7/build/openjdk_full_debug/gensrc/java/nio/charset/CharsetEncoder.java:301: cannot find symbol symbol : class $replType$ location: class java.nio.charset.CharsetEncoder protected void implReplaceWith($replType$ newReplacement) { ^ Note: Some input files use or override a deprecated API. Note: Recompile with -Xlint:deprecation for details. Note: Some input files use unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. 5 errors Any more suggestions? Thanks in advance, kind regards, Bram From Bradford.Wetmore at Sun.COM Wed May 14 19:56:06 2008 From: Bradford.Wetmore at Sun.COM (Brad Wetmore) Date: Wed, 14 May 2008 12:56:06 -0700 Subject: Building on ubuntu 8.04 In-Reply-To: <482B39DF.3030507@skynet.be> References: <482B39DF.3030507@skynet.be> Message-ID: <482B43D6.40902@sun.com> I think you've got a problem still with your sh setup, or possibly something else. IIRC, the ?replType? variables is supposed to be replaced with various values depending on whether you have an encoder or decoder. (sed/awk preprocessing = a Javaman's #ifdef equivalent) It's done a similar way for the {Byte,Char,Int...}Buffers. Check jdk/make/java/nio, specifically Makefile, spp.sh, and genCoder.sh Hope this helps. Brad Bram Somers wrote: > Dear all, > > I've tried building jdk7 on Ubuntu 8.04. I'm aware of the problems with > sh/dash and I remove sh and made a symlink of sh to bash, so normally I > shouldn't get this error anymore: > > jdk7/build/openjdk_full_debug/gensrc/java/nio/charset/CharsetEncoder.java:142: > cannot find symbol > symbol : class $replType$ > location: class java.nio.charset.CharsetEncoder > private $replType$ replacement; > ^ > /home/bsomers/workspaces/openjdk/jdk7/build/openjdk_full_debug/gensrc/java/nio/charset/CharsetEncoder.java:185: > cannot find symbol > symbol : class $replType$ > location: class java.nio.charset.CharsetEncoder > $replType$ replacement) > ^ > /home/bsomers/workspaces/openjdk/jdk7/build/openjdk_full_debug/gensrc/java/nio/charset/CharsetEncoder.java:246: > cannot find symbol > symbol : class $replType$ > location: class java.nio.charset.CharsetEncoder > public final $replType$ replacement() { > ^ > /home/bsomers/workspaces/openjdk/jdk7/build/openjdk_full_debug/gensrc/java/nio/charset/CharsetEncoder.java:275: > cannot find symbol > symbol : class $replType$ > location: class java.nio.charset.CharsetEncoder > public final CharsetEncoder replaceWith($replType$ newReplacement) { > ^ > /home/bsomers/workspaces/openjdk/jdk7/build/openjdk_full_debug/gensrc/java/nio/charset/CharsetEncoder.java:301: > cannot find symbol > symbol : class $replType$ > location: class java.nio.charset.CharsetEncoder > protected void implReplaceWith($replType$ newReplacement) { > ^ > Note: Some input files use or override a deprecated API. > Note: Recompile with -Xlint:deprecation for details. > Note: Some input files use unchecked or unsafe operations. > Note: Recompile with -Xlint:unchecked for details. > 5 errors > > > Any more suggestions? > > Thanks in advance, > > kind regards, > > Bram From roman.kennke at aicas.com Wed May 14 20:05:23 2008 From: roman.kennke at aicas.com (Roman Kennke) Date: Wed, 14 May 2008 22:05:23 +0200 Subject: Building on ubuntu 8.04 In-Reply-To: <482B43D6.40902@sun.com> References: <482B39DF.3030507@skynet.be> <482B43D6.40902@sun.com> Message-ID: <1210795523.6406.30.camel@moonlight> Also, maybe you simply forgot make clean after you fixed your shell? /Roman Am Mittwoch, den 14.05.2008, 12:56 -0700 schrieb Brad Wetmore: > I think you've got a problem still with your sh setup, or possibly > something else. IIRC, the ?replType? variables is supposed to be > replaced with various values depending on whether you have an encoder or > decoder. (sed/awk preprocessing = a Javaman's #ifdef equivalent) It's > done a similar way for the {Byte,Char,Int...}Buffers. > > Check jdk/make/java/nio, specifically Makefile, spp.sh, and genCoder.sh > > Hope this helps. > > Brad > > > Bram Somers wrote: > > Dear all, > > > > I've tried building jdk7 on Ubuntu 8.04. I'm aware of the problems with > > sh/dash and I remove sh and made a symlink of sh to bash, so normally I > > shouldn't get this error anymore: > > > > jdk7/build/openjdk_full_debug/gensrc/java/nio/charset/CharsetEncoder.java:142: > > cannot find symbol > > symbol : class $replType$ > > location: class java.nio.charset.CharsetEncoder > > private $replType$ replacement; > > ^ > > /home/bsomers/workspaces/openjdk/jdk7/build/openjdk_full_debug/gensrc/java/nio/charset/CharsetEncoder.java:185: > > cannot find symbol > > symbol : class $replType$ > > location: class java.nio.charset.CharsetEncoder > > $replType$ replacement) > > ^ > > /home/bsomers/workspaces/openjdk/jdk7/build/openjdk_full_debug/gensrc/java/nio/charset/CharsetEncoder.java:246: > > cannot find symbol > > symbol : class $replType$ > > location: class java.nio.charset.CharsetEncoder > > public final $replType$ replacement() { > > ^ > > /home/bsomers/workspaces/openjdk/jdk7/build/openjdk_full_debug/gensrc/java/nio/charset/CharsetEncoder.java:275: > > cannot find symbol > > symbol : class $replType$ > > location: class java.nio.charset.CharsetEncoder > > public final CharsetEncoder replaceWith($replType$ newReplacement) { > > ^ > > /home/bsomers/workspaces/openjdk/jdk7/build/openjdk_full_debug/gensrc/java/nio/charset/CharsetEncoder.java:301: > > cannot find symbol > > symbol : class $replType$ > > location: class java.nio.charset.CharsetEncoder > > protected void implReplaceWith($replType$ newReplacement) { > > ^ > > Note: Some input files use or override a deprecated API. > > Note: Recompile with -Xlint:deprecation for details. > > Note: Some input files use unchecked or unsafe operations. > > Note: Recompile with -Xlint:unchecked for details. > > 5 errors > > > > > > Any more suggestions? > > > > Thanks in advance, > > > > kind regards, > > > > Bram -- Dipl.-Inform. (FH) Roman Kennke, Software Engineer, http://kennke.org aicas Allerton Interworks Computer Automated Systems GmbH Haid-und-Neu-Stra?e 18 * D-76131 Karlsruhe * Germany http://www.aicas.com * Tel: +49-721-663 968-0 USt-Id: DE216375633, Handelsregister HRB 109481, AG Karlsruhe Gesch?ftsf?hrer: Dr. James J. Hunt From xiomara.jayasena at sun.com Wed May 14 21:16:11 2008 From: xiomara.jayasena at sun.com (xiomara.jayasena at sun.com) Date: Wed, 14 May 2008 21:16:11 +0000 Subject: hg: jdk7/build: 2 new changesets Message-ID: <20080514211611.88311280AE@hg.openjdk.java.net> Changeset: 613dea62de17 Author: xdono Date: 2008-04-24 12:12 -0700 URL: http://hg.openjdk.java.net/jdk7/build/rev/613dea62de17 Added tag jdk7-b26 for changeset 9410f77cc30c ! .hgtags Changeset: 11b4dc9f2be3 Author: xdono Date: 2008-05-13 11:31 -0700 URL: http://hg.openjdk.java.net/jdk7/build/rev/11b4dc9f2be3 Merge From xiomara.jayasena at sun.com Wed May 14 21:16:55 2008 From: xiomara.jayasena at sun.com (xiomara.jayasena at sun.com) Date: Wed, 14 May 2008 21:16:55 +0000 Subject: hg: jdk7/build/corba: Added tag jdk7-b26 for changeset 0043eb3d4e62 Message-ID: <20080514211656.F0E19280B3@hg.openjdk.java.net> Changeset: e84e9018bebb Author: xdono Date: 2008-04-24 12:12 -0700 URL: http://hg.openjdk.java.net/jdk7/build/corba/rev/e84e9018bebb Added tag jdk7-b26 for changeset 0043eb3d4e62 ! .hgtags From xiomara.jayasena at sun.com Wed May 14 21:18:28 2008 From: xiomara.jayasena at sun.com (xiomara.jayasena at sun.com) Date: Wed, 14 May 2008 21:18:28 +0000 Subject: hg: jdk7/build/hotspot: 85 new changesets Message-ID: <20080514212126.50D4A280B8@hg.openjdk.java.net> Changeset: 5ff61c9f5601 Author: jmasa Date: 2008-02-11 15:40 -0800 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/5ff61c9f5601 6624782: Bigapps crashes during CMS precleaning. Summary: Lowered optimization level for files instanceKlass.cpp and objArrayKlass.cpp Reviewed-by: ysr ! build/solaris/makefiles/amd64.make Changeset: f21b879b4c72 Author: ysr Date: 2008-02-12 16:07 -0800 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/f21b879b4c72 6659981: +ParallelRefProcEnabled crashes on single core platform Summary: Disable parallel reference processing when there are no worker threads Reviewed-by: apetrusenko, pbk, jmasa, tonyp ! src/share/vm/memory/referenceProcessor.cpp Changeset: 73e96e5c30df Author: jmasa Date: 2008-02-15 07:01 -0800 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/73e96e5c30df 6624765: Guarantee failure "Unexpected dirty card found" Summary: In verification take into account partial coverage of a region by a card and expansion of the card table. Reviewed-by: ysr, apetrusenko ! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp ! src/share/vm/memory/cardTableModRefBS.cpp ! src/share/vm/memory/cardTableRS.cpp ! src/share/vm/memory/cardTableRS.hpp ! src/share/vm/memory/genRemSet.hpp ! src/share/vm/memory/tenuredGeneration.cpp Changeset: 2faf283ce688 Author: ysr Date: 2008-02-16 22:41 -0800 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/2faf283ce688 6621144: CMS: assertion failure "is_cms_thread == Thread::current()->is_ConcurrentGC_thread()" Summary: Take lock conditionally (in asynchronous mode only) when updating the dead-object map. Reviewed-by: jmasa ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp Changeset: 762905818571 Author: jmasa Date: 2008-02-20 08:40 -0800 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/762905818571 6665445: Backout change to CardTableModRefBS::resize_covered_region() Summary: Backed out part of cahnge for 6624765 because of nightly testing regressions. Reviewers below were for 6624765. Reviewed-by: ysr, apetrusenko ! src/share/vm/memory/cardTableModRefBS.cpp Changeset: 173195ff483a Author: ysr Date: 2008-02-21 11:03 -0800 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/173195ff483a 6642634: Test nsk/regression/b6186200 crashed with SIGSEGV Summary: Use correct allocation path in expand_and_allocate() so object's mark and p-bits are set as appropriate. Reviewed-by: jmasa, pbk ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp Changeset: 28372612af5e Author: jmasa Date: 2008-02-22 17:17 -0800 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/28372612af5e 6362677: Change parallel GC collector default number of parallel GC threads. Summary: Use the same default number of GC threads as used by ParNewGC and ConcMarkSweepGC (i.e., the 5/8th rule). Reviewed-by: ysr, tonyp ! src/cpu/sparc/vm/vm_version_sparc.cpp ! src/cpu/sparc/vm/vm_version_sparc.hpp ! src/share/vm/gc_implementation/parallelScavenge/generationSizer.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/arguments.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/vm_version.cpp ! src/share/vm/runtime/vm_version.hpp Changeset: 3c1dbcaaab1d Author: ysr Date: 2008-02-26 15:57 -0800 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/3c1dbcaaab1d 6621728: Heap inspection should not crash in the face of C-heap exhaustion Summary: Deal more gracefully with situations where C-heap scratch space cannot be had Reviewed-by: jmasa ! src/share/vm/memory/heapInspection.cpp ! src/share/vm/memory/heapInspection.hpp Changeset: 6432c3bb6240 Author: ysr Date: 2008-02-29 14:42 -0800 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/6432c3bb6240 6668743: CMS: Consolidate block statistics reporting code Summary: Reduce the amount of related code replication and improve pretty printing. Reviewed-by: jmasa ! src/share/vm/gc_implementation/concurrentMarkSweep/binaryTreeDictionary.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/freeList.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/freeList.hpp ! src/share/vm/gc_implementation/includeDB_gc_shared + src/share/vm/gc_implementation/shared/allocationStats.cpp + src/share/vm/gc_implementation/shared/allocationStats.hpp ! src/share/vm/includeDB_core - src/share/vm/memory/allocationStats.cpp - src/share/vm/memory/allocationStats.hpp Changeset: 183f41cf8bfe Author: jmasa Date: 2008-03-02 16:10 -0800 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/183f41cf8bfe 6557851: CMS: ergonomics defaults are not set with FLAG_SET_ERGO Summary: Default values set by cms ergonomics are set with FLAG_SET_DEFAULT so down stream the values look like the default values and affect how later parameters are set. Set these values with FLAG_SET_ERGO instead and adjust how later parameters are interpreted. Reviewed-by: iveresov, apetrusenko, pbk, ysr ! src/share/vm/gc_implementation/parNew/asParNewGeneration.cpp ! src/share/vm/gc_implementation/parallelScavenge/asPSYoungGen.cpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.cpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.hpp ! src/share/vm/gc_implementation/parallelScavenge/psYoungGen.cpp ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/memory/collectorPolicy.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.cpp ! src/share/vm/runtime/globals_extension.hpp Changeset: 6228104986ca Author: jcoomes Date: 2008-03-05 17:37 -0800 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/6228104986ca Merge - src/share/vm/memory/allocationStats.cpp - src/share/vm/memory/allocationStats.hpp Changeset: d825a8a2bd39 Author: jmasa Date: 2008-03-11 14:19 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/d825a8a2bd39 6673975: Disable ZapUnusedHeapArea to reduce GC execution times of debug JVM's. Summary: Mangling the unused space is having an adverse affect on testing with fastdebug builds so turn it off by default. Reviewed-by: ysr, tonyp ! src/share/vm/runtime/globals.hpp Changeset: f8236e79048a Author: dcubed Date: 2007-12-05 09:00 -0800 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/f8236e79048a 6664627: Merge changes made only in hotspot 11 forward to jdk 7 Reviewed-by: jcoomes ! src/cpu/sparc/vm/stubGenerator_sparc.cpp ! src/cpu/sparc/vm/vtableStubs_sparc.cpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/cpu/x86/vm/vtableStubs_x86_32.cpp ! src/cpu/x86/vm/vtableStubs_x86_64.cpp ! src/share/vm/oops/klassVtable.cpp ! src/share/vm/oops/klassVtable.hpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/sharedRuntime.hpp ! src/share/vm/runtime/stubRoutines.cpp ! src/share/vm/runtime/stubRoutines.hpp Changeset: ff5961f4c095 Author: never Date: 2007-12-05 09:01 -0800 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/ff5961f4c095 6395208: Elide autoboxing for calls to HashMap.get(int) and HashMap.get(long) Reviewed-by: kvn, rasbold + src/share/vm/ci/ciObjArray.cpp ! src/share/vm/ci/ciObjArray.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/includeDB_core ! src/share/vm/opto/addnode.cpp ! src/share/vm/opto/addnode.hpp ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/cfgnode.hpp ! src/share/vm/opto/ifnode.cpp ! src/share/vm/opto/loopnode.cpp ! src/share/vm/opto/loopnode.hpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/memnode.hpp ! src/share/vm/opto/parse2.cpp ! src/share/vm/opto/type.hpp ! src/share/vm/runtime/arguments.cpp Changeset: c7d713375c94 Author: phh Date: 2007-12-05 09:02 -0800 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/c7d713375c94 6621621: HashMap front cache should be enabled only with AggressiveOpts Reviewed-by: sbohne, xlu ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/runtime/thread.cpp Changeset: a73cc31728fe Author: rasbold Date: 2007-12-05 09:03 -0800 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/a73cc31728fe 6614036: REGRESSION: Java server x86 VM intermittently crash with SIGSEGV (0xb) Summary: restore destination address in x86 32-bit checkcast_arraycopy stub Reviewed-by: jrose, kvn, never ! src/cpu/x86/vm/stubGenerator_x86_32.cpp Changeset: e195fe4c40c7 Author: phh Date: 2007-12-05 09:04 -0800 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/e195fe4c40c7 6629887: 64-bit windows should not restrict default heap size to 1400m Reviewed-by: jmasa, sbohne, ikrylov, xlu ! src/os/linux/vm/os_linux.cpp ! src/os/windows/vm/os_windows.cpp ! src/os_cpu/linux_x86/vm/os_linux_x86.cpp Changeset: b611e572fc5b Author: jcoomes Date: 2007-12-06 13:59 -0800 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/b611e572fc5b 6635560: segv in reference processor on t1000 Summary: Revert back to using the default page size for the card table Reviewed-by: pbk, phh ! src/share/vm/memory/cardTableModRefBS.cpp Changeset: 90f5ddc7297b Author: coleenp Date: 2008-01-17 13:38 -0800 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/90f5ddc7297b 6646946: Kernel installation failed on Japanese and Chinese XP SP2 (VM part) Summary: convert strings from Download Manager into native encoding in the VM Reviewed-by: sbohne, never, phh, kamg, xlu ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/systemDictionary.cpp Changeset: 9bdad1bb1c31 Author: kvn Date: 2008-02-12 18:37 -0800 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/9bdad1bb1c31 6621098: "* HeapWordSize" for TrackedInitializationLimit is missing Summary: '* HeapWordSize' is missing in GraphKit::set_output_for_allocation() Reviewed-by: rasbold, jrose, never ! src/share/vm/opto/graphKit.cpp Changeset: 953939ef62ab Author: kvn Date: 2008-02-20 16:19 -0800 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/953939ef62ab 6614330: Node::dump(n) does not print full graph for specified depth. Summary: A node is not processed in dump_nodes() if it was visited during processing previous inputs. Reviewed-by: rasbold ! src/share/vm/opto/node.cpp Changeset: c5cbd367e4d1 Author: kvn Date: 2008-02-20 17:23 -0800 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/c5cbd367e4d1 6621094: PrintOptoAssembly is broken for oops information in DebugInfo Summary: OopMapValue and VMRegImpl classes miss the virtual method print_on(st). Reviewed-by: rasbold, jrose, never ! src/share/vm/code/vmreg.cpp ! src/share/vm/code/vmreg.hpp ! src/share/vm/compiler/oopMap.cpp ! src/share/vm/compiler/oopMap.hpp Changeset: 0871d5cd64cd Author: kvn Date: 2008-02-21 14:03 -0800 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/0871d5cd64cd 6621084: ciMethodBlocks::split_block_at() is broken for methods with exception handler Summary: After an exception handler block is split the exception information is not moved to the new block which starts in exception handler BCI. Reviewed-by: jrose ! src/share/vm/ci/ciMethodBlocks.cpp ! src/share/vm/ci/ciMethodBlocks.hpp Changeset: 1f530c629c7d Author: kvn Date: 2008-02-21 19:03 -0800 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/1f530c629c7d 6498878: client compiler crashes on windows when dealing with breakpoint instructions Summary: _is_compilable check prevents breakpoint bytecodes reversion when loading bytecodes for ciMethod. Reviewed-by: never ! src/share/vm/ci/ciMethod.cpp Changeset: 67914967a4b5 Author: kvn Date: 2008-02-22 17:55 -0800 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/67914967a4b5 6650373: Assert in methodOopDesc::make_adapters() Summary: AdapterHandlerLibrary::get_create_adapter_index() returns incorrect value (-2) when CodeCache is full. Reviewed-by: sgoldman ! src/share/vm/opto/output.cpp ! src/share/vm/runtime/sharedRuntime.cpp Changeset: d5fc211aea19 Author: kvn Date: 2008-02-25 15:05 -0800 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/d5fc211aea19 6633953: type2aelembytes{T_ADDRESS} should be 8 bytes in 64 bit VM Summary: T_ADDRESS size is defined as 'int' size (4 bytes) but C2 use it for raw pointers and as memory type for StoreP and LoadP nodes. Reviewed-by: jrose ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/sparc/vm/c1_LIRGenerator_sparc.cpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp ! src/share/vm/c1/c1_LIR.cpp ! src/share/vm/ci/ciField.hpp ! src/share/vm/oops/arrayOop.hpp ! src/share/vm/oops/klass.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/memnode.hpp ! src/share/vm/opto/superword.cpp ! src/share/vm/opto/vectornode.cpp ! src/share/vm/opto/vectornode.hpp ! src/share/vm/services/heapDumper.cpp ! src/share/vm/utilities/globalDefinitions.cpp ! src/share/vm/utilities/globalDefinitions.hpp Changeset: 65a06b4a51b8 Author: jrose Date: 2008-02-27 00:23 -0800 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/65a06b4a51b8 6610906: inexplicable IncompatibleClassChangeError Summary: dependency check must treat polymorphic interfaces consistently Reviewed-by: kvn, never, sgoldman ! src/share/vm/code/dependencies.cpp ! src/share/vm/code/nmethod.cpp Changeset: 6152cbb08ce9 Author: kvn Date: 2008-02-28 10:45 -0800 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/6152cbb08ce9 6590177: jck60019 test assert(!repeated,"do not walk merges twice") Summary: A mergemem node could be not in worklist_store but in should_not_repeat vectorset since it was processed and removed from worklist_store before. Reviewed-by: jrose, never ! src/share/vm/opto/gcm.cpp Changeset: 4d428c5b4cb3 Author: kvn Date: 2008-02-28 15:40 -0800 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/4d428c5b4cb3 6667573: Use set_req_X() in AddPNode::Ideal() for Iterative GVN Summary: set_req_X() puts dependent nodes on IGVN worklist which allows to improve graph and gives more opportunities for EA scalar replacement. Reviewed-by: jrose, never ! src/share/vm/opto/addnode.cpp Changeset: 3288958bf319 Author: kvn Date: 2008-02-29 09:57 -0800 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/3288958bf319 6667580: Optimize CmpP for allocations Summary: CmpP could be optimized out if it compares new allocated objects. Reviewed-by: jrose, never, rasbold ! src/share/vm/includeDB_compiler2 ! src/share/vm/opto/callnode.hpp ! src/share/vm/opto/memnode.hpp ! src/share/vm/opto/node.hpp ! src/share/vm/opto/subnode.cpp Changeset: 545c277a3ecf Author: kvn Date: 2008-02-29 11:22 -0800 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/545c277a3ecf 6667581: Don't generate initialization (by 0) code for arrays with size 0 Summary: generate_arraycopy() does not check the size of allocated array. Reviewed-by: jrose, never ! src/share/vm/opto/library_call.cpp Changeset: e2ae28d2ce91 Author: kvn Date: 2008-02-29 19:07 -0800 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/e2ae28d2ce91 6667588: Don't generate duplicated CMP for float/double values Summary: float CMove generation add duplicated CMPF if there are more then one Move depending on the condition. Reviewed-by: jrose, never, rasbold ! src/share/vm/opto/loopopts.cpp Changeset: f34d9da7acb2 Author: kvn Date: 2008-02-29 19:57 -0800 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/f34d9da7acb2 6667618: disable LoadL->ConvL2I ==> LoadI optimization Summary: this optimization causes problems (sizes of Load and Store nodes do not match) for objects initialization code and Escape Analysis Reviewed-by: jrose, never ! src/share/vm/opto/connode.cpp ! src/share/vm/opto/memnode.cpp Changeset: 73970d8c0b27 Author: kvn Date: 2008-03-05 11:33 -0800 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/73970d8c0b27 6671250: In Parse::do_if() old Cmp node 'c' should be replaced with new one after BoolNode transformation Summary: In Parse::do_if() 'c' (CmpNode) node may be changed during BoolNode transformation so 'c' may became dead but the node is referenced later in the code. Reviewed-by: never ! src/share/vm/opto/parse2.cpp Changeset: b789bcaf2dd9 Author: kvn Date: 2008-03-06 10:30 -0800 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/b789bcaf2dd9 6667610: (Escape Analysis) retry compilation without EA if it fails Summary: During split unique types EA could exceed nodes limit and fail the method compilation. Reviewed-by: rasbold ! src/share/vm/includeDB_compiler2 ! src/share/vm/opto/c2compiler.cpp ! src/share/vm/opto/c2compiler.hpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/parse1.cpp Changeset: 76256d272075 Author: kvn Date: 2008-03-06 10:53 -0800 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/76256d272075 6667612: (Escape Analysis) disable loop cloning if it has a scalar replaceable allocation Summary: Cloning an allocation will not allow scalar replacement since memory operations could not be associated with one allocation. Reviewed-by: rasbold ! src/share/vm/opto/callnode.cpp ! src/share/vm/opto/callnode.hpp ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/opto/loopnode.cpp ! src/share/vm/opto/loopnode.hpp Changeset: 7c1f32ae4a20 Author: kvn Date: 2008-03-06 20:58 -0800 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/7c1f32ae4a20 6670459: Fix Node::dump() performance Summary: dump full ideal graph takes forever. Reviewed-by: never, rasbold ! src/share/vm/opto/node.cpp ! src/share/vm/opto/node.hpp Changeset: 874b2c4f43d1 Author: kvn Date: 2008-03-07 11:09 -0800 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/874b2c4f43d1 6667605: (Escape Analysis) inline java constructors when EA is on Summary: java constructors should be inlined to be able scalar replace a new object Reviewed-by: rasbold ! src/share/vm/opto/bytecodeInfo.cpp ! src/share/vm/opto/parse.hpp ! src/share/vm/opto/phaseX.cpp Changeset: 1216832af221 Author: jcoomes Date: 2008-03-10 17:21 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/1216832af221 Merge Changeset: d821d920b465 Author: kvn Date: 2008-03-11 11:04 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/d821d920b465 6623167: C2 crashed in StoreCMNode::Value Summary: C2 crashed in StoreCMNode::Value because n->in(MemNode::OopStore) is 0. Reviewed-by: rasbold, never ! src/share/vm/opto/memnode.cpp Changeset: 52fed2ec0afb Author: kvn Date: 2008-03-11 11:25 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/52fed2ec0afb 6667620: (Escape Analysis) fix deoptimization for scalar replaced objects Summary: Deoptimization code for reallocation and relocking scalar replaced objects has to be fixed. Reviewed-by: rasbold, never ! src/share/vm/ci/ciInstanceKlass.cpp ! src/share/vm/ci/ciInstanceKlass.hpp ! src/share/vm/code/debugInfo.cpp ! src/share/vm/code/scopeDesc.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/runtime/deoptimization.cpp Changeset: 48a3fa21394b Author: kvn Date: 2008-03-11 19:00 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/48a3fa21394b 6667615: (Escape Analysis) extend MDO to cache arguments escape state Summary: Use MDO to cache arguments escape state determined by the byte code escape analyzer. Reviewed-by: never ! src/share/vm/ci/bcEscapeAnalyzer.cpp ! src/share/vm/ci/bcEscapeAnalyzer.hpp ! src/share/vm/ci/ciMethodData.cpp ! src/share/vm/ci/ciMethodData.hpp ! src/share/vm/classfile/vmSymbols.cpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/oops/methodDataOop.cpp ! src/share/vm/oops/methodDataOop.hpp Changeset: 8b6e49187640 Author: rasbold Date: 2008-03-13 05:40 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/8b6e49187640 Merge ! src/share/vm/includeDB_core ! src/share/vm/memory/cardTableModRefBS.cpp ! src/share/vm/runtime/arguments.cpp Changeset: 2c106685d6d0 Author: dcubed Date: 2008-03-12 18:06 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/2c106685d6d0 6497639: 4/3 Profiling Swing application caused JVM crash Summary: Make RedefineClasses() interoperate better with class sharing. Reviewed-by: sspitsyn, jmasa ! src/share/vm/classfile/dictionary.cpp ! src/share/vm/memory/compactingPermGenGen.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp Changeset: d8b3ef7ee3e5 Author: dcubed Date: 2008-03-12 18:07 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/d8b3ef7ee3e5 6599425: 4/3 OopMapCache::lookup() can cause later crash or assert() failure Summary: Add should_not_be_cached() to markOop and methodOop and query that status inOopMapCache::lookup() Reviewed-by: coleenp, sspitsyn, jmasa ! src/share/vm/includeDB_core ! src/share/vm/interpreter/oopMapCache.cpp ! src/share/vm/oops/markOop.cpp ! src/share/vm/oops/markOop.hpp ! src/share/vm/oops/methodOop.cpp ! src/share/vm/oops/methodOop.hpp ! src/share/vm/prims/jvmtiRedefineClassesTrace.hpp Changeset: 31000d79ec71 Author: dcubed Date: 2008-03-12 18:09 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/31000d79ec71 6453355: 4/4 new No_Safepoint_Verifier uses fail during GC Summary: (for Serguei) Clean up use of No_Safepoint_Verifier in JVM TI Reviewed-by: dcubed ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/runtime/thread.cpp Changeset: 485d403e94e1 Author: dcubed Date: 2008-03-12 18:37 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/485d403e94e1 6452081: 3/4 Allow for Linux builds with Sun Studio Linux compilers Summary: (for Serguei) Allow for Linux builds with Sun Studio Linux compilers Reviewed-by: sspitsyn, ohair ! agent/src/os/linux/ps_core.c ! agent/src/os/linux/ps_proc.c ! build/linux/Makefile ! build/linux/makefiles/amd64.make ! build/linux/makefiles/buildtree.make + build/linux/makefiles/sparcWorks.make + build/linux/platform_amd64.suncc + build/linux/platform_i486.suncc ! src/cpu/x86/vm/assembler_x86_64.cpp ! src/os/linux/vm/attachListener_linux.cpp ! src/os_cpu/linux_x86/vm/bytes_linux_x86.inline.hpp ! src/os_cpu/linux_x86/vm/os_linux_x86.cpp ! src/share/vm/utilities/globalDefinitions_sparcWorks.hpp Changeset: 1ffa5cdd0b7e Author: dcubed Date: 2008-03-12 18:39 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/1ffa5cdd0b7e 6667089: 3/3 multiple redefinitions of a class break reflection Summary: Use instanceKlass::method_with_idnum() instead of slot() to work with RedefineClasses(). Reviewed-by: sspitsyn ! src/share/vm/runtime/reflection.cpp Changeset: 75b0f3cb1943 Author: dcubed Date: 2008-03-13 14:17 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/75b0f3cb1943 Merge ! src/os_cpu/linux_x86/vm/os_linux_x86.cpp ! src/share/vm/includeDB_core ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/runtime/thread.cpp Changeset: 9785f6d2dd97 Author: kamg Date: 2008-01-31 09:41 -0500 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/9785f6d2dd97 6631248: Memory problem when doing invalid type cast Summary: Changed memory allocation method for exception method Reviewed-by: ysr, never ! src/share/vm/runtime/sharedRuntime.cpp Changeset: d4a0f561287a Author: sbohne Date: 2008-01-31 14:56 -0500 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/d4a0f561287a 6598190: JPRT tests fail when run with -XX:+CheckUnhandledOops Summary: Work around Sun Studio C++ compiler bug 6629277 in dependencies.cpp Reviewed-by: kamg, sgoldman, pbk ! src/share/vm/code/dependencies.cpp Changeset: 2a8eb116ebbe Author: xlu Date: 2008-02-05 23:21 -0800 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/2a8eb116ebbe 6610420: Debug VM crashes during monitor lock rank checking Summary: Make SerializePage lock as raw lock and add name for mutex locks Reviewed-by: never, dice, dholmes ! src/share/vm/runtime/mutex.cpp ! src/share/vm/runtime/mutex.hpp ! src/share/vm/runtime/mutexLocker.cpp ! src/share/vm/runtime/mutexLocker.hpp ! src/share/vm/runtime/os.cpp Changeset: 31d829b33f26 Author: coleenp Date: 2008-02-27 13:55 -0500 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/31d829b33f26 6549844: Wording problems in "An unexpected error ..." Summary: Changed wording to "A fatal error.." also don't claim it's not VM bug if in hotspot compilers (Java thread in native). Reviewed-by: jjh, sbohne, jrose, never ! src/share/vm/utilities/vmError.cpp Changeset: ff0979201b06 Author: sbohne Date: 2008-03-03 14:47 -0500 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/ff0979201b06 6655385: Disable frame pointer omission in jvm.dll on Windows for better crash logs Summary: Add /Oy- C++ compiler option on Windows Reviewed-by: phh, never, ysr ! build/windows/makefiles/compile.make Changeset: 7ee622712fcf Author: sbohne Date: 2008-03-04 09:44 -0500 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/7ee622712fcf 6666698: EnableBiasedLocking with BiasedLockingStartupDelay can block Watcher thread Summary: Enqueue VM_EnableBiasedLocking operation asynchronously Reviewed-by: never, xlu, kbr, acorn ! src/share/vm/runtime/biasedLocking.cpp Changeset: 887682771f69 Author: jcoomes Date: 2008-03-12 16:31 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/887682771f69 Merge Changeset: 8d84e28e68ba Author: sbohne Date: 2008-03-14 10:43 -0400 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/8d84e28e68ba 6204603: Modify hotspot to use new Solaris mmap semantics for class data archive file Summary: os::attempt_reserve_memory_at() now passes an address hint to mmap Reviewed-by: kamg, dice ! src/os/solaris/vm/os_solaris.cpp ! src/os/solaris/vm/os_solaris.hpp Changeset: 5a76ab815e34 Author: sbohne Date: 2008-03-19 09:58 -0400 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/5a76ab815e34 6667833: Remove CacheTimeMillis Summary: Remove -XX:+CacheTimeMillis option and associated functionality Reviewed-by: acorn, never ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/java.cpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/os.hpp ! src/share/vm/runtime/task.cpp ! src/share/vm/runtime/task.hpp ! src/share/vm/runtime/thread.cpp Changeset: cd0742ba123c Author: kamg Date: 2008-03-20 09:17 -0500 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/cd0742ba123c Merge ! src/os/linux/vm/os_linux.cpp ! src/os/windows/vm/os_windows.cpp ! src/share/vm/code/dependencies.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/thread.cpp Changeset: eac007780a58 Author: kvn Date: 2008-03-13 16:06 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/eac007780a58 6671807: (Escape Analysis) Add new ideal node to represent the state of a scalarized object at a safepoint Summary: Values of non-static fields of a scalarized object should be saved in debug info to reallocate the object during deoptimization. Reviewed-by: never ! src/share/vm/opto/callnode.cpp ! src/share/vm/opto/callnode.hpp ! src/share/vm/opto/classes.hpp ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/matcher.cpp ! src/share/vm/opto/node.hpp ! src/share/vm/opto/output.cpp Changeset: b8f5ba577b02 Author: kvn Date: 2008-03-13 16:31 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/b8f5ba577b02 6673473: (Escape Analysis) Add the instance's field information to PhiNode Summary: Avoid an infinite generation of instance's field values Phi nodes. Reviewed-by: never ! src/share/vm/opto/cfgnode.hpp ! src/share/vm/opto/loopopts.cpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/memnode.hpp ! src/share/vm/opto/type.cpp ! src/share/vm/opto/type.hpp Changeset: 99269dbf4ba8 Author: kvn Date: 2008-03-14 15:26 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/99269dbf4ba8 6674588: (Escape Analysis) Improve Escape Analysis code Summary: Current EA code has several problems which have to be fixed. Reviewed-by: jrose, sgoldman ! src/share/vm/includeDB_compiler2 ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/callnode.cpp ! src/share/vm/opto/callnode.hpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/escape.hpp ! src/share/vm/opto/node.cpp ! src/share/vm/opto/node.hpp ! src/share/vm/opto/phaseX.cpp ! src/share/vm/runtime/arguments.cpp Changeset: 6dbf1a175d6b Author: kvn Date: 2008-03-14 16:40 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/6dbf1a175d6b 6672848: (Escape Analysis) improve lock elimination with EA Summary: Remove lock/unlock MemBar nodes and specify locks in debug info for deoptimization. Reviewed-by: never ! src/share/vm/opto/callnode.cpp ! src/share/vm/opto/locknode.cpp ! src/share/vm/opto/locknode.hpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/macro.hpp ! src/share/vm/opto/output.cpp Changeset: 16e1cb7cde24 Author: never Date: 2008-03-18 11:17 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/16e1cb7cde24 6666343: Compile::has_loops not always set correctly Summary: Compile::has_loops() should be set from inlined methods Reviewed-by: kvn, rasbold ! src/share/vm/opto/doCall.cpp Changeset: daf38130e60d Author: never Date: 2008-03-18 23:44 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/daf38130e60d 6676841: ClearArrayNode::Identity is incorrect for 64-bit Summary: ClearArrayNode::Identity should use TypeX instead of TypeInt Reviewed-by: jrose, kvn, sgoldman ! src/share/vm/opto/memnode.cpp Changeset: 8bb88f9877e5 Author: never Date: 2008-03-18 23:54 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/8bb88f9877e5 6659207: access violation in CompilerThread0 Summary: split_thru_phi produces top on a non-dead path Reviewed-by: kvn, rasbold, sgoldman ! src/share/vm/opto/loopopts.cpp + test/compiler/6659207/Test.java Changeset: b683f557224b Author: never Date: 2008-03-19 15:14 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/b683f557224b 6661247: Internal bug in 32-bit HotSpot optimizer while bit manipulations Summary: copy elimination of a constant value results in incorrect execution Reviewed-by: kvn, sgoldman, rasbold ! src/share/vm/opto/chaitin.hpp ! src/share/vm/opto/postaloc.cpp + test/compiler/6661247/Test.java Changeset: 3d62cb85208d Author: kvn Date: 2008-03-19 15:33 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/3d62cb85208d 6662967: Optimize I2D conversion on new x86 Summary: Use CVTDQ2PS and CVTDQ2PD for integer values conversions to float and double values on new AMD cpu. Reviewed-by: sgoldman, never ! src/cpu/x86/vm/assembler_x86_32.cpp ! src/cpu/x86/vm/assembler_x86_32.hpp ! src/cpu/x86/vm/assembler_x86_64.cpp ! src/cpu/x86/vm/assembler_x86_64.hpp ! src/cpu/x86/vm/vm_version_x86_32.cpp ! src/cpu/x86/vm/vm_version_x86_64.cpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/runtime/globals.hpp Changeset: f705f25597eb Author: never Date: 2008-03-20 10:43 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/f705f25597eb 6663621: JVM crashes while trying to execute api/java_security/Signature/SignatureTests.html#initSign tests. Summary: alignment expression with secondary induction variables is sometimes wrong Reviewed-by: kvn, rasbold ! src/share/vm/opto/superword.cpp + test/compiler/6663621/IVTest.java Changeset: a8880a78d355 Author: kvn Date: 2008-03-20 13:51 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/a8880a78d355 6259129: (Escape Analysis) scalar replacement for not escaping objects Summary: Use scalar replacement with EA to remove allocations for objects which do not escape the compiled method. Reviewed-by: rasbold, never, jrose ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/macro.hpp ! src/share/vm/opto/phaseX.hpp Changeset: 2a9af0b9cb1c Author: kvn Date: 2008-03-20 15:11 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/2a9af0b9cb1c 6674600: (Escape Analysis) Optimize memory graph for instance's fields Summary: EA gives opportunite to do more aggressive memory optimizations. Reviewed-by: never, jrose ! src/share/vm/opto/callnode.cpp ! src/share/vm/opto/callnode.hpp ! src/share/vm/opto/cfgnode.cpp ! src/share/vm/opto/cfgnode.hpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/memnode.hpp Changeset: f68325221ce1 Author: kvn Date: 2008-03-21 00:49 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/f68325221ce1 6678377: Update build number for HS12 Summary: b01 -> b02 Reviewed-by: kvn ! make/hotspot_version Changeset: d6fe2e4959d6 Author: rasbold Date: 2008-03-21 08:32 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/d6fe2e4959d6 Merge ! src/cpu/x86/vm/assembler_x86_64.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: 36cd3cc4d27b Author: kvn Date: 2008-03-27 09:12 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/36cd3cc4d27b 6679854: assert in escape.cpp:397 Summary: The assert misses the case CastX2P 'base' for an unsafe field reference Reviewed-by: never, jrose ! src/share/vm/opto/escape.cpp Changeset: e1e86702e43e Author: kvn Date: 2008-03-28 11:52 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/e1e86702e43e 6680665: bytecode Escape Analyzer produces incorrect escape information for methods without oop arguments Summary: bcEscapeAnalyzer does not analyze methods with no oop arguments. Reviewed-by: rasbold ! src/share/vm/ci/bcEscapeAnalyzer.cpp ! src/share/vm/ci/bcEscapeAnalyzer.hpp ! src/share/vm/oops/methodDataOop.hpp Changeset: 82db0859acbe Author: jcoomes Date: 2008-03-28 23:35 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/82db0859acbe 6642862: Code cache allocation fails with large pages after 6588638 Reviewed-by: apetrusenko ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp ! src/share/vm/gc_implementation/parallelScavenge/parMarkBitMap.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/memory/heap.cpp ! src/share/vm/runtime/os.hpp Changeset: 092ea87cc974 Author: jcoomes Date: 2008-03-28 23:35 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/092ea87cc974 6679422: networkStream::connect() in ostream.cpp is not 64-bit clean Reviewed-by: jmasa, xlu ! src/share/vm/utilities/ostream.cpp Changeset: dee7a3f3dc9d Author: never Date: 2008-03-31 16:22 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/dee7a3f3dc9d 6636352: Unit tests for supplementary character support fail with -XX:+AggressiveOpts Summary: incorrect encoding Reviewed-by: kvn, rasbold, sgoldman, jrose ! src/cpu/sparc/vm/sparc.ad Changeset: de93acbb64fc Author: kvn Date: 2008-03-31 18:37 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/de93acbb64fc 6682236: C2 hits ideal nodes limit during IGVN optimization with EA Summary: missing check in LoadNode::Ideal() causes infinite generation of a value Phi. Reviewed-by: jrose, never ! src/share/vm/opto/memnode.cpp Changeset: d3cd40645d0d Author: kvn Date: 2008-04-01 16:14 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/d3cd40645d0d 6681646: Relocking of a scalar replaced object during deoptimization is broken Summary: Relocking of a thread-local object during deoptimization is broken Reviewed-by: kbr, jrose, never ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/runtime/deoptimization.hpp ! src/share/vm/runtime/vframe.cpp ! src/share/vm/runtime/vframe.hpp ! src/share/vm/runtime/vframe_hp.cpp Changeset: 6e085831cad7 Author: sbohne Date: 2008-04-10 15:49 -0400 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/6e085831cad7 6692235: Fix for 6666698 broke -XX:BiasedLockingStartupDelay=0 Summary: Stack allocated VM_EnableBiasedLocking op must be marked as such Reviewed-by: xlu, acorn, never, dholmes ! src/share/vm/runtime/biasedLocking.cpp Changeset: f3b3fe64f59f Author: kvn Date: 2008-04-15 10:49 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/f3b3fe64f59f 6692301: Side effect in NumberFormat tests with -server -Xcomp Summary: Optimization in CmpPNode::sub() removed the valid compare instruction because of false positive answer from detect_dominating_control(). Reviewed-by: jrose, sgoldman ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/memnode.hpp ! src/share/vm/opto/node.cpp ! src/share/vm/opto/node.hpp Changeset: 6cc3576e5142 Author: jcoomes Date: 2008-04-16 15:34 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/6cc3576e5142 6689788: Bump HSX12 build version number Summary: Update HSX12 build number to 03 Reviewed-by: kvn ! make/hotspot_version Changeset: ad0b851458ff Author: trims Date: 2008-04-22 15:36 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/ad0b851458ff Merge - src/share/vm/memory/allocationStats.cpp - src/share/vm/memory/allocationStats.hpp Changeset: 24706b95d959 Author: xdono Date: 2008-04-24 12:12 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/24706b95d959 Added tag jdk7-b26 for changeset ad0b851458ff ! .hgtags From xiomara.jayasena at sun.com Wed May 14 21:24:15 2008 From: xiomara.jayasena at sun.com (xiomara.jayasena at sun.com) Date: Wed, 14 May 2008 21:24:15 +0000 Subject: hg: jdk7/build/jaxp: Added tag jdk7-b26 for changeset da43cb85fac1 Message-ID: <20080514212417.2B6FA280BD@hg.openjdk.java.net> Changeset: bafed478d67c Author: xdono Date: 2008-04-24 12:12 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jaxp/rev/bafed478d67c Added tag jdk7-b26 for changeset da43cb85fac1 ! .hgtags From xiomara.jayasena at sun.com Wed May 14 21:25:01 2008 From: xiomara.jayasena at sun.com (xiomara.jayasena at sun.com) Date: Wed, 14 May 2008 21:25:01 +0000 Subject: hg: jdk7/build/jaxws: Added tag jdk7-b26 for changeset debd37e1a422 Message-ID: <20080514212503.86C81280C2@hg.openjdk.java.net> Changeset: 27d8f42862c1 Author: xdono Date: 2008-04-24 12:12 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jaxws/rev/27d8f42862c1 Added tag jdk7-b26 for changeset debd37e1a422 ! .hgtags From xiomara.jayasena at sun.com Wed May 14 21:28:01 2008 From: xiomara.jayasena at sun.com (xiomara.jayasena at sun.com) Date: Wed, 14 May 2008 21:28:01 +0000 Subject: hg: jdk7/build/jdk: 72 new changesets Message-ID: <20080514214238.274C2280C7@hg.openjdk.java.net> Changeset: 256d28e3fd98 Author: xdono Date: 2008-04-24 12:12 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/256d28e3fd98 Added tag jdk7-b26 for changeset fb57027902e0 ! .hgtags Changeset: c2019d1360ef Author: ksrini Date: 2008-04-10 09:02 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/c2019d1360ef 6684582: Launcher needs improved error reporting Summary: indicate the missing main class in the error message Reviewed-by: darcy, kbr ! src/share/bin/emessages.h ! src/share/bin/java.c ! test/tools/launcher/Arrrghs.java ! test/tools/launcher/Arrrghs.sh Changeset: cb934dd5e073 Author: sherman Date: 2008-04-10 14:45 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/cb934dd5e073 6529796: Support JIS X 0213:2004 in existing JDK versions, especially for Windows Vista Summary: SJIS0213 support Reviewed-by: naoto ! make/java/sun_nio/FILES_java.gmk ! make/sun/nio/Makefile + make/tools/CharsetMapping/Makefile + make/tools/CharsetMapping/sjis0213.map ! make/tools/Makefile + make/tools/src/build/tools/charsetmapping/CharsetMapping.java + make/tools/src/build/tools/charsetmapping/GenerateMapping.java + src/share/classes/sun/nio/cs/CharsetMapping.java ! src/share/classes/sun/nio/cs/ext/ExtendedCharsets.java + src/share/classes/sun/nio/cs/ext/MS932_0213.java + src/share/classes/sun/nio/cs/ext/SJIS_0213.java Changeset: fd563c5dd750 Author: mchung Date: 2008-04-10 10:47 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/fd563c5dd750 6610094: Add generic support for platform MXBeans of any type (also fixed 6681031) Summary: Add new methods in ManagementFactory class to obtain platform MXBeans Reviewed-by: alanb, dfuchs, emcmanus ! src/share/classes/com/sun/management/HotSpotDiagnosticMXBean.java ! src/share/classes/java/lang/management/ClassLoadingMXBean.java ! src/share/classes/java/lang/management/CompilationMXBean.java ! src/share/classes/java/lang/management/GarbageCollectorMXBean.java ! src/share/classes/java/lang/management/ManagementFactory.java ! src/share/classes/java/lang/management/MemoryMXBean.java ! src/share/classes/java/lang/management/MemoryManagerMXBean.java ! src/share/classes/java/lang/management/MemoryPoolMXBean.java ! src/share/classes/java/lang/management/OperatingSystemMXBean.java + src/share/classes/java/lang/management/PlatformComponent.java + src/share/classes/java/lang/management/PlatformManagedObject.java ! src/share/classes/java/lang/management/RuntimeMXBean.java ! src/share/classes/java/lang/management/ThreadInfo.java ! src/share/classes/java/lang/management/ThreadMXBean.java ! src/share/classes/java/util/logging/Logging.java ! src/share/classes/java/util/logging/LoggingMXBean.java ! src/share/classes/sun/management/ClassLoadingImpl.java ! src/share/classes/sun/management/CompilationImpl.java ! src/share/classes/sun/management/GarbageCollectorImpl.java ! src/share/classes/sun/management/GcInfoBuilder.java ! src/share/classes/sun/management/GcInfoCompositeData.java ! src/share/classes/sun/management/HotSpotDiagnostic.java ! src/share/classes/sun/management/HotspotCompilation.java ! src/share/classes/sun/management/HotspotInternal.java ! src/share/classes/sun/management/LockDataConverter.java ! src/share/classes/sun/management/ManagementFactory.java + src/share/classes/sun/management/ManagementFactoryHelper.java ! src/share/classes/sun/management/MappedMXBeanType.java ! src/share/classes/sun/management/MemoryImpl.java ! src/share/classes/sun/management/MemoryManagerImpl.java ! src/share/classes/sun/management/MemoryNotifInfoCompositeData.java ! src/share/classes/sun/management/MemoryPoolImpl.java ! src/share/classes/sun/management/MemoryUsageCompositeData.java ! src/share/classes/sun/management/MonitorInfoCompositeData.java ! src/share/classes/sun/management/NotificationEmitterSupport.java ! src/share/classes/sun/management/OperatingSystemImpl.java ! src/share/classes/sun/management/RuntimeImpl.java ! src/share/classes/sun/management/StackTraceElementCompositeData.java ! src/share/classes/sun/management/ThreadImpl.java ! src/share/classes/sun/management/ThreadInfoCompositeData.java ! src/share/classes/sun/management/Util.java ! src/share/classes/sun/management/VMManagementImpl.java ! src/share/classes/sun/management/VMOptionCompositeData.java ! test/com/sun/management/HotSpotDiagnosticMXBean/DumpHeap.java ! test/com/sun/management/HotSpotDiagnosticMXBean/GetDiagnosticOptions.java ! test/com/sun/management/HotSpotDiagnosticMXBean/GetVMOption.java ! test/com/sun/management/HotSpotDiagnosticMXBean/SetVMOption.java + test/java/lang/management/ManagementFactory/GetPlatformMXBeans.java + test/java/lang/management/OperatingSystemMXBean/PlatformMXBeanTest.java Changeset: bcf689d26c1c Author: mchung Date: 2008-04-10 16:11 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/bcf689d26c1c Merge Changeset: 18eed13fe9f6 Author: mchung Date: 2008-04-11 10:26 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/18eed13fe9f6 6687508: Update test/sun/management jtreg tests due to sun.management.ManagementFactory class rename Summary: Modified the jtreg tests to use ManagementFactoryHelper instead Reviewed-by: emcmanus ! test/sun/management/HotspotClassLoadingMBean/GetClassInitializationTime.java ! test/sun/management/HotspotClassLoadingMBean/GetClassLoadingTime.java ! test/sun/management/HotspotClassLoadingMBean/GetInitializedClassCount.java ! test/sun/management/HotspotClassLoadingMBean/GetLoadedClassSize.java ! test/sun/management/HotspotClassLoadingMBean/GetMethodDataSize.java ! test/sun/management/HotspotClassLoadingMBean/GetUnloadedClassSize.java ! test/sun/management/HotspotRuntimeMBean/GetSafepointCount.java ! test/sun/management/HotspotRuntimeMBean/GetSafepointSyncTime.java ! test/sun/management/HotspotRuntimeMBean/GetTotalSafepointTime.java ! test/sun/management/HotspotThreadMBean/GetInternalThreads.java Changeset: dd212ba9a0c6 Author: sherman Date: 2008-04-14 21:45 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/dd212ba9a0c6 6635133: Exception thrown when using a Unicode escape Summary: Update regex engine to handle unicode escape correctly in character class Reviewed-by: okutsu ! src/share/classes/java/util/regex/Pattern.java Changeset: 74a42d77106b Author: tbell Date: 2008-04-15 17:46 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/74a42d77106b Merge Changeset: 2bfddc119eea Author: kamg Date: 2008-04-17 22:00 -0400 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/2bfddc119eea 6690122: Provide a mechanism for specifying Java-level USDT-like dtrace probes Summary: Initial checkin of JSDT code Reviewed-by: sspitsyn, sbohne ! make/com/sun/Makefile + make/com/sun/tracing/Makefile + make/com/sun/tracing/dtrace/Makefile ! make/docs/Makefile ! make/docs/NON_CORE_PKGS.gmk ! make/sun/Makefile + make/sun/tracing/Makefile + make/sun/tracing/dtrace/Makefile + make/sun/tracing/dtrace/mapfile-vers + src/share/classes/com/sun/tracing/Probe.java + src/share/classes/com/sun/tracing/ProbeName.java + src/share/classes/com/sun/tracing/Provider.java + src/share/classes/com/sun/tracing/ProviderFactory.java + src/share/classes/com/sun/tracing/ProviderName.java + src/share/classes/com/sun/tracing/dtrace/ArgsAttributes.java + src/share/classes/com/sun/tracing/dtrace/Attributes.java + src/share/classes/com/sun/tracing/dtrace/DependencyClass.java + src/share/classes/com/sun/tracing/dtrace/FunctionAttributes.java + src/share/classes/com/sun/tracing/dtrace/FunctionName.java + src/share/classes/com/sun/tracing/dtrace/ModuleAttributes.java + src/share/classes/com/sun/tracing/dtrace/ModuleName.java + src/share/classes/com/sun/tracing/dtrace/NameAttributes.java + src/share/classes/com/sun/tracing/dtrace/ProviderAttributes.java + src/share/classes/com/sun/tracing/dtrace/StabilityLevel.java + src/share/classes/com/sun/tracing/dtrace/package-info.java + src/share/classes/com/sun/tracing/package-info.java + src/share/classes/sun/tracing/MultiplexProviderFactory.java + src/share/classes/sun/tracing/NullProviderFactory.java + src/share/classes/sun/tracing/PrintStreamProviderFactory.java + src/share/classes/sun/tracing/ProbeSkeleton.java + src/share/classes/sun/tracing/ProviderSkeleton.java + src/share/classes/sun/tracing/dtrace/Activation.java + src/share/classes/sun/tracing/dtrace/DTraceProbe.java + src/share/classes/sun/tracing/dtrace/DTraceProvider.java + src/share/classes/sun/tracing/dtrace/DTraceProviderFactory.java + src/share/classes/sun/tracing/dtrace/JVM.java + src/share/classes/sun/tracing/package-info.java ! src/share/javavm/export/jvm.h + src/share/native/sun/tracing/dtrace/JVM.c + src/share/native/sun/tracing/dtrace/jvm_symbols.h + src/solaris/native/sun/tracing/dtrace/jvm_symbols_md.c + src/windows/native/sun/tracing/dtrace/jvm_symbols_md.c + test/com/sun/tracing/BasicFunctionality.java Changeset: 79b594e72df0 Author: kamg Date: 2008-04-21 11:24 -0400 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/79b594e72df0 6691494: doc build broken in tracingdocs Summary: Wrong variable names in makefile Reviewed-by: tbell ! make/docs/Makefile Changeset: 2249879c6f22 Author: tbell Date: 2008-04-25 15:18 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/2249879c6f22 Merge ! make/tools/Makefile Changeset: 5a0950c45a27 Author: xdono Date: 2008-05-13 11:33 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/5a0950c45a27 Merge Changeset: 94638b3696a6 Author: peterz Date: 2008-04-03 16:41 +0400 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/94638b3696a6 4714674: JEditorPane.setPage(url) blocks AWT thread when HTTP protocol is used Summary: Both POST and GET can now be processed asynchronously; PageLoader refactored Reviewed-by: gsm ! src/share/classes/javax/swing/JEditorPane.java + test/javax/swing/JEditorPane/bug4714674.java Changeset: 56646502accb Author: peterz Date: 2008-04-07 13:07 +0400 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/56646502accb 4765383: JTextArea.append(String) not thread safe Summary: Several swing.text methods are not marked thread-safe anymore. Reviewed-by: gsm ! src/share/classes/javax/swing/JEditorPane.java ! src/share/classes/javax/swing/JTextArea.java ! src/share/classes/javax/swing/JTextPane.java ! src/share/classes/javax/swing/text/JTextComponent.java Changeset: eecc88fb2430 Author: stayer Date: 2008-04-11 16:25 +0400 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/eecc88fb2430 6624717: Corrupted combo box, GTK L&F, Ubuntu 7.10 Reviewed-by: peterz ! src/solaris/native/sun/awt/gtk2_interface.c Changeset: 147803acf437 Author: mlapshin Date: 2008-04-14 16:41 +0400 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/147803acf437 6612531: api/javax_swing/ScrollPaneLayout/index.html#xxxLayoutSize (ScrollPaneLayout2024) throws NPE Summary: Added a check for the NPE Reviewed-by: alexp ! src/share/classes/javax/swing/ScrollPaneLayout.java + test/javax/swing/JScrollPane/6612531/bug6612531.java Changeset: dd66920b2d51 Author: mlapshin Date: 2008-04-18 18:21 +0400 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/dd66920b2d51 6675802: Regression: heavyweight popups cause SecurityExceptions in applets Summary: The problem code in Popup class is surrounded by AccessController.doPrivileged() Reviewed-by: alexp ! src/share/classes/javax/swing/Popup.java + test/javax/swing/JPopupMenu/6675802/bug6675802.java Changeset: 40414219305f Author: mlapshin Date: 2008-04-23 18:06 +0400 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/40414219305f 6691503: Malicious applet can show always-on-top popup menu which has whole screen size Summary: The fix for 6675802 is replaced by a try-catch clause that catches SequrityExceptions for applets. Reviewed-by: alexp ! src/share/classes/javax/swing/Popup.java + test/javax/swing/JPopupMenu/6691503/bug6691503.java Changeset: a15dae99414c Author: mlapshin Date: 2008-04-24 05:58 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/a15dae99414c Merge Changeset: a883bd215e94 Author: mlapshin Date: 2008-04-29 06:30 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/a883bd215e94 Merge Changeset: de9e902b1f24 Author: dav Date: 2008-03-24 18:24 +0300 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/de9e902b1f24 6638872: invalid links Summary: removed invalid links Reviewed-by: dcherepanov ! src/share/classes/java/awt/event/TextEvent.java ! src/share/classes/java/awt/event/TextListener.java Changeset: 58c90502785d Author: dav Date: 2008-03-25 15:16 +0300 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/58c90502785d 6610244: modal dialog closes with fatal error if -Xcheck:jni is set Summary: obtain WWindowPeer class every time it is required Reviewed-by: art ! src/windows/native/sun/windows/awt_Dialog.cpp ! src/windows/native/sun/windows/awt_Window.cpp ! src/windows/native/sun/windows/awt_Window.h + test/java/awt/Dialog/CrashXCheckJni/CrashXCheckJni.java Changeset: f72baf3b4419 Author: ant Date: 2008-03-24 15:51 +0300 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/f72baf3b4419 6637607: 1st char. is discarded after a modal dialogue shows up and disappears Summary: Reset consuming next KEY_TYPED on every subsequent KEY_PRESS. Reviewed-by: son ! src/share/classes/java/awt/DefaultKeyboardFocusManager.java ! src/windows/native/sun/windows/awt_Component.cpp + test/java/awt/Focus/ConsumeNextKeyTypedOnModalShowTest/ConsumeNextKeyTypedOnModalShowTest.java Changeset: 8b34e2cde06f Author: ant Date: 2008-03-25 18:08 +0300 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/8b34e2cde06f 6613426: two WM_TAKE_FOCUS messages on one mouse click in GNOME Metacity 2.16.0 Summary: A workaround to the metacity issue 485016. Reviewed-by: son ! src/solaris/classes/sun/awt/X11/XDecoratedPeer.java Changeset: 401d820d0b4a Author: ant Date: 2008-03-25 18:14 +0300 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/401d820d0b4a Merge Changeset: c58ca64469bb Author: anthony Date: 2008-03-27 11:08 +0300 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/c58ca64469bb 6603312: Segmentation fault running java -jar SwingSet2.jar in 256 color mode Summary: Force hiding the splashscreen if the code cannot allocate a reasonable number of color cells on PseudoColor displays Reviewed-by: son, art ! src/solaris/native/sun/awt/splashscreen/splashscreen_sys.c Changeset: 3b0cd0389985 Author: ant Date: 2008-03-26 16:20 +0300 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/3b0cd0389985 6680135: A number of test/closed/java/awt/Focus/* tests should be opened Summary: The tests moved from the closed repository. Reviewed-by: son + test/java/awt/Focus/ActualFocusedWindowTest/ActualFocusedWindowBlockingTest.java + test/java/awt/Focus/ActualFocusedWindowTest/ActualFocusedWindowRetaining.java + test/java/awt/Focus/AppletInitialFocusTest/AppletInitialFocusTest.html + test/java/awt/Focus/AppletInitialFocusTest/AppletInitialFocusTest.java + test/java/awt/Focus/AppletInitialFocusTest/AppletInitialFocusTest1.html + test/java/awt/Focus/AppletInitialFocusTest/AppletInitialFocusTest1.java + test/java/awt/Focus/FrameJumpingToMouse/FrameJumpingToMouse.java + test/java/awt/Focus/NonFocusableWindowTest/NonfocusableOwnerTest.java + test/java/awt/Focus/NonFocusableWindowTest/Test.java + test/java/awt/Focus/TypeAhead/TestFocusFreeze.java + test/java/awt/Focus/WrongKeyTypedConsumedTest/WrongKeyTypedConsumedTest.java Changeset: 72a4f94cd2f7 Author: ant Date: 2008-03-26 16:56 +0300 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/72a4f94cd2f7 6609607: test/closed/java/awt/Focus/AppletInitialFocusTest should be rewritten Summary: Using test.java.awt.regtesthelpers.Util. Refactoring. Reviewed-by: volk ! test/java/awt/Focus/AppletInitialFocusTest/AppletInitialFocusTest.html ! test/java/awt/Focus/AppletInitialFocusTest/AppletInitialFocusTest.java ! test/java/awt/Focus/AppletInitialFocusTest/AppletInitialFocusTest1.html ! test/java/awt/Focus/AppletInitialFocusTest/AppletInitialFocusTest1.java Changeset: 4a6dd11fe9fc Author: ant Date: 2008-03-26 17:38 +0300 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/4a6dd11fe9fc 6616792: five AWT focus regression tests should be fixed Summary: Fixed/refactored the tests. Reviewed-by: volk ! test/java/awt/Focus/ActualFocusedWindowTest/ActualFocusedWindowBlockingTest.java ! test/java/awt/Focus/ActualFocusedWindowTest/ActualFocusedWindowRetaining.java ! test/java/awt/Focus/FrameJumpingToMouse/FrameJumpingToMouse.java + test/java/awt/Focus/NonFocusableWindowTest/NoEventsTest.java ! test/java/awt/Focus/NonFocusableWindowTest/NonfocusableOwnerTest.java - test/java/awt/Focus/NonFocusableWindowTest/Test.java ! test/java/awt/Focus/TypeAhead/TestFocusFreeze.java ! test/java/awt/Focus/WrongKeyTypedConsumedTest/WrongKeyTypedConsumedTest.java Changeset: 5d98f1b8a6bb Author: ant Date: 2008-03-27 11:35 +0300 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/5d98f1b8a6bb Merge Changeset: c2252f113414 Author: dav Date: 2008-03-25 16:23 +0300 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/c2252f113414 6255653: REGRESSION: Override isLightweight() causes access violation in awt.dll Summary: verufy that the component to restack is a HW component by checking for instanceof WComponentPeer Reviewed-by: son, anthony ! src/windows/classes/sun/awt/windows/WPanelPeer.java + test/java/awt/Component/isLightweightCrash/IsLightweightCrash.java + test/java/awt/Component/isLightweightCrash/StubPeerCrash.java Changeset: 6e2a17c648a4 Author: dav Date: 2008-03-27 12:31 +0300 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/6e2a17c648a4 Merge Changeset: 4a06c0b6fdef Author: yan Date: 2008-03-28 03:06 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/4a06c0b6fdef Merge Changeset: ada64880c5d0 Author: dcherepanov Date: 2008-03-31 15:41 +0400 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/ada64880c5d0 6508505: JComboBox collapses immediately if it is placed to embedded frame Summary: XWindowPeer should translate absolute coordinates to local Reviewed-by: son ! src/solaris/classes/sun/awt/X11/XWindowPeer.java Changeset: b0bc376a5360 Author: dcherepanov Date: 2008-03-31 15:56 +0400 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/b0bc376a5360 6637204: TrayIcon.displayMessage fails to show icon twice Summary: the icon canvas should be validated to finalize its layout Reviewed-by: ant ! src/solaris/classes/sun/awt/X11/XTrayIconPeer.java Changeset: 908cab7b2f1c Author: anthony Date: 2008-04-01 17:38 +0400 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/908cab7b2f1c 6681889: JSN security test headline/noWarningApp failed with NPE exception Summary: The java.awt.Component.changeSupportLock field should be initialized in the readObject() method. Reviewed-by: son, art ! src/share/classes/java/awt/Component.java + test/java/awt/Window/PropertyChangeListenerLockSerialization/PropertyChangeListenerLockSerialization.java Changeset: 58b6b665424a Author: son Date: 2008-04-02 17:45 +0400 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/58b6b665424a 6677332: incorrect signatures for JNI methods in XWindow.c and XlibWrapper.c Summary: int replaced with jint in XWindow.c and WlibWrapper.c, and BOOL replaced with Bool in MouseInfo.c. Reviewed-by: anthony Contributed-by: roman.kennke at aicas.com ! src/solaris/native/sun/awt/MouseInfo.c ! src/solaris/native/sun/xawt/XWindow.c ! src/solaris/native/sun/xawt/XlibWrapper.c Changeset: a1bef1a012e0 Author: dcherepanov Date: 2008-04-03 15:00 +0400 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/a1bef1a012e0 6619458: testcase depends on a file with the name te{st.html Summary: using test.html instead of te{st.html in reg test Reviewed-by: son + test/java/awt/appletviewer/IOExceptionIfEncodedURLTest/IOExceptionIfEncodedURLTest.java + test/java/awt/appletviewer/IOExceptionIfEncodedURLTest/IOExceptionIfEncodedURLTest.sh + test/java/awt/appletviewer/IOExceptionIfEncodedURLTest/test.html Changeset: e80d1e36f553 Author: dcherepanov Date: 2008-04-03 15:48 +0400 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/e80d1e36f553 6615015: Typo in javadoc for Component.getTreeLock() Summary: fix for typo Reviewed-by: son ! src/share/classes/java/awt/Component.java Changeset: 9ca7032ada2b Author: dav Date: 2008-04-04 20:20 +0400 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/9ca7032ada2b 6573289: api/java_awt/Color/index.html#CreateContextTesttestCase4,5,6,7 fail since JDK 7 b14 Summary: specify current behavior - not caching the painting context Reviewed-by: flar, son ! src/share/classes/java/awt/Color.java ! src/share/classes/java/awt/GradientPaint.java ! src/share/classes/java/awt/LinearGradientPaint.java ! src/share/classes/java/awt/Paint.java ! src/share/classes/java/awt/RadialGradientPaint.java ! src/share/classes/java/awt/TexturePaint.java Changeset: 5c5a54b9d08d Author: dav Date: 2008-04-04 20:32 +0400 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/5c5a54b9d08d Merge Changeset: 664def01b886 Author: dav Date: 2008-04-07 14:53 +0400 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/664def01b886 6613529: Avoid duplicate object creation within JDK packages Summary: avoid using constructors when unique values are not necessary Reviewed-by: volk, igor, peterz ! src/share/classes/com/sun/imageio/plugins/gif/GIFImageReader.java ! src/share/classes/com/sun/imageio/plugins/gif/GIFWritableImageMetadata.java ! src/share/classes/com/sun/java/swing/plaf/gtk/GTKColorChooserPanel.java ! src/share/classes/com/sun/java/swing/plaf/gtk/GTKLookAndFeel.java ! src/share/classes/com/sun/java/swing/plaf/gtk/GTKStyle.java ! src/share/classes/com/sun/java/swing/plaf/gtk/Metacity.java ! src/share/classes/com/sun/java/swing/plaf/motif/MotifLookAndFeel.java ! src/share/classes/com/sun/java/swing/plaf/windows/WindowsLookAndFeel.java ! src/share/classes/java/awt/Button.java ! src/share/classes/java/awt/MenuItem.java ! src/share/classes/java/awt/datatransfer/SystemFlavorMap.java ! src/share/classes/java/awt/image/BufferedImage.java ! src/share/classes/java/text/DictionaryBasedBreakIterator.java ! src/share/classes/java/text/MessageFormat.java ! src/share/classes/javax/imageio/stream/ImageInputStreamImpl.java ! src/share/classes/javax/swing/AbstractButton.java ! src/share/classes/javax/swing/DebugGraphicsInfo.java ! src/share/classes/javax/swing/JInternalFrame.java ! src/share/classes/javax/swing/JOptionPane.java ! src/share/classes/javax/swing/JProgressBar.java ! src/share/classes/javax/swing/JScrollBar.java ! src/share/classes/javax/swing/JSlider.java ! src/share/classes/javax/swing/JSplitPane.java ! src/share/classes/javax/swing/JTabbedPane.java ! src/share/classes/javax/swing/JTable.java ! src/share/classes/javax/swing/JTextArea.java ! src/share/classes/javax/swing/SpinnerNumberModel.java ! src/share/classes/javax/swing/TablePrintable.java ! src/share/classes/javax/swing/plaf/basic/BasicButtonUI.java ! src/share/classes/javax/swing/plaf/basic/BasicLookAndFeel.java ! src/share/classes/javax/swing/plaf/basic/BasicMenuItemUI.java ! src/share/classes/javax/swing/plaf/basic/BasicOptionPaneUI.java ! src/share/classes/javax/swing/plaf/basic/BasicTabbedPaneUI.java ! src/share/classes/javax/swing/plaf/basic/BasicToolBarUI.java ! src/share/classes/javax/swing/plaf/metal/MetalLookAndFeel.java ! src/share/classes/javax/swing/plaf/synth/SynthArrowButton.java ! src/share/classes/javax/swing/plaf/synth/SynthDesktopPaneUI.java ! src/share/classes/javax/swing/plaf/synth/SynthSplitPaneUI.java ! src/share/classes/javax/swing/table/TableColumn.java ! src/share/classes/javax/swing/text/AbstractDocument.java ! src/share/classes/javax/swing/text/NumberFormatter.java ! src/share/classes/javax/swing/text/PlainDocument.java ! src/share/classes/javax/swing/text/Segment.java ! src/share/classes/javax/swing/text/StyleConstants.java ! src/share/classes/javax/swing/text/html/AccessibleHTML.java ! src/share/classes/javax/swing/text/html/CSS.java ! src/share/classes/javax/swing/text/html/HTMLEditorKit.java ! src/share/classes/javax/swing/text/html/parser/AttributeList.java ! src/share/classes/javax/swing/text/html/parser/DTD.java ! src/share/classes/javax/swing/text/html/parser/Element.java ! src/share/classes/javax/swing/text/html/parser/Entity.java ! src/share/classes/javax/swing/text/html/parser/Parser.java ! src/share/classes/javax/swing/text/rtf/RTFAttributes.java ! src/share/classes/javax/swing/text/rtf/RTFGenerator.java ! src/share/classes/javax/swing/tree/DefaultTreeSelectionModel.java ! src/share/classes/sun/applet/AppletPanel.java ! src/share/classes/sun/applet/AppletViewer.java ! src/share/classes/sun/awt/FontConfiguration.java ! src/share/classes/sun/awt/im/InputContext.java ! src/share/classes/sun/font/FileFontStrike.java ! src/share/classes/sun/font/FontManager.java ! src/share/classes/sun/font/FontResolver.java ! src/share/classes/sun/font/PhysicalStrike.java ! src/share/classes/sun/java2d/SunGraphics2D.java ! src/share/classes/sun/java2d/loops/SurfaceType.java ! src/share/classes/sun/print/PSPrinterJob.java ! src/share/classes/sun/print/RasterPrinterJob.java ! src/share/classes/sun/text/normalizer/VersionInfo.java ! src/solaris/classes/sun/awt/X11/XDropTargetProtocol.java ! src/solaris/classes/sun/awt/X11/XDropTargetRegistry.java ! src/solaris/classes/sun/awt/X11/XEmbedServerTester.java ! src/solaris/classes/sun/awt/X11/XFileDialogPeer.java ! src/solaris/classes/sun/awt/X11/XScrollbar.java ! src/solaris/classes/sun/awt/X11GraphicsConfig.java ! src/solaris/classes/sun/awt/X11GraphicsDevice.java ! src/solaris/classes/sun/print/UnixPrintJob.java ! src/windows/classes/sun/awt/windows/WDataTransferer.java ! src/windows/classes/sun/awt/windows/WInputMethod.java ! src/windows/classes/sun/awt/windows/WWindowPeer.java ! src/windows/classes/sun/print/Win32PrintService.java Changeset: 840f49e23a40 Author: dav Date: 2008-04-07 16:52 +0400 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/840f49e23a40 6623459: Get rid of XConstant, XProtocolConstants and XUtilConstants antipattern Summary: Access to interface's fiels via their name rather then implementation Reviewed-by: volk, son ! src/solaris/classes/sun/awt/X11/MWMConstants.java ! src/solaris/classes/sun/awt/X11/MotifDnDConstants.java ! src/solaris/classes/sun/awt/X11/MotifDnDDragSourceProtocol.java ! src/solaris/classes/sun/awt/X11/MotifDnDDropTargetProtocol.java ! src/solaris/classes/sun/awt/X11/WindowPropertyGetter.java ! src/solaris/classes/sun/awt/X11/XAWTXSettings.java ! src/solaris/classes/sun/awt/X11/XAtom.java ! src/solaris/classes/sun/awt/X11/XBaseMenuWindow.java ! src/solaris/classes/sun/awt/X11/XBaseWindow.java ! src/solaris/classes/sun/awt/X11/XClipboard.java ! src/solaris/classes/sun/awt/X11/XComponentPeer.java ! src/solaris/classes/sun/awt/X11/XConstants.java ! src/solaris/classes/sun/awt/X11/XContentWindow.java ! src/solaris/classes/sun/awt/X11/XCursorFontConstants.java ! src/solaris/classes/sun/awt/X11/XCustomCursor.java ! src/solaris/classes/sun/awt/X11/XDecoratedPeer.java ! src/solaris/classes/sun/awt/X11/XDialogPeer.java ! src/solaris/classes/sun/awt/X11/XDnDDragSourceProtocol.java ! src/solaris/classes/sun/awt/X11/XDnDDropTargetProtocol.java ! src/solaris/classes/sun/awt/X11/XDragSourceContextPeer.java ! src/solaris/classes/sun/awt/X11/XDragSourceProtocol.java ! src/solaris/classes/sun/awt/X11/XDropTargetEventProcessor.java ! src/solaris/classes/sun/awt/X11/XDropTargetProtocol.java ! src/solaris/classes/sun/awt/X11/XDropTargetRegistry.java ! src/solaris/classes/sun/awt/X11/XEmbedCanvasPeer.java ! src/solaris/classes/sun/awt/X11/XEmbedChildProxyPeer.java ! src/solaris/classes/sun/awt/X11/XEmbedClientHelper.java ! src/solaris/classes/sun/awt/X11/XEmbedHelper.java ! src/solaris/classes/sun/awt/X11/XEmbedServerTester.java ! src/solaris/classes/sun/awt/X11/XEmbeddedFramePeer.java ! src/solaris/classes/sun/awt/X11/XEmbeddingContainer.java ! src/solaris/classes/sun/awt/X11/XFocusProxyWindow.java ! src/solaris/classes/sun/awt/X11/XFramePeer.java ! src/solaris/classes/sun/awt/X11/XGlobalCursorManager.java ! src/solaris/classes/sun/awt/X11/XIconWindow.java ! src/solaris/classes/sun/awt/X11/XMSelection.java ! src/solaris/classes/sun/awt/X11/XNETProtocol.java ! src/solaris/classes/sun/awt/X11/XProtocol.java ! src/solaris/classes/sun/awt/X11/XProtocolConstants.java ! src/solaris/classes/sun/awt/X11/XSelection.java ! src/solaris/classes/sun/awt/X11/XSystemTrayPeer.java ! src/solaris/classes/sun/awt/X11/XToolkit.java ! src/solaris/classes/sun/awt/X11/XTrayIconPeer.java ! src/solaris/classes/sun/awt/X11/XUtilConstants.java ! src/solaris/classes/sun/awt/X11/XWINProtocol.java ! src/solaris/classes/sun/awt/X11/XWM.java ! src/solaris/classes/sun/awt/X11/XWindow.java ! src/solaris/classes/sun/awt/X11/XWindowPeer.java ! src/solaris/classes/sun/awt/X11/XlibUtil.java ! src/solaris/classes/sun/awt/X11/XlibWrapper.java Changeset: 0a053f373969 Author: dav Date: 2008-04-08 12:46 +0400 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/0a053f373969 6520716: event classes lack info about parameters Summary: clarify allowed values for event constructors Reviewed-by: son, denis ! src/share/classes/java/awt/dnd/DragGestureEvent.java ! src/share/classes/java/awt/dnd/DropTargetEvent.java ! src/share/classes/java/awt/event/ActionEvent.java ! src/share/classes/java/awt/event/AdjustmentEvent.java ! src/share/classes/java/awt/event/ComponentEvent.java ! src/share/classes/java/awt/event/ContainerEvent.java ! src/share/classes/java/awt/event/FocusEvent.java ! src/share/classes/java/awt/event/HierarchyEvent.java ! src/share/classes/java/awt/event/InputEvent.java ! src/share/classes/java/awt/event/InvocationEvent.java ! src/share/classes/java/awt/event/ItemEvent.java ! src/share/classes/java/awt/event/KeyEvent.java ! src/share/classes/java/awt/event/MouseEvent.java ! src/share/classes/java/awt/event/MouseWheelEvent.java ! src/share/classes/java/awt/event/PaintEvent.java ! src/share/classes/java/awt/event/TextEvent.java ! src/share/classes/java/awt/event/WindowEvent.java Changeset: dd05b5b0e7bd Author: ant Date: 2008-04-08 13:32 +0400 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/dd05b5b0e7bd 6607170: Focus not set by requestFocus Summary: fixing/refactoring focus auto-transfer mechanism. Reviewed-by: son ! src/share/classes/java/awt/Component.java ! src/share/classes/java/awt/Container.java ! src/share/classes/java/awt/DefaultKeyboardFocusManager.java ! src/share/classes/java/awt/KeyboardFocusManager.java ! src/solaris/classes/sun/awt/X11/XKeyboardFocusManagerPeer.java ! src/windows/native/sun/windows/awt_Component.cpp + test/java/awt/Focus/ContainerFocusAutoTransferTest/ContainerFocusAutoTransferTest.java Changeset: ddfd2acb2347 Author: ant Date: 2008-04-09 09:37 +0400 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/ddfd2acb2347 6522725: Component in a minimized Frame has focus and receives key events Summary: XAWT: a window natively focused may request focus in it only synthetically Reviewed-by: son ! src/solaris/classes/sun/awt/X11/XComponentPeer.java ! src/solaris/classes/sun/awt/X11/XDecoratedPeer.java ! src/solaris/classes/sun/awt/X11/XWindowPeer.java + test/java/awt/Focus/IconifiedFrameFocusChangeTest/IconifiedFrameFocusChangeTest.java Changeset: 61ea2d05afba Author: volk Date: 2008-04-13 23:41 +0400 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/61ea2d05afba 6686273: Some AWT reg. tests should be moved to open repository (for CRs 6444769, 6480547, and 6560348) Summary: Some AWT reg. tests are moved to open repository (for CRs 6444769, 6480547, and 6560348) Reviewed-by: ant + test/java/awt/Insets/WindowWithWarningTest/WindowWithWarningTest.html + test/java/awt/Insets/WindowWithWarningTest/WindowWithWarningTest.java + test/java/awt/TextField/ScrollSelectionTest/ScrollSelectionTest.html + test/java/awt/TextField/ScrollSelectionTest/ScrollSelectionTest.java + test/java/awt/xembed/server/JavaClient.java + test/java/awt/xembed/server/RunTestXEmbed.java + test/java/awt/xembed/server/TestXEmbedServer.java + test/java/awt/xembed/server/TestXEmbedServerJava.java + test/java/awt/xembed/server/TesterClient.java Changeset: 5a9dcfdf856d Author: volk Date: 2008-04-13 23:56 +0400 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/5a9dcfdf856d Merge Changeset: 863b81ff642c Author: dcherepanov Date: 2008-04-14 15:21 +0400 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/863b81ff642c 6471693: Moving the vertical scroll bar of List in FileDialog leads Flickering in solaris Summary: unite paint() calls in one call Reviewed-by: son ! src/solaris/classes/sun/awt/X11/XListPeer.java Changeset: 9d15a1989b84 Author: dcherepanov Date: 2008-04-14 15:53 +0400 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/9d15a1989b84 6688067: regression test for 6471693 is missed Summary: added regression test Reviewed-by: son + test/java/awt/List/ListFlickers/ListFlickers.java Changeset: adae10f1c14d Author: dav Date: 2008-04-15 14:00 +0400 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/adae10f1c14d 6430553: MouseClick event should not be fired if MouseRelease happened without MousePress Summary: verify that the there was a PRESS event before sending CLICK event Reviewed-by: son, dcherepanov ! src/solaris/classes/sun/awt/X11/XWindow.java ! src/windows/native/sun/windows/awt_Component.cpp ! src/windows/native/sun/windows/awt_Component.h ! src/windows/native/sun/windows/awt_TrayIcon.cpp ! src/windows/native/sun/windows/awt_TrayIcon.h Changeset: e2e1127aed7b Author: dav Date: 2008-04-15 14:14 +0400 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/e2e1127aed7b Merge Changeset: 29a4bb79a0fd Author: son Date: 2008-04-18 11:38 +0400 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/29a4bb79a0fd 6690036: some code cleanup for insets-related code Summary: all insets-related code from XWindowPeer, XFramePeer, and XDialogPeer has been moved to XDecoratedPeer. Reviewed-by: anthony ! src/solaris/classes/sun/awt/X11/XDecoratedPeer.java ! src/solaris/classes/sun/awt/X11/XDialogPeer.java ! src/solaris/classes/sun/awt/X11/XFramePeer.java ! src/solaris/classes/sun/awt/X11/XWindowPeer.java Changeset: a35e9e11d907 Author: yan Date: 2008-04-23 14:35 +0400 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/a35e9e11d907 6627324: Alt Graph doesnot generate any key event when pressing in German locale Summary: This Unix only problem solved by mapping XK_ISO_Level3_Shift keysym to Java keycode VK_ALT_GRAPH. Reviewed-by: son ! src/solaris/classes/sun/awt/X11/XKeysym.java ! src/solaris/classes/sun/awt/X11/genhash.awk ! src/solaris/classes/sun/awt/X11/keysym2ucs.h Changeset: 8da00cb83d01 Author: yan Date: 2008-05-04 07:05 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/8da00cb83d01 Merge Changeset: c1e547a4c0ef Author: yan Date: 2008-05-13 21:58 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/c1e547a4c0ef Merge ! src/share/classes/javax/swing/JTextArea.java Changeset: 97240b4b5074 Author: rupashka Date: 2008-04-28 17:17 +0400 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/97240b4b5074 4252173: Inability to reuse the HorizontalSliderThumbIcon Summary: Removed casting component to JSlider from MetalIconFactory Reviewed-by: alexp ! src/share/classes/javax/swing/plaf/metal/MetalIconFactory.java + test/javax/swing/JFileChooser/4252173/bug4252173.java Changeset: 0447f9c7aed7 Author: rupashka Date: 2008-04-29 13:49 +0400 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/0447f9c7aed7 6210674: FileChooser fails to load custom harddrive icon and gets NullPointerException Summary: WindowsPlacesBar should use default icon for folders that doesn't have own icon Reviewed-by: loneid ! src/share/classes/sun/swing/WindowsPlacesBar.java ! src/windows/classes/sun/awt/shell/Win32ShellFolder2.java ! src/windows/classes/sun/awt/shell/Win32ShellFolderManager2.java Changeset: 5b1734431fa5 Author: rupashka Date: 2008-04-29 15:47 +0400 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/5b1734431fa5 6693507: There are unnecessary compilation warnings in the com.sun.java.swing.plaf.motif package Summary: Removed unnecessary castings and other warnings Reviewed-by: peterz Contributed-by: Florian Brunner ! src/share/classes/com/sun/java/swing/plaf/motif/MotifGraphicsUtils.java ! src/share/classes/com/sun/java/swing/plaf/motif/MotifInternalFrameTitlePane.java ! src/share/classes/com/sun/java/swing/plaf/motif/MotifLookAndFeel.java Changeset: aaa771ded30b Author: rupashka Date: 2008-04-29 17:48 +0400 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/aaa771ded30b 6614972: JSlider value should not change on right-click Summary: WindowsSliderUI won't use the right mouse button for change slider position Reviewed-by: alexp ! src/share/classes/com/sun/java/swing/plaf/gtk/GTKLookAndFeel.java ! src/share/classes/javax/swing/plaf/basic/BasicLookAndFeel.java ! src/share/classes/javax/swing/plaf/basic/BasicSliderUI.java Changeset: eca2e5716b86 Author: rupashka Date: 2008-04-30 12:32 +0400 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/eca2e5716b86 6524424: JSlider Clicking In Tracks Behavior Inconsistent For Different Tick Spacings Summary: JSlider should use minimal tick space in SnapToTicks mode Reviewed-by: peterz ! src/share/classes/javax/swing/plaf/basic/BasicSliderUI.java + test/javax/swing/JFileChooser/6524424/bug6524424.html + test/javax/swing/JFileChooser/6524424/bug6524424.java Changeset: 9a322f3dccd8 Author: rupashka Date: 2008-04-30 13:01 +0400 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/9a322f3dccd8 6642612: JFileChooser approve buttons should use Open and Save text (GTK) Summary: In FileChooser under GTK LaF "Ok" and "Cancel" buttons were made with the same size Reviewed-by: peterz ! src/share/classes/com/sun/java/swing/plaf/gtk/GTKFileChooserUI.java Changeset: b49c01fd4b1c Author: mlapshin Date: 2008-04-30 13:19 +0400 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/b49c01fd4b1c 6690791: Even more ClassCasetException with TrayIcon Summary: event.getComponent() is used unstead of (Component)event.getSource() Reviewed-by: peterz ! src/share/classes/javax/swing/MenuSelectionManager.java + test/javax/swing/JPopupMenu/6690791/bug6690791.java Changeset: b5c38f2632d0 Author: mlapshin Date: 2008-04-30 07:03 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/b5c38f2632d0 Merge Changeset: 812b1e9aa7e5 Author: mlapshin Date: 2008-04-30 08:23 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/812b1e9aa7e5 Merge Changeset: 06916e21e10f Author: rupashka Date: 2008-05-01 14:47 +0400 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/06916e21e10f 6688203: Memory leak and performance problems in the method getFileSystemView of FileSystemView Summary: Removed from the "FileSystemView#getFileSystemView" method creation of a new listener and adding it to UIManager Reviewed-by: peterz ! src/share/classes/javax/swing/filechooser/FileSystemView.java + test/javax/swing/JFileChooser/6688203/bug6688203.java Changeset: c25ed95b96a8 Author: malenkov Date: 2008-05-07 16:08 +0400 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/c25ed95b96a8 6625450: javax.swing.border.TitledBorder.getBaseline() doesn't throw IAE when width is < 0 Summary: necessary check is added Reviewed-by: peterz, alexp ! src/share/classes/javax/swing/border/TitledBorder.java + test/javax/swing/border/Test6625450.java Changeset: 4cf10bc1973d Author: rupashka Date: 2008-05-07 20:26 +0400 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/4cf10bc1973d 6635277: Incorrect text seen when creating a new folder, when selection is on the image file in JFileChooser Summary: Corrected bounds of editor area Reviewed-by: loneid ! src/share/classes/sun/swing/FilePane.java Changeset: 56cae54e668c Author: malenkov Date: 2008-05-07 21:54 +0400 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/56cae54e668c 6348456: BasicColorChooserUI ignores JColorChooser selection model changes Summary: Some methods are moved from AbstractColorChooserPanel to BasicColorChooserUI Reviewed-by: peterz, alexp ! src/share/classes/javax/swing/colorchooser/AbstractColorChooserPanel.java ! src/share/classes/javax/swing/plaf/basic/BasicColorChooserUI.java + test/javax/swing/JColorChooser/Test6348456.html + test/javax/swing/JColorChooser/Test6348456.java Changeset: 5bcff22d837d Author: malenkov Date: 2008-05-07 23:20 +0400 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/5bcff22d837d 4935607: RFE: LTP: Should be possible to set the TRANSIENT attribute of propertiies to FALSE Summary: Add the Transient annotation and support it (JSR-273) Reviewed-by: peterz, loneid ! src/share/classes/java/awt/Component.java ! src/share/classes/java/awt/Dimension.java ! src/share/classes/java/awt/Point.java ! src/share/classes/java/awt/Rectangle.java ! src/share/classes/java/awt/ScrollPane.java ! src/share/classes/java/awt/geom/RectangularShape.java ! src/share/classes/java/awt/im/InputContext.java ! src/share/classes/java/beans/DefaultPersistenceDelegate.java ! src/share/classes/java/beans/EventSetDescriptor.java ! src/share/classes/java/beans/FeatureDescriptor.java ! src/share/classes/java/beans/IndexedPropertyDescriptor.java ! src/share/classes/java/beans/MetaData.java ! src/share/classes/java/beans/PropertyDescriptor.java + src/share/classes/java/beans/Transient.java ! src/share/classes/javax/swing/AbstractButton.java ! src/share/classes/javax/swing/DefaultListSelectionModel.java ! src/share/classes/javax/swing/ImageIcon.java ! src/share/classes/javax/swing/JComboBox.java ! src/share/classes/javax/swing/JComponent.java ! src/share/classes/javax/swing/JLabel.java ! src/share/classes/javax/swing/JList.java ! src/share/classes/javax/swing/JMenuBar.java ! src/share/classes/javax/swing/JScrollPane.java ! src/share/classes/javax/swing/JTabbedPane.java ! src/share/classes/javax/swing/JViewport.java ! src/share/classes/javax/swing/table/JTableHeader.java ! src/share/classes/javax/swing/text/JTextComponent.java ! test/java/beans/Introspector/BeanUtils.java ! test/java/beans/Introspector/Test4896879.java + test/java/beans/Introspector/Test4935607.java + test/java/beans/XMLEncoder/Test4935607.java Changeset: ec3bbc3f675a Author: mlapshin Date: 2008-05-14 07:53 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/ec3bbc3f675a Merge ! src/share/classes/com/sun/java/swing/plaf/gtk/GTKLookAndFeel.java ! src/share/classes/com/sun/java/swing/plaf/motif/MotifLookAndFeel.java ! src/share/classes/java/awt/Component.java ! src/share/classes/javax/swing/AbstractButton.java ! src/share/classes/javax/swing/JTabbedPane.java ! src/share/classes/javax/swing/plaf/basic/BasicLookAndFeel.java Changeset: 8767ccc53b42 Author: xdono Date: 2008-05-14 14:06 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/8767ccc53b42 Merge From xiomara.jayasena at sun.com Wed May 14 21:48:42 2008 From: xiomara.jayasena at sun.com (xiomara.jayasena at sun.com) Date: Wed, 14 May 2008 21:48:42 +0000 Subject: hg: jdk7/build/langtools: 11 new changesets Message-ID: <20080514214900.6ECDC280CC@hg.openjdk.java.net> Changeset: 3c41acaad702 Author: xdono Date: 2008-04-24 12:12 -0700 URL: http://hg.openjdk.java.net/jdk7/build/langtools/rev/3c41acaad702 Added tag jdk7-b26 for changeset c46d25a2350a ! .hgtags Changeset: 961ae2608114 Author: mcimadamore Date: 2008-04-09 13:19 +0100 URL: http://hg.openjdk.java.net/jdk7/build/langtools/rev/961ae2608114 6531075: Missing synthetic casts when accessing fields/methods of intersection types including type variables Summary: bug when javac generates code involving intersection types Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/TransTypes.java + test/tools/javac/generics/6531075/T6531075.java Changeset: d032d5090fd5 Author: mcimadamore Date: 2008-04-09 13:41 +0100 URL: http://hg.openjdk.java.net/jdk7/build/langtools/rev/d032d5090fd5 5009937: hiding versus generics versus binary compatibility Summary: missing implementation of JLS 8.4.8.3 (different arguments with same erasure not always triggering a compiler error) Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Check.java + test/tools/javac/generics/5009937/T5009937.java + test/tools/javac/generics/5009937/T5009937.out ! test/tools/javac/generics/InheritanceConflict.java ! test/tools/javac/generics/InheritanceConflict2.java Changeset: 57ba4f70f0d8 Author: mcimadamore Date: 2008-04-09 13:53 +0100 URL: http://hg.openjdk.java.net/jdk7/build/langtools/rev/57ba4f70f0d8 6365166: javac (generic) unable to resolve methods Summary: Unignore regression test as this bug has been fixed by CR 6278587 Reviewed-by: jjg + test/tools/javac/generics/inference/6356673/T6365166.java Changeset: 25338c55e458 Author: mcimadamore Date: 2008-04-09 14:05 +0100 URL: http://hg.openjdk.java.net/jdk7/build/langtools/rev/25338c55e458 6481655: Parser confused by combination of parens and explicit type args Summary: Bug in the parser caused by the fact that explicit type arguments are disabled when parsing parenthesized expressions Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/parser/Parser.java + test/tools/javac/generics/T6481655.java Changeset: 447c300a24e7 Author: mcimadamore Date: 2008-04-09 14:45 +0100 URL: http://hg.openjdk.java.net/jdk7/build/langtools/rev/447c300a24e7 6450290: Capture of nested wildcards causes type error Summary: A missing capture conversion makes javac to think that some expressions are well-formed even when they aren't Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Attr.java + test/tools/javac/generics/wildcards/T6450290.java Changeset: e7bf2e39b8fe Author: mcimadamore Date: 2008-04-09 14:57 +0100 URL: http://hg.openjdk.java.net/jdk7/build/langtools/rev/e7bf2e39b8fe 6657499: javac 1.6.0 fails to compile class with inner class Summary: Lookup of member inner classes silently fails leading to an unwanted erasure to take place Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Attr.java + test/tools/javac/generics/T6657499.java Changeset: 6522ea413d23 Author: mcimadamore Date: 2008-04-09 15:04 +0100 URL: http://hg.openjdk.java.net/jdk7/build/langtools/rev/6522ea413d23 6683438: Bad regression test for CR 6611449 Summary: The regression test for CR 6611449 contains some inconstistencies Reviewed-by: jjg ! test/tools/javac/generics/inference/6611449/T6611449.java ! test/tools/javac/generics/inference/6611449/T6611449.out Changeset: a1d1f335633f Author: mcimadamore Date: 2008-04-09 15:30 +0100 URL: http://hg.openjdk.java.net/jdk7/build/langtools/rev/a1d1f335633f 6559182: Cast from a raw type with non-generic supertype to a raw type fails unexpectedly Summary: Javac doesn't conform to JLS 4.8 - all the supertypes of a raw type must be erased Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Type.java ! src/share/classes/com/sun/tools/javac/code/Types.java + test/tools/javac/generics/Casting5.java Changeset: 627deea1ea4f Author: tbell Date: 2008-04-15 17:48 -0700 URL: http://hg.openjdk.java.net/jdk7/build/langtools/rev/627deea1ea4f Merge Changeset: eb4c60ad2fa2 Author: tbell Date: 2008-04-25 15:22 -0700 URL: http://hg.openjdk.java.net/jdk7/build/langtools/rev/eb4c60ad2fa2 Merge From bram.somers at skynet.be Thu May 15 11:07:38 2008 From: bram.somers at skynet.be (bram.somers at skynet.be) Date: Thu, 15 May 2008 13:07:38 +0200 Subject: Building on ubuntu 8.04 Message-ID: <6tkfr8$3reall@relay.skynet.be> undefined -------------- next part -------------- An HTML attachment was scrubbed... URL: From martinrb at google.com Thu May 15 15:19:49 2008 From: martinrb at google.com (Martin Buchholz) Date: Thu, 15 May 2008 08:19:49 -0700 Subject: Building on ubuntu 8.04 In-Reply-To: <6tkfr8$3reall@relay.skynet.be> References: <6tkfr8$3reall@relay.skynet.be> Message-ID: <1ccfd1c10805150819t2b6bc51dk478c1675dcbf3128@mail.gmail.com> FYI - simply changing the /bin/sh symlink probably works, but the official way to do this is with dpkg-reconfigure. BTW, I think the message below is incorrect; neither bash nor dash is fully POSIX compliant. See also https://bugs.launchpad.net/ubuntu/+source/dash/+bug/61463 $ sudo dpkg-reconfigure dash Configuring dash ---------------- Bash is the default /bin/sh on a Debian system. However, since the Debian policy requires all shell scripts using /bin/sh to be POSIX compliant, any shell that conforms to POSIX can serve as /bin/sh. Since dash is POSIX compliant, it can be used as /bin/sh. You may wish to do this because dash is faster and smaller than bash. Install dash as /bin/sh? no Martin On Thu, May 15, 2008 at 4:07 AM, wrote: > > > Hi all, > > First, I really appreciate the help, thank you all! > > Second, I did perform a make clean. And I don't understand. I removed sh > from my system and made a symlink from sh to bash, so every time sh is > called, it is forwarded to bash, isn't it? > Anyway, I checked the files you gave, and I changed the calls, so they > should use bash now. But, I'm a newbie on this kind of stuff, I use Java for > several years now, but this is new for me. > > Kind regards, > > Bram > > > Roman Kennke wrote: > Also, maybe you simply forgot make clean after you fixed your shell? > > /Roman > > Am Mittwoch, den 14.05.2008, 12:56 -0700 schrieb Brad Wetmore: > > I think you've got a problem still with your sh setup, or possibly something > else. IIRC, the ?replType? variables is supposed to be replaced with > various values depending on whether you have an encoder or decoder. > (sed/awk preprocessing = a Javaman's #ifdef equivalent) It's done a similar > way for the {Byte,Char,Int...}Buffers. > > Check jdk/make/java/nio, specifically Makefile, spp.sh, and genCoder.sh > > Hope this helps. > > Brad > > > Bram Somers wrote: > > Dear all, > > I've tried building jdk7 on Ubuntu 8.04. I'm aware of the problems with > sh/dash and I remove sh and made a symlink of sh to bash, so normally I > shouldn't get this error anymore: > > jdk7/build/openjdk_full_debug/gensrc/java/nio/charset/CharsetEncoder.java:142: > cannot find symbol > symbol : class $replType$ > location: class java.nio.charset.CharsetEncoder > private $replType$ replacement; > ^ > /home/bsomers/workspaces/openjdk/jdk7/build/openjdk_full_debug/gensrc/java/nio/charset/CharsetEncoder.java:185: > cannot find symbol > symbol : class $replType$ > location: class java.nio.charset.CharsetEncoder > $replType$ replacement) > ^ > /home/bsomers/workspaces/openjdk/jdk7/build/openjdk_full_debug/gensrc/java/nio/charset/CharsetEncoder.java:246: > cannot find symbol > symbol : class $replType$ > location: class java.nio.charset.CharsetEncoder > public final $replType$ replacement() { > ^ > /home/bsomers/workspaces/openjdk/jdk7/build/openjdk_full_debug/gensrc/java/nio/charset/CharsetEncoder.java:275: > cannot find symbol > symbol : class $replType$ > location: class java.nio.charset.CharsetEncoder > public final CharsetEncoder replaceWith($replType$ newReplacement) { > ^ > /home/bsomers/workspaces/openjdk/jdk7/build/openjdk_full_debug/gensrc/java/nio/charset/CharsetEncoder.java:301: > cannot find symbol > symbol : class $replType$ > location: class java.nio.charset.CharsetEncoder > protected void implReplaceWith($replType$ newReplacement) { > ^ > Note: Some input files use or override a deprecated API. > Note: Recompile with -Xlint:deprecation for details. > Note: Some input files use unchecked or unsafe operations. > Note: Recompile with -Xlint:unchecked for details. > 5 errors > > > Any more suggestions? > > Thanks in advance, > > kind regards, > > Bram > > > > > > From ted at tedneward.com Thu May 15 16:42:48 2008 From: ted at tedneward.com (Ted Neward) Date: Thu, 15 May 2008 09:42:48 -0700 Subject: FW: ATL headers and libraries? In-Reply-To: <4829DCAF.3090707@sun.com> References: <049501c8b51e$4ed61b40$ec8251c0$@com> <4829DCAF.3090707@sun.com> Message-ID: <091401c8b6aa$b7cc1540$27643fc0$@com> My understanding was that it did--there are a few build-dev emails about missing "atlmfc.h" just a few weeks ago.... But I haven't verified that from looking at the sources yet--been busy with other things. I'll take a look and see. Can you check with the Hotspot team if they know of any in the meantime (or, perhaps better yet, can you suggest which list would be best to forward this email to)? Ted Neward Java, .NET, XML Services Consulting, Teaching, Speaking, Writing http://www.tedneward.com > -----Original Message----- > From: Kelly.Ohair at Sun.COM [mailto:Kelly.Ohair at Sun.COM] > Sent: Tuesday, May 13, 2008 11:24 AM > To: Ted Neward > Cc: build-dev at openjdk.java.net > Subject: Re: FW: ATL headers and libraries? > > Does the hotspot sources have a ATL/MFC dependence? > > -kto > > > Ted Neward wrote: > > Kelly, et al? > > > > > > > > Should we just wait with the attempted port until this (see below) > > happens? Or do we want to try and actively remove the dependencies on > > ATL/MFC from the Hotspot code? > > > > > > > > Ted Neward > > > > Java, .NET, XML Services > > > > Consulting, Teaching, Speaking, Writing > > > > http://www.tedneward.com > > > > > > > > *From:* Herb Sutter [mailto:hsutter at microsoft.com] > > *Sent:* Tuesday, May 13, 2008 4:08 AM > > *To:* Ted Neward > > *Subject:* RE: ATL headers and libraries? > > > > > > > > Unfortunately, no, there is no way to get to ATL and/or MFC without > > buying VS Std/Pro/etc. (of course, you can get those through your > MSDN > > subscription, etc.) > > > > > > > > For the future, though, the plan is to ship both ATL and MFC (x86, I > > believe) in VC++ Express at some point. > > > > > > > > Herb > > > > > > > > > > > > *From:* Ted Neward [mailto:ted at tedneward.com] > > *Sent:* Monday, May 12, 2008 12:23 PM > > *To:* Herb Sutter > > *Subject:* ATL headers and libraries? > > > > > > > > Can you tell me (or put me in touch with somebody who can) if it?s > > possible to get a hold of the ATL and/or MFC headers and libraries > > without buying Visual Studio Standard/Professional/Enterprise/etc? I > > have a client who?s looking to see if they can use just VC++ Express > to > > maintain some code that uses ATL and MFC. > > > > > > > > Ted Neward > > > > Java, .NET, XML Services > > > > Consulting, Teaching, Speaking, Writing > > > > http://www.tedneward.com > > > > > > > > > > > > No virus found in this outgoing message. > > Checked by AVG. > > Version: 7.5.524 / Virus Database: 269.23.15/1426 - Release Date: > > 5/10/2008 11:12 AM > > > > > > > > No virus found in this incoming message. > > Checked by AVG. > > Version: 7.5.524 / Virus Database: 269.23.15/1426 - Release Date: > > 5/10/2008 11:12 AM > > > > > > No virus found in this outgoing message. > > Checked by AVG. > > Version: 7.5.524 / Virus Database: 269.23.16/1430 - Release Date: > > 5/13/2008 7:31 AM > > > > No virus found in this incoming message. > Checked by AVG. > Version: 7.5.524 / Virus Database: 269.23.16/1430 - Release Date: > 5/13/2008 7:31 AM > No virus found in this outgoing message. Checked by AVG. Version: 7.5.524 / Virus Database: 269.23.16/1434 - Release Date: 5/15/2008 7:24 AM From Kelly.Ohair at Sun.COM Thu May 15 17:15:25 2008 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Thu, 15 May 2008 10:15:25 -0700 Subject: FW: ATL headers and libraries? In-Reply-To: <091401c8b6aa$b7cc1540$27643fc0$@com> References: <049501c8b51e$4ed61b40$ec8251c0$@com> <4829DCAF.3090707@sun.com> <091401c8b6aa$b7cc1540$27643fc0$@com> Message-ID: <482C6FAD.4020100@sun.com> Tim's email: http://mail.openjdk.java.net/pipermail/build-dev/2007-December/000654.html Mentions this: hotspot\src\os\windows\vm\jvm_windows.h(33) : fatal error C1083: Cannot open include file: 'windows.h': No such file or directory But windows.h should not be a problem to find, right? Platform SDK should have one I assume. I seriously doubt that Hotspot would have any dependence on atlmfc. I searched and found no include's of any obvious atl files. -kto Ted Neward wrote: > My understanding was that it did--there are a few build-dev emails about > missing "atlmfc.h" just a few weeks ago.... > > But I haven't verified that from looking at the sources yet--been busy with > other things. I'll take a look and see. Can you check with the Hotspot team > if they know of any in the meantime (or, perhaps better yet, can you suggest > which list would be best to forward this email to)? > > Ted Neward > Java, .NET, XML Services > Consulting, Teaching, Speaking, Writing > http://www.tedneward.com > > >> -----Original Message----- >> From: Kelly.Ohair at Sun.COM [mailto:Kelly.Ohair at Sun.COM] >> Sent: Tuesday, May 13, 2008 11:24 AM >> To: Ted Neward >> Cc: build-dev at openjdk.java.net >> Subject: Re: FW: ATL headers and libraries? >> >> Does the hotspot sources have a ATL/MFC dependence? >> >> -kto >> >> >> Ted Neward wrote: >>> Kelly, et al? >>> >>> >>> >>> Should we just wait with the attempted port until this (see below) >>> happens? Or do we want to try and actively remove the dependencies on >>> ATL/MFC from the Hotspot code? >>> >>> >>> >>> Ted Neward >>> >>> Java, .NET, XML Services >>> >>> Consulting, Teaching, Speaking, Writing >>> >>> http://www.tedneward.com >>> >>> >>> >>> *From:* Herb Sutter [mailto:hsutter at microsoft.com] >>> *Sent:* Tuesday, May 13, 2008 4:08 AM >>> *To:* Ted Neward >>> *Subject:* RE: ATL headers and libraries? >>> >>> >>> >>> Unfortunately, no, there is no way to get to ATL and/or MFC without >>> buying VS Std/Pro/etc. (of course, you can get those through your >> MSDN >>> subscription, etc.) >>> >>> >>> >>> For the future, though, the plan is to ship both ATL and MFC (x86, I >>> believe) in VC++ Express at some point. >>> >>> >>> >>> Herb >>> >>> >>> >>> >>> >>> *From:* Ted Neward [mailto:ted at tedneward.com] >>> *Sent:* Monday, May 12, 2008 12:23 PM >>> *To:* Herb Sutter >>> *Subject:* ATL headers and libraries? >>> >>> >>> >>> Can you tell me (or put me in touch with somebody who can) if it?s >>> possible to get a hold of the ATL and/or MFC headers and libraries >>> without buying Visual Studio Standard/Professional/Enterprise/etc? I >>> have a client who?s looking to see if they can use just VC++ Express >> to >>> maintain some code that uses ATL and MFC. >>> >>> >>> >>> Ted Neward >>> >>> Java, .NET, XML Services >>> >>> Consulting, Teaching, Speaking, Writing >>> >>> http://www.tedneward.com >>> >>> >>> >>> >>> >>> No virus found in this outgoing message. >>> Checked by AVG. >>> Version: 7.5.524 / Virus Database: 269.23.15/1426 - Release Date: >>> 5/10/2008 11:12 AM >>> >>> >>> >>> No virus found in this incoming message. >>> Checked by AVG. >>> Version: 7.5.524 / Virus Database: 269.23.15/1426 - Release Date: >>> 5/10/2008 11:12 AM >>> >>> >>> No virus found in this outgoing message. >>> Checked by AVG. >>> Version: 7.5.524 / Virus Database: 269.23.16/1430 - Release Date: >>> 5/13/2008 7:31 AM >>> >> No virus found in this incoming message. >> Checked by AVG. >> Version: 7.5.524 / Virus Database: 269.23.16/1430 - Release Date: >> 5/13/2008 7:31 AM >> > > No virus found in this outgoing message. > Checked by AVG. > Version: 7.5.524 / Virus Database: 269.23.16/1434 - Release Date: 5/15/2008 > 7:24 AM > > From Phil.Race at Sun.COM Thu May 15 17:45:49 2008 From: Phil.Race at Sun.COM (Phil Race) Date: Thu, 15 May 2008 10:45:49 -0700 Subject: FW: ATL headers and libraries? In-Reply-To: <482C6FAD.4020100@sun.com> References: <049501c8b51e$4ed61b40$ec8251c0$@com> <4829DCAF.3090707@sun.com> <091401c8b6aa$b7cc1540$27643fc0$@com> <482C6FAD.4020100@sun.com> Message-ID: <482C76CD.8080707@sun.com> A member of the hotspot team built hotspot (nothing else) with Visual Studio Express 2008 about a month ago, so there should be no dependencies on ATL since that isn't in VS Express. -phil. Kelly O'Hair wrote: > > Tim's email: > http://mail.openjdk.java.net/pipermail/build-dev/2007-December/000654.html > > > Mentions this: > hotspot\src\os\windows\vm\jvm_windows.h(33) : fatal error C1083: > Cannot open include file: 'windows.h': No such file or directory > > > But windows.h should not be a problem to find, right? Platform SDK should > have one I assume. > > I seriously doubt that Hotspot would have any dependence on atlmfc. > I searched and found no include's of any obvious atl files. > > - >> From kelly.ohair at sun.com Fri May 16 06:59:27 2008 From: kelly.ohair at sun.com (kelly.ohair at sun.com) Date: Fri, 16 May 2008 06:59:27 +0000 Subject: hg: jdk7/build/jdk: 6590549: Cygwin build of OpenJDK has problems and not very well documented Message-ID: <20080516065952.73A74281A6@hg.openjdk.java.net> Changeset: 7971bbb6dc42 Author: ohair Date: 2008-05-15 13:04 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/7971bbb6dc42 6590549: Cygwin build of OpenJDK has problems and not very well documented Summary: Just the Makefile changes to fix a cygwin nawk BINMODE=w problem. Reviewed-by: igor, tbell ! make/common/shared/Defs-utils.gmk ! make/java/java/Makefile ! make/java/nio/Makefile From jesse.glick at sun.com Fri May 16 19:04:10 2008 From: jesse.glick at sun.com (Jesse Glick) Date: Fri, 16 May 2008 15:04:10 -0400 Subject: Continuous builds for OpenJDK (was: Running findbugs) In-Reply-To: <482A2E1B.5070901@sun.com> References: <482A264F.2070301@sun.com> <482A2E1B.5070901@sun.com> Message-ID: David Herron wrote: > I would be happy to have more quality metrics like findbugs results > to publish on the site. On that note, has anyone set up or thought about setting up a public continuous builder for OpenJDK, e.g. using Hudson? This would ensure that the codeline is still buildable (of course), and could show test status, show FindBugs metrics, permit downloads of snapshot builds, etc. One issue with Hudson is that it does not yet support the Forest extension in its Mercurial plugin. You can 'hg fpull -u' in your build script to do the update, but then the changelog will only show changes in the root tree, and polling will not work correctly. Probably fixable in the plugin; or it might just be better to set up a separate job for each tree, assuming these components can be built meaningfully in isolation (definitely true for langtools). You can also have "downstream" jobs, so it would be possible for a jdk job to use binary artifacts from the most recent successful build of a hotspot job, assuming the makefile supports this scenario. From Kelly.Ohair at Sun.COM Fri May 16 20:47:37 2008 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Fri, 16 May 2008 13:47:37 -0700 Subject: Continuous builds for OpenJDK In-Reply-To: References: <482A264F.2070301@sun.com> <482A2E1B.5070901@sun.com> Message-ID: <482DF2E9.6020508@sun.com> Jesse Glick wrote: > David Herron wrote: >> I would be happy to have more quality metrics like findbugs results >> to publish on the site. > > On that note, has anyone set up or thought about setting up a public > continuous builder for OpenJDK, e.g. using Hudson? This would ensure > that the codeline is still buildable (of course), and could show test > status, show FindBugs metrics, permit downloads of snapshot builds, etc. Last I looked, Hudson did not support building native code on all 8 basic platforms, and more platforms if you want to include all the various Linux flavors. Having the OpenJDK build on just one platform is valuable, but not really very re-assuring when it's so easy to break native code when using all the different architectures and C/C++ compilers we use. The findbugs issue doesn't get any better with Hudson, not sure how it can help when it takes 12+hours to run findbugs on the jdk. Hudson is a great tool, but I think it's sweet spot is the typical Java project or product, built with a build.xml file and with little or no native code. > > One issue with Hudson is that it does not yet support the Forest > extension in its Mercurial plugin. You can 'hg fpull -u' in your build > script to do the update, but then the changelog will only show changes > in the root tree, and polling will not work correctly. Probably fixable > in the plugin; or it might just be better to set up a separate job for > each tree, assuming these components can be built meaningfully in > isolation (definitely true for langtools). You can also have > "downstream" jobs, so it would be possible for a jdk job to use binary > artifacts from the most recent successful build of a hotspot job, > assuming the makefile supports this scenario. We have an in-house build/test system for the jdk called JPRT, which we hope to open source, but it requires all the various platform client hardware. The JPRT principle is based on a distributed SCM model, where all the builds on all the platforms are guaranteed successful before the changes ever get pushed to any shared repository. This is different than doing a continuous build, which detects when an area won't build and raises alarms when a shared repository fails to build. JPRT works on a 'on-demand' job request from a user needing to push changes, the shared repository is always guaranteed to build. -kto From Jesse.Glick at Sun.COM Fri May 16 21:47:54 2008 From: Jesse.Glick at Sun.COM (Jesse Glick) Date: Fri, 16 May 2008 17:47:54 -0400 Subject: Continuous builds for OpenJDK In-Reply-To: <482DF2E9.6020508@sun.com> References: <482A264F.2070301@sun.com> <482A2E1B.5070901@sun.com> <482DF2E9.6020508@sun.com> Message-ID: <482E010A.8060102@sun.com> Kelly O'Hair wrote: > Last I looked, Hudson did not support building native code If there's a makefile, it can run it. > on all 8 basic platforms There is a way to run the same build across different slaves with different machine architectures: http://hudson.gotdns.com/wiki/display/HUDSON/Building+a+matrix+project > The findbugs issue doesn't get any better with Hudson Well of course however long it takes to run that is how long you have to wait. Hudson might make it a bit easier to run FB on a separate slave, as a downstream job, so it does not slow down other jobs. > JPRT works on a 'on-demand' job request from a user needing to push > changes, the shared repository is always guaranteed to build. So if all changesets are preverified you don't need a separate continuous builder for much. From ted at tedneward.com Sat May 17 20:16:04 2008 From: ted at tedneward.com (Ted Neward) Date: Sat, 17 May 2008 13:16:04 -0700 Subject: FW: ATL headers and libraries? In-Reply-To: <482C76CD.8080707@sun.com> References: <049501c8b51e$4ed61b40$ec8251c0$@com> <4829DCAF.3090707@sun.com> <091401c8b6aa$b7cc1540$27643fc0$@com> <482C6FAD.4020100@sun.com> <482C76CD.8080707@sun.com> Message-ID: <064901c8b85a$d6f35da0$84da18e0$@com> AH.... Excellent. :-) Ted Neward Java, .NET, XML Services Consulting, Teaching, Speaking, Writing http://www.tedneward.com > -----Original Message----- > From: Phil.Race at Sun.COM [mailto:Phil.Race at Sun.COM] > Sent: Thursday, May 15, 2008 10:46 AM > To: Kelly O'Hair > Cc: Ted Neward; build-dev at openjdk.java.net > Subject: Re: FW: ATL headers and libraries? > > A member of the hotspot team built hotspot (nothing else) with Visual > Studio Express 2008 about > a month ago, so there should be no dependencies on ATL since that isn't > in VS Express. > > -phil. > > Kelly O'Hair wrote: > > > > Tim's email: > > http://mail.openjdk.java.net/pipermail/build-dev/2007- > December/000654.html > > > > > > Mentions this: > > hotspot\src\os\windows\vm\jvm_windows.h(33) : fatal error C1083: > > Cannot open include file: 'windows.h': No such file or directory > > > > > > But windows.h should not be a problem to find, right? Platform SDK > should > > have one I assume. > > > > I seriously doubt that Hotspot would have any dependence on atlmfc. > > I searched and found no include's of any obvious atl files. > > > > - > >> > > No virus found in this incoming message. > Checked by AVG. > Version: 7.5.524 / Virus Database: 269.23.16/1434 - Release Date: > 5/15/2008 7:24 AM > No virus found in this outgoing message. Checked by AVG. Version: 7.5.524 / Virus Database: 269.23.16/1448 - Release Date: 5/16/2008 7:42 PM From ted at tedneward.com Sat May 17 20:16:29 2008 From: ted at tedneward.com (Ted Neward) Date: Sat, 17 May 2008 13:16:29 -0700 Subject: FW: ATL headers and libraries? In-Reply-To: <482C6FAD.4020100@sun.com> References: <049501c8b51e$4ed61b40$ec8251c0$@com> <4829DCAF.3090707@sun.com> <091401c8b6aa$b7cc1540$27643fc0$@com> <482C6FAD.4020100@sun.com> Message-ID: <064a01c8b85a$e5aa2680$b0fe7380$@com> This would also explain why I'm not finding any there, either. :-) Ted Neward Java, .NET, XML Services Consulting, Teaching, Speaking, Writing http://www.tedneward.com > -----Original Message----- > From: Kelly.Ohair at Sun.COM [mailto:Kelly.Ohair at Sun.COM] > Sent: Thursday, May 15, 2008 10:15 AM > To: Ted Neward > Cc: build-dev at openjdk.java.net > Subject: Re: FW: ATL headers and libraries? > > > Tim's email: http://mail.openjdk.java.net/pipermail/build-dev/2007- > December/000654.html > > Mentions this: > hotspot\src\os\windows\vm\jvm_windows.h(33) : fatal error C1083: > Cannot open include file: 'windows.h': No such file > or directory > > > But windows.h should not be a problem to find, right? Platform SDK > should > have one I assume. > > I seriously doubt that Hotspot would have any dependence on atlmfc. > I searched and found no include's of any obvious atl files. > > -kto > > > Ted Neward wrote: > > My understanding was that it did--there are a few build-dev emails > about > > missing "atlmfc.h" just a few weeks ago.... > > > > But I haven't verified that from looking at the sources yet--been > busy with > > other things. I'll take a look and see. Can you check with the > Hotspot team > > if they know of any in the meantime (or, perhaps better yet, can you > suggest > > which list would be best to forward this email to)? > > > > Ted Neward > > Java, .NET, XML Services > > Consulting, Teaching, Speaking, Writing > > http://www.tedneward.com > > > > > >> -----Original Message----- > >> From: Kelly.Ohair at Sun.COM [mailto:Kelly.Ohair at Sun.COM] > >> Sent: Tuesday, May 13, 2008 11:24 AM > >> To: Ted Neward > >> Cc: build-dev at openjdk.java.net > >> Subject: Re: FW: ATL headers and libraries? > >> > >> Does the hotspot sources have a ATL/MFC dependence? > >> > >> -kto > >> > >> > >> Ted Neward wrote: > >>> Kelly, et al? > >>> > >>> > >>> > >>> Should we just wait with the attempted port until this (see below) > >>> happens? Or do we want to try and actively remove the dependencies > on > >>> ATL/MFC from the Hotspot code? > >>> > >>> > >>> > >>> Ted Neward > >>> > >>> Java, .NET, XML Services > >>> > >>> Consulting, Teaching, Speaking, Writing > >>> > >>> http://www.tedneward.com > >>> > >>> > >>> > >>> *From:* Herb Sutter [mailto:hsutter at microsoft.com] > >>> *Sent:* Tuesday, May 13, 2008 4:08 AM > >>> *To:* Ted Neward > >>> *Subject:* RE: ATL headers and libraries? > >>> > >>> > >>> > >>> Unfortunately, no, there is no way to get to ATL and/or MFC without > >>> buying VS Std/Pro/etc. (of course, you can get those through your > >> MSDN > >>> subscription, etc.) > >>> > >>> > >>> > >>> For the future, though, the plan is to ship both ATL and MFC (x86, > I > >>> believe) in VC++ Express at some point. > >>> > >>> > >>> > >>> Herb > >>> > >>> > >>> > >>> > >>> > >>> *From:* Ted Neward [mailto:ted at tedneward.com] > >>> *Sent:* Monday, May 12, 2008 12:23 PM > >>> *To:* Herb Sutter > >>> *Subject:* ATL headers and libraries? > >>> > >>> > >>> > >>> Can you tell me (or put me in touch with somebody who can) if it?s > >>> possible to get a hold of the ATL and/or MFC headers and libraries > >>> without buying Visual Studio Standard/Professional/Enterprise/etc? > I > >>> have a client who?s looking to see if they can use just VC++ > Express > >> to > >>> maintain some code that uses ATL and MFC. > >>> > >>> > >>> > >>> Ted Neward > >>> > >>> Java, .NET, XML Services > >>> > >>> Consulting, Teaching, Speaking, Writing > >>> > >>> http://www.tedneward.com > >>> > >>> > >>> > >>> > >>> > >>> No virus found in this outgoing message. > >>> Checked by AVG. > >>> Version: 7.5.524 / Virus Database: 269.23.15/1426 - Release Date: > >>> 5/10/2008 11:12 AM > >>> > >>> > >>> > >>> No virus found in this incoming message. > >>> Checked by AVG. > >>> Version: 7.5.524 / Virus Database: 269.23.15/1426 - Release Date: > >>> 5/10/2008 11:12 AM > >>> > >>> > >>> No virus found in this outgoing message. > >>> Checked by AVG. > >>> Version: 7.5.524 / Virus Database: 269.23.16/1430 - Release Date: > >>> 5/13/2008 7:31 AM > >>> > >> No virus found in this incoming message. > >> Checked by AVG. > >> Version: 7.5.524 / Virus Database: 269.23.16/1430 - Release Date: > >> 5/13/2008 7:31 AM > >> > > > > No virus found in this outgoing message. > > Checked by AVG. > > Version: 7.5.524 / Virus Database: 269.23.16/1434 - Release Date: > 5/15/2008 > > 7:24 AM > > > > > > No virus found in this incoming message. > Checked by AVG. > Version: 7.5.524 / Virus Database: 269.23.16/1434 - Release Date: > 5/15/2008 7:24 AM > No virus found in this outgoing message. Checked by AVG. Version: 7.5.524 / Virus Database: 269.23.16/1448 - Release Date: 5/16/2008 7:42 PM From martinrb at google.com Sat May 17 20:31:52 2008 From: martinrb at google.com (Martin Buchholz) Date: Sat, 17 May 2008 13:31:52 -0700 Subject: JDK_DEBUG_IMAGE_DIR Message-ID: <1ccfd1c10805171331k44829daxae93c3e05ddabadc@mail.gmail.com> The only reference to JDK_DEBUG_IMAGE_DIR in the jdk workspace is ./make/common/Release.gmk:1239: $(RM) -r $(JDK_DEBUG_IMAGE_DIR) This variable is defined nowhere. As a result, "make images-clobber" runs the command rm -f -r This is Mostly Harmless, but what would happen if a user happened to have defined an environment variable JDK_DEBUG_IMAGE_DIR=/ so I consider this a P2 bug. Just remove that line from Release.gmk. For bonus points, write a script to find all never-defined MAKE variables in all the JDK makefiles. # HG changeset patch # User martin # Date 1211056134 25200 # Node ID 9149e388e6e353da275887a0e6b4ae5ef63b4689 # Parent 1483094a7c17de9c594d51e0f0785d24e3858392 [mq]: JDK_DEBUG_IMAGE_DIR.patch diff --git a/make/common/Release.gmk b/make/common/Release.gmk --- a/make/common/Release.gmk +++ b/make/common/Release.gmk @@ -1236,7 +1236,6 @@ ifeq ($(PLATFORM), windows) $(RM) $(TEMPDIR)/rebase.input endif $(RM) -r $(JDK_IMAGE_DIR) - $(RM) -r $(JDK_DEBUG_IMAGE_DIR) $(RM) -r $(JRE_IMAGE_DIR) images images-clobber:: From Tim.Bell at Sun.COM Sat May 17 21:42:01 2008 From: Tim.Bell at Sun.COM (Tim Bell) Date: Sat, 17 May 2008 14:42:01 -0700 Subject: JDK_DEBUG_IMAGE_DIR In-Reply-To: <1ccfd1c10805171331k44829daxae93c3e05ddabadc@mail.gmail.com> References: <1ccfd1c10805171331k44829daxae93c3e05ddabadc@mail.gmail.com> Message-ID: <482F5129.6040408@sun.com> Martin Buchholz wrote: > The only reference to JDK_DEBUG_IMAGE_DIR > in the jdk workspace is > > ./make/common/Release.gmk:1239: $(RM) -r $(JDK_DEBUG_IMAGE_DIR) > > This variable is defined nowhere. Thanks, Martin. I filed bug-ID 6704165 with the contents of this email. In a day or two the information should be visible here: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6704165 Tim From rob.ross at gmail.com Mon May 19 11:27:39 2008 From: rob.ross at gmail.com (Rob Ross) Date: Mon, 19 May 2008 04:27:39 -0700 Subject: Building OpenJDK 7 on Windows XP Message-ID: Hi there everyone. This will officially be my first email to the OpenJDK project. I got to attend a couple of sessions/BOFs at JavaOne2008 about OpenJDK and my interest was piqued. I've been playing with the build for the last week. (A more accurate description would be, "yanking my hair out and cursing my computer quite often", but I supposed it's part of the learning curve.) I was finally able to get "make sanity" to pass this evening, and I felt quite pleased with myself. However, I have no expectations that this will actually build now - but I still consider this a milestone victory. Some of the difficulties I encountered were 1. Just assembling the prerequisite software The jdk7/README-builds.html actually does a fairly good job of listing everything needed. But I'm not a Windows developer, so finding a copy of VS .Net 2003 was a little challenging. Luckily that install process was pretty simple. The build generates a warning if Ant and FindBugs aren't locatable; those were easy to install but perhaps you should add these programs to the list of requirements in the README. Cygwin was also pretty easy to install after spending a little time reading up on it. Finding an earlier version of make (gmake) was a little hard, but I see now there are links in the mailing list archive so that would be useful to add a link to the README as well. Some of the Categories/package names you gave for the particular cygwin utilities needed may be out of date. Zip and Unzip are found in the Archive category, not Utils as described in the README. "Free" is listed as being in Utils but it's actually part of the "procps" package, under the System category. And there isn't an "awk" implementation, but there is a gawk. Freetype was the bane of my existence for 3 days. I never could get the "stock" build scripts to work with the version you stated was needed (2.3.0), and what was available to be downloaded (2.3.5). I could not figure out how to build it from source either via DOS/windows or cygwin. So I ended up downloading the binary setup executable, which contained freetype.lib, freetype6.dll, and zlib1.dll, and a freetype.dll.a that was a red herring. I modified the Makefile for the freetypecheck tool to change the name of the expected dll from "freetype.dll" to "freetype6.dll", and added its dependent "zlib1.dll" to the copy command. Not a very portable solution I know, but I just wanted to get this thing to work! How is everyone else getting this to compile? 2. Mercurial - well, it's new, and a little more complicated than CVS/ SVN, but I think I'll get the hang of it. I fcloned from the jdk7 master forest, (using the forest extension) yesterday, so I have the latest code (baring any changes in the last day). It will be a while before I even have to worry about wanting to submit anything back upstream, so I should be more comfortable with how it all works by then. 3. Setting up the ALT_* environment variables The hardest part, and mostly trial-and-error, was determining what variables needed to use the cygwin path syntax, and what needed to use the normal Windows path syntax, and what needed to be "shortcutted" by using the cygpath utility. This was mind numbingly frustrating!!!! I found an email from Tim Bell that included his sample script that was quite helpful in getting the right directories from the VS .Net 2003 install into the PATH, LIB, and INCLUDE variables, with the right syntax. As I was writing this email my initial "gmake all" build failed, due to javac not being able to find the binary plugins I had specified in ALT_BINARY_PLUGINS_PATH. It seems THAT one needs to be a java IO file path! So now there are THREE different path syntaxes in use in this script file :) Anyway, I just wanted to share my experiences building the OpenJDK 7 on Windows. Ironically, I'm only doing this to get some practice on the existing build process. My ultimate goal is to port the OpenJDK 7 to Mac OS X, as a full native app. I'm doing some preliminary analysis on the existing code base to determine all calls to native methods, to get a sense of the scope. For example, there are currently about 421 native method calls in the jdk/src/share classes. The Windows implementation classes make 210 native calls, and the Solaris implementation makes 299. But the first task would be to integrate Mac OS build targets into the OpenJDK 7 project, so it can be built on that platform. (Of course, it won't actually run without any native implementation - that's step #2.) But I'll be making a more formal presentation/declaration/request for sponsorship/ at a later time. Rob Ross From Kelly.Ohair at Sun.COM Mon May 19 15:44:08 2008 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Mon, 19 May 2008 08:44:08 -0700 Subject: Building OpenJDK 7 on Windows XP In-Reply-To: References: Message-ID: <4831A048.2070201@sun.com> Rob Ross wrote: > Hi there everyone. > > This will officially be my first email to the OpenJDK project. Welcome. I actually appreciate the email, some comments below. > > I got to attend a couple of sessions/BOFs at JavaOne2008 about OpenJDK > and my interest was piqued. I've been playing with the build for the > last week. (A more accurate description would be, "yanking my hair out > and cursing my computer quite often", but I supposed it's part of the > learning curve.) You did pick the most difficult platform you know. ;^) These are the notes and action items I see from your comments: 1. assembling the prerequisite software - VS .Net 2003 - Will be changing soon to a newer VC compiler, and if at all possible the free one. - Ant is a requirement, I'll fix the Build README, findbugs is not strictly a requirement, it's under discussion, I had hoped to use it as part of the build. I may be removing the sanity check on findbugs. - Cygwin is a bit of a challenge, it changes/updates rather often, I'll try and correct the references to the packages you mention, but it's like the different Linux packages, sometimes all I can give is hints. - The Build README should have some references to the older cygwin 'make' now, but I'll double check. I kind of hoped it would fix itself someday. :^( - Freetype is new to many of us, I use a freetype that someone else built so I have never experienced building it myself. I will try and look into this and see if I can document it better. 2. Mercurial - CVS/Subversion users seem to have trouble understanding the distributed nature of Mercurial. I'd recommend looking at the first few chapters of the Mercurial book: http://hgbook.red-bean.com/hgbook.html 3. Setting up the ALT_* environment variables - If I didn't document this I should have, my apologies, but I encourage all ALT_* variables to use the C:/ style of paths, not C:\ and definitely not the /cygdrive/ style paths. The makefiles try and turn the C:\ paths into C:/, but using the cygwin paths are more difficult to deal with. The problem is that some of the exe's we use understand these paths and some don't, almost everything understands C:/, and avoiding the use of \ characters in shell scripts and Makefiles is a very sane thing to do. Making matters worse, the cygwin 'make' that stopped working with C: paths for a while, hopefully this gets fixed someday. Of course cygwin PATH must use ':' characters to separate paths, so you have to use /cygdrive/ paths in PATH. The LIB and INCLUDE env variables belong to the VS2003 compiler and they use a ';' separator and need the C:/ paths. See my blog: http://blogs.sun.com/kto/entry/windows_cygwin_mks_java_and I suspect that your experience with MacOS X will not be the same as Windows. Thanks for taking the time to make the comments. -kto > > I was finally able to get "make sanity" to pass this evening, and I felt > quite pleased with myself. However, I have no expectations that this > will actually build now - but I still consider this a milestone victory. > > Some of the difficulties I encountered were > > 1. Just assembling the prerequisite software > The jdk7/README-builds.html actually does a fairly good job of listing > everything needed. But I'm not a Windows developer, so finding a copy of > VS .Net 2003 was a little challenging. Luckily that install process was > pretty simple. The build generates a warning if Ant and FindBugs aren't > locatable; those were easy to install but perhaps you should add these > programs to the list of requirements in the README. Cygwin was also > pretty easy to install after spending a little time reading up on it. > Finding an earlier version of make (gmake) was a little hard, but I see > now there are links in the mailing list archive so that would be useful > to add a link to the README as well. Some of the Categories/package > names you gave for the particular cygwin utilities needed may be out of > date. Zip and Unzip are found in the Archive category, not Utils as > described in the README. "Free" is listed as being in Utils but it's > actually part of the "procps" package, under the System category. And > there isn't an "awk" implementation, but there is a gawk. Freetype was > the bane of my existence for 3 days. I never could get the "stock" build > scripts to work with the version you stated was needed (2.3.0), and what > was available to be downloaded (2.3.5). I could not figure out how to > build it from source either via DOS/windows or cygwin. So I ended up > downloading the binary setup executable, which contained freetype.lib, > freetype6.dll, and zlib1.dll, and a freetype.dll.a that was a red > herring. I modified the Makefile for the freetypecheck tool to change > the name of the expected dll from "freetype.dll" to "freetype6.dll", and > added its dependent "zlib1.dll" to the copy command. Not a very portable > solution I know, but I just wanted to get this thing to work! How is > everyone else getting this to compile? > > 2. Mercurial - well, it's new, and a little more complicated than > CVS/SVN, but I think I'll get the hang of it. I fcloned from the jdk7 > master forest, (using the forest extension) yesterday, so I have the > latest code (baring any changes in the last day). It will be a while > before I even have to worry about wanting to submit anything back > upstream, so I should be more comfortable with how it all works by then. > > 3. Setting up the ALT_* environment variables > The hardest part, and mostly trial-and-error, was determining what > variables needed to use the cygwin path syntax, and what needed to use > the normal Windows path syntax, and what needed to be "shortcutted" by > using the cygpath utility. This was mind numbingly frustrating!!!! I > found an email from Tim Bell that included his sample script that was > quite helpful in getting the right directories from the VS .Net 2003 > install into the PATH, LIB, and INCLUDE variables, with the right > syntax. As I was writing this email my initial "gmake all" build failed, > due to javac not being able to find the binary plugins I had specified > in ALT_BINARY_PLUGINS_PATH. It seems THAT one needs to be a java IO file > path! So now there are THREE different path syntaxes in use in this > script file :) > > > Anyway, I just wanted to share my experiences building the OpenJDK 7 on > Windows. > > Ironically, I'm only doing this to get some practice on the existing > build process. My ultimate goal is to port the OpenJDK 7 to Mac OS X, as > a full native app. I'm doing some preliminary analysis on the existing > code base to determine all calls to native methods, to get a sense of > the scope. For example, there are currently about 421 native method > calls in the jdk/src/share classes. The Windows implementation classes > make 210 native calls, and the Solaris implementation makes 299. But the > first task would be to integrate Mac OS build targets into the OpenJDK 7 > project, so it can be built on that platform. (Of course, it won't > actually run without any native implementation - that's step #2.) But > I'll be making a more formal presentation/declaration/request for > sponsorship/ at a later time. > > Rob Ross > From martinrb at google.com Mon May 19 16:02:08 2008 From: martinrb at google.com (Martin Buchholz) Date: Mon, 19 May 2008 09:02:08 -0700 Subject: Building OpenJDK 7 on Windows XP In-Reply-To: <4831A048.2070201@sun.com> References: <4831A048.2070201@sun.com> Message-ID: <1ccfd1c10805190902u5a4f81d9p46f05774a7c3e75c@mail.gmail.com> I propose that Sun create an externally-visible tree of binaries in the form that the JDK makefiles expect for ALT_SLASH_JAVA. Then OpenJDK developers could copy this tree to their development machine, set ALT_SLASH_JAVA to this directory, and most of the sanity warnings would evaporate. Of course, this may not be possible for everything that is expected to be found in ALT_SLASH_JAVA. E.g. Sun compilers probably cannot be provided this way, because of the usual requirement to have click-through licenses?! Perhaps Sun could aggregate a complete JDK development environment in one mega-tarball, protected by just one click-through license? Perhaps Sun could provide a known-to-work copy of Cygwin for JDK development. The Cygwin project itself doesn't provide historic binaries, but if you install Cygwin by first downloading everything to disk, and then installing from there, you'll have a frozen-in-time set of Cygwin binaries that you can probably legally redistribute later when they've gotten the thumbs-up from Sun JDK development engineers. Martin From Jonathan.Gibbons at Sun.COM Mon May 19 17:17:51 2008 From: Jonathan.Gibbons at Sun.COM (Jonathan Gibbons) Date: Mon, 19 May 2008 10:17:51 -0700 Subject: Building OpenJDK 7 on Windows XP In-Reply-To: <1ccfd1c10805190902u5a4f81d9p46f05774a7c3e75c@mail.gmail.com> References: <4831A048.2070201@sun.com> <1ccfd1c10805190902u5a4f81d9p46f05774a7c3e75c@mail.gmail.com> Message-ID: <8536E2CF-5841-4B1B-98F8-D15F8517FE10@sun.com> Martin, I'd settle for just a *list* of all the tools you need, and have the JDK build able to find all the tools given a minimum of ALT variable settings. For licensing reasons, I suspect Sun cannot redistribute many of the tools, but if the user could populate such a tree, then any version of OpenJDK should be able to build with it, with perhaps just one ALT_TOOLS setting. -- Jon On May 19, 2008, at 9:02 AM, Martin Buchholz wrote: > I propose that Sun create an externally-visible tree of binaries > in the form that the JDK makefiles expect for ALT_SLASH_JAVA. > Then OpenJDK developers could copy this tree to their development > machine, set ALT_SLASH_JAVA to this directory, and most of > the sanity warnings would evaporate. > > Of course, this may not be possible for everything that is > expected to be found in ALT_SLASH_JAVA. E.g. Sun compilers > probably cannot be provided this way, because of the usual > requirement to have click-through licenses?! > Perhaps Sun could aggregate a complete JDK development > environment in one mega-tarball, protected by just one > click-through license? > > Perhaps Sun could provide a known-to-work copy of Cygwin > for JDK development. The Cygwin project itself doesn't provide > historic binaries, but if you install Cygwin by first downloading > everything to disk, and then installing from there, you'll have > a frozen-in-time set of Cygwin binaries that you can probably > legally redistribute later when they've gotten the thumbs-up > from Sun JDK development engineers. > > Martin From Kelly.Ohair at Sun.COM Mon May 19 18:28:04 2008 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Mon, 19 May 2008 11:28:04 -0700 Subject: Building OpenJDK 7 on Windows XP In-Reply-To: <1ccfd1c10805190902u5a4f81d9p46f05774a7c3e75c@mail.gmail.com> References: <4831A048.2070201@sun.com> <1ccfd1c10805190902u5a4f81d9p46f05774a7c3e75c@mail.gmail.com> Message-ID: <4831C6B4.6090603@sun.com> I can't see this happening due to the legal re-distribution issues and requirements you'd have on all these different software packages. And I for one would NOT want to be the maintainer of it. Maybe my frustrations with Windows is blinding me to some new good solution to this problem, but installing cygwin is the least of the Windows issues in my opinion. -kto Martin Buchholz wrote: > I propose that Sun create an externally-visible tree of binaries > in the form that the JDK makefiles expect for ALT_SLASH_JAVA. > Then OpenJDK developers could copy this tree to their development > machine, set ALT_SLASH_JAVA to this directory, and most of > the sanity warnings would evaporate. > > Of course, this may not be possible for everything that is > expected to be found in ALT_SLASH_JAVA. E.g. Sun compilers > probably cannot be provided this way, because of the usual > requirement to have click-through licenses?! > Perhaps Sun could aggregate a complete JDK development > environment in one mega-tarball, protected by just one > click-through license? > > Perhaps Sun could provide a known-to-work copy of Cygwin > for JDK development. The Cygwin project itself doesn't provide > historic binaries, but if you install Cygwin by first downloading > everything to disk, and then installing from there, you'll have > a frozen-in-time set of Cygwin binaries that you can probably > legally redistribute later when they've gotten the thumbs-up > from Sun JDK development engineers. > > Martin From Kelly.Ohair at Sun.COM Mon May 19 18:31:14 2008 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Mon, 19 May 2008 11:31:14 -0700 Subject: Building OpenJDK 7 on Windows XP In-Reply-To: <8536E2CF-5841-4B1B-98F8-D15F8517FE10@sun.com> References: <4831A048.2070201@sun.com> <1ccfd1c10805190902u5a4f81d9p46f05774a7c3e75c@mail.gmail.com> <8536E2CF-5841-4B1B-98F8-D15F8517FE10@sun.com> Message-ID: <4831C772.3090704@sun.com> I tried to provide that list at: http://hg.openjdk.java.net/jdk7/build/raw-file/tip/README-builds.html#windows Did I miss the target somehow? -kto Jonathan Gibbons wrote: > Martin, > > I'd settle for just a *list* of all the tools you need, and have the JDK > build able to find all the tools given a minimum of ALT variable settings. > For licensing reasons, I suspect Sun cannot redistribute many of the tools, > but if the user could populate such a tree, then any version of OpenJDK > should be able to build with it, with perhaps just one ALT_TOOLS setting. > > -- Jon > > > On May 19, 2008, at 9:02 AM, Martin Buchholz wrote: > >> I propose that Sun create an externally-visible tree of binaries >> in the form that the JDK makefiles expect for ALT_SLASH_JAVA. >> Then OpenJDK developers could copy this tree to their development >> machine, set ALT_SLASH_JAVA to this directory, and most of >> the sanity warnings would evaporate. >> >> Of course, this may not be possible for everything that is >> expected to be found in ALT_SLASH_JAVA. E.g. Sun compilers >> probably cannot be provided this way, because of the usual >> requirement to have click-through licenses?! >> Perhaps Sun could aggregate a complete JDK development >> environment in one mega-tarball, protected by just one >> click-through license? >> >> Perhaps Sun could provide a known-to-work copy of Cygwin >> for JDK development. The Cygwin project itself doesn't provide >> historic binaries, but if you install Cygwin by first downloading >> everything to disk, and then installing from there, you'll have >> a frozen-in-time set of Cygwin binaries that you can probably >> legally redistribute later when they've gotten the thumbs-up >> from Sun JDK development engineers. >> >> Martin > From Weijun.Wang at Sun.COM Mon May 19 23:57:36 2008 From: Weijun.Wang at Sun.COM (Max (Weijun) Wang) Date: Tue, 20 May 2008 07:57:36 +0800 Subject: Building OpenJDK 7 on Windows XP In-Reply-To: <4831C772.3090704@sun.com> References: <4831A048.2070201@sun.com> <1ccfd1c10805190902u5a4f81d9p46f05774a7c3e75c@mail.gmail.com> <8536E2CF-5841-4B1B-98F8-D15F8517FE10@sun.com> <4831C772.3090704@sun.com> Message-ID: One setting is enough, if the directory structure is right: $ALT_SLASH_JAVA devtools share ant... findbugs... plugin mozilla_headers_18.win32... Windows DXSDK... re jdk 1.6.0/archive/fcs/binaries/windows-i586... 1.7.0/promoted/latest/binaries/windows-i586... (I hope the last 2 are correct) and, a very clean instruction: 1. Open the VC++.2003 Command prompt 2. call c:\cygwin\cygwin.bat 3. cd myjdk 4. /cygdrive/c/precious/make380.exe Max On May 20, 2008, at 2:31 AM, Kelly O'Hair wrote: > > I tried to provide that list at: > > http://hg.openjdk.java.net/jdk7/build/raw-file/tip/README- > builds.html#windows > > Did I miss the target somehow? > > -kto > > > Jonathan Gibbons wrote: >> Martin, >> I'd settle for just a *list* of all the tools you need, and have >> the JDK >> build able to find all the tools given a minimum of ALT variable >> settings. >> For licensing reasons, I suspect Sun cannot redistribute many of >> the tools, >> but if the user could populate such a tree, then any version of >> OpenJDK >> should be able to build with it, with perhaps just one ALT_TOOLS >> setting. >> -- Jon >> On May 19, 2008, at 9:02 AM, Martin Buchholz wrote: >>> I propose that Sun create an externally-visible tree of binaries >>> in the form that the JDK makefiles expect for ALT_SLASH_JAVA. >>> Then OpenJDK developers could copy this tree to their development >>> machine, set ALT_SLASH_JAVA to this directory, and most of >>> the sanity warnings would evaporate. >>> >>> Of course, this may not be possible for everything that is >>> expected to be found in ALT_SLASH_JAVA. E.g. Sun compilers >>> probably cannot be provided this way, because of the usual >>> requirement to have click-through licenses?! >>> Perhaps Sun could aggregate a complete JDK development >>> environment in one mega-tarball, protected by just one >>> click-through license? >>> >>> Perhaps Sun could provide a known-to-work copy of Cygwin >>> for JDK development. The Cygwin project itself doesn't provide >>> historic binaries, but if you install Cygwin by first downloading >>> everything to disk, and then installing from there, you'll have >>> a frozen-in-time set of Cygwin binaries that you can probably >>> legally redistribute later when they've gotten the thumbs-up >>> from Sun JDK development engineers. >>> >>> Martin From Jonathan.Gibbons at Sun.COM Tue May 20 01:13:00 2008 From: Jonathan.Gibbons at Sun.COM (Jonathan Gibbons) Date: Mon, 19 May 2008 18:13:00 -0700 Subject: Building OpenJDK 7 on Windows XP In-Reply-To: References: <4831A048.2070201@sun.com> <1ccfd1c10805190902u5a4f81d9p46f05774a7c3e75c@mail.gmail.com> <8536E2CF-5841-4B1B-98F8-D15F8517FE10@sun.com> <4831C772.3090704@sun.com> Message-ID: <4832259C.8060806@sun.com> Kelly, Max, That list mostly covers what you need for a build (Ant does not seem to be present, required by langtools), but it bdoesn't cover everything you may need to work on OpenJDK, and it doesn't particularly encourage a single shared tree. As Max points out, you can get by with a single setting, but the hierarchy is somewhat weird and betrays more than a little bit of its Sun history :-) And, as more tools get involved, the current system of lots of separate env variables might not scale well. Although not required for the build, the page does not list additional tools that may be required for working on OpenJDK -- Mercurial, official Mercurial extensions (forest), OpenJDK Mercurial extensions (jcheck), other tools (FindBugs, etc) -- Jon Max (Weijun) Wang wrote: > One setting is enough, if the directory structure is right: > > $ALT_SLASH_JAVA > devtools > share > ant... > findbugs... > plugin > mozilla_headers_18.win32... > Windows > DXSDK... > re > jdk > 1.6.0/archive/fcs/binaries/windows-i586... > 1.7.0/promoted/latest/binaries/windows-i586... > (I hope the last 2 are correct) > > and, a very clean instruction: > > 1. Open the VC++.2003 Command prompt > 2. call c:\cygwin\cygwin.bat > 3. cd myjdk > 4. /cygdrive/c/precious/make380.exe > > Max > > On May 20, 2008, at 2:31 AM, Kelly O'Hair wrote: >> >> I tried to provide that list at: >> >> >> http://hg.openjdk.java.net/jdk7/build/raw-file/tip/README-builds.html#windows >> >> >> Did I miss the target somehow? >> >> -kto >> >> >> Jonathan Gibbons wrote: >>> Martin, >>> I'd settle for just a *list* of all the tools you need, and have the >>> JDK >>> build able to find all the tools given a minimum of ALT variable >>> settings. >>> For licensing reasons, I suspect Sun cannot redistribute many of the >>> tools, >>> but if the user could populate such a tree, then any version of OpenJDK >>> should be able to build with it, with perhaps just one ALT_TOOLS >>> setting. >>> -- Jon >>> On May 19, 2008, at 9:02 AM, Martin Buchholz wrote: >>>> I propose that Sun create an externally-visible tree of binaries >>>> in the form that the JDK makefiles expect for ALT_SLASH_JAVA. >>>> Then OpenJDK developers could copy this tree to their development >>>> machine, set ALT_SLASH_JAVA to this directory, and most of >>>> the sanity warnings would evaporate. >>>> >>>> Of course, this may not be possible for everything that is >>>> expected to be found in ALT_SLASH_JAVA. E.g. Sun compilers >>>> probably cannot be provided this way, because of the usual >>>> requirement to have click-through licenses?! >>>> Perhaps Sun could aggregate a complete JDK development >>>> environment in one mega-tarball, protected by just one >>>> click-through license? >>>> >>>> Perhaps Sun could provide a known-to-work copy of Cygwin >>>> for JDK development. The Cygwin project itself doesn't provide >>>> historic binaries, but if you install Cygwin by first downloading >>>> everything to disk, and then installing from there, you'll have >>>> a frozen-in-time set of Cygwin binaries that you can probably >>>> legally redistribute later when they've gotten the thumbs-up >>>> from Sun JDK development engineers. >>>> >>>> Martin > From Kelly.Ohair at Sun.COM Tue May 20 02:42:37 2008 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Mon, 19 May 2008 19:42:37 -0700 Subject: Building OpenJDK 7 on Windows XP In-Reply-To: <4832259C.8060806@sun.com> References: <4831A048.2070201@sun.com> <1ccfd1c10805190902u5a4f81d9p46f05774a7c3e75c@mail.gmail.com> <8536E2CF-5841-4B1B-98F8-D15F8517FE10@sun.com> <4831C772.3090704@sun.com> <4832259C.8060806@sun.com> Message-ID: <48323A9D.9080407@sun.com> It is a "BUILD" readme. The development requirements are a separate thing, perhaps that should be documented in the development guide? Yes, we should add "ant" as a build requirement, I'll fix that. --- Trying to satisfy everyone with the build configurations is frustrating to say the least. If you drew a venn diagram of what everybody wants in the build system, I'm not sure the overlapping parts are all that large. :^( -kto Jonathan Gibbons wrote: > Kelly, Max, > > That list mostly covers what you need for a build (Ant does not seem to > be present, required > by langtools), but it bdoesn't cover everything you may need to work on > OpenJDK, and it > doesn't particularly encourage a single shared tree. > > As Max points out, you can get by with a single setting, but the > hierarchy is somewhat > weird and betrays more than a little bit of its Sun history :-) And, as > more tools get involved, > the current system of lots of separate env variables might not scale well. > > Although not required for the build, the page does not list additional > tools that may be required > for working on OpenJDK -- Mercurial, official Mercurial extensions > (forest), OpenJDK Mercurial > extensions (jcheck), other tools (FindBugs, etc) > > -- Jon > > > Max (Weijun) Wang wrote: >> One setting is enough, if the directory structure is right: >> >> $ALT_SLASH_JAVA >> devtools >> share >> ant... >> findbugs... >> plugin >> mozilla_headers_18.win32... >> Windows >> DXSDK... >> re >> jdk >> 1.6.0/archive/fcs/binaries/windows-i586... >> 1.7.0/promoted/latest/binaries/windows-i586... >> (I hope the last 2 are correct) >> >> and, a very clean instruction: >> >> 1. Open the VC++.2003 Command prompt >> 2. call c:\cygwin\cygwin.bat >> 3. cd myjdk >> 4. /cygdrive/c/precious/make380.exe >> >> Max >> >> On May 20, 2008, at 2:31 AM, Kelly O'Hair wrote: >>> >>> I tried to provide that list at: >>> >>> >>> http://hg.openjdk.java.net/jdk7/build/raw-file/tip/README-builds.html#windows >>> >>> >>> Did I miss the target somehow? >>> >>> -kto >>> >>> >>> Jonathan Gibbons wrote: >>>> Martin, >>>> I'd settle for just a *list* of all the tools you need, and have the >>>> JDK >>>> build able to find all the tools given a minimum of ALT variable >>>> settings. >>>> For licensing reasons, I suspect Sun cannot redistribute many of the >>>> tools, >>>> but if the user could populate such a tree, then any version of OpenJDK >>>> should be able to build with it, with perhaps just one ALT_TOOLS >>>> setting. >>>> -- Jon >>>> On May 19, 2008, at 9:02 AM, Martin Buchholz wrote: >>>>> I propose that Sun create an externally-visible tree of binaries >>>>> in the form that the JDK makefiles expect for ALT_SLASH_JAVA. >>>>> Then OpenJDK developers could copy this tree to their development >>>>> machine, set ALT_SLASH_JAVA to this directory, and most of >>>>> the sanity warnings would evaporate. >>>>> >>>>> Of course, this may not be possible for everything that is >>>>> expected to be found in ALT_SLASH_JAVA. E.g. Sun compilers >>>>> probably cannot be provided this way, because of the usual >>>>> requirement to have click-through licenses?! >>>>> Perhaps Sun could aggregate a complete JDK development >>>>> environment in one mega-tarball, protected by just one >>>>> click-through license? >>>>> >>>>> Perhaps Sun could provide a known-to-work copy of Cygwin >>>>> for JDK development. The Cygwin project itself doesn't provide >>>>> historic binaries, but if you install Cygwin by first downloading >>>>> everything to disk, and then installing from there, you'll have >>>>> a frozen-in-time set of Cygwin binaries that you can probably >>>>> legally redistribute later when they've gotten the thumbs-up >>>>> from Sun JDK development engineers. >>>>> >>>>> Martin >> > From Jonathan.Gibbons at Sun.COM Tue May 20 02:55:28 2008 From: Jonathan.Gibbons at Sun.COM (Jonathan Gibbons) Date: Mon, 19 May 2008 19:55:28 -0700 Subject: Building OpenJDK 7 on Windows XP In-Reply-To: <48323A9D.9080407@sun.com> References: <4831A048.2070201@sun.com> <1ccfd1c10805190902u5a4f81d9p46f05774a7c3e75c@mail.gmail.com> <8536E2CF-5841-4B1B-98F8-D15F8517FE10@sun.com> <4831C772.3090704@sun.com> <4832259C.8060806@sun.com> <48323A9D.9080407@sun.com> Message-ID: <48323DA0.3080905@sun.com> True, and to be fair, the BUILD readme is quite good. Perhaps I'd be happy with a simple short table in the developers guide that at least gives me one place to go to find a list of everything I need, with (references to) info on where to get and how to "use" those tools. (ie what env variables to set.) -- Jon Kelly O'Hair wrote: > It is a "BUILD" readme. The development requirements are a separate > thing, perhaps that should be documented in the development guide? > > Yes, we should add "ant" as a build requirement, I'll fix that. > > --- > > Trying to satisfy everyone with the build configurations is frustrating > to say the least. > If you drew a venn diagram of what everybody wants in the build system, > I'm not sure the overlapping parts are all that large. :^( > > -kto > > Jonathan Gibbons wrote: >> Kelly, Max, >> >> That list mostly covers what you need for a build (Ant does not seem >> to be present, required >> by langtools), but it bdoesn't cover everything you may need to work >> on OpenJDK, and it >> doesn't particularly encourage a single shared tree. >> >> As Max points out, you can get by with a single setting, but the >> hierarchy is somewhat >> weird and betrays more than a little bit of its Sun history :-) And, >> as more tools get involved, >> the current system of lots of separate env variables might not scale >> well. >> >> Although not required for the build, the page does not list >> additional tools that may be required >> for working on OpenJDK -- Mercurial, official Mercurial extensions >> (forest), OpenJDK Mercurial >> extensions (jcheck), other tools (FindBugs, etc) >> >> -- Jon >> >> >> Max (Weijun) Wang wrote: >>> One setting is enough, if the directory structure is right: >>> >>> $ALT_SLASH_JAVA >>> devtools >>> share >>> ant... >>> findbugs... >>> plugin >>> mozilla_headers_18.win32... >>> Windows >>> DXSDK... >>> re >>> jdk >>> 1.6.0/archive/fcs/binaries/windows-i586... >>> 1.7.0/promoted/latest/binaries/windows-i586... >>> (I hope the last 2 are correct) >>> >>> and, a very clean instruction: >>> >>> 1. Open the VC++.2003 Command prompt >>> 2. call c:\cygwin\cygwin.bat >>> 3. cd myjdk >>> 4. /cygdrive/c/precious/make380.exe >>> >>> Max >>> >>> On May 20, 2008, at 2:31 AM, Kelly O'Hair wrote: >>>> >>>> I tried to provide that list at: >>>> >>>> >>>> http://hg.openjdk.java.net/jdk7/build/raw-file/tip/README-builds.html#windows >>>> >>>> >>>> Did I miss the target somehow? >>>> >>>> -kto >>>> >>>> >>>> Jonathan Gibbons wrote: >>>>> Martin, >>>>> I'd settle for just a *list* of all the tools you need, and have >>>>> the JDK >>>>> build able to find all the tools given a minimum of ALT variable >>>>> settings. >>>>> For licensing reasons, I suspect Sun cannot redistribute many of >>>>> the tools, >>>>> but if the user could populate such a tree, then any version of >>>>> OpenJDK >>>>> should be able to build with it, with perhaps just one ALT_TOOLS >>>>> setting. >>>>> -- Jon >>>>> On May 19, 2008, at 9:02 AM, Martin Buchholz wrote: >>>>>> I propose that Sun create an externally-visible tree of binaries >>>>>> in the form that the JDK makefiles expect for ALT_SLASH_JAVA. >>>>>> Then OpenJDK developers could copy this tree to their development >>>>>> machine, set ALT_SLASH_JAVA to this directory, and most of >>>>>> the sanity warnings would evaporate. >>>>>> >>>>>> Of course, this may not be possible for everything that is >>>>>> expected to be found in ALT_SLASH_JAVA. E.g. Sun compilers >>>>>> probably cannot be provided this way, because of the usual >>>>>> requirement to have click-through licenses?! >>>>>> Perhaps Sun could aggregate a complete JDK development >>>>>> environment in one mega-tarball, protected by just one >>>>>> click-through license? >>>>>> >>>>>> Perhaps Sun could provide a known-to-work copy of Cygwin >>>>>> for JDK development. The Cygwin project itself doesn't provide >>>>>> historic binaries, but if you install Cygwin by first downloading >>>>>> everything to disk, and then installing from there, you'll have >>>>>> a frozen-in-time set of Cygwin binaries that you can probably >>>>>> legally redistribute later when they've gotten the thumbs-up >>>>>> from Sun JDK development engineers. >>>>>> >>>>>> Martin >>> >> From Igor.Nekrestyanov at Sun.COM Tue May 20 05:28:14 2008 From: Igor.Nekrestyanov at Sun.COM (Igor Nekrestyanov) Date: Tue, 20 May 2008 09:28:14 +0400 Subject: Building OpenJDK 7 on Windows XP In-Reply-To: <4831A048.2070201@sun.com> References: <4831A048.2070201@sun.com> Message-ID: <4832616E.7060309@sun.com> > - Freetype is new to many of us, I use a freetype that someone else > built > so I have never experienced building it myself. > I will try and look into this and see if I can document it better. Original way to build freetype on windows is described here: http://mail.openjdk.java.net/pipermail/build-dev/2007-August/000187.html However, since then several people reported they simply used VC project file in the freetype source tree. To get project file to work with VC 2003 it has to be updated to refer to VC 2003 instead of VC 2008 - this is just 1 byte change with any text editor. -igor From rob.ross at gmail.com Tue May 20 10:43:28 2008 From: rob.ross at gmail.com (Rob Ross) Date: Tue, 20 May 2008 03:43:28 -0700 Subject: Building OpenJDK 7 on Windows XP In-Reply-To: <4831A048.2070201@sun.com> References: <4831A048.2070201@sun.com> Message-ID: <40CBB608-257A-4B9C-B903-4CC513B985DB@gmail.com> Well I'm happy to report I finally got the full build to work, although it took another 15 hours or so. The last two big issues I encountered: 1. Unfamiliarity with the freetype project, so had to figure out what needed to be built. This project is rather complicated. It supports building on at least 11 platforms, and allows for multiple compilers/ environments on many of these platforms. There are 14 different build systems supported on Windows alone! Also, this project is highly configurable, and you can build it with support for many optional features. So someone from the OpenJDK architecture team will have to decide what is officially included in this library when it is built for the OpenJDK project. And the build code for it will have to be included in the jdk7 Makefile system. I was able to build it by tweaking the VC 8 file included, and opening in VS .Net 2003. I compiled from within VS, then ran the link script I found via a link in this list's archive to create the freetype.dll and freetype.lib. The "aha" moment was when I realized there were actually TWO .lib files being created, a large static one aroung 800K, and a smaller one around 40K. I needed to use the smaller one along with the dll. 2. This is most likely a cygwin issue, but I continually experienced deadlocks/starvation of the spawned gmake processes. cygwin's gmake seems to ignore the -j option. At any one time I could have a bash process, a few shell processes, and up to 9 gmake processes running. I could easily tell when a deadlock occurred - my computer would go from sounding like a jet engine to being totally quiet. Then I tried to guess what gmake process was the oldest (not sure if window's task manager sorts them by process ID or creation time, so this is just a guess) and killed that one, and then the build would continue, but obviously with errors as some task was not completed. I had to try to rebuild more than 5 times before it finally got through it all. But in the end it completed with no errors. java -version worked! Good start java HelloWorld worked! Getting better. Going for it, I tried SwingSet2 and Java2D demos from the 1.6 JDK.. AND THEY WORKED! I did get an error in the Java2D demo complaining about missing a JPEG decoder, but I was too happy the build had worked to really worry about that right now. So add another success story to this list. Rob Ross, Lead Software Engineer E! Networks --------------------------------------------------- "Beware of he who would deny you access to information, for in his heart he dreams himself your master." -- Commissioner Pravin Lal On May 19, 2008, at 8:44 AM, Kelly O'Hair wrote: > > > Rob Ross wrote: >> Hi there everyone. >> This will officially be my first email to the OpenJDK project. > > Welcome. I actually appreciate the email, some comments below. > >> I got to attend a couple of sessions/BOFs at JavaOne2008 about >> OpenJDK and my interest was piqued. I've been playing with the >> build for the last week. (A more accurate description would be, >> "yanking my hair out and cursing my computer quite often", but I >> supposed it's part of the learning curve.) > > You did pick the most difficult platform you know. ;^) > > These are the notes and action items I see from your comments: > > 1. assembling the prerequisite software > - VS .Net 2003 - Will be changing soon to a newer VC compiler, > and if > at all possible the free one. > - Ant is a requirement, I'll fix the Build README, findbugs is > not strictly > a requirement, it's under discussion, I had hoped to use it as > part of the build. > I may be removing the sanity check on findbugs. > - Cygwin is a bit of a challenge, it changes/updates rather > often, I'll > try and correct the references to the packages you mention, but > it's like the different Linux packages, sometimes all I can > give is hints. > - The Build README should have some references to the older > cygwin 'make' > now, but I'll double check. I kind of hoped it would fix itself > someday. :^( > - Freetype is new to many of us, I use a freetype that someone > else built > so I have never experienced building it myself. > I will try and look into this and see if I can document it better. > > 2. Mercurial > - CVS/Subversion users seem to have trouble understanding the > distributed > nature of Mercurial. I'd recommend looking at the first few > chapters > of the Mercurial book: http://hgbook.red-bean.com/hgbook.html > > 3. Setting up the ALT_* environment variables > - If I didn't document this I should have, my apologies, but I > encourage > all ALT_* variables to use the C:/ style of paths, not C:\ and > definitely > not the /cygdrive/ style paths. > The makefiles try and turn the C:\ paths into C:/, but using > the cygwin > paths are more difficult to deal with. > The problem is that some of the exe's we use understand these > paths and > some don't, almost everything understands C:/, and avoiding the > use of > \ characters in shell scripts and Makefiles is a very sane > thing to do. > Making matters worse, the cygwin 'make' that stopped working > with C: > paths for a while, hopefully this gets fixed someday. > Of course cygwin PATH must use ':' characters to separate > paths, so > you have to use /cygdrive/ paths in PATH. > The LIB and INCLUDE env variables belong to the VS2003 compiler > and > they use a ';' separator and need the C:/ paths. > See my blog: > http://blogs.sun.com/kto/entry/windows_cygwin_mks_java_and > > I suspect that your experience with MacOS X will not be the same as > Windows. > > Thanks for taking the time to make the comments. > > -kto > >> I was finally able to get "make sanity" to pass this evening, and >> I felt quite pleased with myself. However, I have no expectations >> that this will actually build now - but I still consider this a >> milestone victory. >> Some of the difficulties I encountered were >> 1. Just assembling the prerequisite software >> The jdk7/README-builds.html actually does a fairly good job of >> listing everything needed. But I'm not a Windows developer, so >> finding a copy of VS .Net 2003 was a little challenging. Luckily >> that install process was pretty simple. The build generates a >> warning if Ant and FindBugs aren't locatable; those were easy to >> install but perhaps you should add these programs to the list of >> requirements in the README. Cygwin was also >> pretty easy to install after spending a little time reading up on >> it. Finding an earlier version of make (gmake) was a little hard, >> but I see now there are links in the mailing list archive so that >> would be useful to add a link to the README as well. Some of the >> Categories/package names you gave for the particular cygwin >> utilities needed may be out of date. Zip and Unzip are found in >> the Archive category, not Utils as described in the README. "Free" >> is listed as being in Utils but it's actually part of the "procps" >> package, under the System category. And there isn't an "awk" >> implementation, but there is a gawk. Freetype was the bane of my >> existence for 3 days. I never could get the "stock" build scripts >> to work with the version you stated was needed (2.3.0), and what >> was available to be downloaded (2.3.5). I could not figure out how >> to build it from source either via DOS/windows or cygwin. So I >> ended up downloading the binary setup executable, which contained >> freetype.lib, freetype6.dll, and zlib1.dll, and a freetype.dll.a >> that was a red herring. I modified the Makefile for the >> freetypecheck tool to change the name of the expected dll from >> "freetype.dll" to "freetype6.dll", and added its dependent >> "zlib1.dll" to the copy command. Not a very portable solution I >> know, but I just wanted to get this thing to work! How is everyone >> else getting this to compile? >> 2. Mercurial - well, it's new, and a little more complicated than >> CVS/SVN, but I think I'll get the hang of it. I fcloned from the >> jdk7 master forest, (using the forest extension) yesterday, so I >> have the latest code (baring any changes in the last day). It will >> be a while before I even have to worry about wanting to submit >> anything back upstream, so I should be more comfortable with how >> it all works by then. >> 3. Setting up the ALT_* environment variables >> The hardest part, and mostly trial-and-error, was determining what >> variables needed to use the cygwin path syntax, and what needed to >> use the normal Windows path syntax, and what needed to be >> "shortcutted" by using the cygpath utility. This was mind >> numbingly frustrating!!!! I found an email from Tim Bell that >> included his sample script that was quite helpful in getting the >> right directories from the VS .Net 2003 install into the PATH, >> LIB, and INCLUDE variables, with the right syntax. As I was >> writing this email my initial "gmake all" build failed, due to >> javac not being able to find the binary plugins I had specified in >> ALT_BINARY_PLUGINS_PATH. It seems THAT one needs to be a java IO >> file path! So now there are THREE different path syntaxes in use >> in this script file :) >> Anyway, I just wanted to share my experiences building the OpenJDK >> 7 on Windows. >> Ironically, I'm only doing this to get some practice on the >> existing build process. My ultimate goal is to port the OpenJDK 7 >> to Mac OS X, as a full native app. I'm doing some preliminary >> analysis on the existing code base to determine all calls to >> native methods, to get a sense of the scope. For example, there >> are currently about 421 native method calls in the jdk/src/share >> classes. The Windows implementation classes make 210 native calls, >> and the Solaris implementation makes 299. But the first task would >> be to integrate Mac OS build targets into the OpenJDK 7 project, >> so it can be built on that platform. (Of course, it won't actually >> run without any native implementation - that's step #2.) But I'll >> be making a more formal presentation/declaration/request for >> sponsorship/ at a later time. >> Rob Ross From Kelly.Ohair at Sun.COM Tue May 20 15:57:08 2008 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Tue, 20 May 2008 08:57:08 -0700 Subject: Building OpenJDK 7 on Windows XP In-Reply-To: <4832616E.7060309@sun.com> References: <4831A048.2070201@sun.com> <4832616E.7060309@sun.com> Message-ID: <4832F4D4.3020206@sun.com> Thanks Igor, I'll try and add that information to the OpenJDK Build README. -kto Igor Nekrestyanov wrote: > >> - Freetype is new to many of us, I use a freetype that someone else >> built >> so I have never experienced building it myself. >> I will try and look into this and see if I can document it better. > Original way to build freetype on windows is described here: > http://mail.openjdk.java.net/pipermail/build-dev/2007-August/000187.html > > However, since then several people reported they simply used VC project > file in the freetype source tree. > To get project file to work with VC 2003 it has to be updated to refer > to VC 2003 instead of VC 2008 > - this is just 1 byte change with any text editor. > > -igor From Kelly.Ohair at Sun.COM Tue May 20 16:05:39 2008 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Tue, 20 May 2008 09:05:39 -0700 Subject: Building OpenJDK 7 on Windows XP In-Reply-To: <40CBB608-257A-4B9C-B903-4CC513B985DB@gmail.com> References: <4831A048.2070201@sun.com> <40CBB608-257A-4B9C-B903-4CC513B985DB@gmail.com> Message-ID: <4832F6D3.5070206@sun.com> On Windows, I don't think gmake -j is used by default, unless you used it yourself. The jdk makefiles won't use it, and hotspot is built with NMAKE on windows. I have never seen the parallel job feature of GNU make work on windows, or work very well, I always avoid it. -kto Rob Ross wrote: > Well I'm happy to report I finally got the full build to work, although > it took another 15 hours or so. > > The last two big issues I encountered: > > 1. Unfamiliarity with the freetype project, so had to figure out what > needed to be built. This project is rather complicated. It supports > building on at least 11 platforms, and allows for multiple > compilers/environments on many of these platforms. There are 14 > different build systems supported on Windows alone! > > Also, this project is highly configurable, and you can build it with > support for many optional features. So someone from the OpenJDK > architecture team will have to decide what is officially included in > this library when it is built for the OpenJDK project. And the build > code for it will have to be included in the jdk7 Makefile system. > > I was able to build it by tweaking the VC 8 file included, and opening > in VS .Net 2003. I compiled from within VS, then ran the link script I > found via a link in this list's archive to create the freetype.dll and > freetype.lib. The "aha" moment was when I realized there were actually > TWO .lib files being created, a large static one aroung 800K, and a > smaller one around 40K. I needed to use the smaller one along with the dll. > > 2. This is most likely a cygwin issue, but I continually experienced > deadlocks/starvation of the spawned gmake processes. cygwin's gmake > seems to ignore the -j option. At any one time I could have a bash > process, a few shell processes, and up to 9 gmake processes running. I > could easily tell when a deadlock occurred - my computer would go from > sounding like a jet engine to being totally quiet. Then I tried to guess > what gmake process was the oldest (not sure if window's task manager > sorts them by process ID or creation time, so this is just a guess) and > killed that one, and then the build would continue, but obviously with > errors as some task was not completed. > > I had to try to rebuild more than 5 times before it finally got through > it all. But in the end it completed with no errors. > > java -version worked! Good start > > java HelloWorld worked! Getting better. > > Going for it, I tried SwingSet2 and Java2D demos from the 1.6 JDK.. AND > THEY WORKED! > > I did get an error in the Java2D demo complaining about missing a JPEG > decoder, but I was too happy the build had worked to really worry about > that right now. > > So add another success story to this list. > > > Rob Ross, Lead Software Engineer > E! Networks > > --------------------------------------------------- > "Beware of he who would deny you access to information, for in his heart > he dreams himself your master." -- Commissioner Pravin Lal > > > > On May 19, 2008, at 8:44 AM, Kelly O'Hair wrote: > >> >> >> Rob Ross wrote: >>> Hi there everyone. >>> This will officially be my first email to the OpenJDK project. >> >> Welcome. I actually appreciate the email, some comments below. >> >>> I got to attend a couple of sessions/BOFs at JavaOne2008 about >>> OpenJDK and my interest was piqued. I've been playing with the build >>> for the last week. (A more accurate description would be, "yanking my >>> hair out and cursing my computer quite often", but I supposed it's >>> part of the learning curve.) >> >> You did pick the most difficult platform you know. ;^) >> >> These are the notes and action items I see from your comments: >> >> 1. assembling the prerequisite software >> - VS .Net 2003 - Will be changing soon to a newer VC compiler, and if >> at all possible the free one. >> - Ant is a requirement, I'll fix the Build README, findbugs is not >> strictly >> a requirement, it's under discussion, I had hoped to use it as >> part of the build. >> I may be removing the sanity check on findbugs. >> - Cygwin is a bit of a challenge, it changes/updates rather often, I'll >> try and correct the references to the packages you mention, but >> it's like the different Linux packages, sometimes all I can give >> is hints. >> - The Build README should have some references to the older cygwin >> 'make' >> now, but I'll double check. I kind of hoped it would fix itself >> someday. :^( >> - Freetype is new to many of us, I use a freetype that someone else >> built >> so I have never experienced building it myself. >> I will try and look into this and see if I can document it better. >> >> 2. Mercurial >> - CVS/Subversion users seem to have trouble understanding the >> distributed >> nature of Mercurial. I'd recommend looking at the first few chapters >> of the Mercurial book: http://hgbook.red-bean.com/hgbook.html >> >> 3. Setting up the ALT_* environment variables >> - If I didn't document this I should have, my apologies, but I >> encourage >> all ALT_* variables to use the C:/ style of paths, not C:\ and >> definitely >> not the /cygdrive/ style paths. >> The makefiles try and turn the C:\ paths into C:/, but using the >> cygwin >> paths are more difficult to deal with. >> The problem is that some of the exe's we use understand these >> paths and >> some don't, almost everything understands C:/, and avoiding the >> use of >> \ characters in shell scripts and Makefiles is a very sane thing >> to do. >> Making matters worse, the cygwin 'make' that stopped working with C: >> paths for a while, hopefully this gets fixed someday. >> Of course cygwin PATH must use ':' characters to separate paths, so >> you have to use /cygdrive/ paths in PATH. >> The LIB and INCLUDE env variables belong to the VS2003 compiler and >> they use a ';' separator and need the C:/ paths. >> See my blog: >> http://blogs.sun.com/kto/entry/windows_cygwin_mks_java_and >> >> I suspect that your experience with MacOS X will not be the same as >> Windows. >> >> Thanks for taking the time to make the comments. >> >> -kto >> >>> I was finally able to get "make sanity" to pass this evening, and I >>> felt quite pleased with myself. However, I have no expectations that >>> this will actually build now - but I still consider this a milestone >>> victory. >>> Some of the difficulties I encountered were >>> 1. Just assembling the prerequisite software >>> The jdk7/README-builds.html actually does a fairly good job of >>> listing everything needed. But I'm not a Windows developer, so >>> finding a copy of VS .Net 2003 was a little challenging. Luckily that >>> install process was pretty simple. The build generates a warning if >>> Ant and FindBugs aren't locatable; those were easy to install but >>> perhaps you should add these programs to the list of requirements in >>> the README. Cygwin was also >>> pretty easy to install after spending a little time reading up on it. >>> Finding an earlier version of make (gmake) was a little hard, but I >>> see now there are links in the mailing list archive so that would be >>> useful to add a link to the README as well. Some of the >>> Categories/package names you gave for the particular cygwin utilities >>> needed may be out of date. Zip and Unzip are found in the Archive >>> category, not Utils as described in the README. "Free" is listed as >>> being in Utils but it's actually part of the "procps" package, under >>> the System category. And there isn't an "awk" implementation, but >>> there is a gawk. Freetype was the bane of my existence for 3 days. I >>> never could get the "stock" build scripts to work with the version >>> you stated was needed (2.3.0), and what was available to be >>> downloaded (2.3.5). I could not figure out how to build it from >>> source either via DOS/windows or cygwin. So I ended up downloading >>> the binary setup executable, which contained freetype.lib, >>> freetype6.dll, and zlib1.dll, and a freetype.dll.a that was a red >>> herring. I modified the Makefile for the freetypecheck tool to change >>> the name of the expected dll from "freetype.dll" to "freetype6.dll", >>> and added its dependent "zlib1.dll" to the copy command. Not a very >>> portable solution I know, but I just wanted to get this thing to >>> work! How is everyone else getting this to compile? >>> 2. Mercurial - well, it's new, and a little more complicated than >>> CVS/SVN, but I think I'll get the hang of it. I fcloned from the jdk7 >>> master forest, (using the forest extension) yesterday, so I have the >>> latest code (baring any changes in the last day). It will be a while >>> before I even have to worry about wanting to submit anything back >>> upstream, so I should be more comfortable with how it all works by then. >>> 3. Setting up the ALT_* environment variables >>> The hardest part, and mostly trial-and-error, was determining what >>> variables needed to use the cygwin path syntax, and what needed to >>> use the normal Windows path syntax, and what needed to be >>> "shortcutted" by using the cygpath utility. This was mind numbingly >>> frustrating!!!! I found an email from Tim Bell that included his >>> sample script that was quite helpful in getting the right directories >>> from the VS .Net 2003 install into the PATH, LIB, and INCLUDE >>> variables, with the right syntax. As I was writing this email my >>> initial "gmake all" build failed, due to javac not being able to find >>> the binary plugins I had specified in ALT_BINARY_PLUGINS_PATH. It >>> seems THAT one needs to be a java IO file path! So now there are >>> THREE different path syntaxes in use in this script file :) >>> Anyway, I just wanted to share my experiences building the OpenJDK 7 >>> on Windows. >>> Ironically, I'm only doing this to get some practice on the existing >>> build process. My ultimate goal is to port the OpenJDK 7 to Mac OS X, >>> as a full native app. I'm doing some preliminary analysis on the >>> existing code base to determine all calls to native methods, to get >>> a sense of the scope. For example, there are currently about 421 >>> native method calls in the jdk/src/share classes. The Windows >>> implementation classes make 210 native calls, and the Solaris >>> implementation makes 299. But the first task would be to integrate >>> Mac OS build targets into the OpenJDK 7 project, so it can be built >>> on that platform. (Of course, it won't actually run without any >>> native implementation - that's step #2.) But I'll be making a more >>> formal presentation/declaration/request for sponsorship/ at a later >>> time. >>> Rob Ross > From Kelly.Ohair at Sun.COM Tue May 20 16:48:49 2008 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Tue, 20 May 2008 09:48:49 -0700 Subject: Building OpenJDK 7 on Windows XP In-Reply-To: <4832F6D3.5070206@sun.com> References: <4831A048.2070201@sun.com> <40CBB608-257A-4B9C-B903-4CC513B985DB@gmail.com> <4832F6D3.5070206@sun.com> Message-ID: <483300F1.40806@sun.com> I do recall that a large part of the problem is that the Visual Studio compiler uses default filenames that are generic names, so that if GNU make does try and compile two different files, they can end up trying to write to the same file, not good. So it may not be GNU make's fault in all cases, more of a makefile and compile line issue. I recall having to make sure that each compile line included specifying unique paths for every file created by the compilation. I did this when I was trying to get COMPILE_APPROACH=parallel and the ALT_PARALLEL_COMPILE_JOBS feature working on windows in the jdk makefiles. The default on windows is COMPILE_APPROACH=normal, or one compile at a time. Using parallel on windows just didn't seem to give much benefit, not exactly sure why. -kto Kelly O'Hair wrote: > On Windows, I don't think gmake -j is used by default, unless you used it > yourself. The jdk makefiles won't use it, and hotspot is built with NMAKE > on windows. > > I have never seen the parallel job feature of GNU make work on windows, > or work very well, I always avoid it. > > -kto > > Rob Ross wrote: >> Well I'm happy to report I finally got the full build to work, >> although it took another 15 hours or so. >> >> The last two big issues I encountered: >> >> 1. Unfamiliarity with the freetype project, so had to figure out what >> needed to be built. This project is rather complicated. It supports >> building on at least 11 platforms, and allows for multiple >> compilers/environments on many of these platforms. There are 14 >> different build systems supported on Windows alone! >> >> Also, this project is highly configurable, and you can build it with >> support for many optional features. So someone from the OpenJDK >> architecture team will have to decide what is officially included in >> this library when it is built for the OpenJDK project. And the build >> code for it will have to be included in the jdk7 Makefile system. >> >> I was able to build it by tweaking the VC 8 file included, and opening >> in VS .Net 2003. I compiled from within VS, then ran the link script I >> found via a link in this list's archive to create the freetype.dll and >> freetype.lib. The "aha" moment was when I realized there were actually >> TWO .lib files being created, a large static one aroung 800K, and a >> smaller one around 40K. I needed to use the smaller one along with the >> dll. >> >> 2. This is most likely a cygwin issue, but I continually experienced >> deadlocks/starvation of the spawned gmake processes. cygwin's gmake >> seems to ignore the -j option. At any one time I could have a bash >> process, a few shell processes, and up to 9 gmake processes running. I >> could easily tell when a deadlock occurred - my computer would go from >> sounding like a jet engine to being totally quiet. Then I tried to >> guess what gmake process was the oldest (not sure if window's task >> manager sorts them by process ID or creation time, so this is just a >> guess) and killed that one, and then the build would continue, but >> obviously with errors as some task was not completed. >> >> I had to try to rebuild more than 5 times before it finally got >> through it all. But in the end it completed with no errors. >> >> java -version worked! Good start >> >> java HelloWorld worked! Getting better. >> >> Going for it, I tried SwingSet2 and Java2D demos from the 1.6 JDK.. >> AND THEY WORKED! >> >> I did get an error in the Java2D demo complaining about missing a JPEG >> decoder, but I was too happy the build had worked to really worry >> about that right now. >> >> So add another success story to this list. >> >> >> Rob Ross, Lead Software Engineer >> E! Networks >> >> --------------------------------------------------- >> "Beware of he who would deny you access to information, for in his >> heart he dreams himself your master." -- Commissioner Pravin Lal >> >> >> >> On May 19, 2008, at 8:44 AM, Kelly O'Hair wrote: >> >>> >>> >>> Rob Ross wrote: >>>> Hi there everyone. >>>> This will officially be my first email to the OpenJDK project. >>> >>> Welcome. I actually appreciate the email, some comments below. >>> >>>> I got to attend a couple of sessions/BOFs at JavaOne2008 about >>>> OpenJDK and my interest was piqued. I've been playing with the build >>>> for the last week. (A more accurate description would be, "yanking >>>> my hair out and cursing my computer quite often", but I supposed >>>> it's part of the learning curve.) >>> >>> You did pick the most difficult platform you know. ;^) >>> >>> These are the notes and action items I see from your comments: >>> >>> 1. assembling the prerequisite software >>> - VS .Net 2003 - Will be changing soon to a newer VC compiler, >>> and if >>> at all possible the free one. >>> - Ant is a requirement, I'll fix the Build README, findbugs is not >>> strictly >>> a requirement, it's under discussion, I had hoped to use it as >>> part of the build. >>> I may be removing the sanity check on findbugs. >>> - Cygwin is a bit of a challenge, it changes/updates rather often, >>> I'll >>> try and correct the references to the packages you mention, but >>> it's like the different Linux packages, sometimes all I can give >>> is hints. >>> - The Build README should have some references to the older cygwin >>> 'make' >>> now, but I'll double check. I kind of hoped it would fix itself >>> someday. :^( >>> - Freetype is new to many of us, I use a freetype that someone else >>> built >>> so I have never experienced building it myself. >>> I will try and look into this and see if I can document it better. >>> >>> 2. Mercurial >>> - CVS/Subversion users seem to have trouble understanding the >>> distributed >>> nature of Mercurial. I'd recommend looking at the first few chapters >>> of the Mercurial book: http://hgbook.red-bean.com/hgbook.html >>> >>> 3. Setting up the ALT_* environment variables >>> - If I didn't document this I should have, my apologies, but I >>> encourage >>> all ALT_* variables to use the C:/ style of paths, not C:\ and >>> definitely >>> not the /cygdrive/ style paths. >>> The makefiles try and turn the C:\ paths into C:/, but using the >>> cygwin >>> paths are more difficult to deal with. >>> The problem is that some of the exe's we use understand these >>> paths and >>> some don't, almost everything understands C:/, and avoiding the >>> use of >>> \ characters in shell scripts and Makefiles is a very sane thing >>> to do. >>> Making matters worse, the cygwin 'make' that stopped working with C: >>> paths for a while, hopefully this gets fixed someday. >>> Of course cygwin PATH must use ':' characters to separate paths, so >>> you have to use /cygdrive/ paths in PATH. >>> The LIB and INCLUDE env variables belong to the VS2003 compiler and >>> they use a ';' separator and need the C:/ paths. >>> See my blog: >>> http://blogs.sun.com/kto/entry/windows_cygwin_mks_java_and >>> >>> I suspect that your experience with MacOS X will not be the same as >>> Windows. >>> >>> Thanks for taking the time to make the comments. >>> >>> -kto >>> >>>> I was finally able to get "make sanity" to pass this evening, and I >>>> felt quite pleased with myself. However, I have no expectations that >>>> this will actually build now - but I still consider this a milestone >>>> victory. >>>> Some of the difficulties I encountered were >>>> 1. Just assembling the prerequisite software >>>> The jdk7/README-builds.html actually does a fairly good job of >>>> listing everything needed. But I'm not a Windows developer, so >>>> finding a copy of VS .Net 2003 was a little challenging. Luckily >>>> that install process was pretty simple. The build generates a >>>> warning if Ant and FindBugs aren't locatable; those were easy to >>>> install but perhaps you should add these programs to the list of >>>> requirements in the README. Cygwin was also >>>> pretty easy to install after spending a little time reading up on >>>> it. Finding an earlier version of make (gmake) was a little hard, >>>> but I see now there are links in the mailing list archive so that >>>> would be useful to add a link to the README as well. Some of the >>>> Categories/package names you gave for the particular cygwin >>>> utilities needed may be out of date. Zip and Unzip are found in the >>>> Archive category, not Utils as described in the README. "Free" is >>>> listed as being in Utils but it's actually part of the "procps" >>>> package, under the System category. And there isn't an "awk" >>>> implementation, but there is a gawk. Freetype was the bane of my >>>> existence for 3 days. I never could get the "stock" build scripts to >>>> work with the version you stated was needed (2.3.0), and what was >>>> available to be downloaded (2.3.5). I could not figure out how to >>>> build it from source either via DOS/windows or cygwin. So I ended up >>>> downloading the binary setup executable, which contained >>>> freetype.lib, freetype6.dll, and zlib1.dll, and a freetype.dll.a >>>> that was a red herring. I modified the Makefile for the >>>> freetypecheck tool to change the name of the expected dll from >>>> "freetype.dll" to "freetype6.dll", and added its dependent >>>> "zlib1.dll" to the copy command. Not a very portable solution I >>>> know, but I just wanted to get this thing to work! How is everyone >>>> else getting this to compile? >>>> 2. Mercurial - well, it's new, and a little more complicated than >>>> CVS/SVN, but I think I'll get the hang of it. I fcloned from the >>>> jdk7 master forest, (using the forest extension) yesterday, so I >>>> have the latest code (baring any changes in the last day). It will >>>> be a while before I even have to worry about wanting to submit >>>> anything back upstream, so I should be more comfortable with how it >>>> all works by then. >>>> 3. Setting up the ALT_* environment variables >>>> The hardest part, and mostly trial-and-error, was determining what >>>> variables needed to use the cygwin path syntax, and what needed to >>>> use the normal Windows path syntax, and what needed to be >>>> "shortcutted" by using the cygpath utility. This was mind numbingly >>>> frustrating!!!! I found an email from Tim Bell that included his >>>> sample script that was quite helpful in getting the right >>>> directories from the VS .Net 2003 install into the PATH, LIB, and >>>> INCLUDE variables, with the right syntax. As I was writing this >>>> email my initial "gmake all" build failed, due to javac not being >>>> able to find the binary plugins I had specified in >>>> ALT_BINARY_PLUGINS_PATH. It seems THAT one needs to be a java IO >>>> file path! So now there are THREE different path syntaxes in use in >>>> this script file :) >>>> Anyway, I just wanted to share my experiences building the OpenJDK 7 >>>> on Windows. >>>> Ironically, I'm only doing this to get some practice on the existing >>>> build process. My ultimate goal is to port the OpenJDK 7 to Mac OS >>>> X, as a full native app. I'm doing some preliminary analysis on the >>>> existing code base to determine all calls to native methods, to get >>>> a sense of the scope. For example, there are currently about 421 >>>> native method calls in the jdk/src/share classes. The Windows >>>> implementation classes make 210 native calls, and the Solaris >>>> implementation makes 299. But the first task would be to integrate >>>> Mac OS build targets into the OpenJDK 7 project, so it can be built >>>> on that platform. (Of course, it won't actually run without any >>>> native implementation - that's step #2.) But I'll be making a more >>>> formal presentation/declaration/request for sponsorship/ at a later >>>> time. >>>> Rob Ross >> From ted at tedneward.com Fri May 23 05:21:14 2008 From: ted at tedneward.com (Ted Neward) Date: Thu, 22 May 2008 22:21:14 -0700 Subject: Building OpenJDK 7 on Windows XP In-Reply-To: <40CBB608-257A-4B9C-B903-4CC513B985DB@gmail.com> References: <4831A048.2070201@sun.com> <40CBB608-257A-4B9C-B903-4CC513B985DB@gmail.com> Message-ID: <08b201c8bc94$d411fef0$7c35fcd0$@com> Now.... check out http://blogs.tedneward.com/2007/12/15/Let+The+JDK+Hacking+Begin.aspx (sorry I didn't see your email sooner, but I've been AFK for a while), and tell me if I left anything out of the process. Ted Neward Java, .NET, XML Services Consulting, Teaching, Speaking, Writing http://www.tedneward.com > -----Original Message----- > From: build-dev-bounces at openjdk.java.net [mailto:build-dev- > bounces at openjdk.java.net] On Behalf Of Rob Ross > Sent: Tuesday, May 20, 2008 3:43 AM > To: Kelly O'Hair > Cc: build-dev > Subject: Re: Building OpenJDK 7 on Windows XP > > Well I'm happy to report I finally got the full build to work, > although it took another 15 hours or so. > > The last two big issues I encountered: > > 1. Unfamiliarity with the freetype project, so had to figure out what > needed to be built. This project is rather complicated. It supports > building on at least 11 platforms, and allows for multiple compilers/ > environments on many of these platforms. There are 14 different build > systems supported on Windows alone! > > Also, this project is highly configurable, and you can build it with > support for many optional features. So someone from the OpenJDK > architecture team will have to decide what is officially included in > this library when it is built for the OpenJDK project. And the build > code for it will have to be included in the jdk7 Makefile system. > > I was able to build it by tweaking the VC 8 file included, and > opening in VS .Net 2003. I compiled from within VS, then ran the link > script I found via a link in this list's archive to create the > freetype.dll and freetype.lib. The "aha" moment was when I realized > there were actually TWO .lib files being created, a large static one > aroung 800K, and a smaller one around 40K. I needed to use the > smaller one along with the dll. > > 2. This is most likely a cygwin issue, but I continually experienced > deadlocks/starvation of the spawned gmake processes. cygwin's gmake > seems to ignore the -j option. At any one time I could have a bash > process, a few shell processes, and up to 9 gmake processes running. > I could easily tell when a deadlock occurred - my computer would go > from sounding like a jet engine to being totally quiet. Then I tried > to guess what gmake process was the oldest (not sure if window's task > manager sorts them by process ID or creation time, so this is just a > guess) and killed that one, and then the build would continue, but > obviously with errors as some task was not completed. > > I had to try to rebuild more than 5 times before it finally got > through it all. But in the end it completed with no errors. > > java -version worked! Good start > > java HelloWorld worked! Getting better. > > Going for it, I tried SwingSet2 and Java2D demos from the 1.6 JDK.. > AND THEY WORKED! > > I did get an error in the Java2D demo complaining about missing a > JPEG decoder, but I was too happy the build had worked to really > worry about that right now. > > So add another success story to this list. > > > Rob Ross, Lead Software Engineer > E! Networks > > --------------------------------------------------- > "Beware of he who would deny you access to information, for in his > heart he dreams himself your master." -- Commissioner Pravin Lal > > > > On May 19, 2008, at 8:44 AM, Kelly O'Hair wrote: > > > > > > > Rob Ross wrote: > >> Hi there everyone. > >> This will officially be my first email to the OpenJDK project. > > > > Welcome. I actually appreciate the email, some comments below. > > > >> I got to attend a couple of sessions/BOFs at JavaOne2008 about > >> OpenJDK and my interest was piqued. I've been playing with the > >> build for the last week. (A more accurate description would be, > >> "yanking my hair out and cursing my computer quite often", but I > >> supposed it's part of the learning curve.) > > > > You did pick the most difficult platform you know. ;^) > > > > These are the notes and action items I see from your comments: > > > > 1. assembling the prerequisite software > > - VS .Net 2003 - Will be changing soon to a newer VC compiler, > > and if > > at all possible the free one. > > - Ant is a requirement, I'll fix the Build README, findbugs is > > not strictly > > a requirement, it's under discussion, I had hoped to use it as > > part of the build. > > I may be removing the sanity check on findbugs. > > - Cygwin is a bit of a challenge, it changes/updates rather > > often, I'll > > try and correct the references to the packages you mention, but > > it's like the different Linux packages, sometimes all I can > > give is hints. > > - The Build README should have some references to the older > > cygwin 'make' > > now, but I'll double check. I kind of hoped it would fix itself > > someday. :^( > > - Freetype is new to many of us, I use a freetype that someone > > else built > > so I have never experienced building it myself. > > I will try and look into this and see if I can document it > better. > > > > 2. Mercurial > > - CVS/Subversion users seem to have trouble understanding the > > distributed > > nature of Mercurial. I'd recommend looking at the first few > > chapters > > of the Mercurial book: http://hgbook.red-bean.com/hgbook.html > > > > 3. Setting up the ALT_* environment variables > > - If I didn't document this I should have, my apologies, but I > > encourage > > all ALT_* variables to use the C:/ style of paths, not C:\ and > > definitely > > not the /cygdrive/ style paths. > > The makefiles try and turn the C:\ paths into C:/, but using > > the cygwin > > paths are more difficult to deal with. > > The problem is that some of the exe's we use understand these > > paths and > > some don't, almost everything understands C:/, and avoiding the > > use of > > \ characters in shell scripts and Makefiles is a very sane > > thing to do. > > Making matters worse, the cygwin 'make' that stopped working > > with C: > > paths for a while, hopefully this gets fixed someday. > > Of course cygwin PATH must use ':' characters to separate > > paths, so > > you have to use /cygdrive/ paths in PATH. > > The LIB and INCLUDE env variables belong to the VS2003 compiler > > and > > they use a ';' separator and need the C:/ paths. > > See my blog: > > http://blogs.sun.com/kto/entry/windows_cygwin_mks_java_and > > > > I suspect that your experience with MacOS X will not be the same as > > Windows. > > > > Thanks for taking the time to make the comments. > > > > -kto > > > >> I was finally able to get "make sanity" to pass this evening, and > >> I felt quite pleased with myself. However, I have no expectations > >> that this will actually build now - but I still consider this a > >> milestone victory. > >> Some of the difficulties I encountered were > >> 1. Just assembling the prerequisite software > >> The jdk7/README-builds.html actually does a fairly good job of > >> listing everything needed. But I'm not a Windows developer, so > >> finding a copy of VS .Net 2003 was a little challenging. Luckily > >> that install process was pretty simple. The build generates a > >> warning if Ant and FindBugs aren't locatable; those were easy to > >> install but perhaps you should add these programs to the list of > >> requirements in the README. Cygwin was also > >> pretty easy to install after spending a little time reading up on > >> it. Finding an earlier version of make (gmake) was a little hard, > >> but I see now there are links in the mailing list archive so that > >> would be useful to add a link to the README as well. Some of the > >> Categories/package names you gave for the particular cygwin > >> utilities needed may be out of date. Zip and Unzip are found in > >> the Archive category, not Utils as described in the README. "Free" > >> is listed as being in Utils but it's actually part of the "procps" > >> package, under the System category. And there isn't an "awk" > >> implementation, but there is a gawk. Freetype was the bane of my > >> existence for 3 days. I never could get the "stock" build scripts > >> to work with the version you stated was needed (2.3.0), and what > >> was available to be downloaded (2.3.5). I could not figure out how > >> to build it from source either via DOS/windows or cygwin. So I > >> ended up downloading the binary setup executable, which contained > >> freetype.lib, freetype6.dll, and zlib1.dll, and a freetype.dll.a > >> that was a red herring. I modified the Makefile for the > >> freetypecheck tool to change the name of the expected dll from > >> "freetype.dll" to "freetype6.dll", and added its dependent > >> "zlib1.dll" to the copy command. Not a very portable solution I > >> know, but I just wanted to get this thing to work! How is everyone > >> else getting this to compile? > >> 2. Mercurial - well, it's new, and a little more complicated than > >> CVS/SVN, but I think I'll get the hang of it. I fcloned from the > >> jdk7 master forest, (using the forest extension) yesterday, so I > >> have the latest code (baring any changes in the last day). It will > >> be a while before I even have to worry about wanting to submit > >> anything back upstream, so I should be more comfortable with how > >> it all works by then. > >> 3. Setting up the ALT_* environment variables > >> The hardest part, and mostly trial-and-error, was determining what > >> variables needed to use the cygwin path syntax, and what needed to > >> use the normal Windows path syntax, and what needed to be > >> "shortcutted" by using the cygpath utility. This was mind > >> numbingly frustrating!!!! I found an email from Tim Bell that > >> included his sample script that was quite helpful in getting the > >> right directories from the VS .Net 2003 install into the PATH, > >> LIB, and INCLUDE variables, with the right syntax. As I was > >> writing this email my initial "gmake all" build failed, due to > >> javac not being able to find the binary plugins I had specified in > >> ALT_BINARY_PLUGINS_PATH. It seems THAT one needs to be a java IO > >> file path! So now there are THREE different path syntaxes in use > >> in this script file :) > >> Anyway, I just wanted to share my experiences building the OpenJDK > >> 7 on Windows. > >> Ironically, I'm only doing this to get some practice on the > >> existing build process. My ultimate goal is to port the OpenJDK 7 > >> to Mac OS X, as a full native app. I'm doing some preliminary > >> analysis on the existing code base to determine all calls to > >> native methods, to get a sense of the scope. For example, there > >> are currently about 421 native method calls in the jdk/src/share > >> classes. The Windows implementation classes make 210 native calls, > >> and the Solaris implementation makes 299. But the first task would > >> be to integrate Mac OS build targets into the OpenJDK 7 project, > >> so it can be built on that platform. (Of course, it won't actually > >> run without any native implementation - that's step #2.) But I'll > >> be making a more formal presentation/declaration/request for > >> sponsorship/ at a later time. > >> Rob Ross > > No virus found in this incoming message. > Checked by AVG. > Version: 7.5.524 / Virus Database: 269.23.21/1454 - Release Date: > 5/19/2008 7:44 AM > No virus found in this outgoing message. Checked by AVG. Version: 7.5.524 / Virus Database: 269.24.0/1460 - Release Date: 5/22/2008 7:06 AM From ted at tedneward.com Fri May 23 05:34:50 2008 From: ted at tedneward.com (Ted Neward) Date: Thu, 22 May 2008 22:34:50 -0700 Subject: FW: ATL headers and libraries? In-Reply-To: <064901c8b85a$d6f35da0$84da18e0$@com> References: <049501c8b51e$4ed61b40$ec8251c0$@com> <4829DCAF.3090707@sun.com> <091401c8b6aa$b7cc1540$27643fc0$@com> <482C6FAD.4020100@sun.com> <482C76CD.8080707@sun.com> <064901c8b85a$d6f35da0$84da18e0$@com> Message-ID: <08b301c8bc96$ba019000$2e04b000$@com> Are there any build changes for Hotspot that need to be forwarded into the central Mercurial repos? I tried building with *just* the FrameworkSDK compiler (just to see if I even need the VC Express tool), and I'm erroring out on some 0-length generated .cpp files. I'm guessing the Hotspot team had to hit this problem as well.... For those unfamiliar with the difference, the Platform SDK contains the command-line compiler tools for the Windows platform, as well as all the Windows platform-specific header files (a la windows.h). Theoretically, we *should* be able to build with just the Platform SDK, since it'll be a superset of the headers and libraries included in VC Express (as far as I can tell, anyway). Once this gets done, technically the Challenge would be complete, since nobody was expecting to port away from the Makefiles over to MSBuild (and VC Express doesn't even use MSBuild, it uses its own "VCBuild" tool), and you'd still need the GNU make to execute the builds. Thus, the only advantage of having VC Express would be the IDE (the editor, really), and even then you'd want/need to shell out to run the make scripts anyway. :-) There may be a few changes (I've found one so far, having to add _CRT_SECURE_NO_WARNINGS to the command-line compile to avoid warnings about using the "unsafe" versions of the C string functions, since right now the build says to treat warnings as errors), but so far it's been pretty minimal. Kelly, in the event I have changes to make, can I just detail them to you in an email, or should I do formal diffs and/or set up a Mercurial repo? Ted Neward Java, .NET, XML Services Consulting, Teaching, Speaking, Writing http://www.tedneward.com > -----Original Message----- > From: build-dev-bounces at openjdk.java.net [mailto:build-dev- > bounces at openjdk.java.net] On Behalf Of Ted Neward > Sent: Saturday, May 17, 2008 1:16 PM > To: Phil.Race at Sun.COM; 'Kelly O'Hair' > Cc: build-dev at openjdk.java.net > Subject: RE: FW: ATL headers and libraries? > > AH.... Excellent. :-) > > Ted Neward > Java, .NET, XML Services > Consulting, Teaching, Speaking, Writing > http://www.tedneward.com > > > > -----Original Message----- > > From: Phil.Race at Sun.COM [mailto:Phil.Race at Sun.COM] > > Sent: Thursday, May 15, 2008 10:46 AM > > To: Kelly O'Hair > > Cc: Ted Neward; build-dev at openjdk.java.net > > Subject: Re: FW: ATL headers and libraries? > > > > A member of the hotspot team built hotspot (nothing else) with Visual > > Studio Express 2008 about > > a month ago, so there should be no dependencies on ATL since that > isn't > > in VS Express. > > > > -phil. > > > > Kelly O'Hair wrote: > > > > > > Tim's email: > > > http://mail.openjdk.java.net/pipermail/build-dev/2007- > > December/000654.html > > > > > > > > > Mentions this: > > > hotspot\src\os\windows\vm\jvm_windows.h(33) : fatal error C1083: > > > Cannot open include file: 'windows.h': No such file or directory > > > > > > > > > But windows.h should not be a problem to find, right? Platform SDK > > should > > > have one I assume. > > > > > > I seriously doubt that Hotspot would have any dependence on atlmfc. > > > I searched and found no include's of any obvious atl files. > > > > > > - > > >> > > > > No virus found in this incoming message. > > Checked by AVG. > > Version: 7.5.524 / Virus Database: 269.23.16/1434 - Release Date: > > 5/15/2008 7:24 AM > > > > No virus found in this outgoing message. > Checked by AVG. > Version: 7.5.524 / Virus Database: 269.23.16/1448 - Release Date: > 5/16/2008 > 7:42 PM > > > No virus found in this incoming message. > Checked by AVG. > Version: 7.5.524 / Virus Database: 269.23.16/1448 - Release Date: > 5/16/2008 7:42 PM > No virus found in this outgoing message. Checked by AVG. Version: 7.5.524 / Virus Database: 269.24.0/1460 - Release Date: 5/22/2008 7:06 AM From gnu_andrew at member.fsf.org Fri May 23 07:50:35 2008 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Fri, 23 May 2008 08:50:35 +0100 Subject: Building OpenJDK 7 on Windows XP In-Reply-To: <08b201c8bc94$d411fef0$7c35fcd0$@com> References: <4831A048.2070201@sun.com> <40CBB608-257A-4B9C-B903-4CC513B985DB@gmail.com> <08b201c8bc94$d411fef0$7c35fcd0$@com> Message-ID: <17c6771e0805230050p7fc2fcafk2df7d86455cdd2e7@mail.gmail.com> 2008/5/23 Ted Neward : > Now.... check out > http://blogs.tedneward.com/2007/12/15/Let+The+JDK+Hacking+Begin.aspx (sorry > I didn't see your email sooner, but I've been AFK for a while), and tell me > if I left anything out of the process. > Hmmm... your blog doesn't seem to allow comments, so I'll say what I wanted to say here. First of all, thanks for documenting the Windows build. I've had enough issues building it on a sensible platform. I can't even imagine the horrors of building it on Windows. Secondly, have you looked at OpenJDK6? This is more useful to those who want a stable API to work against. Finally I couldn't understand your comments about building on Ubuntu; support is already much better there, with OpenJDK6 in the latest release and OpenJDK in the last. -- Andrew :-) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From ted at tedneward.com Fri May 23 08:42:03 2008 From: ted at tedneward.com (Ted Neward) Date: Fri, 23 May 2008 01:42:03 -0700 Subject: Building OpenJDK 7 on Windows XP In-Reply-To: <17c6771e0805230050p7fc2fcafk2df7d86455cdd2e7@mail.gmail.com> References: <4831A048.2070201@sun.com> <40CBB608-257A-4B9C-B903-4CC513B985DB@gmail.com> <08b201c8bc94$d411fef0$7c35fcd0$@com> <17c6771e0805230050p7fc2fcafk2df7d86455cdd2e7@mail.gmail.com> Message-ID: <095601c8bcb0$e210d8c0$a6328a40$@com> Did I make a disparaging remark about Ubuntu? Didn't mean to--I agree, building on Ubuntu is far easier than building on Windows. I haven't looked at 6 yet; I'm more interested in following along with latest developments, and possibly contributing back to the upcoming build. If I get time, though, I'll try doing a OpenJDK6 build on Windows and see how it'll work. (It shouldn't be too much different from what's there, though, since the JDK source hadn't really been modified all that much when I posted that.) Ted Neward Java, .NET, XML Services Consulting, Teaching, Speaking, Writing http://www.tedneward.com > -----Original Message----- > From: gnu.andrew.rocks at gmail.com [mailto:gnu.andrew.rocks at gmail.com] On > Behalf Of Andrew John Hughes > Sent: Friday, May 23, 2008 12:51 AM > To: Ted Neward > Cc: Rob Ross; Kelly O'Hair; build-dev > Subject: Re: Building OpenJDK 7 on Windows XP > > 2008/5/23 Ted Neward : > > Now.... check out > > http://blogs.tedneward.com/2007/12/15/Let+The+JDK+Hacking+Begin.aspx > (sorry > > I didn't see your email sooner, but I've been AFK for a while), and > tell me > > if I left anything out of the process. > > > > Hmmm... your blog doesn't seem to allow comments, so I'll say what I > wanted to say here. > > First of all, thanks for documenting the Windows build. I've had > enough issues building it on a sensible platform. I can't even imagine > the horrors of building it on Windows. > Secondly, have you looked at OpenJDK6? This is more useful to those > who want a stable API to work against. Finally I couldn't understand > your comments about building > on Ubuntu; support is already much better there, with OpenJDK6 in the > latest release and OpenJDK in the last. > -- > Andrew :-) > > Support Free Java! > Contribute to GNU Classpath and the OpenJDK > http://www.gnu.org/software/classpath > http://openjdk.java.net > > PGP Key: 94EFD9D8 (http://subkeys.pgp.net) > Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 > > No virus found in this incoming message. > Checked by AVG. > Version: 7.5.524 / Virus Database: 269.24.0/1460 - Release Date: > 5/22/2008 7:06 AM > No virus found in this outgoing message. Checked by AVG. Version: 7.5.524 / Virus Database: 269.24.0/1460 - Release Date: 5/22/2008 7:06 AM From xiomara.jayasena at sun.com Wed May 28 14:28:26 2008 From: xiomara.jayasena at sun.com (xiomara.jayasena at sun.com) Date: Wed, 28 May 2008 14:28:26 +0000 Subject: hg: jdk7/build: Added tag jdk7-b27 for changeset 11b4dc9f2be3 Message-ID: <20080528142827.212DC287BB@hg.openjdk.java.net> Changeset: 56652b46f328 Author: xdono Date: 2008-05-22 09:37 -0700 URL: http://hg.openjdk.java.net/jdk7/build/rev/56652b46f328 Added tag jdk7-b27 for changeset 11b4dc9f2be3 ! .hgtags From xiomara.jayasena at sun.com Wed May 28 14:29:17 2008 From: xiomara.jayasena at sun.com (xiomara.jayasena at sun.com) Date: Wed, 28 May 2008 14:29:17 +0000 Subject: hg: jdk7/build/corba: Added tag jdk7-b27 for changeset e84e9018bebb Message-ID: <20080528142918.BB998287C0@hg.openjdk.java.net> Changeset: 27509b7d21ed Author: xdono Date: 2008-05-22 09:37 -0700 URL: http://hg.openjdk.java.net/jdk7/build/corba/rev/27509b7d21ed Added tag jdk7-b27 for changeset e84e9018bebb ! .hgtags From xiomara.jayasena at sun.com Wed May 28 14:31:15 2008 From: xiomara.jayasena at sun.com (xiomara.jayasena at sun.com) Date: Wed, 28 May 2008 14:31:15 +0000 Subject: hg: jdk7/build/hotspot: 62 new changesets Message-ID: <20080528143314.30154287C5@hg.openjdk.java.net> Changeset: b97de546208e Author: xlu Date: 2008-04-03 12:21 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/b97de546208e 6671882: memory access after free in solaris/vm/os_solaris.cpp Summary: Corrected the wrong memory access problem and made some minor clean ups Reviewed-by: dholmes, jcoomes ! src/os/solaris/vm/os_solaris.cpp Changeset: cf4e16e9ca60 Author: kamg Date: 2008-04-04 10:48 -0400 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/cf4e16e9ca60 Merge Changeset: a294fd0c4b38 Author: kamg Date: 2008-04-09 14:22 -0400 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/a294fd0c4b38 6583644: Move all managed/SCCS files out of 'build' into 'make' directory Summary: Moved makefiles out of build and build/closed into make/ Reviewed-by: kvn, ohair ! .hgignore - build/hotspot_distro - build/linux/Makefile - build/linux/Queens.class - build/linux/README - build/linux/adlc_updater - build/linux/build.sh - build/linux/makefiles/adjust-mflags.sh - build/linux/makefiles/adlc.make - build/linux/makefiles/amd64.make - build/linux/makefiles/buildtree.make - build/linux/makefiles/compiler1.make - build/linux/makefiles/compiler2.make - build/linux/makefiles/core.make - build/linux/makefiles/cscope.make - build/linux/makefiles/debug.make - build/linux/makefiles/defs.make - build/linux/makefiles/dtrace.make - build/linux/makefiles/fastdebug.make - build/linux/makefiles/gcc.make - build/linux/makefiles/hp.make - build/linux/makefiles/hp1.make - build/linux/makefiles/i486.make - build/linux/makefiles/jsig.make - build/linux/makefiles/jvmg.make - build/linux/makefiles/jvmti.make - build/linux/makefiles/launcher.make - build/linux/makefiles/makedeps.make - build/linux/makefiles/mapfile-vers-debug - build/linux/makefiles/mapfile-vers-jsig - build/linux/makefiles/mapfile-vers-product - build/linux/makefiles/optimized.make - build/linux/makefiles/product.make - build/linux/makefiles/profiled.make - build/linux/makefiles/rules.make - build/linux/makefiles/sa.make - build/linux/makefiles/saproc.make - build/linux/makefiles/sparcWorks.make - build/linux/makefiles/tiered.make - build/linux/makefiles/top.make - build/linux/makefiles/vm.make - build/linux/platform_amd64 - build/linux/platform_amd64.suncc - build/linux/platform_i486 - build/linux/platform_i486.suncc - build/linux/platform_sparc - build/sa.files - build/solaris/Makefile - build/solaris/Queens.class - build/solaris/adlc_updater - build/solaris/build.sh - build/solaris/makefiles/adjust-mflags.sh - build/solaris/makefiles/adlc.make - build/solaris/makefiles/amd64.make - build/solaris/makefiles/buildtree.make - build/solaris/makefiles/compiler1.make - build/solaris/makefiles/compiler2.make - build/solaris/makefiles/core.make - build/solaris/makefiles/cscope.make - build/solaris/makefiles/debug.make - build/solaris/makefiles/defs.make - build/solaris/makefiles/dtrace.make - build/solaris/makefiles/fastdebug.make - build/solaris/makefiles/gcc.make - build/solaris/makefiles/hp.make - build/solaris/makefiles/hp1.make - build/solaris/makefiles/i486.make - build/solaris/makefiles/jsig.make - build/solaris/makefiles/jvmg.make - build/solaris/makefiles/jvmti.make - build/solaris/makefiles/kernel.make - build/solaris/makefiles/launcher.make - build/solaris/makefiles/makedeps.make - build/solaris/makefiles/mapfile-vers - build/solaris/makefiles/mapfile-vers-COMPILER1 - build/solaris/makefiles/mapfile-vers-COMPILER2 - build/solaris/makefiles/mapfile-vers-CORE - build/solaris/makefiles/mapfile-vers-TIERED - build/solaris/makefiles/mapfile-vers-debug - build/solaris/makefiles/mapfile-vers-jsig - build/solaris/makefiles/mapfile-vers-jvm_db - build/solaris/makefiles/mapfile-vers-jvm_dtrace - build/solaris/makefiles/mapfile-vers-nonproduct - build/solaris/makefiles/optimized.make - build/solaris/makefiles/product.make - build/solaris/makefiles/profiled.make - build/solaris/makefiles/reorder_COMPILER1_i486 - build/solaris/makefiles/reorder_COMPILER1_sparc - build/solaris/makefiles/reorder_COMPILER1_sparcv9 - build/solaris/makefiles/reorder_COMPILER2_amd64 - build/solaris/makefiles/reorder_COMPILER2_i486 - build/solaris/makefiles/reorder_COMPILER2_sparc - build/solaris/makefiles/reorder_COMPILER2_sparcv9 - build/solaris/makefiles/reorder_CORE_amd64 - build/solaris/makefiles/reorder_CORE_i486 - build/solaris/makefiles/reorder_CORE_sparc - build/solaris/makefiles/reorder_CORE_sparcv9 - build/solaris/makefiles/reorder_TIERED_amd64 - build/solaris/makefiles/reorder_TIERED_i486 - build/solaris/makefiles/reorder_TIERED_sparc - build/solaris/makefiles/rules.make - build/solaris/makefiles/sa.make - build/solaris/makefiles/saproc.make - build/solaris/makefiles/sparc.make - build/solaris/makefiles/sparcWorks.make - build/solaris/makefiles/sparcv9.make - build/solaris/makefiles/tiered.make - build/solaris/makefiles/top.make - build/solaris/makefiles/vm.make - build/solaris/platform_amd64 - build/solaris/platform_amd64.gcc - build/solaris/platform_i486 - build/solaris/platform_i486.gcc - build/solaris/platform_sparc - build/solaris/platform_sparc.gcc - build/solaris/platform_sparcv9 - build/solaris/platform_sparcv9.gcc - build/solaris/reorder.sh - build/test/Queens.java - build/windows/README - build/windows/build.bat - build/windows/build.make - build/windows/build_vm_def.sh - build/windows/create.bat - build/windows/cross_build.bat - build/windows/get_msc_ver.sh - build/windows/jvmexp.lcf - build/windows/jvmexp_g.lcf - build/windows/makefiles/adlc.make - build/windows/makefiles/compile.make - build/windows/makefiles/debug.make - build/windows/makefiles/defs.make - build/windows/makefiles/fastdebug.make - build/windows/makefiles/generated.make - build/windows/makefiles/jvmti.make - build/windows/makefiles/makedeps.make - build/windows/makefiles/product.make - build/windows/makefiles/rules.make - build/windows/makefiles/sa.make - build/windows/makefiles/sanity.make - build/windows/makefiles/shared.make - build/windows/makefiles/top.make - build/windows/makefiles/vm.make - build/windows/platform_amd64 - build/windows/platform_i486 - build/windows/projectfiles/common/Makefile - build/windows/projectfiles/compiler1/Makefile - build/windows/projectfiles/compiler1/vm.def - build/windows/projectfiles/compiler1/vm.dsw - build/windows/projectfiles/compiler2/ADLCompiler.dsp - build/windows/projectfiles/compiler2/ADLCompiler.dsw - build/windows/projectfiles/compiler2/Makefile - build/windows/projectfiles/compiler2/vm.def - build/windows/projectfiles/compiler2/vm.dsw - build/windows/projectfiles/core/Makefile - build/windows/projectfiles/core/vm.def - build/windows/projectfiles/core/vm.dsw - build/windows/projectfiles/kernel/Makefile - build/windows/projectfiles/kernel/vm.def - build/windows/projectfiles/kernel/vm.dsw - build/windows/projectfiles/tiered/ADLCompiler.dsp - build/windows/projectfiles/tiered/ADLCompiler.dsw - build/windows/projectfiles/tiered/Makefile - build/windows/projectfiles/tiered/vm.def - build/windows/projectfiles/tiered/vm.dsw ! make/defs.make + make/hotspot_distro ! make/jprt.properties + make/linux/Makefile + make/linux/Queens.class + make/linux/README + make/linux/adlc_updater + make/linux/build.sh + make/linux/makefiles/adjust-mflags.sh + make/linux/makefiles/adlc.make + make/linux/makefiles/amd64.make + make/linux/makefiles/buildtree.make + make/linux/makefiles/compiler1.make + make/linux/makefiles/compiler2.make + make/linux/makefiles/core.make + make/linux/makefiles/cscope.make + make/linux/makefiles/debug.make + make/linux/makefiles/defs.make + make/linux/makefiles/dtrace.make + make/linux/makefiles/fastdebug.make + make/linux/makefiles/gcc.make + make/linux/makefiles/hp.make + make/linux/makefiles/hp1.make + make/linux/makefiles/i486.make + make/linux/makefiles/ia64.make + make/linux/makefiles/jsig.make + make/linux/makefiles/jvmg.make + make/linux/makefiles/jvmti.make + make/linux/makefiles/launcher.make + make/linux/makefiles/makedeps.make + make/linux/makefiles/mapfile-vers-debug + make/linux/makefiles/mapfile-vers-jsig + make/linux/makefiles/mapfile-vers-product + make/linux/makefiles/optimized.make + make/linux/makefiles/product.make + make/linux/makefiles/profiled.make + make/linux/makefiles/rules.make + make/linux/makefiles/sa.make + make/linux/makefiles/saproc.make + make/linux/makefiles/sparc.make + make/linux/makefiles/sparcWorks.make + make/linux/makefiles/sparcv9.make + make/linux/makefiles/tiered.make + make/linux/makefiles/top.make + make/linux/makefiles/vm.make + make/linux/platform_amd64 + make/linux/platform_amd64.suncc + make/linux/platform_i486 + make/linux/platform_i486.suncc + make/linux/platform_ia64 + make/linux/platform_sparc + make/openjdk_distro + make/sa.files + make/solaris/Makefile + make/solaris/Queens.class + make/solaris/adlc_updater + make/solaris/build.sh + make/solaris/makefiles/adjust-mflags.sh + make/solaris/makefiles/adlc.make + make/solaris/makefiles/amd64.make + make/solaris/makefiles/buildtree.make + make/solaris/makefiles/compiler1.make + make/solaris/makefiles/compiler2.make + make/solaris/makefiles/core.make + make/solaris/makefiles/cscope.make + make/solaris/makefiles/debug.make + make/solaris/makefiles/defs.make + make/solaris/makefiles/dtrace.make + make/solaris/makefiles/fastdebug.make + make/solaris/makefiles/gcc.make + make/solaris/makefiles/hp.make + make/solaris/makefiles/hp1.make + make/solaris/makefiles/i486.make + make/solaris/makefiles/jsig.make + make/solaris/makefiles/jvmg.make + make/solaris/makefiles/jvmti.make + make/solaris/makefiles/kernel.make + make/solaris/makefiles/launcher.make + make/solaris/makefiles/makedeps.make + make/solaris/makefiles/mapfile-vers + make/solaris/makefiles/mapfile-vers-COMPILER1 + make/solaris/makefiles/mapfile-vers-COMPILER2 + make/solaris/makefiles/mapfile-vers-CORE + make/solaris/makefiles/mapfile-vers-TIERED + make/solaris/makefiles/mapfile-vers-debug + make/solaris/makefiles/mapfile-vers-jsig + make/solaris/makefiles/mapfile-vers-jvm_db + make/solaris/makefiles/mapfile-vers-jvm_dtrace + make/solaris/makefiles/mapfile-vers-nonproduct + make/solaris/makefiles/optimized.make + make/solaris/makefiles/product.make + make/solaris/makefiles/profiled.make + make/solaris/makefiles/reorder_COMPILER1_i486 + make/solaris/makefiles/reorder_COMPILER1_sparc + make/solaris/makefiles/reorder_COMPILER1_sparcv9 + make/solaris/makefiles/reorder_COMPILER2_amd64 + make/solaris/makefiles/reorder_COMPILER2_i486 + make/solaris/makefiles/reorder_COMPILER2_sparc + make/solaris/makefiles/reorder_COMPILER2_sparcv9 + make/solaris/makefiles/reorder_CORE_amd64 + make/solaris/makefiles/reorder_CORE_i486 + make/solaris/makefiles/reorder_CORE_sparc + make/solaris/makefiles/reorder_CORE_sparcv9 + make/solaris/makefiles/reorder_TIERED_amd64 + make/solaris/makefiles/reorder_TIERED_i486 + make/solaris/makefiles/reorder_TIERED_sparc + make/solaris/makefiles/rules.make + make/solaris/makefiles/sa.make + make/solaris/makefiles/saproc.make + make/solaris/makefiles/sparc.make + make/solaris/makefiles/sparcWorks.make + make/solaris/makefiles/sparcv9.make + make/solaris/makefiles/tiered.make + make/solaris/makefiles/top.make + make/solaris/makefiles/vm.make + make/solaris/platform_amd64 + make/solaris/platform_amd64.gcc + make/solaris/platform_i486 + make/solaris/platform_i486.gcc + make/solaris/platform_sparc + make/solaris/platform_sparc.gcc + make/solaris/platform_sparcv9 + make/solaris/platform_sparcv9.gcc + make/solaris/reorder.sh + make/test/Queens.java + make/windows/README + make/windows/build.bat + make/windows/build.make + make/windows/build_vm_def.sh + make/windows/create.bat + make/windows/cross_build.bat + make/windows/get_msc_ver.sh + make/windows/jvmexp.lcf + make/windows/jvmexp_g.lcf + make/windows/makefiles/adlc.make + make/windows/makefiles/compile.make + make/windows/makefiles/debug.make + make/windows/makefiles/defs.make + make/windows/makefiles/fastdebug.make + make/windows/makefiles/generated.make + make/windows/makefiles/jvmti.make + make/windows/makefiles/makedeps.make + make/windows/makefiles/product.make + make/windows/makefiles/rules.make + make/windows/makefiles/sa.make + make/windows/makefiles/sanity.make + make/windows/makefiles/shared.make + make/windows/makefiles/top.make + make/windows/makefiles/vm.make + make/windows/platform_amd64 + make/windows/platform_i486 + make/windows/platform_ia64 + make/windows/projectfiles/common/Makefile + make/windows/projectfiles/compiler1/Makefile + make/windows/projectfiles/compiler1/vm.def + make/windows/projectfiles/compiler1/vm.dsw + make/windows/projectfiles/compiler2/ADLCompiler.dsp + make/windows/projectfiles/compiler2/ADLCompiler.dsw + make/windows/projectfiles/compiler2/Makefile + make/windows/projectfiles/compiler2/vm.def + make/windows/projectfiles/compiler2/vm.dsw + make/windows/projectfiles/core/Makefile + make/windows/projectfiles/core/vm.def + make/windows/projectfiles/core/vm.dsw + make/windows/projectfiles/kernel/Makefile + make/windows/projectfiles/kernel/vm.def + make/windows/projectfiles/kernel/vm.dsw + make/windows/projectfiles/tiered/ADLCompiler.dsp + make/windows/projectfiles/tiered/ADLCompiler.dsw + make/windows/projectfiles/tiered/Makefile + make/windows/projectfiles/tiered/vm.def + make/windows/projectfiles/tiered/vm.dsw Changeset: ebec5b9731e2 Author: kamg Date: 2008-04-10 12:21 -0400 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/ebec5b9731e2 6615981: JVM class file parser incorrectly rejects class files with version < 45.2 Summary: A check on Code length did not take into account the old sizes of the max_stack, max_locals, and code_length. Reviewed-by: phh, sbohne ! src/share/vm/classfile/classFileParser.cpp Changeset: c6ff24ceec1c Author: sbohne Date: 2008-04-10 15:49 -0400 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/c6ff24ceec1c 6686407: Fix for 6666698 broke -XX:BiasedLockingStartupDelay=0 Summary: Stack allocated VM_EnableBiasedLocking op must be marked as such Reviewed-by: xlu, acorn, never, dholmes ! src/share/vm/runtime/biasedLocking.cpp Changeset: 0834225a7916 Author: ysr Date: 2008-03-16 21:57 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/0834225a7916 6634032: CMS: Need CMSInitiatingPermOccupancyFraction for perm, divorcing from CMSInitiatingOccupancyFraction Summary: The option CMSInitiatingPermOccupancyFraction now controls perm triggering threshold. Even though the actual value of the threshold has not yet been changed, so there is no change in policy, we now have the infrastructure in place for dynamically deciding when to collect the perm gen, an issue that will be addressed in the near future. Reviewed-by: jmasa ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.inline.hpp ! src/share/vm/runtime/globals.hpp Changeset: d05ebaf00ed0 Author: tonyp Date: 2008-03-27 17:22 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/d05ebaf00ed0 Merge ! src/share/vm/runtime/globals.hpp Changeset: 2acabb781f53 Author: apetrusenko Date: 2008-04-07 09:32 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/2acabb781f53 Merge Changeset: f38a25e2458a Author: kamg Date: 2008-04-09 10:38 -0400 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/f38a25e2458a Merge Changeset: deb97b8ef02b Author: never Date: 2008-03-26 12:25 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/deb97b8ef02b 6679708: No_Safepoint_Verifier and BacktraceBuilder have uninitialized fields Summary: fix or remove uninitialized fields Reviewed-by: kvn, rasbold ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/memory/gcLocker.hpp Changeset: 8a4ef4e001d3 Author: never Date: 2008-03-28 09:00 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/8a4ef4e001d3 6680594: Load + Load isn't canonicalized leading to missed GVN opportunities Reviewed-by: kvn, jrose ! src/share/vm/opto/addnode.cpp Changeset: c7c777385a15 Author: jrose Date: 2008-04-02 12:09 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/c7c777385a15 6667042: PrintAssembly option does not work without special plugin Summary: remove old private plugin interface, simplify, rework old plugin to use unchanged Gnu sources Reviewed-by: kvn, rasbold ! .hgignore ! build/linux/makefiles/vm.make ! build/linux/platform_amd64 ! build/linux/platform_i486 ! build/linux/platform_sparc ! build/solaris/makefiles/vm.make ! build/solaris/platform_amd64 ! build/solaris/platform_amd64.gcc ! build/solaris/platform_i486 ! build/solaris/platform_i486.gcc ! build/solaris/platform_sparc ! build/solaris/platform_sparc.gcc ! build/solaris/platform_sparcv9 ! build/solaris/platform_sparcv9.gcc ! build/windows/makefiles/vm.make ! build/windows/platform_amd64 ! build/windows/platform_i486 - src/cpu/sparc/vm/disassembler_sparc.cpp ! src/cpu/sparc/vm/disassembler_sparc.hpp - src/cpu/x86/vm/disassembler_x86.cpp ! src/cpu/x86/vm/disassembler_x86.hpp + src/share/tools/hsdis/Makefile + src/share/tools/hsdis/README + src/share/tools/hsdis/hsdis-demo.c + src/share/tools/hsdis/hsdis.c + src/share/tools/hsdis/hsdis.h ! src/share/vm/asm/codeBuffer.cpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/nmethod.hpp ! src/share/vm/code/vmreg.cpp ! src/share/vm/code/vmreg.hpp + src/share/vm/compiler/disassembler.cpp + src/share/vm/compiler/disassembler.hpp - src/share/vm/compiler/disassemblerEnv.hpp ! src/share/vm/compiler/oopMap.cpp ! src/share/vm/compiler/oopMap.hpp ! src/share/vm/includeDB_compiler1 ! src/share/vm/includeDB_core ! src/share/vm/opto/compile.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/stubCodeGenerator.cpp ! src/share/vm/utilities/ostream.cpp ! src/share/vm/utilities/ostream.hpp Changeset: a6cb86dd209b Author: kvn Date: 2008-04-02 16:59 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/a6cb86dd209b 6681577: PIT: some VM tests fails with -XX:+AggressiveOpts in 6u5p b01 Summary: C2 spends > 60% in escape analysis code during test nsk/regression/b4675027. Reviewed-by: never ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/escape.hpp Changeset: f96100ac3d12 Author: rasbold Date: 2008-04-03 06:41 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/f96100ac3d12 Merge - src/cpu/sparc/vm/disassembler_sparc.cpp - src/cpu/x86/vm/disassembler_x86.cpp - src/share/vm/compiler/disassemblerEnv.hpp ! src/share/vm/opto/escape.cpp ! src/share/vm/utilities/ostream.cpp Changeset: 38a50dd839cf Author: never Date: 2008-04-03 10:20 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/38a50dd839cf 6619271: The -Xprintflags causes the VM to segv Summary: add null checks Reviewed-by: jrose, kvn ! src/share/vm/runtime/globals.cpp Changeset: 541929da62d2 Author: rasbold Date: 2008-04-03 13:33 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/541929da62d2 6624474: Server compiler generates unexpected LinkageError Summary: Fix load_signature_classes to tolerate LinkageErrors Reviewed-by: kvn, never ! src/share/vm/oops/methodOop.cpp Changeset: a7d0f95410bd Author: never Date: 2008-04-03 21:26 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/a7d0f95410bd 6646020: assert(in_bb(n),"must be in block") in -Xcomp mode Reviewed-by: kvn, rasbold ! src/share/vm/opto/superword.cpp + test/compiler/6646020/Tester.java Changeset: c9314fa4f757 Author: rasbold Date: 2008-04-07 15:15 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/c9314fa4f757 6663908: NegativeArraySizeException is not thrown Summary: Don't optimize zero length array allocations at compile time. Reviewed-by: kvn, never ! src/share/vm/opto/parse3.cpp Changeset: 93b6525e3b82 Author: sgoldman Date: 2008-04-08 12:23 -0400 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/93b6525e3b82 6603919: Stackwalking crash on x86 -server with Sun Studio's collect -j on Summary: Rewrite frame::safe_for_sender and friends to be safe for collector/analyzer Reviewed-by: dcubed, kvn ! src/cpu/sparc/vm/frame_sparc.cpp ! src/cpu/x86/vm/frame_x86.cpp ! src/cpu/x86/vm/frame_x86.inline.hpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/os_cpu/solaris_sparc/vm/thread_solaris_sparc.cpp ! src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp ! src/os_cpu/solaris_x86/vm/thread_solaris_x86.cpp ! src/share/vm/code/codeCache.hpp ! src/share/vm/prims/forte.cpp ! src/share/vm/runtime/fprofiler.cpp ! src/share/vm/runtime/fprofiler.hpp ! src/share/vm/runtime/frame.hpp ! src/share/vm/runtime/vframe.hpp Changeset: a761c2d3b76a Author: rasbold Date: 2008-04-09 09:25 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/a761c2d3b76a 6684385: Loop unswitching crashes without LoopNode Summary: Without LoopNode, exit early from loop unswitching and partial peeling Reviewed-by: kvn, never, sgoldman ! src/share/vm/opto/loopUnswitch.cpp ! src/share/vm/opto/loopopts.cpp Changeset: 9f4457a14b58 Author: rasbold Date: 2008-04-09 15:10 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/9f4457a14b58 Merge - src/cpu/sparc/vm/disassembler_sparc.cpp - src/cpu/x86/vm/disassembler_x86.cpp - src/share/vm/compiler/disassemblerEnv.hpp ! src/share/vm/runtime/globals.hpp Changeset: a49a647afe9a Author: kamg Date: 2008-04-11 09:56 -0400 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/a49a647afe9a Merge ! .hgignore ! make/linux/makefiles/vm.make ! make/linux/platform_amd64 ! make/linux/platform_i486 ! make/linux/platform_sparc ! make/solaris/makefiles/vm.make ! make/solaris/platform_amd64 ! make/solaris/platform_amd64.gcc ! make/solaris/platform_i486 ! make/solaris/platform_i486.gcc ! make/solaris/platform_sparc ! make/solaris/platform_sparc.gcc ! make/solaris/platform_sparcv9 ! make/solaris/platform_sparcv9.gcc ! make/windows/makefiles/vm.make ! make/windows/platform_amd64 ! make/windows/platform_i486 - src/cpu/sparc/vm/disassembler_sparc.cpp - src/cpu/x86/vm/disassembler_x86.cpp - src/share/vm/compiler/disassemblerEnv.hpp Changeset: 7747916a0945 Author: ysr Date: 2008-04-08 12:10 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/7747916a0945 6685160: fix cscope build with hg Summary: Use hg's fstatus instead of teamware's nametable to trigger cscope database rebuild Reviewed-by: jcoomes, kamg ! build/linux/makefiles/cscope.make ! build/solaris/makefiles/cscope.make Changeset: 7c5dac90daef Author: apetrusenko Date: 2008-04-14 08:29 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/7c5dac90daef Merge Changeset: ba764ed4b6f2 Author: coleenp Date: 2008-04-13 17:43 -0400 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/ba764ed4b6f2 6420645: Create a vm that uses compressed oops for up to 32gb heapsizes Summary: Compressed oops in instances, arrays, and headers. Code contributors are coleenp, phh, never, swamyv Reviewed-by: jmasa, kamg, acorn, tbell, kvn, rasbold ! agent/src/share/classes/sun/jvm/hotspot/CommandProcessor.java ! agent/src/share/classes/sun/jvm/hotspot/HSDB.java ! agent/src/share/classes/sun/jvm/hotspot/HotSpotTypeDataBase.java ! agent/src/share/classes/sun/jvm/hotspot/compiler/OopMapSet.java ! agent/src/share/classes/sun/jvm/hotspot/compiler/OopMapValue.java ! agent/src/share/classes/sun/jvm/hotspot/compiler/OopMapVisitor.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/Address.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/Debugger.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/DebuggerBase.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/JVMDebugger.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/MachineDescription.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/MachineDescriptionAMD64.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/MachineDescriptionIA64.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/MachineDescriptionIntelX86.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/MachineDescriptionSPARC32Bit.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/MachineDescriptionSPARC64Bit.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/DbxAddress.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/DbxDebugger.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/dbx/DbxDebuggerLocal.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/dummy/DummyAddress.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/linux/LinuxAddress.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/linux/LinuxDebugger.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/linux/LinuxDebuggerLocal.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/proc/ProcAddress.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/proc/ProcDebugger.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/proc/ProcDebuggerLocal.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/remote/RemoteAddress.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/remote/RemoteDebugger.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/remote/RemoteDebuggerClient.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/remote/RemoteDebuggerServer.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32Address.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32Debugger.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/win32/Win32DebuggerLocal.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/windbg/WindbgAddress.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/windbg/WindbgDebugger.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/windbg/WindbgDebuggerLocal.java ! agent/src/share/classes/sun/jvm/hotspot/memory/Universe.java ! agent/src/share/classes/sun/jvm/hotspot/oops/Array.java ! agent/src/share/classes/sun/jvm/hotspot/oops/ConstantPool.java ! agent/src/share/classes/sun/jvm/hotspot/oops/ConstantPoolCache.java ! agent/src/share/classes/sun/jvm/hotspot/oops/ConstantPoolCacheKlass.java ! agent/src/share/classes/sun/jvm/hotspot/oops/ConstantPoolKlass.java ! agent/src/share/classes/sun/jvm/hotspot/oops/DefaultOopVisitor.java ! agent/src/share/classes/sun/jvm/hotspot/oops/Instance.java ! agent/src/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java ! agent/src/share/classes/sun/jvm/hotspot/oops/Klass.java + agent/src/share/classes/sun/jvm/hotspot/oops/NarrowOopField.java ! agent/src/share/classes/sun/jvm/hotspot/oops/ObjArray.java ! agent/src/share/classes/sun/jvm/hotspot/oops/ObjectHeap.java ! agent/src/share/classes/sun/jvm/hotspot/oops/ObjectHistogram.java ! agent/src/share/classes/sun/jvm/hotspot/oops/ObjectHistogramElement.java ! agent/src/share/classes/sun/jvm/hotspot/oops/Oop.java ! agent/src/share/classes/sun/jvm/hotspot/oops/OopPrinter.java ! agent/src/share/classes/sun/jvm/hotspot/oops/OopUtilities.java ! agent/src/share/classes/sun/jvm/hotspot/oops/OopVisitor.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/AddressVisitor.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/Frame.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java ! agent/src/share/classes/sun/jvm/hotspot/types/Field.java + agent/src/share/classes/sun/jvm/hotspot/types/NarrowOopField.java ! agent/src/share/classes/sun/jvm/hotspot/types/Type.java ! agent/src/share/classes/sun/jvm/hotspot/types/basic/BasicField.java ! agent/src/share/classes/sun/jvm/hotspot/types/basic/BasicFieldWrapper.java + agent/src/share/classes/sun/jvm/hotspot/types/basic/BasicNarrowOopField.java ! agent/src/share/classes/sun/jvm/hotspot/types/basic/BasicOopField.java ! agent/src/share/classes/sun/jvm/hotspot/types/basic/BasicType.java ! agent/src/share/classes/sun/jvm/hotspot/types/basic/BasicTypeDataBase.java ! agent/src/share/classes/sun/jvm/hotspot/ui/FindInHeapPanel.java ! agent/src/share/classes/sun/jvm/hotspot/ui/classbrowser/HTMLGenerator.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/AbstractHeapGraphWriter.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/HeapHprofBinWriter.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/ReversePtrsAnalysis.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/RobustOopDeterminator.java ! make/Makefile ! make/solaris/makefiles/sparcWorks.make ! src/cpu/sparc/vm/assembler_sparc.cpp ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/c1_MacroAssembler_sparc.cpp ! src/cpu/sparc/vm/copy_sparc.hpp ! src/cpu/sparc/vm/interp_masm_sparc.cpp ! src/cpu/sparc/vm/register_definitions_sparc.cpp ! src/cpu/sparc/vm/sharedRuntime_sparc.cpp ! src/cpu/sparc/vm/sparc.ad ! src/cpu/sparc/vm/stubGenerator_sparc.cpp ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/sparc/vm/vm_version_sparc.cpp ! src/cpu/sparc/vm/vtableStubs_sparc.cpp ! src/cpu/x86/vm/assembler_x86_64.cpp ! src/cpu/x86/vm/assembler_x86_64.hpp ! src/cpu/x86/vm/c1_MacroAssembler_x86.cpp ! src/cpu/x86/vm/interp_masm_x86_64.cpp ! src/cpu/x86/vm/interpreter_x86_64.cpp ! src/cpu/x86/vm/register_definitions_x86.cpp ! src/cpu/x86/vm/sharedRuntime_x86_64.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/cpu/x86/vm/vtableStubs_x86_64.cpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/os/solaris/dtrace/generateJvmOffsets.cpp ! src/os/solaris/dtrace/jhelper.d ! src/os/solaris/dtrace/libjvm_db.c ! src/os/windows/vm/os_windows.cpp ! src/os_cpu/solaris_sparc/vm/solaris_sparc.s ! src/share/vm/adlc/archDesc.cpp ! src/share/vm/adlc/forms.cpp ! src/share/vm/adlc/forms.hpp ! src/share/vm/adlc/formssel.cpp ! src/share/vm/adlc/output_c.cpp ! src/share/vm/adlc/output_h.cpp ! src/share/vm/asm/codeBuffer.cpp ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/ci/ciInstanceKlass.cpp ! src/share/vm/ci/ciInstanceKlass.hpp ! src/share/vm/ci/ciObjectFactory.cpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/compiler/oopMap.cpp ! src/share/vm/compiler/oopMap.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsOopClosures.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp ! src/share/vm/gc_implementation/includeDB_gc_parNew ! src/share/vm/gc_implementation/includeDB_gc_parallelScavenge ! src/share/vm/gc_implementation/parNew/parGCAllocBuffer.cpp ! src/share/vm/gc_implementation/parNew/parGCAllocBuffer.hpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.hpp ! src/share/vm/gc_implementation/parNew/parOopClosures.hpp ! src/share/vm/gc_implementation/parNew/parOopClosures.inline.hpp ! src/share/vm/gc_implementation/parallelScavenge/cardTableExtension.cpp ! src/share/vm/gc_implementation/parallelScavenge/cardTableExtension.hpp ! src/share/vm/gc_implementation/parallelScavenge/pcTasks.cpp ! src/share/vm/gc_implementation/parallelScavenge/prefetchQueue.hpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweepDecorator.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.hpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionLAB.cpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionLAB.hpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.cpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.hpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.inline.hpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.hpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.inline.hpp ! src/share/vm/gc_implementation/parallelScavenge/psTasks.cpp ! src/share/vm/gc_implementation/shared/markSweep.cpp ! src/share/vm/gc_implementation/shared/markSweep.hpp ! src/share/vm/gc_implementation/shared/markSweep.inline.hpp ! src/share/vm/gc_interface/collectedHeap.cpp ! src/share/vm/gc_interface/collectedHeap.hpp ! src/share/vm/gc_interface/collectedHeap.inline.hpp ! src/share/vm/includeDB_core ! src/share/vm/interpreter/interpreterRuntime.hpp ! src/share/vm/memory/barrierSet.hpp ! src/share/vm/memory/barrierSet.inline.hpp ! src/share/vm/memory/cardTableModRefBS.cpp ! src/share/vm/memory/cardTableModRefBS.hpp ! src/share/vm/memory/cardTableRS.cpp ! src/share/vm/memory/cardTableRS.hpp ! src/share/vm/memory/compactingPermGenGen.cpp ! src/share/vm/memory/defNewGeneration.cpp ! src/share/vm/memory/defNewGeneration.hpp ! src/share/vm/memory/defNewGeneration.inline.hpp ! src/share/vm/memory/dump.cpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/genCollectedHeap.hpp ! src/share/vm/memory/genMarkSweep.cpp ! src/share/vm/memory/genOopClosures.hpp ! src/share/vm/memory/genOopClosures.inline.hpp ! src/share/vm/memory/genRemSet.hpp ! src/share/vm/memory/genRemSet.inline.hpp ! src/share/vm/memory/generation.cpp ! src/share/vm/memory/generation.hpp ! src/share/vm/memory/iterator.hpp ! src/share/vm/memory/modRefBarrierSet.hpp ! src/share/vm/memory/referenceProcessor.cpp ! src/share/vm/memory/referenceProcessor.hpp ! src/share/vm/memory/restore.cpp ! src/share/vm/memory/serialize.cpp ! src/share/vm/memory/sharedHeap.cpp ! src/share/vm/memory/space.cpp ! src/share/vm/memory/space.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/memory/universe.hpp ! src/share/vm/oops/arrayOop.hpp ! src/share/vm/oops/constantPoolKlass.cpp ! src/share/vm/oops/constantPoolKlass.hpp ! src/share/vm/oops/constantPoolOop.hpp ! src/share/vm/oops/cpCacheKlass.cpp ! src/share/vm/oops/cpCacheKlass.hpp ! src/share/vm/oops/cpCacheOop.cpp ! src/share/vm/oops/cpCacheOop.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/instanceKlassKlass.cpp ! src/share/vm/oops/instanceOop.hpp ! src/share/vm/oops/instanceRefKlass.cpp ! src/share/vm/oops/klass.cpp ! src/share/vm/oops/klass.hpp ! src/share/vm/oops/klassVtable.cpp ! src/share/vm/oops/markOop.hpp ! src/share/vm/oops/methodDataKlass.cpp ! src/share/vm/oops/methodOop.cpp ! src/share/vm/oops/objArrayKlass.cpp ! src/share/vm/oops/objArrayKlass.hpp ! src/share/vm/oops/objArrayOop.cpp ! src/share/vm/oops/objArrayOop.hpp ! src/share/vm/oops/oop.cpp ! src/share/vm/oops/oop.hpp ! src/share/vm/oops/oop.inline.hpp ! src/share/vm/oops/oop.pcgc.inline.hpp ! src/share/vm/oops/oopsHierarchy.hpp ! src/share/vm/opto/buildOopMap.cpp ! src/share/vm/opto/callnode.hpp ! src/share/vm/opto/cfgnode.cpp ! src/share/vm/opto/chaitin.cpp ! src/share/vm/opto/classes.hpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/connode.cpp ! src/share/vm/opto/connode.hpp ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/idealKit.cpp ! src/share/vm/opto/lcm.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/opto/machnode.cpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/macro.hpp ! src/share/vm/opto/matcher.cpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/memnode.hpp ! src/share/vm/opto/node.cpp ! src/share/vm/opto/node.hpp ! src/share/vm/opto/opcodes.cpp ! src/share/vm/opto/opcodes.hpp ! src/share/vm/opto/parse2.cpp ! src/share/vm/opto/parse3.cpp ! src/share/vm/opto/phaseX.cpp ! src/share/vm/opto/phaseX.hpp ! src/share/vm/opto/subnode.cpp ! src/share/vm/opto/subnode.hpp ! src/share/vm/opto/superword.cpp ! src/share/vm/opto/type.cpp ! src/share/vm/opto/type.hpp ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jvmtiTagMap.cpp ! src/share/vm/prims/unsafe.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/atomic.cpp ! src/share/vm/runtime/atomic.hpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/frame.hpp ! src/share/vm/runtime/globals.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/globals_extension.hpp ! src/share/vm/runtime/hpi.cpp ! src/share/vm/runtime/init.cpp ! src/share/vm/runtime/jniHandles.cpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/services/heapDumper.cpp ! src/share/vm/utilities/copy.hpp ! src/share/vm/utilities/debug.cpp ! src/share/vm/utilities/globalDefinitions.cpp ! src/share/vm/utilities/globalDefinitions.hpp ! src/share/vm/utilities/taskqueue.hpp ! src/share/vm/utilities/vmError.cpp Changeset: 34935c25a52d Author: kamg Date: 2008-04-15 18:11 -0400 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/34935c25a52d Merge ! make/linux/makefiles/cscope.make ! make/solaris/makefiles/cscope.make Changeset: e7a91a357527 Author: kamg Date: 2008-04-16 17:36 -0400 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/e7a91a357527 6622385: Accessing protected static methods Summary: Protected contraints should only be applied if member is not static Reviewed-by: acorn, coleenp ! src/share/vm/runtime/reflection.cpp Changeset: 018d5b58dd4f Author: kamg Date: 2008-04-17 22:18 -0400 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/018d5b58dd4f 6537506: Provide a mechanism for specifying Java-level USDT-like dtrace probes Summary: Initial checkin of JSDT code Reviewed-by: acorn, sbohne ! make/linux/makefiles/mapfile-vers-debug ! make/linux/makefiles/mapfile-vers-product ! make/solaris/makefiles/dtrace.make ! make/solaris/makefiles/mapfile-vers ! src/cpu/sparc/vm/nativeInst_sparc.cpp ! src/cpu/sparc/vm/nativeInst_sparc.hpp ! src/cpu/sparc/vm/sharedRuntime_sparc.cpp ! src/cpu/x86/vm/nativeInst_x86.cpp ! src/cpu/x86/vm/nativeInst_x86.hpp ! src/cpu/x86/vm/sharedRuntime_x86_32.cpp ! src/cpu/x86/vm/sharedRuntime_x86_64.cpp + src/os/linux/vm/dtraceJSDT_linux.cpp + src/os/solaris/vm/dtraceJSDT_solaris.cpp + src/os/windows/vm/dtraceJSDT_windows.cpp ! src/share/vm/asm/codeBuffer.hpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/nmethod.hpp ! src/share/vm/includeDB_core ! src/share/vm/oops/methodOop.cpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvm.h + src/share/vm/runtime/dtraceJSDT.cpp + src/share/vm/runtime/dtraceJSDT.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/sharedRuntime.hpp Changeset: deadee49286e Author: sgoldman Date: 2008-04-11 06:18 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/deadee49286e 6644928: Internal Error (src/share/vm/code/relocInfo.hpp:1089) Summary: Cardtable base can be zero, ExternalAddress can't take a NULL. ! src/cpu/x86/vm/assembler_x86_32.cpp ! src/cpu/x86/vm/assembler_x86_64.cpp Changeset: fb75a7673531 Author: rasbold Date: 2008-04-16 14:55 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/fb75a7673531 Merge ! src/cpu/x86/vm/assembler_x86_64.cpp Changeset: d1a5218d7eaf Author: kvn Date: 2008-04-16 19:19 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/d1a5218d7eaf 6686791: Side effect in NumberFormat tests with -server -Xcomp Summary: Optimization in CmpPNode::sub() removed the valid compare instruction because of false positive answer from detect_dominating_control(). Reviewed-by: jrose, sgoldman ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/memnode.hpp ! src/share/vm/opto/node.cpp ! src/share/vm/opto/node.hpp Changeset: aab136449123 Author: trims Date: 2008-04-17 16:29 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/aab136449123 6690518: Bump Version to 13 B01 Summary: Change Hotspot version and build number for 13b1 Reviewed-by: pbk ! make/hotspot_version Changeset: 86a689f680c5 Author: kamg Date: 2008-04-18 07:51 -0400 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/86a689f680c5 Merge Changeset: ec73d88d5b43 Author: kamg Date: 2008-04-23 06:35 -0400 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/ec73d88d5b43 Merge ! make/hotspot_version ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/memnode.hpp ! src/share/vm/opto/node.cpp ! src/share/vm/opto/node.hpp Changeset: 9e5a7340635e Author: sgoldman Date: 2008-04-17 07:16 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/9e5a7340635e 6688137: c++ interpreter fails on 64bit sparc Summary: Misc. 64bit and endian fixes for sparc Reviewed-by: never, kvn, rasbold Contributed-by: volker.simonis at gmail.com ! src/cpu/sparc/vm/bytecodeInterpreter_sparc.hpp ! src/cpu/sparc/vm/cppInterpreter_sparc.cpp ! src/share/vm/interpreter/bytecodeInterpreter.cpp Changeset: b130b98db9cf Author: kvn Date: 2008-04-23 11:20 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/b130b98db9cf 6689060: Escape Analysis does not work with Compressed Oops Summary: 64-bits VM crashes with -XX:+AggresiveOpts (Escape Analysis + Compressed Oops) Reviewed-by: never, sgoldman ! src/cpu/sparc/vm/assembler_sparc.cpp ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/sparc.ad ! src/cpu/x86/vm/assembler_x86_64.cpp ! src/cpu/x86/vm/assembler_x86_64.hpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/opto/connode.cpp ! src/share/vm/opto/connode.hpp ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/runtime/sharedRuntime.cpp Changeset: d942c7e64bd9 Author: never Date: 2008-04-23 13:57 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/d942c7e64bd9 6601321: Assert(j == 1 || b->_nodes[j-1]->is_Phi(),"CreateEx must be first instruction in block") Reviewed-by: kvn, rasbold, sgoldman, jrose ! src/share/vm/opto/lcm.cpp Changeset: 72f4a668df19 Author: kvn Date: 2008-04-23 19:09 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/72f4a668df19 6625997: CastPP, CheckCastPP and Proj nodes are not dead loop safe Summary: EA and initialization optimizations could bypass these nodes. Reviewed-by: rasbold, never ! src/share/vm/opto/cfgnode.cpp ! src/share/vm/opto/connode.hpp ! src/share/vm/opto/multnode.hpp ! src/share/vm/opto/node.hpp Changeset: e0bd2e08e3d0 Author: never Date: 2008-04-24 11:13 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/e0bd2e08e3d0 6663848: assert(i < Max(),"oob") in C2 with -Xcomp Summary: NeverBranchNodes aren't handled properly Reviewed-by: kvn, sgoldman, rasbold, jrose ! src/share/vm/opto/cfgnode.cpp ! src/share/vm/opto/cfgnode.hpp ! src/share/vm/opto/compile.cpp + test/compiler/6663848/Tester.java Changeset: a76240c8b133 Author: rasbold Date: 2008-04-28 08:08 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/a76240c8b133 Merge ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/node.hpp ! src/share/vm/runtime/sharedRuntime.cpp Changeset: c0939256690b Author: rasbold Date: 2008-04-24 14:02 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/c0939256690b 6646019: array subscript expressions become top() with -d64 Summary: stop compilation after negative array allocation Reviewed-by: never, jrose ! src/share/vm/opto/parse2.cpp + test/compiler/6646019/Test.java Changeset: 3e2d987e2e68 Author: rasbold Date: 2008-04-29 06:52 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/3e2d987e2e68 Merge Changeset: 6e825ad773c6 Author: jrose Date: 2008-04-29 19:40 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/6e825ad773c6 6695288: runThese tests expr30303 and drem00301m1 fail when compiled code executes without deopt Summary: rework Value method for ModD and ModF, to DTRT for infinities Reviewed-by: sgoldman, kvn, rasbold ! src/share/vm/opto/divnode.cpp Changeset: 60b728ec77c1 Author: jrose Date: 2008-04-29 19:45 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/60b728ec77c1 6652736: well known classes in system dictionary are inefficiently processed Summary: combine many scalar variables into a single enum-indexed array in SystemDictionary. Reviewed-by: kvn ! agent/src/share/classes/sun/jvm/hotspot/memory/SystemDictionary.java ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/services/threadService.cpp Changeset: 435e64505015 Author: phh Date: 2008-04-24 15:07 -0400 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/435e64505015 6693457: Open-source hotspot linux-sparc support Summary: Move os_cpu/linux_sparc from closed to open Reviewed-by: kamg + make/linux/platform_sparcv9 + src/os_cpu/linux_sparc/vm/assembler_linux_sparc.cpp + src/os_cpu/linux_sparc/vm/atomic_linux_sparc.inline.hpp + src/os_cpu/linux_sparc/vm/globals_linux_sparc.hpp + src/os_cpu/linux_sparc/vm/linux_sparc.ad + src/os_cpu/linux_sparc/vm/linux_sparc.s + src/os_cpu/linux_sparc/vm/orderAccess_linux_sparc.inline.hpp + src/os_cpu/linux_sparc/vm/os_linux_sparc.cpp + src/os_cpu/linux_sparc/vm/os_linux_sparc.hpp + src/os_cpu/linux_sparc/vm/prefetch_linux_sparc.inline.hpp + src/os_cpu/linux_sparc/vm/threadLS_linux_sparc.cpp + src/os_cpu/linux_sparc/vm/threadLS_linux_sparc.hpp + src/os_cpu/linux_sparc/vm/thread_linux_sparc.cpp + src/os_cpu/linux_sparc/vm/thread_linux_sparc.hpp + src/os_cpu/linux_sparc/vm/vmStructs_linux_sparc.hpp + src/os_cpu/linux_sparc/vm/vm_version_linux_sparc.cpp ! src/share/vm/oops/oop.inline.hpp Changeset: 8a79f7ec8f5d Author: kamg Date: 2008-04-29 11:21 -0400 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/8a79f7ec8f5d 6692246: Regression : JDK 6u4 b01 fails two JCK tests when fallback is switched off Summary: Added a clause to allow null to be an operand to the arraylength bytecode Reviewed-by: sbohne, coleenp ! src/share/vm/classfile/verifier.cpp Changeset: b7268662a986 Author: coleenp Date: 2008-04-29 19:31 -0400 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/b7268662a986 6689523: max heap calculation for compressed oops is off by MaxPermSize Summary: Need to subtract MaxPermSize from the total heap size when determining whether compressed oops is turned on. Reviewed-by: jmasa, jcoomes, kvn ! src/share/vm/oops/oop.hpp ! src/share/vm/oops/oop.inline.hpp ! src/share/vm/runtime/arguments.cpp Changeset: 7f3a69574470 Author: kamg Date: 2008-04-30 10:58 -0400 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/7f3a69574470 6695506: JVM should accept classfiles with classfile version 51 Summary: increase class file parser's acceptable max to 51 Reviewed-by: sbohne, ikrylov ! src/share/vm/classfile/classFileParser.cpp Changeset: 53735b80b9f1 Author: sbohne Date: 2008-05-01 09:38 -0400 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/53735b80b9f1 Merge Changeset: bcdc68eb7e1f Author: sbohne Date: 2008-05-02 08:22 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/bcdc68eb7e1f Merge Changeset: c0492d52d55b Author: apetrusenko Date: 2008-04-01 15:13 +0400 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/c0492d52d55b 6539517: CR 6186200 should be extended to perm gen allocation to prevent spurious OOM's from perm gen Reviewed-by: ysr, jmasa ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsPermGen.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsPermGen.hpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/vmPSOperations.cpp ! src/share/vm/gc_implementation/shared/vmGCOperations.cpp ! src/share/vm/gc_implementation/shared/vmGCOperations.hpp ! src/share/vm/includeDB_core ! src/share/vm/memory/gcLocker.cpp ! src/share/vm/memory/genCollectedHeap.hpp ! src/share/vm/memory/permGen.cpp ! src/share/vm/memory/permGen.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/vm_operations.hpp Changeset: 3febac328d82 Author: apetrusenko Date: 2008-04-16 12:58 +0400 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/3febac328d82 Merge - src/cpu/sparc/vm/disassembler_sparc.cpp - src/cpu/x86/vm/disassembler_x86.cpp - src/share/vm/compiler/disassemblerEnv.hpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/includeDB_core ! src/share/vm/runtime/globals.hpp Changeset: fcbfc50865ab Author: iveresov Date: 2008-04-29 13:51 +0400 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/fcbfc50865ab 6684395: Port NUMA-aware allocator to linux Summary: NUMA-aware allocator port to Linux Reviewed-by: jmasa, apetrusenko ! build/linux/makefiles/mapfile-vers-debug ! build/linux/makefiles/mapfile-vers-product ! src/os/linux/vm/os_linux.cpp ! src/os/linux/vm/os_linux.hpp ! src/os/linux/vm/os_linux.inline.hpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/solaris/vm/os_solaris.inline.hpp ! src/os/windows/vm/os_windows.cpp ! src/os/windows/vm/os_windows.inline.hpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.hpp ! src/share/vm/gc_implementation/shared/mutableNUMASpace.cpp ! src/share/vm/gc_implementation/shared/mutableNUMASpace.hpp ! src/share/vm/includeDB_core ! src/share/vm/runtime/os.hpp Changeset: 8bd1e4487c18 Author: iveresov Date: 2008-05-04 03:29 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/8bd1e4487c18 Merge ! make/linux/makefiles/mapfile-vers-debug ! make/linux/makefiles/mapfile-vers-product ! src/os/windows/vm/os_windows.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/includeDB_core ! src/share/vm/memory/genCollectedHeap.hpp ! src/share/vm/runtime/globals.hpp Changeset: b5489bb705c9 Author: ysr Date: 2008-05-06 15:37 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/b5489bb705c9 6662086: 6u4+, 7b11+: CMS never clears referents when -XX:+ParallelRefProcEnabled Summary: Construct the relevant CMSIsAliveClosure used by CMS during parallel reference processing with the correct span. It had incorrectly been constructed with an empty span, a regression introduced in 6417901. Reviewed-by: jcoomes ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsOopClosures.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp Changeset: e3729351c946 Author: iveresov Date: 2008-05-09 16:34 +0400 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/e3729351c946 6697534: Premature GC and invalid lgrp selection with NUMA-aware allocator. Summary: Don't move tops of the chunks in ensure_parsibility(). Handle the situation with Solaris when a machine has a locality group with no memory. Reviewed-by: apetrusenko, jcoomes, ysr ! src/os/solaris/vm/os_solaris.cpp ! src/os/solaris/vm/os_solaris.hpp ! src/share/vm/gc_implementation/shared/mutableNUMASpace.cpp Changeset: f3de1255b035 Author: rasbold Date: 2008-05-07 08:06 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/f3de1255b035 6603011: RFE: Optimize long division Summary: Transform long division by constant into multiply Reviewed-by: never, kvn ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/opto/classes.hpp ! src/share/vm/opto/divnode.cpp ! src/share/vm/opto/mulnode.cpp ! src/share/vm/opto/mulnode.hpp ! src/share/vm/opto/type.hpp ! src/share/vm/utilities/globalDefinitions.hpp Changeset: 7cce9e4e0f7c Author: rasbold Date: 2008-05-09 05:26 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/7cce9e4e0f7c Merge Changeset: 83c868b757c0 Author: jrose Date: 2008-05-14 00:41 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/83c868b757c0 6701024: SAJDI functionality is broken Summary: back out sa-related changes to 6652736, use concrete expressions for WKK names in the SA Reviewed-by: never, sundar ! agent/src/share/classes/sun/jvm/hotspot/memory/SystemDictionary.java ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 7a0a921a1a8c Author: rasbold Date: 2008-05-14 15:01 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/7a0a921a1a8c Merge Changeset: e3d2692f8442 Author: trims Date: 2008-05-20 19:50 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/e3d2692f8442 Merge Changeset: c14dab40ed9b Author: xdono Date: 2008-05-22 09:37 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/c14dab40ed9b Added tag jdk7-b27 for changeset e3d2692f8442 ! .hgtags From xiomara.jayasena at sun.com Wed May 28 14:35:18 2008 From: xiomara.jayasena at sun.com (xiomara.jayasena at sun.com) Date: Wed, 28 May 2008 14:35:18 +0000 Subject: hg: jdk7/build/jaxp: Added tag jdk7-b27 for changeset bafed478d67c Message-ID: <20080528143520.168C8287CA@hg.openjdk.java.net> Changeset: b996318955c0 Author: xdono Date: 2008-05-22 09:37 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jaxp/rev/b996318955c0 Added tag jdk7-b27 for changeset bafed478d67c ! .hgtags From xiomara.jayasena at sun.com Wed May 28 14:36:10 2008 From: xiomara.jayasena at sun.com (xiomara.jayasena at sun.com) Date: Wed, 28 May 2008 14:36:10 +0000 Subject: hg: jdk7/build/jaxws: Added tag jdk7-b27 for changeset 27d8f42862c1 Message-ID: <20080528143612.31D6B287CF@hg.openjdk.java.net> Changeset: eefcd5204500 Author: xdono Date: 2008-05-22 09:37 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jaxws/rev/eefcd5204500 Added tag jdk7-b27 for changeset 27d8f42862c1 ! .hgtags From xiomara.jayasena at sun.com Wed May 28 14:38:09 2008 From: xiomara.jayasena at sun.com (xiomara.jayasena at sun.com) Date: Wed, 28 May 2008 14:38:09 +0000 Subject: hg: jdk7/build/jdk: 34 new changesets Message-ID: <20080528144503.E87DB287D4@hg.openjdk.java.net> Changeset: 92ea0ac77d2f Author: emcmanus Date: 2008-04-22 18:58 +0200 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/92ea0ac77d2f 6692027: Custom subclasses of QueryEval don't serialize Summary: Remove non-public superclass of QueryEval Reviewed-by: dfuchs ! src/share/classes/javax/management/AndQueryExp.java ! src/share/classes/javax/management/BetweenQueryExp.java ! src/share/classes/javax/management/BinaryRelQueryExp.java ! src/share/classes/javax/management/NotQueryExp.java ! src/share/classes/javax/management/ObjectName.java ! src/share/classes/javax/management/OrQueryExp.java ! src/share/classes/javax/management/Query.java ! src/share/classes/javax/management/QueryEval.java + test/javax/management/query/CustomQueryTest.java Changeset: ad75c4b21d63 Author: weijun Date: 2008-04-10 19:58 +0800 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/ad75c4b21d63 6675606: javax.security.auth.login.Configuration does not recognize path with spaces Reviewed-by: chegar, xuelei ! src/share/classes/com/sun/security/auth/login/ConfigFile.java + test/javax/security/auth/login/Configuration/ConfigFileWithBlank.java Changeset: c0eb84957bea Author: xuelei Date: 2008-04-11 03:33 -0400 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/c0eb84957bea 6546639: (spec)javax.net.ssl.SSLContext.getInstance(null) throws undocumented NPE Summary: add NullPointerException description to those methods. Reviewed-by: weijun ! src/share/classes/javax/net/ssl/SSLContext.java Changeset: da9fa1fa9b95 Author: xuelei Date: 2008-04-11 03:43 -0400 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/da9fa1fa9b95 6546671: (spec)javax.net.ssl.TrustManagerFactory.getInstance() throws undocumented NP 5053895: (spec) Unspecified IllegalStateException in TrustManagerFactory Summary: add NullPointerException/IllegalStateException description Reviewed-by: weijun ! src/share/classes/javax/net/ssl/TrustManagerFactory.java ! src/share/classes/javax/net/ssl/TrustManagerFactorySpi.java Changeset: 143e1a9b51a9 Author: xuelei Date: 2008-04-11 03:50 -0400 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/143e1a9b51a9 6571950: SSLSocket(raddr, rport, laddr, lport) allows null as laddr that spec doesn't reflect Summary: add the description that while the local address parameter is null, anyLocalAddress will be used instead. Reviewed-by: weijun ! src/share/classes/java/net/Socket.java ! src/share/classes/javax/net/ssl/SSLSocket.java Changeset: aabdc646cb31 Author: mullan Date: 2008-04-14 10:25 -0400 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/aabdc646cb31 6631361: Spec of AccessControlContext constructor is not complete Summary: Add NullPointerException to @throws clause and treat empty array and array of nulls as equivalent Reviewed-by: valeriep ! src/share/classes/java/security/AccessControlContext.java + test/java/security/AccessControlContext/CheckCtor.java Changeset: b627c3efd97c Author: mullan Date: 2008-04-14 10:41 -0400 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/b627c3efd97c Merge Changeset: 459d23a95dfb Author: chegar Date: 2008-04-15 14:22 +0100 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/459d23a95dfb 6659779: HttpURLConnections logger should log tunnel requests Summary: Invoke Logger for CONNECT request/responses. Reviewed-by: jccollet ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java Changeset: a954a6f3be6f Author: chegar Date: 2008-04-16 14:17 +0100 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/a954a6f3be6f 6687282: URLConnection for HTTPS connection through Proxy w/ Digest Authentication gives 400 Bad Request Summary: Change http/digest implementation to use host:port from CONNECT request Reviewed-by: michaelm ! src/share/classes/sun/net/www/protocol/http/DigestAuthentication.java ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java Changeset: d44e3bf49ffb Author: jccollet Date: 2008-04-17 11:05 +0200 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/d44e3bf49ffb 6644726: Cookie management issues Summary: Many changes to accomodate RFC 2965 and old Netscape specs Reviewed-by: chegar ! src/share/classes/java/net/CookieManager.java ! src/share/classes/java/net/HttpCookie.java ! src/share/classes/sun/net/www/protocol/http/InMemoryCookieStore.java + test/java/net/CookieHandler/B6644726.java Changeset: 493af4f4be79 Author: wetmore Date: 2008-04-17 16:56 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/493af4f4be79 Merge Changeset: a71ab67d3ece Author: jccollet Date: 2008-04-18 15:23 +0200 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/a71ab67d3ece 6558853: getHostAddress() on connections using IPv6 link-local addrs should have zone id Summary: Set the scope_id_set flag when necessary Reviewed-by: chegar ! src/share/native/java/net/net_util.c + test/java/net/Inet6Address/B6558853.java Changeset: 4e7ad09de58b Author: weijun Date: 2008-04-23 08:10 +0800 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/4e7ad09de58b 6689000: Changes in 6675606 causing regression test failures on windows-i586 Summary: Accept illegal URLs like file:c:/root/x.conf and file:this/that/x.conf Reviewed-by: alanb, chegar ! src/share/classes/com/sun/security/auth/login/ConfigFile.java + test/com/sun/security/auth/login/ConfigFile/IllegalURL.java Changeset: d3af7105cc15 Author: wetmore Date: 2008-04-23 10:20 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/d3af7105cc15 Merge Changeset: 072695f32409 Author: mullan Date: 2008-04-25 08:58 -0400 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/072695f32409 6690169: Specification for BasicPermission.equals() is not consistent Summary: Clarified @return to be consistent with method description Reviewed-by: vinnie ! src/share/classes/java/security/BasicPermission.java Changeset: 44700b433be2 Author: mullan Date: 2008-04-25 09:03 -0400 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/44700b433be2 Merge Changeset: 51eab854cb1a Author: valeriep Date: 2008-04-25 15:19 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/51eab854cb1a 6524501: inconsistency with PKCS#11 spec - 0-value flags in CK_SLOT_INFO struct returned by C_GetSlotInfo() Reviewed-by: mullan ! src/share/classes/sun/security/pkcs11/SunPKCS11.java Changeset: 01dbd203d40e Author: valeriep Date: 2008-04-25 15:24 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/01dbd203d40e 6659990: KerberosTicket.getEndTime does not copy date (findbugs) Reviewed-by: mullan ! src/share/classes/javax/security/auth/kerberos/KerberosTicket.java + test/javax/security/auth/kerberos/KerberosTixDateTest.java Changeset: 4d62bebb22ea Author: valeriep Date: 2008-04-25 15:32 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/4d62bebb22ea Merge Changeset: 27719467fb93 Author: valeriep Date: 2008-04-30 11:10 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/27719467fb93 6695818: New regression test (KerberosTixDateTest) for Kerberos failing on (probably) all platforms. Reviewed-by: mullan ! test/javax/security/auth/kerberos/KerberosTixDateTest.java Changeset: a3b3f07682b5 Author: kamg Date: 2008-05-08 09:16 -0400 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/a3b3f07682b5 6697875: Copyright headers need to be upgraded with GPL derivative Summary: Update copyright headers to GPL Reviewed-by: xdono ! make/com/sun/tracing/Makefile ! make/com/sun/tracing/dtrace/Makefile ! make/sun/tracing/Makefile ! make/sun/tracing/dtrace/Makefile ! make/sun/tracing/dtrace/mapfile-vers ! src/share/classes/com/sun/tracing/Probe.java ! src/share/classes/com/sun/tracing/ProbeName.java ! src/share/classes/com/sun/tracing/Provider.java ! src/share/classes/com/sun/tracing/ProviderName.java ! src/share/classes/com/sun/tracing/dtrace/ArgsAttributes.java ! src/share/classes/com/sun/tracing/dtrace/Attributes.java ! src/share/classes/com/sun/tracing/dtrace/DependencyClass.java ! src/share/classes/com/sun/tracing/dtrace/FunctionAttributes.java ! src/share/classes/com/sun/tracing/dtrace/FunctionName.java ! src/share/classes/com/sun/tracing/dtrace/ModuleAttributes.java ! src/share/classes/com/sun/tracing/dtrace/ModuleName.java ! src/share/classes/com/sun/tracing/dtrace/NameAttributes.java ! src/share/classes/com/sun/tracing/dtrace/ProviderAttributes.java ! src/share/classes/com/sun/tracing/dtrace/StabilityLevel.java ! src/share/classes/com/sun/tracing/dtrace/package-info.java ! src/share/classes/com/sun/tracing/package-info.java ! src/share/classes/sun/tracing/MultiplexProviderFactory.java ! src/share/classes/sun/tracing/NullProviderFactory.java ! src/share/classes/sun/tracing/PrintStreamProviderFactory.java ! src/share/classes/sun/tracing/ProbeSkeleton.java ! src/share/classes/sun/tracing/ProviderSkeleton.java ! src/share/classes/sun/tracing/dtrace/Activation.java ! src/share/classes/sun/tracing/dtrace/DTraceProbe.java ! src/share/classes/sun/tracing/dtrace/DTraceProvider.java ! src/share/classes/sun/tracing/dtrace/DTraceProviderFactory.java ! src/share/classes/sun/tracing/dtrace/JVM.java ! src/share/classes/sun/tracing/package-info.java ! src/share/native/sun/tracing/dtrace/JVM.c ! src/share/native/sun/tracing/dtrace/jvm_symbols.h ! src/solaris/native/sun/tracing/dtrace/jvm_symbols_md.c ! src/windows/native/sun/tracing/dtrace/jvm_symbols_md.c Changeset: d64b14c25c82 Author: martin Date: 2008-05-10 11:30 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/d64b14c25c82 6636363: BufferUnderflowException decoding length 6 UTF-8 sequences with direct buffers Reviewed-by: sherman ! src/share/classes/sun/nio/cs/UTF_8.java Changeset: 3e7a4b6ef105 Author: martin Date: 2008-05-10 11:49 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/3e7a4b6ef105 6691185: (coll) TreeMap.navigableKeySet's descendingIterator method starts at first instead of last entry Reviewed-by: dl, chegar ! src/share/classes/java/util/TreeMap.java ! test/java/util/Collection/MOAT.java ! test/java/util/NavigableMap/LockStep.java Changeset: 9781e5c7b9ba Author: martin Date: 2008-05-10 12:14 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/9781e5c7b9ba 6691215: (coll) IdentityHashMap.containsValue(null) returns true when null value not present Reviewed-by: dl, chegar, alanb Contributed-by: scottb at google.com ! src/share/classes/java/util/IdentityHashMap.java ! test/java/util/Collection/MOAT.java Changeset: d95a6a4ea502 Author: chegar Date: 2008-05-02 21:33 +0100 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/d95a6a4ea502 6687919: REGRESSION : Classloader can handle any resource which is not included in classpath Reviewed-by: jccollet, alanb ! src/share/classes/sun/misc/URLClassPath.java Changeset: 61a7e1919ba3 Author: wetmore Date: 2008-05-11 00:26 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/61a7e1919ba3 Merge Changeset: 2bf15b903bec Author: tbell Date: 2008-05-12 18:06 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/2bf15b903bec Merge Changeset: 3e599d98875d Author: tbell Date: 2008-05-16 12:25 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/3e599d98875d Merge Changeset: da9a7ef8d34e Author: xdono Date: 2008-05-22 09:37 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/da9a7ef8d34e Added tag jdk7-b27 for changeset 3e599d98875d ! .hgtags Changeset: 94ded5c8cfba Author: emcmanus Date: 2008-05-14 18:38 +0200 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/94ded5c8cfba 6701459: Synchronization bug pattern found in javax.management.relation.RelationService Summary: Fixed this and many other problems found by FindBugs. Reviewed-by: dfuchs ! src/share/classes/com/sun/jmx/interceptor/DefaultMBeanServerInterceptor.java ! src/share/classes/com/sun/jmx/mbeanserver/MBeanInstantiator.java ! src/share/classes/com/sun/jmx/mbeanserver/Repository.java ! src/share/classes/com/sun/jmx/remote/internal/ClientNotifForwarder.java ! src/share/classes/com/sun/jmx/remote/internal/ServerNotifForwarder.java ! src/share/classes/com/sun/jmx/remote/security/FileLoginModule.java ! src/share/classes/com/sun/jmx/remote/security/JMXPluggableAuthenticator.java ! src/share/classes/com/sun/jmx/remote/security/MBeanServerFileAccessController.java ! src/share/classes/javax/management/NumericValueExp.java ! src/share/classes/javax/management/ObjectName.java ! src/share/classes/javax/management/StandardMBean.java ! src/share/classes/javax/management/loading/MLet.java ! src/share/classes/javax/management/loading/MLetParser.java ! src/share/classes/javax/management/modelmbean/DescriptorSupport.java ! src/share/classes/javax/management/modelmbean/ModelMBeanAttributeInfo.java ! src/share/classes/javax/management/modelmbean/ModelMBeanConstructorInfo.java ! src/share/classes/javax/management/modelmbean/ModelMBeanInfoSupport.java ! src/share/classes/javax/management/modelmbean/ModelMBeanNotificationInfo.java ! src/share/classes/javax/management/modelmbean/ModelMBeanOperationInfo.java ! src/share/classes/javax/management/modelmbean/RequiredModelMBean.java ! src/share/classes/javax/management/monitor/CounterMonitor.java ! src/share/classes/javax/management/monitor/GaugeMonitor.java ! src/share/classes/javax/management/monitor/Monitor.java ! src/share/classes/javax/management/openmbean/ArrayType.java ! src/share/classes/javax/management/openmbean/CompositeType.java ! src/share/classes/javax/management/openmbean/OpenMBeanAttributeInfoSupport.java ! src/share/classes/javax/management/openmbean/OpenMBeanConstructorInfoSupport.java ! src/share/classes/javax/management/openmbean/OpenMBeanInfoSupport.java ! src/share/classes/javax/management/openmbean/SimpleType.java ! src/share/classes/javax/management/openmbean/TabularType.java ! src/share/classes/javax/management/relation/RelationNotification.java ! src/share/classes/javax/management/relation/RelationService.java ! src/share/classes/javax/management/relation/RelationSupport.java ! src/share/classes/javax/management/remote/JMXConnectorFactory.java ! src/share/classes/javax/management/remote/JMXConnectorServerFactory.java ! src/share/classes/javax/management/remote/JMXServiceURL.java ! src/share/classes/javax/management/remote/rmi/RMIConnector.java ! src/share/classes/javax/management/remote/rmi/RMIConnectorServer.java ! src/share/classes/javax/management/timer/Timer.java Changeset: 1483094a7c17 Author: emcmanus Date: 2008-05-16 11:34 +0200 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/1483094a7c17 6703552: Missing files from changeset for 6701459 Summary: Previous push missed a small number of files. Reviewed-by: dfuchs ! src/share/classes/javax/management/openmbean/OpenMBeanOperationInfoSupport.java ! src/share/classes/javax/management/relation/RelationService.java ! src/share/classes/javax/management/timer/Timer.java + test/javax/management/relation/RelationNotificationSeqNoTest.java Changeset: a36a7f0f11ec Author: tbell Date: 2008-05-22 15:58 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/a36a7f0f11ec Merge Changeset: cbd182c404d8 Author: tbell Date: 2008-05-23 11:13 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/cbd182c404d8 Merge Changeset: b6601ba7f6df Author: xdono Date: 2008-05-27 17:18 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/b6601ba7f6df Merge From xiomara.jayasena at sun.com Wed May 28 14:48:44 2008 From: xiomara.jayasena at sun.com (xiomara.jayasena at sun.com) Date: Wed, 28 May 2008 14:48:44 +0000 Subject: hg: jdk7/build/langtools: 3 new changesets Message-ID: <20080528144850.4E13D287D9@hg.openjdk.java.net> Changeset: ec29a1a284ca Author: mcimadamore Date: 2008-04-23 17:10 +0100 URL: http://hg.openjdk.java.net/jdk7/build/langtools/rev/ec29a1a284ca 6682380: Foreach loop with generics inside finally block crashes javac with -target 1.5 Summary: A missing type-erasure in Lower.java causes the compiler to crash since JDK6 Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Lower.java + test/tools/javac/foreach/T6682380.java Changeset: a17265993253 Author: tbell Date: 2008-05-12 18:07 -0700 URL: http://hg.openjdk.java.net/jdk7/build/langtools/rev/a17265993253 Merge Changeset: 4ef4bd318569 Author: xdono Date: 2008-05-22 09:37 -0700 URL: http://hg.openjdk.java.net/jdk7/build/langtools/rev/4ef4bd318569 Added tag jdk7-b27 for changeset a17265993253 ! .hgtags From martinrb at google.com Sat May 31 07:54:17 2008 From: martinrb at google.com (Martin Buchholz) Date: Sat, 31 May 2008 00:54:17 -0700 Subject: duplicated sanity check warning Message-ID: <1ccfd1c10805310054r48dd5c95obf21123ecd9b7c93@mail.gmail.com> This is a bug report. I was trying to build openjdk6, and make sanity got duplicated BUILD_JDK = true lines in the output. Looking at control/make/make/sanity-rules.gmk, I see duplicate lines ifeq ($(JDK_SRC_AVAILABLE), true) @$(ECHO) " BUILD_JDK = $(BUILD_JDK) " >> $(MESSAGE_FILE) endif ifeq ($(JDK_SRC_AVAILABLE), true) @$(ECHO) " BUILD_JDK = $(BUILD_JDK) " >> $(MESSAGE_FILE) endif Delete one of the above. Martin