From pete at a11ysoft.com Thu Oct 1 17:21:03 2009 From: pete at a11ysoft.com (Pete Brunet) Date: Thu, 01 Oct 2009 19:21:03 -0500 Subject: Freetype version check failure - copy of DLL failed In-Reply-To: <4AC3D2A0.4030708@sun.com> References: <4AC0E0EC.4000103@a11ysoft.com> <4AC0F368.2010908@sun.com> <4AC12270.30504@a11ysoft.com> <4AC3D2A0.4030708@sun.com> Message-ID: <4AC5476F.4010304@a11ysoft.com> Tim, I went back to my original fixes (copy dll to lib and change the make to use freetype6.dll) then did the following: cd /cygdrive/c/OpenJDK/jdk7/jdk/make/tools/freetypecheck make clean make all and started getting a trace. I don't know if running from the freetypecheck directory is a valid thing to do, but when I do that I noticed that mt.exe is not found. In this (possibly invalid) invocation of make, $(MT) resolves to c:/PROGRA~1/MICROS~1.0/Common7/Tools/../../Vc/Bin/mt aka "C:\Program Files\Microsoft Visual Studio 9.0\VC\bin\mt" but on my system mt.exe is at C:\Program Files\Microsoft SDKs\Windows\v6.0A\bin\mt.exe If I change $(MT) to just mt so it's found via the PATH then the above build is OK. However, even with that fix, when I do make sanity the normal way the exe isn't being built. And no matter what I try (echo, $(warning ...) I can't get make to trace when I run make sanity the normal way. Pete --- Tim Bell wrote: > Pete Brunet wrote: > >> Thanks Tim, It must be something else. Here are my two environment >> variables: >> >> ALT_FREETYPE_HEADERS_PATH=C:/Progra~1/GnuWin32/include >> ALT_FREETYPE_LIB_PATH=C:/Progra~1/GnuWin32/lib >> > > Good - that looks OK. > > >>>> freetype was installed via the binary installer at >>>> http://gnuwin32.sourceforge.net/packages/freetype.htm. >>>> > > After installing bits from there, I needed to copy bin/freetype6.dll > to lib/freetype6.dll > > >> At a minimum I have to edit >> C:\OpenJDK\jdk7\jdk\make\tools\freetypecheck\Makefile as follows: >> # change freetype.dll to freetype6.dll >> FREETYPE_DLL = $(FREETYPE_LIB_PATH)/freetype6.dll >> because there is no freetype.dll in C:\Program Files\GnuWin32, just >> freetype6.dll. >> > > And then edit the makefile to reach for freetype6.dll, as you > did. Here are my diffs: > > % pwd > /cygdrive/g/OpenJDK/jdk/make/tools/freetypecheck > > $ diff -u Makefile.00 Makefile > --- Makefile.00 2009-08-19 18:39:51.531250000 -0700 > +++ Makefile 2009-09-30 13:49:28.794625000 -0700 > @@ -36,7 +36,7 @@ > # Start with CFLAGS (which gets us the required -xarch setting on solaris) > ifeq ($(PLATFORM), windows) > FT_OPTIONS = /nologo $(CC_OBJECT_OUTPUT_FLAG)$(TEMPDIR) > - FREETYPE_DLL = $(FREETYPE_LIB_PATH)/freetype.dll > + FREETYPE_DLL = $(FREETYPE_LIB_PATH)/freetype6.dll > FT_LD_OPTIONS = $(FREETYPE_LIB_PATH)/freetype.lib > else > FT_OPTIONS = $(CFLAGS) > > Unfortunately, the freetype_versioncheck.exe that is created after > doing that fails to initialize: > > When run in a Cygwin window: > $ g:/OpenJDK/build/windows-i586/btbins/freetype_versioncheck.exe > $ echo $? > 34 > > When run in a DOS cmd window, I get an "Application Error" pop-up > that reads "The application failed to initialize properly (0xc0000022). > Click on OK to terminate the application" [OK] > > If I look at freetype_versioncheck.exe using the dependancywalker > tool [1], it shows an unresolved reference to ZLIB1.DLL > > > When I switch my OpenJDK build environment back to use my existing > copy of freetype 2.3.4 [2], the versioncheck program builds, works > OK (no mention of ZLIB1.DLL), and prints: > > $ g:/OpenJDK/build/windows-i586/btbins/freetype_versioncheck.exe > Required version of freetype: 2.3.0 > Detected freetype headers: 2.3.4 > Detected freetype library: 2.3.4 > $ echo $? > 0 > > > >> Here is my "make sanity" output: >> >> ERROR: FreeType version 2.3.0 or higher is required. >> make[2]: Entering directory >> `/cygdrive/c/OpenJDK/jdk7/jdk/make/tools/freetypecheck' >> c:/OpenJDK/jdk7/build/windows-i586/btbins/freetype_versioncheck.exe >> make[2]: Leaving directory >> `/cygdrive/c/OpenJDK/jdk7/jdk/make/tools/freetypecheck' >> Failed to build freetypecheck. >> >> BTW, How do I put prints in the make file to see the values of the >> variables? >> > > You could add "echo" lines to the commands run by a make rule. > Also, make commands are prefixed with '@' to make them silent. > Remove the '@' to see more output. > > HTH- > Tim > > [1] http://www.dependencywalker.com/ > > [2] See step 8: > http://blogs.sun.com/TimBell/entry/building_openjdk7_on_32_bit > > The files I modified are available here: > http://cr.openjdk.java.net/~tbell/freetype/ > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/build-dev/attachments/20091001/2b634c3f/attachment.html From pete at a11ysoft.com Fri Oct 2 08:50:13 2009 From: pete at a11ysoft.com (Pete Brunet) Date: Fri, 02 Oct 2009 10:50:13 -0500 Subject: [Fwd: Re: Freetype version check failure - copy of DLL failed] Message-ID: <4AC62135.9090504@a11ysoft.com> I ran make -d sanity today and see the following. I don't know why it doesn't want to build freetype_versioncheck.exe. It doesn't exist. There is however a file named freetype_versioncheck.exe.manifest so to make sure that isn't a problem I commented out its build from freetypecheck/makefile and renamed it to freetype_versioncheck-OLD.exe.manifest in the btbins directory, but the debug make output looks the same after that test. Considering target file `all'. File `all' does not exist. Considering target file `c:/OpenJDK/jdk7/build/windows-i586/btbins/freetype_versioncheck.exe'. Considering target file `freetypecheck.c'. ..... No need to remake target `freetypecheck.c'. Finished prerequisites of target file `c:/OpenJDK/jdk7/build/windows-i586/btbins/freetype_versioncheck.exe'. Prerequisite `freetypecheck.c' is older than target `c:/OpenJDK/jdk7/build/windows-i586/btbins/freetype_versioncheck.exe'. No need to remake target `c:/OpenJDK/jdk7/build/windows-i586/btbins/freetype_versioncheck.exe'. Finished prerequisites of target file `all'. Must remake target `all'. make[2]: Entering directory `/cygdrive/c/OpenJDK/jdk7/jdk/make/tools/freetypecheck' c:/OpenJDK/jdk7/build/windows-i586/btbins/freetype_versioncheck.exe Putting child 0x006de0c0 (all) PID 6916 on the chain. Live child 0x006de0c0 (all) PID 6916 Got a SIGCHLD; 1 unreaped children. Reaping losing child 0x006de0c0 PID 6916 Removing child 0x006de0c0 PID 6916 from chain. make[2]: Leaving directory `/cygdrive/c/OpenJDK/jdk7/jdk/make/tools/freetypecheck' Failed to build freetypecheck. Exiting because of the above error(s). -------- Original Message -------- Subject: Re: Freetype version check failure - copy of DLL failed Date: Thu, 01 Oct 2009 19:21:03 -0500 From: Pete Brunet Reply-To: pete at a11ysoft.com To: Tim Bell CC: build-dev at openjdk.java.net References: <4AC0E0EC.4000103 at a11ysoft.com> <4AC0F368.2010908 at sun.com> <4AC12270.30504 at a11ysoft.com> <4AC3D2A0.4030708 at sun.com> Tim, I went back to my original fixes (copy dll to lib and change the make to use freetype6.dll) then did the following: cd /cygdrive/c/OpenJDK/jdk7/jdk/make/tools/freetypecheck make clean make all and started getting a trace. I don't know if running from the freetypecheck directory is a valid thing to do, but when I do that I noticed that mt.exe is not found. In this (possibly invalid) invocation of make, $(MT) resolves to c:/PROGRA~1/MICROS~1.0/Common7/Tools/../../Vc/Bin/mt aka "C:\Program Files\Microsoft Visual Studio 9.0\VC\bin\mt" but on my system mt.exe is at C:\Program Files\Microsoft SDKs\Windows\v6.0A\bin\mt.exe If I change $(MT) to just mt so it's found via the PATH then the above build is OK. However, even with that fix, when I do make sanity the normal way the exe isn't being built. And no matter what I try (echo, $(warning ...) I can't get make to trace when I run make sanity the normal way. Pete --- Tim Bell wrote: > Pete Brunet wrote: > >> Thanks Tim, It must be something else. Here are my two environment >> variables: >> >> ALT_FREETYPE_HEADERS_PATH=C:/Progra~1/GnuWin32/include >> ALT_FREETYPE_LIB_PATH=C:/Progra~1/GnuWin32/lib >> > > Good - that looks OK. > > >>>> freetype was installed via the binary installer at >>>> http://gnuwin32.sourceforge.net/packages/freetype.htm. >>>> > > After installing bits from there, I needed to copy bin/freetype6.dll > to lib/freetype6.dll > > >> At a minimum I have to edit >> C:\OpenJDK\jdk7\jdk\make\tools\freetypecheck\Makefile as follows: >> # change freetype.dll to freetype6.dll >> FREETYPE_DLL = $(FREETYPE_LIB_PATH)/freetype6.dll >> because there is no freetype.dll in C:\Program Files\GnuWin32, just >> freetype6.dll. >> > > And then edit the makefile to reach for freetype6.dll, as you > did. Here are my diffs: > > % pwd > /cygdrive/g/OpenJDK/jdk/make/tools/freetypecheck > > $ diff -u Makefile.00 Makefile > --- Makefile.00 2009-08-19 18:39:51.531250000 -0700 > +++ Makefile 2009-09-30 13:49:28.794625000 -0700 > @@ -36,7 +36,7 @@ > # Start with CFLAGS (which gets us the required -xarch setting on solaris) > ifeq ($(PLATFORM), windows) > FT_OPTIONS = /nologo $(CC_OBJECT_OUTPUT_FLAG)$(TEMPDIR) > - FREETYPE_DLL = $(FREETYPE_LIB_PATH)/freetype.dll > + FREETYPE_DLL = $(FREETYPE_LIB_PATH)/freetype6.dll > FT_LD_OPTIONS = $(FREETYPE_LIB_PATH)/freetype.lib > else > FT_OPTIONS = $(CFLAGS) > > Unfortunately, the freetype_versioncheck.exe that is created after > doing that fails to initialize: > > When run in a Cygwin window: > $ g:/OpenJDK/build/windows-i586/btbins/freetype_versioncheck.exe > $ echo $? > 34 > > When run in a DOS cmd window, I get an "Application Error" pop-up > that reads "The application failed to initialize properly (0xc0000022). > Click on OK to terminate the application" [OK] > > If I look at freetype_versioncheck.exe using the dependancywalker > tool [1], it shows an unresolved reference to ZLIB1.DLL > > > When I switch my OpenJDK build environment back to use my existing > copy of freetype 2.3.4 [2], the versioncheck program builds, works > OK (no mention of ZLIB1.DLL), and prints: > > $ g:/OpenJDK/build/windows-i586/btbins/freetype_versioncheck.exe > Required version of freetype: 2.3.0 > Detected freetype headers: 2.3.4 > Detected freetype library: 2.3.4 > $ echo $? > 0 > > > >> Here is my "make sanity" output: >> >> ERROR: FreeType version 2.3.0 or higher is required. >> make[2]: Entering directory >> `/cygdrive/c/OpenJDK/jdk7/jdk/make/tools/freetypecheck' >> c:/OpenJDK/jdk7/build/windows-i586/btbins/freetype_versioncheck.exe >> make[2]: Leaving directory >> `/cygdrive/c/OpenJDK/jdk7/jdk/make/tools/freetypecheck' >> Failed to build freetypecheck. >> >> BTW, How do I put prints in the make file to see the values of the >> variables? >> > > You could add "echo" lines to the commands run by a make rule. > Also, make commands are prefixed with '@' to make them silent. > Remove the '@' to see more output. > > HTH- > Tim > > [1] http://www.dependencywalker.com/ > > [2] See step 8: > http://blogs.sun.com/TimBell/entry/building_openjdk7_on_32_bit > > The files I modified are available here: > http://cr.openjdk.java.net/~tbell/freetype/ > > > -- *Pete Brunet* a11ysoft - Accessibility Architecture and Development (512) 238-6967 (work), (512) 689-4155 (cell) Skype: pete.brunet IM: ptbrunet (AOL, Google), ptbrunet at live.com (MSN) http://www.a11ysoft.com/about/ Ionosphere: WS4G -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/build-dev/attachments/20091002/377b4363/attachment.html From Tim.Bell at Sun.COM Fri Oct 2 11:48:08 2009 From: Tim.Bell at Sun.COM (Tim Bell) Date: Fri, 02 Oct 2009 11:48:08 -0700 Subject: [Fwd: Re: Freetype version check failure - copy of DLL failed] In-Reply-To: <4AC62135.9090504@a11ysoft.com> References: <4AC62135.9090504@a11ysoft.com> Message-ID: <4AC64AE8.7030507@sun.com> Pete Brunet wrote: > I ran make -d sanity today and see the following. I don't know why it > doesn't want to build freetype_versioncheck.exe. It doesn't exist. > > There is however a file named freetype_versioncheck.exe.manifest so to > make sure that isn't a problem I commented out its build from > freetypecheck/makefile and renamed it to > freetype_versioncheck-OLD.exe.manifest in the btbins directory, but the > debug make output looks the same after that test. sanity will need that .manifest file to run freetype_versioncheck.exe That was build bugID 6705913 "freetype_versioncheck.exe - Unable To Locate Component" https://bugs.openjdk.java.net/show_bug.cgi?id=100101 (SNIP!) > No need to remake target `c:/OpenJDK/jdk7/build/windows-i586/btbins/freetype_versioncheck.exe'. What is the output when you run that executable in an MS-DOS CMD window? > Tim, I went back to my original fixes (copy dll to lib and change the > make to use freetype6.dll) then did the following: > > cd /cygdrive/c/OpenJDK/jdk7/jdk/make/tools/freetypecheck > make clean > make all > > and started getting a trace. I don't know if running from the > freetypecheck directory is a valid thing to do, but when I do that I > noticed that mt.exe is not found. In this (possibly invalid) invocation > of make, $(MT) resolves to > > c:/PROGRA~1/MICROS~1.0/Common7/Tools/../../Vc/Bin/mt aka "C:\Program > Files\Microsoft Visual Studio 9.0\VC\bin\mt" > > but on my system mt.exe is at > > C:\Program Files\Microsoft SDKs\Windows\v6.0A\bin\mt.exe > > If I change $(MT) to just mt so it's found via the PATH then the above > build is OK. That is what my build is doing. $(CL) and $(MT) are both found on PATH, ahead of the Cygwin bin directories. But I also set the ALT_ variables in my environment and build scripts (see below). $ echo $PATH /cygdrive/c/JDK16~1.0_0/bin:/cygdrive/c/PROGRA~1/MICROS~1.0/Common7/IDE:/cygdriv e/c/PROGRA~1/MICROS~1.0/VC/BIN:/cygdrive/c/PROGRA~1/MICROS~1.0/Common7/Tools:/cy gdrive/c/PROGRA~1/MICROS~2/Windows/v6.1/bin:/cygdrive/c/WINDOWS/MICROS~1.NET/FRA MEW~1/V20~1.507:/cygdrive/c/PROGRA~1/MICROS~1.0/VC/VCPACK~1:/usr/local/bin:/usr/ bin:/bin:/usr/X11R6/bin:/cygdrive/c/WINDOWS/system32:/cygdrive/c/WINDOWS:/cygdri ve/c/WINDOWS/System32/Wbem:/cygdrive/c/Mercurial:/cygdrive/g/jtreg/4.0/win32/bin > However, even with that fix, when I do make sanity the normal way the > exe isn't being built. And no matter what I try (echo, $(warning ...) I > can't get make to trace when I run make sanity the normal way. I wish I could say incremental builds worked well in OpenJDK7. In some areas of the code it works, but other areas are problematical. When I want to be sure, I use a 'big hammer' approach to start building with a clean slate: cd mkdir lose mv build lose \rm -rf lose . $HOME/openjdk.env.bash ../openjdk.build.bash My OpenJDK build using these scripts has already built as far as jdk/make/sun/rmi I put copies of my openjdk.env.bash and openjdk.build.bash files here: http://cr.openjdk.java.net/~tbell/OpenJDK-build-scripts/ You will need to modify these to suit the setup on your PC, but they should serve as a guide. I hope this helps. Feel free to contact me off the alias with your full build log if you need to. I will take a look at it. Tim From pete at a11ysoft.com Fri Oct 2 12:11:01 2009 From: pete at a11ysoft.com (Pete Brunet) Date: Fri, 02 Oct 2009 14:11:01 -0500 Subject: [Fwd: Re: Freetype version check failure - copy of DLL failed] In-Reply-To: <4AC64AE8.7030507@sun.com> References: <4AC62135.9090504@a11ysoft.com> <4AC64AE8.7030507@sun.com> Message-ID: <4AC65045.8020009@a11ysoft.com> Thanks Tim, >>No need to remake target `c:/OpenJDK/jdk7/build/windows-i586/btbins/freetype_versioncheck.exe'. >What is the output when you run that executable in an MS-DOS CMD window? The exe file doesn't exist as the result of running make sanity, but if I cd /cygdrive/c/OpenJDK/jdk7/jdk/make/tools/freetypecheck make then the exe does get created and if I then run the exe from a DOS command line it works fine. Here is what my PATH looks like: $ echo $PATH /usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/cygdrive/c/Program Files/Microsoft Visual Studio 9.0/Common7/IDE:/cygdrive/c/Program Files/Microsoft Visual Studio 9.0/VC/BIN:/cygdrive/c/Program Files/Microsoft Visual Studio 9.0/Common7/Tools:/ cygdrive/c/WINDOWS/Microsoft.NET/Framework/v3.5:/cygdrive/c/WINDOWS/Microsoft.NE T/Framework/v2.0.50727:/cygdrive/c/Program Files/Microsoft Visual Studio 9.0/VC/ VCPackages:/cygdrive/c/Program Files/Microsoft SDKs/Windows/v6.0A/bin:/cygdrive/ c/WINDOWS/system32:/cygdrive/c/WINDOWS:/cygdrive/c/WINDOWS/System32/Wbem:/cygdri ve/c/Program Files/Intel/WiFi/bin/:/cygdrive/c/Program Files/ATI Technologies/AT I.ACE/Core-Static:/cygdrive/c/Program Files/Common Files/Lenovo:/cygdrive/c/Prog ram Files/Common Files/Roxio Shared/10.0/DLLShared/:/cygdrive/c/Program Files/Co mmon Files/Roxio Shared/DLLShared/:/cygdrive/c/Program Files/ThinkPad/ConnectUti lities:/cygdrive/c/Program Files/Lenovo/Client Security Solution:/cygdrive/c/Pro gram Files/Microsoft SQL Server/90/Tools/binn/:/cygdrive/c/Program Files/doxygen /bin:/cygdrive/c/Program Files/Support Tools/:/cygdrive/c/utilities:/cygdrive/c/ Program Files/apache-ant-1.7.1:/cygdrive/c/Python26:/cygdrive/c/MinGW/bin:/cygdr ive/c/Program Files/KDiff3:/cygdrive/c/Program Files/QuickTime/QTSystem/ I'll have to cogitate on the rest of your note a bit later. Pete --- Tim Bell wrote: > Pete Brunet wrote: > >> I ran make -d sanity today and see the following. I don't know why it >> doesn't want to build freetype_versioncheck.exe. It doesn't exist. >> >> There is however a file named freetype_versioncheck.exe.manifest so to >> make sure that isn't a problem I commented out its build from >> freetypecheck/makefile and renamed it to >> freetype_versioncheck-OLD.exe.manifest in the btbins directory, but the >> debug make output looks the same after that test. >> > > sanity will need that .manifest file to run freetype_versioncheck.exe > > That was build bugID 6705913 "freetype_versioncheck.exe - Unable To Locate Component" > https://bugs.openjdk.java.net/show_bug.cgi?id=100101 > > (SNIP!) > > >> No need to remake target `c:/OpenJDK/jdk7/build/windows-i586/btbins/freetype_versioncheck.exe'. >> > > > What is the output when you run that executable in an MS-DOS CMD window? > > >> Tim, I went back to my original fixes (copy dll to lib and change the >> make to use freetype6.dll) then did the following: >> >> cd /cygdrive/c/OpenJDK/jdk7/jdk/make/tools/freetypecheck >> make clean >> make all >> >> and started getting a trace. I don't know if running from the >> freetypecheck directory is a valid thing to do, but when I do that I >> noticed that mt.exe is not found. In this (possibly invalid) invocation >> of make, $(MT) resolves to >> >> c:/PROGRA~1/MICROS~1.0/Common7/Tools/../../Vc/Bin/mt aka "C:\Program >> Files\Microsoft Visual Studio 9.0\VC\bin\mt" >> >> but on my system mt.exe is at >> >> C:\Program Files\Microsoft SDKs\Windows\v6.0A\bin\mt.exe >> >> If I change $(MT) to just mt so it's found via the PATH then the above >> build is OK. >> > > That is what my build is doing. $(CL) and $(MT) are both found on PATH, ahead > of the Cygwin bin directories. But I also set the ALT_ variables in my environment > and build scripts (see below). > > $ echo $PATH > /cygdrive/c/JDK16~1.0_0/bin:/cygdrive/c/PROGRA~1/MICROS~1.0/Common7/IDE:/cygdriv > e/c/PROGRA~1/MICROS~1.0/VC/BIN:/cygdrive/c/PROGRA~1/MICROS~1.0/Common7/Tools:/cy > gdrive/c/PROGRA~1/MICROS~2/Windows/v6.1/bin:/cygdrive/c/WINDOWS/MICROS~1.NET/FRA > MEW~1/V20~1.507:/cygdrive/c/PROGRA~1/MICROS~1.0/VC/VCPACK~1:/usr/local/bin:/usr/ > bin:/bin:/usr/X11R6/bin:/cygdrive/c/WINDOWS/system32:/cygdrive/c/WINDOWS:/cygdri > ve/c/WINDOWS/System32/Wbem:/cygdrive/c/Mercurial:/cygdrive/g/jtreg/4.0/win32/bin > > > >> However, even with that fix, when I do make sanity the normal way the >> exe isn't being built. And no matter what I try (echo, $(warning ...) I >> can't get make to trace when I run make sanity the normal way. >> > > I wish I could say incremental builds worked well in OpenJDK7. In some > areas of the code it works, but other areas are problematical. > > When I want to be sure, I use a 'big hammer' approach to start building > with a clean slate: > > cd > mkdir lose > mv build lose > \rm -rf lose > . $HOME/openjdk.env.bash > ../openjdk.build.bash > > My OpenJDK build using these scripts has already built as far > as jdk/make/sun/rmi > > > I put copies of my openjdk.env.bash and openjdk.build.bash files here: > > http://cr.openjdk.java.net/~tbell/OpenJDK-build-scripts/ > > You will need to modify these to suit the setup on your PC, but they > should serve as a guide. > > I hope this helps. > > Feel free to contact me off the alias with your full build log > if you need to. I will take a look at it. > > Tim > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/build-dev/attachments/20091002/95434269/attachment.html From Tim.Bell at Sun.COM Fri Oct 2 12:44:32 2009 From: Tim.Bell at Sun.COM (Tim Bell) Date: Fri, 02 Oct 2009 12:44:32 -0700 Subject: [Fwd: Re: Freetype version check failure - copy of DLL failed] In-Reply-To: <4AC65045.8020009@a11ysoft.com> References: <4AC62135.9090504@a11ysoft.com> <4AC64AE8.7030507@sun.com> <4AC65045.8020009@a11ysoft.com> Message-ID: <4AC65820.1020207@sun.com> Pete Brunet wrote: > Here is what my PATH looks like: > $ echo $PATH > /usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/cygdrive/c/Program > Files/Microsoft > Visual Studio 9.0/Common7/IDE:/cygdrive/c/Program Files/Microsoft Visual > Studio > 9.0/VC/BIN:/cygdrive/c/Program Files/Microsoft Visual Studio > 9.0/Common7/Tools:/ > cygdrive/c/WINDOWS/Microsoft.NET/Framework/v3.5:/cygdrive/c/WINDOWS/Microsoft.NE > T/Framework/v2.0.50727:/cygdrive/c/Program Files/Microsoft Visual Studio > 9.0/VC/ > VCPackages:/cygdrive/c/Program Files/Microsoft > SDKs/Windows/v6.0A/bin:/cygdrive/ > c/WINDOWS/system32:/cygdrive/c/WINDOWS:/cygdrive/c/WINDOWS/System32/Wbem:/cygdri > ve/c/Program Files/Intel/WiFi/bin/:/cygdrive/c/Program Files/ATI > Technologies/AT > I.ACE/Core-Static:/cygdrive/c/Program Files/Common > Files/Lenovo:/cygdrive/c/Prog > ram Files/Common Files/Roxio Shared/10.0/DLLShared/:/cygdrive/c/Program > Files/Co > mmon Files/Roxio Shared/DLLShared/:/cygdrive/c/Program > Files/ThinkPad/ConnectUti > lities:/cygdrive/c/Program Files/Lenovo/Client Security > Solution:/cygdrive/c/Pro > gram Files/Microsoft SQL Server/90/Tools/binn/:/cygdrive/c/Program > Files/doxygen > /bin:/cygdrive/c/Program Files/Support > Tools/:/cygdrive/c/utilities:/cygdrive/c/ > Program > Files/apache-ant-1.7.1:/cygdrive/c/Python26:/cygdrive/c/MinGW/bin:/cygdr > ive/c/Program Files/KDiff3:/cygdrive/c/Program Files/QuickTime/QTSystem/ > > I'll have to cogitate on the rest of your note a bit later. OK. I am surprised your build works at all since you have the Cygwin /usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin directories at the start of your PATH. We put the bootstrap JDK and the Microsoft directories first in PATH, followed by the Cygwin directories. In particular, the Cygwin link command will not work for us - we need the Microsoft link.exe from $ALT_COMPILER_PATH Having said that, the JDK Makefiles try to run with a minimal PATH and get what they need from ALT_foo variables: $ env | grep ALT_ ALT_DEVTOOLS_DIR=/usr/bin ALT_COMPILER_PATH=C:/PROGRA~1/MICROS~1.0/VC/bin/ ALT_MSDEVTOOLS_PATH=/cygdrive/c/PROGRA~1/MICROS~2/Windows/v6.1/Bin ALT_DXSDK_PATH=/cygdrive/c/PROGRA~1/MICROS~1.0SD ALT_BOOTDIR=C:/jdk1.6.0_03 ALT_MSVCRNN_DLL_PATH=/cygdrive/c/PROGRA~1/MICROS~1.0/VC/redist/x86/MICROS~1.CRT $ grep ALT_ ../openjdk.build.bash export ALT_FREETYPE_LIB_PATH=c:/devtools/windows/freetype-i586/lib export ALT_FREETYPE_HEADERS_PATH=c:/devtools/windows/freetype-i586/include export ALT_JDK_IMPORT_PATH=g:/jdk1.7.0-b73 export ALT_BUILD_JDK_IMPORT_PATH=g:/jdk1.7.0-b73 export ALT_JDK_DEVTOOLS_DIR=/cygdrive/c/devtools Tim From pete at a11ysoft.com Fri Oct 2 13:35:14 2009 From: pete at a11ysoft.com (Pete Brunet) Date: Fri, 02 Oct 2009 15:35:14 -0500 Subject: [Fwd: Re: Freetype version check failure - copy of DLL failed] In-Reply-To: <4AC65820.1020207@sun.com> References: <4AC62135.9090504@a11ysoft.com> <4AC64AE8.7030507@sun.com> <4AC65045.8020009@a11ysoft.com> <4AC65820.1020207@sun.com> Message-ID: <4AC66402.9050609@a11ysoft.com> Tim, I remember some instructions about modifying the path that but I didn't know how to do it so I renamed cygwin's link so it wouldn't get called. I have a bat file in my c:\ a follows: cd C:\Program Files\Microsoft Visual Studio 9.0\Common7\Tools call vsvars32 cd c:\cygwin\bin set CLASSPATH= bash --login -i and then I cd /cygdrive/c/OpenJDK/jdk7 make sanity I assume vsvars32 is prepending all the VS9/SDK stuff and then bash login is prepending the cygwin stuff. How do you set up the path? I didn't see that in any instructions I read. Is the linker the only issue? Pete ---- Tim Bell wrote: > Pete Brunet wrote: > > >> Here is what my PATH looks like: >> $ echo $PATH >> /usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/cygdrive/c/Program >> Files/Microsoft >> Visual Studio 9.0/Common7/IDE:/cygdrive/c/Program Files/Microsoft Visual >> Studio >> 9.0/VC/BIN:/cygdrive/c/Program Files/Microsoft Visual Studio >> 9.0/Common7/Tools:/ >> cygdrive/c/WINDOWS/Microsoft.NET/Framework/v3.5:/cygdrive/c/WINDOWS/Microsoft.NE >> T/Framework/v2.0.50727:/cygdrive/c/Program Files/Microsoft Visual Studio >> 9.0/VC/ >> VCPackages:/cygdrive/c/Program Files/Microsoft >> SDKs/Windows/v6.0A/bin:/cygdrive/ >> c/WINDOWS/system32:/cygdrive/c/WINDOWS:/cygdrive/c/WINDOWS/System32/Wbem:/cygdri >> ve/c/Program Files/Intel/WiFi/bin/:/cygdrive/c/Program Files/ATI >> Technologies/AT >> I.ACE/Core-Static:/cygdrive/c/Program Files/Common >> Files/Lenovo:/cygdrive/c/Prog >> ram Files/Common Files/Roxio Shared/10.0/DLLShared/:/cygdrive/c/Program >> Files/Co >> mmon Files/Roxio Shared/DLLShared/:/cygdrive/c/Program >> Files/ThinkPad/ConnectUti >> lities:/cygdrive/c/Program Files/Lenovo/Client Security >> Solution:/cygdrive/c/Pro >> gram Files/Microsoft SQL Server/90/Tools/binn/:/cygdrive/c/Program >> Files/doxygen >> /bin:/cygdrive/c/Program Files/Support >> Tools/:/cygdrive/c/utilities:/cygdrive/c/ >> Program >> Files/apache-ant-1.7.1:/cygdrive/c/Python26:/cygdrive/c/MinGW/bin:/cygdr >> ive/c/Program Files/KDiff3:/cygdrive/c/Program Files/QuickTime/QTSystem/ >> >> I'll have to cogitate on the rest of your note a bit later. >> > > OK. > > I am surprised your build works at all since you have the Cygwin > /usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin directories at the > start of your PATH. We put the bootstrap JDK and the Microsoft > directories first in PATH, followed by the Cygwin directories. > In particular, the Cygwin link command will not work for us - > we need the Microsoft link.exe from $ALT_COMPILER_PATH > > Having said that, the JDK Makefiles try to run with a minimal > PATH and get what they need from ALT_foo variables: > > $ env | grep ALT_ > ALT_DEVTOOLS_DIR=/usr/bin > ALT_COMPILER_PATH=C:/PROGRA~1/MICROS~1.0/VC/bin/ > ALT_MSDEVTOOLS_PATH=/cygdrive/c/PROGRA~1/MICROS~2/Windows/v6.1/Bin > ALT_DXSDK_PATH=/cygdrive/c/PROGRA~1/MICROS~1.0SD > ALT_BOOTDIR=C:/jdk1.6.0_03 > ALT_MSVCRNN_DLL_PATH=/cygdrive/c/PROGRA~1/MICROS~1.0/VC/redist/x86/MICROS~1.CRT > > $ grep ALT_ ../openjdk.build.bash > export ALT_FREETYPE_LIB_PATH=c:/devtools/windows/freetype-i586/lib > export ALT_FREETYPE_HEADERS_PATH=c:/devtools/windows/freetype-i586/include > export ALT_JDK_IMPORT_PATH=g:/jdk1.7.0-b73 > export ALT_BUILD_JDK_IMPORT_PATH=g:/jdk1.7.0-b73 > export ALT_JDK_DEVTOOLS_DIR=/cygdrive/c/devtools > > > Tim > > > > -- *Pete Brunet* a11ysoft - Accessibility Architecture and Development (512) 238-6967 (work), (512) 689-4155 (cell) Skype: pete.brunet IM: ptbrunet (AOL, Google), ptbrunet at live.com (MSN) http://www.a11ysoft.com/about/ Ionosphere: WS4G -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/build-dev/attachments/20091002/fe20e04f/attachment.html From martinrb at google.com Fri Oct 2 17:41:44 2009 From: martinrb at google.com (Martin Buchholz) Date: Fri, 2 Oct 2009 17:41:44 -0700 Subject: JDK 7 build 73 is available at the openjdk.java.net website In-Reply-To: <4AC67DBB.7060209@sun.com> References: <4AC67DBB.7060209@sun.com> Message-ID: <1ccfd1c10910021741w366b51bte86d2fea99267e72@mail.gmail.com> Hi, I tried building jdk7-b73 on Ubuntu dapper, and had it fail with BUILD FAILED .../jaxp/build-defs.xml:66: Could not create task or type of type: replaceregexp. Ant could not find the task or a class this task relies upon. ---- This problem does not happen on Ubuntu hardy. It appears to be fixed by installing the "ant-optional" debian package, in addition to "ant". But this is not obvious - it might be worth adding sanity checks and/or documentation. Martin On Fri, Oct 2, 2009 at 15:24, Michael Wilkerson wrote: > The OpenJDK source is available at: > http://hg.openjdk.java.net/jdk7/jdk7 > http://hg.openjdk.java.net/jdk7/jdk7/rev/3ac6dcf78232 > > The OpenJDK source binary plugs for the promoted JDK 7 build 73 are > available under the openjdk http://openjdk.java.net website under Source > Code (direct link to bundles: http://download.java.net/openjdk/jdk7) > > Summary of changes: > http://download.java.net/jdk7/changes/jdk7-b73.html > > > -Michael > From Kelly.Ohair at Sun.COM Mon Oct 5 16:35:11 2009 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Mon, 05 Oct 2009 16:35:11 -0700 Subject: Reducing build time by minimizing fork/exec and file system visits Message-ID: <4ACA82AF.8020301@sun.com> This is kind of an update on the bug that started out as: 6875240: Reduce Makefile build time by limiting repeated exec's (mostly for cygwin building) But that bug has been closed as a fix to just the corba repository Makefiles. So if and when these changes are pushed in, the bugid will be different, or it may appear as multiple bugids and changesets. This webrev: http://cr.openjdk.java.net/~ohair/openjdk7/jdk7-build-cygwin-6875240/webrev/ Is my current state for the jdk repository Makefiles. The fork/exec reduction is pretty significant, over 50% reduction as measured on Solaris builds, but the goal of significantly improving the overall Windows CYGWIN build time is less fruitful, maybe a 10-15% reduction in build time. This is not at all the same results as I saw with the corba repository makefile changes. I was going to post some build time data, but it's hard to be accurate, with Windows in particular. The environment variables are effectively being used as a sort of cache of information with these changes. Plus the number of 'find' commands has been limited. The above webrev includes a few diversions to the primary change: * All source files that were template java files, used to generate java source files were renamed *.java-template. This file suffix change simplifies much of the Makefile logic and could probably be done as a separate changeset. * Use of the make syntax $(eval) required an upgrade to make 3.81, and this upgrade brought out a problem with make 3.81 and MKS shells regarding escaped quotes on compile lines. So you will see changes from things like -DX="\"Y\"" to -DX='"Y"', to avoid the problem, but that makes it the same for all platforms, a good thing. The old make 3.78.1 (or < 3.81) and MKS shells seem happy with either way. These changes could probably be done with a separate changeset too. * Use of AUTO_JAVA_PRUNE had to become more specific because of the use of the make $(filter*) functions rather than SED and GREPs. This makes the act of pruning more explicit. I'm not sure where to go from here, it's obvious that the low hanging fruit that I thought would help here is not helping that much. At this point, internally, at least for Windows X64, we will probably continue to use MKS, perhaps just build with CYGWIN on 32bit Windows? Advice, ideas, or suggestions are welcome. -kto From gnu_andrew at member.fsf.org Wed Oct 7 14:24:11 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Wed, 7 Oct 2009 22:24:11 +0100 Subject: 6856630: Restructure jaxp/jaxws repository In-Reply-To: <4AB80C37.6000108@sun.com> References: <4AB80C37.6000108@sun.com> Message-ID: <17c6771e0910071424n3b12402bg80ed2f56210fb6e3@mail.gmail.com> 2009/9/22 Kelly O'Hair : > > This 6856630 change has been integrated into the build > forest jaxp and jaxws repositories: > > http://hg.openjdk.java.net/jdk7/build/jaxws/rev/ae2bec597586 > http://hg.openjdk.java.net/jdk7/build/jaxp/rev/534e23823a1b > > Assuming we get successful test builds of the build forest, these > changes will get integrated into the jdk7 master forest. > > Notes: > ?* The jaxws (and jaf) and jaxp sources have been extracted and > ? ?put into separate source zip files. These zip files represent > ? ?the source deliveries into the jdk7 project. Selection of > ? ?the bundles is determined by the properties in the files > ? ?jax*/jax*.properties and jax*/build-defs.xml. > ? ?The current 3 source drop bundles are: > ? ? ?jdk7-jaf-2009_08_28.zip > ? ? ?jdk7-jaxp-2009_08_28.zip > ? ? ?jdk7-jaxws-2009_08_28.zip > ? ?If not found in the /java/devtools/share/jdk7-drops directory, > ? ?the ant scripts will look for them at > ? ? ?http://kenai.com/projects/jdk7-drops/downloads > ? ?a temporary site for now until the JAX* teams engage. > > ?* The original jaxp/src and jaxws/src files are still there, > ? ?but should not be used unless the drop source bundles are > ? ?unavailable (currently the drop bundles contain the exact > ? ?same files). A warning will be issued if they are used. > ? ?Eventually the original jaxp/src and jaxws/src files will > ? ?be deleted from the jdk7 repositories. > > ?* 'ant source' or 'cd make && make source' will get the drop > ? ?bundles and populate the drop source area. But this should > ? ?happen automatically. > > Please ask questions, this is kind of a big change and anything > can go wrong, please let me know if there are problems. > > -kto > > Hi Kelly, This patch is now in b73 and I'm trying to get IcedTea7 to build with it. How do I specify the location of the zips to use? Thanks, -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From gbenson at redhat.com Fri Oct 9 04:58:39 2009 From: gbenson at redhat.com (Gary Benson) Date: Fri, 9 Oct 2009 12:58:39 +0100 Subject: Review request: Zero buildsystem changes Message-ID: <20091009115839.GC3506@redhat.com> Hi all, Zero is an interpreter-only port of HotSpot that uses no assembler and can trivially be built on any Linux system. The following two webrevs add Zero support to OpenJDK: http://cr.openjdk.java.net/~gbenson/zero-11-build/ http://cr.openjdk.java.net/~gbenson/zero-11-hotspot/ The bulk of the changes are in the zero-11-hotspot webrev, which has been through a couple of review cycles and is (hopefully!) about to be tested with JPRT and pushed. The zero-11-build webrev contains a small number of changes, mostly to makefiles, that are required in order to build OpenJDK with Zero. Is this the right list to review these changes? Cheers, Gary -- http://gbenson.net/ -------------- next part -------------- Build Instructions ================== There are a number of environment variables that need setting before running make, but if you are using jdk/make/jdk_generic_profile.sh to set up your environment then you only need to set one, and a build can be as simple as: export ZERO_BUILD=true . jdk/make/jdk_generic_profile.sh gmake sanity && gmake The mandatory environment variable does the following: ZERO_BUILD Setting ZERO_BUILD to "true" will cause the Zero interpreter to be used. If ZERO_BUILD is unset, or set to any other value than "true", the standard, platform-specific interpreter will be used. Of the other environment variables the following are required when ZERO_BUILD is set to "true". These are set by jdk/make/jdk_generic_profile.sh based on the result of uname -m: ZERO_LIBARCH This is the name of the architecture-specific subdirectory under $JAVA_HOME/jre/lib. Typically this will be the same as the output of uname -m, although there are some exceptions: "amd64" instead of "x86_64", for example, and "i386" instead of "i686". ZERO_ARCHDEF The value of ZERO_ARCHDEF will be passed to the C++ compiler using -D${ZERO_ARCHDEF} to allow conditionalized platform-specific code. This is typically set to ZERO_LIBARCH converted to uppercase but, again, there are exceptions. "i386" becomes "IA32", to match what HotSpot already does, and on platforms with both 32- and 64-bit variants ZERO_ARCHDEF corresponds to the 32-bit version, so both ppc and ppc64 have ZERO_ARCHDEF set to "PPC". ZERO_ENDIANNESS This is set to "little" or "big". ARCH_DATA_MODEL This is set to "32" or "64". ZERO_ARCHFLAG This is a flag that will be passed to the C++ compiler and to the linker to instruct them to generate code for the particular platform. This is required for platforms with both 32- and 64-bit variants where the compiler needs to be told which variant to build for. ZERO_ARCHFLAG will typically be set to "-m32" or "-m64", except on 31-bit zSeries where it will be set to "-m31". Zero uses one external library, libffi, for JNI method invocation. The following two variables are used to tell the compiler and linker how to find libffi. These can be set by the user, but if left unset then jdk/make/jdk_generic_profile.sh will attempt to set them using pkg-config or, failing that, by supplying defaults pointing to the standard locations: LIBFFI_CFLAGS Flags to be passed to the C++ compiler to build against libffi. If unset (and pkg-config is not installed, or if libffi is not built with pkg-config) then this defaults to "". LIBFFI_LIBS Flags to be passed to the linker to link against libffi. If unset (and pkg-config is not installed, or if libffi is not built with pkg-config) then this defaults to "-lffi". From gnu_andrew at member.fsf.org Fri Oct 9 07:26:38 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Fri, 9 Oct 2009 15:26:38 +0100 Subject: 6856630: Restructure jaxp/jaxws repository In-Reply-To: <17c6771e0910071424n3b12402bg80ed2f56210fb6e3@mail.gmail.com> References: <4AB80C37.6000108@sun.com> <17c6771e0910071424n3b12402bg80ed2f56210fb6e3@mail.gmail.com> Message-ID: <17c6771e0910090726r14a12ee4wadb5cc4e9fd141@mail.gmail.com> 2009/10/7 Andrew John Hughes : > 2009/9/22 Kelly O'Hair : >> >> This 6856630 change has been integrated into the build >> forest jaxp and jaxws repositories: >> >> http://hg.openjdk.java.net/jdk7/build/jaxws/rev/ae2bec597586 >> http://hg.openjdk.java.net/jdk7/build/jaxp/rev/534e23823a1b >> >> Assuming we get successful test builds of the build forest, these >> changes will get integrated into the jdk7 master forest. >> >> Notes: >> ?* The jaxws (and jaf) and jaxp sources have been extracted and >> ? ?put into separate source zip files. These zip files represent >> ? ?the source deliveries into the jdk7 project. Selection of >> ? ?the bundles is determined by the properties in the files >> ? ?jax*/jax*.properties and jax*/build-defs.xml. >> ? ?The current 3 source drop bundles are: >> ? ? ?jdk7-jaf-2009_08_28.zip >> ? ? ?jdk7-jaxp-2009_08_28.zip >> ? ? ?jdk7-jaxws-2009_08_28.zip >> ? ?If not found in the /java/devtools/share/jdk7-drops directory, >> ? ?the ant scripts will look for them at >> ? ? ?http://kenai.com/projects/jdk7-drops/downloads >> ? ?a temporary site for now until the JAX* teams engage. >> >> ?* The original jaxp/src and jaxws/src files are still there, >> ? ?but should not be used unless the drop source bundles are >> ? ?unavailable (currently the drop bundles contain the exact >> ? ?same files). A warning will be issued if they are used. >> ? ?Eventually the original jaxp/src and jaxws/src files will >> ? ?be deleted from the jdk7 repositories. >> >> ?* 'ant source' or 'cd make && make source' will get the drop >> ? ?bundles and populate the drop source area. But this should >> ? ?happen automatically. >> >> Please ask questions, this is kind of a big change and anything >> can go wrong, please let me know if there are problems. >> >> -kto >> >> > > Hi Kelly, > > This patch is now in b73 and I'm trying to get IcedTea7 to build with > it. ?How do I specify the location of the zips to use? > > Thanks, > -- > Andrew :-) > > Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > Support Free Java! > Contribute to GNU Classpath and the OpenJDK > http://www.gnu.org/software/classpath > http://openjdk.java.net > > PGP Key: 94EFD9D8 (http://subkeys.pgp.net) > Fingerprint: F8EF F1EA 401E 2E60 15FA ?7927 142C 2591 94EF D9D8 > I found a number of issues with the current version: * The drop zips are expected to be in a share/jdk7-drops subdirectory of the devtools directory. This doesn't really work outside Sun's internal setup. I've added support for ALT_DROP_DIR which can be used to specify an exact path to the zips. If this is not set, the old devtools behaviour is used. * The zips are being downloaded and extracted in the source directory, which could be read only. I've changed this so they are written to the build directory like everything else. The webrev for these changes is here: http://cr.openjdk.java.net/~andrew/drops/webrev.01/ I've committed this to IcedTea already. Does this look ok for build also? -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From Kelly.Ohair at Sun.COM Fri Oct 9 10:11:40 2009 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Fri, 09 Oct 2009 10:11:40 -0700 Subject: 6856630: Restructure jaxp/jaxws repository In-Reply-To: <17c6771e0910090726r14a12ee4wadb5cc4e9fd141@mail.gmail.com> References: <4AB80C37.6000108@sun.com> <17c6771e0910071424n3b12402bg80ed2f56210fb6e3@mail.gmail.com> <17c6771e0910090726r14a12ee4wadb5cc4e9fd141@mail.gmail.com> Message-ID: <4ACF6ECC.7070407@sun.com> I can't see the webrev right now due to the server issues. As soon as I can look at it I'll let you know. At first I wondered if it should be named ALT_JDK7_DROP_DIR, but then I thought not, and I should have used jdk-drops instead of jdk7-drops, getting the version out of the directory. The file names should make them unique enough. So your change may be fine as is, as soon as I can see it. ;^) And I apologize for not creating an ALT_* setting before... my oversight. -kto Andrew John Hughes wrote: > 2009/10/7 Andrew John Hughes : >> 2009/9/22 Kelly O'Hair : >>> This 6856630 change has been integrated into the build >>> forest jaxp and jaxws repositories: >>> >>> http://hg.openjdk.java.net/jdk7/build/jaxws/rev/ae2bec597586 >>> http://hg.openjdk.java.net/jdk7/build/jaxp/rev/534e23823a1b >>> >>> Assuming we get successful test builds of the build forest, these >>> changes will get integrated into the jdk7 master forest. >>> >>> Notes: >>> * The jaxws (and jaf) and jaxp sources have been extracted and >>> put into separate source zip files. These zip files represent >>> the source deliveries into the jdk7 project. Selection of >>> the bundles is determined by the properties in the files >>> jax*/jax*.properties and jax*/build-defs.xml. >>> The current 3 source drop bundles are: >>> jdk7-jaf-2009_08_28.zip >>> jdk7-jaxp-2009_08_28.zip >>> jdk7-jaxws-2009_08_28.zip >>> If not found in the /java/devtools/share/jdk7-drops directory, >>> the ant scripts will look for them at >>> http://kenai.com/projects/jdk7-drops/downloads >>> a temporary site for now until the JAX* teams engage. >>> >>> * The original jaxp/src and jaxws/src files are still there, >>> but should not be used unless the drop source bundles are >>> unavailable (currently the drop bundles contain the exact >>> same files). A warning will be issued if they are used. >>> Eventually the original jaxp/src and jaxws/src files will >>> be deleted from the jdk7 repositories. >>> >>> * 'ant source' or 'cd make && make source' will get the drop >>> bundles and populate the drop source area. But this should >>> happen automatically. >>> >>> Please ask questions, this is kind of a big change and anything >>> can go wrong, please let me know if there are problems. >>> >>> -kto >>> >>> >> Hi Kelly, >> >> This patch is now in b73 and I'm trying to get IcedTea7 to build with >> it. How do I specify the location of the zips to use? >> >> Thanks, >> -- >> Andrew :-) >> >> Free Java Software Engineer >> Red Hat, Inc. (http://www.redhat.com) >> >> Support Free Java! >> Contribute to GNU Classpath and the OpenJDK >> http://www.gnu.org/software/classpath >> http://openjdk.java.net >> >> PGP Key: 94EFD9D8 (http://subkeys.pgp.net) >> Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 >> > > I found a number of issues with the current version: > > * The drop zips are expected to be in a share/jdk7-drops subdirectory > of the devtools directory. This doesn't really work outside Sun's > internal setup. I've added support for ALT_DROP_DIR which can be used > to specify an exact path to the zips. If this is not set, the old > devtools behaviour is used. > * The zips are being downloaded and extracted in the source directory, > which could be read only. I've changed this so they are written to > the build directory like everything else. > > The webrev for these changes is here: > > http://cr.openjdk.java.net/~andrew/drops/webrev.01/ > > I've committed this to IcedTea already. Does this look ok for build also? From Tim.Bell at Sun.COM Fri Oct 9 15:08:20 2009 From: Tim.Bell at Sun.COM (Tim Bell) Date: Fri, 09 Oct 2009 15:08:20 -0700 Subject: 6856630: Restructure jaxp/jaxws repository In-Reply-To: <4ACF6ECC.7070407@sun.com> References: <4AB80C37.6000108@sun.com> <17c6771e0910071424n3b12402bg80ed2f56210fb6e3@mail.gmail.com> <17c6771e0910090726r14a12ee4wadb5cc4e9fd141@mail.gmail.com> <4ACF6ECC.7070407@sun.com> Message-ID: <4ACFB454.3090902@sun.com> Kelly O'Hair wrote: > I can't see the webrev right now due to the server issues. % date Fri Oct 9 15:08:00 PDT 2009 The fact that we all got this email, and that I can load up http://cr.openjdk.java.net/~andrew/drops/webrev.01/ Makes me hopeful that the .ojn servers are back online. But - your mileage may vary. We do not have an official 'all clear' message yet. Tim > As soon as I can look at it I'll let you know. > > At first I wondered if it should be named ALT_JDK7_DROP_DIR, > but then I thought not, and I should have used jdk-drops > instead of jdk7-drops, getting the version out of the directory. > The file names should make them unique enough. > > So your change may be fine as is, as soon as I can see it. ;^) > > And I apologize for not creating an ALT_* setting before... my oversight. > > -kto > > Andrew John Hughes wrote: >> 2009/10/7 Andrew John Hughes : >>> 2009/9/22 Kelly O'Hair : >>>> This 6856630 change has been integrated into the build >>>> forest jaxp and jaxws repositories: >>>> >>>> http://hg.openjdk.java.net/jdk7/build/jaxws/rev/ae2bec597586 >>>> http://hg.openjdk.java.net/jdk7/build/jaxp/rev/534e23823a1b >>>> >>>> Assuming we get successful test builds of the build forest, these >>>> changes will get integrated into the jdk7 master forest. >>>> >>>> Notes: >>>> * The jaxws (and jaf) and jaxp sources have been extracted and >>>> put into separate source zip files. These zip files represent >>>> the source deliveries into the jdk7 project. Selection of >>>> the bundles is determined by the properties in the files >>>> jax*/jax*.properties and jax*/build-defs.xml. >>>> The current 3 source drop bundles are: >>>> jdk7-jaf-2009_08_28.zip >>>> jdk7-jaxp-2009_08_28.zip >>>> jdk7-jaxws-2009_08_28.zip >>>> If not found in the /java/devtools/share/jdk7-drops directory, >>>> the ant scripts will look for them at >>>> http://kenai.com/projects/jdk7-drops/downloads >>>> a temporary site for now until the JAX* teams engage. >>>> >>>> * The original jaxp/src and jaxws/src files are still there, >>>> but should not be used unless the drop source bundles are >>>> unavailable (currently the drop bundles contain the exact >>>> same files). A warning will be issued if they are used. >>>> Eventually the original jaxp/src and jaxws/src files will >>>> be deleted from the jdk7 repositories. >>>> >>>> * 'ant source' or 'cd make && make source' will get the drop >>>> bundles and populate the drop source area. But this should >>>> happen automatically. >>>> >>>> Please ask questions, this is kind of a big change and anything >>>> can go wrong, please let me know if there are problems. >>>> >>>> -kto >>>> >>>> >>> Hi Kelly, >>> >>> This patch is now in b73 and I'm trying to get IcedTea7 to build with >>> it. How do I specify the location of the zips to use? >>> >>> Thanks, >>> -- >>> Andrew :-) >>> >>> Free Java Software Engineer >>> Red Hat, Inc. (http://www.redhat.com) >>> >>> Support Free Java! >>> Contribute to GNU Classpath and the OpenJDK >>> http://www.gnu.org/software/classpath >>> http://openjdk.java.net >>> >>> PGP Key: 94EFD9D8 (http://subkeys.pgp.net) >>> Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 >>> >> I found a number of issues with the current version: >> >> * The drop zips are expected to be in a share/jdk7-drops subdirectory >> of the devtools directory. This doesn't really work outside Sun's >> internal setup. I've added support for ALT_DROP_DIR which can be used >> to specify an exact path to the zips. If this is not set, the old >> devtools behaviour is used. >> * The zips are being downloaded and extracted in the source directory, >> which could be read only. I've changed this so they are written to >> the build directory like everything else. >> >> The webrev for these changes is here: >> >> http://cr.openjdk.java.net/~andrew/drops/webrev.01/ >> >> I've committed this to IcedTea already. Does this look ok for build also? From Kelly.Ohair at Sun.COM Sun Oct 11 17:35:31 2009 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Sun, 11 Oct 2009 17:35:31 -0700 Subject: Need reviewer Message-ID: <4AD279D3.8070800@sun.com> 6888701: Change all template java source files to a .java.template file suffix http://cr.openjdk.java.net/~ohair/openjdk7/jdk7-build-template-6888701/webrev/ -kto From Kelly.Ohair at Sun.COM Sun Oct 11 17:37:35 2009 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Sun, 11 Oct 2009 17:37:35 -0700 Subject: Need reviewer - Fixing -D quotes Message-ID: <4AD27A4F.8020408@sun.com> 6888709: Change use of -DX=\""Y\"" to -DX='"Y"', consistently for all platforms http://cr.openjdk.java.net/~ohair/openjdk7/jdk7-build-quotes-6888709/webrev/ -kto From Jonathan.Gibbons at Sun.COM Sun Oct 11 18:53:42 2009 From: Jonathan.Gibbons at Sun.COM (Jonathan Gibbons) Date: Sun, 11 Oct 2009 18:53:42 -0700 Subject: Need reviewer In-Reply-To: <4AD279D3.8070800@sun.com> References: <4AD279D3.8070800@sun.com> Message-ID: <4AD28C26.5020502@sun.com> Kelly O'Hair wrote: > > 6888701: Change all template java source files to a .java.template > file suffix > > http://cr.openjdk.java.net/~ohair/openjdk7/jdk7-build-template-6888701/webrev/ > > > -kto Looks good to me -- but I think you should get approval from the owners of the src/* files as well. -- Jon From Jonathan.Gibbons at Sun.COM Sun Oct 11 18:56:36 2009 From: Jonathan.Gibbons at Sun.COM (Jonathan Gibbons) Date: Sun, 11 Oct 2009 18:56:36 -0700 Subject: Need reviewer - Fixing -D quotes In-Reply-To: <4AD27A4F.8020408@sun.com> References: <4AD27A4F.8020408@sun.com> Message-ID: <4AD28CD4.8090000@sun.com> Kelly O'Hair wrote: > > 6888709: Change use of -DX=\""Y\"" to -DX='"Y"', consistently for all > platforms > > http://cr.openjdk.java.net/~ohair/openjdk7/jdk7-build-quotes-6888709/webrev/ > > > -kto For the record, you changed some quoting of { } as well, but still looks good to me. -- Jon From mr at sun.com Sun Oct 11 22:26:37 2009 From: mr at sun.com (Mark Reinhold) Date: Sun, 11 Oct 2009 22:26:37 -0700 Subject: Need reviewer In-Reply-To: kelly.ohair@sun.com; Sun, 11 Oct 2009 17:35:31 PDT; <4AD279D3.8070800@sun.com> Message-ID: <20091012052637.71AA54D2@eggemoggin.niobe.net> > Date: Sun, 11 Oct 2009 17:35:31 -0700 > From: kelly.ohair at sun.com > 6888701: Change all template java source files to a .java.template file suffix > > http://cr.openjdk.java.net/~ohair/openjdk7/jdk7-build-template-6888701/webrev/ Most of the files you are renaming in this change are in NIO, and the names of those files were carefully chosen so as to be invalid Java class names -- they all contain at least one dash character. This approach has the advantage that when you visit the files in an editor or IDE they're treated as Java source files without any further effort. This is a feature, not a bug as claimed in 6888701. I'd like to understand more about the complications in Makefile logic claimed in 6888701. If this is such a problem then why are we just now getting around to fixing it? - Mark From Jonathan.Gibbons at sun.com Mon Oct 12 07:35:25 2009 From: Jonathan.Gibbons at sun.com (Jonathan Gibbons) Date: Mon, 12 Oct 2009 07:35:25 -0700 Subject: Need reviewer In-Reply-To: <20091012052637.71AA54D2@eggemoggin.niobe.net> References: <20091012052637.71AA54D2@eggemoggin.niobe.net> Message-ID: <4AD33EAD.90504@sun.com> I doubt this is driving Kelly's work, but I note that with exotic identifiers added in JSR292, any JVMS name is a legal Java identifier. Thus these files have potentially valid class names. The interaction with an IDE can be inconvenient, since the IDE is likely to handle these files incorrectly. langtools did this cleanup quite a while back for this reason. -- Jon Mark Reinhold wrote: >> Date: Sun, 11 Oct 2009 17:35:31 -0700 >> From: kelly.ohair at sun.com >> > > >> 6888701: Change all template java source files to a .java.template file suffix >> >> http://cr.openjdk.java.net/~ohair/openjdk7/jdk7-build-template-6888701/webrev/ >> > > Most of the files you are renaming in this change are in NIO, and the > names of those files were carefully chosen so as to be invalid Java > class names -- they all contain at least one dash character. > > This approach has the advantage that when you visit the files in an > editor or IDE they're treated as Java source files without any further > effort. This is a feature, not a bug as claimed in 6888701. > > I'd like to understand more about the complications in Makefile logic > claimed in 6888701. If this is such a problem then why are we just > now getting around to fixing it? > > - Mark > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/build-dev/attachments/20091012/16e03ee8/attachment.html From Kelly.Ohair at Sun.COM Mon Oct 12 09:12:06 2009 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Mon, 12 Oct 2009 09:12:06 -0700 Subject: Need reviewer In-Reply-To: <20091012052637.71AA54D2@eggemoggin.niobe.net> References: <20091012052637.71AA54D2@eggemoggin.niobe.net> Message-ID: <4AD35556.1070507@sun.com> Mark Reinhold wrote: >> Date: Sun, 11 Oct 2009 17:35:31 -0700 >> From: kelly.ohair at sun.com > >> 6888701: Change all template java source files to a .java.template file suffix >> >> http://cr.openjdk.java.net/~ohair/openjdk7/jdk7-build-template-6888701/webrev/ > > Most of the files you are renaming in this change are in NIO, and the > names of those files were carefully chosen so as to be invalid Java > class names -- they all contain at least one dash character. > > This approach has the advantage that when you visit the files in an > editor or IDE they're treated as Java source files without any further > effort. This is a feature, not a bug as claimed in 6888701. > > I'd like to understand more about the complications in Makefile logic > claimed in 6888701. If this is such a problem then why are we just > now getting around to fixing it? I have been trying to change some of the Makefiles to use the GNU make functions and everything is easier when knowing that a file ending in .java is really input for javac. Filtering is easier. We have at least 3 conventions being used for processing java source files: *-template.java, *X-*.java, and *.java.template. By far the easiest one to deal with in build scripts (make and ant) is the *.template convention. I'm just trying to normalize this to one convention that is the easiest to deal with in build scripts and for IDEs. I know these files have been around for ages, and if IDE's treated them as valid java sources files back then, I suspect the newer IDE's might have figured out by now that they are not java source files. NetBeans will let you open any file, and when I open these files with the *.java suffix, I get hundreds of error indicators, but when opened as *.java.template files, they appear as normal files with no error indications. NetBeans doesn't know what these files really are anyway. The complications in the Makefiles is that every time you want a list of java sources from a directory to compile, you have to have a special exclude list to remove all these files: X-*.java *-X-*.java *-template.java It's a pain, in make files or in ant scripts. -kto > > - Mark From Jonathan.Gibbons at Sun.COM Mon Oct 12 09:48:20 2009 From: Jonathan.Gibbons at Sun.COM (Jonathan Gibbons) Date: Mon, 12 Oct 2009 09:48:20 -0700 Subject: Need reviewer In-Reply-To: <4AD35556.1070507@sun.com> References: <20091012052637.71AA54D2@eggemoggin.niobe.net> <4AD35556.1070507@sun.com> Message-ID: <4AD35DD4.30800@sun.com> NetBeans, and other IDEs that try to do "compilation on the fly", will definitely have trouble with these files. Lesser IDEs, like emacs, could presumably be taught to recognize *.java.template as a Java file for Java mode. -- Jon Kelly O'Hair wrote: > > Mark Reinhold wrote: >>> Date: Sun, 11 Oct 2009 17:35:31 -0700 >>> From: kelly.ohair at sun.com >> >>> 6888701: Change all template java source files to a .java.template >>> file suffix >>> >>> http://cr.openjdk.java.net/~ohair/openjdk7/jdk7-build-template-6888701/webrev/ >>> >> >> Most of the files you are renaming in this change are in NIO, and the >> names of those files were carefully chosen so as to be invalid Java >> class names -- they all contain at least one dash character. >> >> This approach has the advantage that when you visit the files in an >> editor or IDE they're treated as Java source files without any further >> effort. This is a feature, not a bug as claimed in 6888701. >> >> I'd like to understand more about the complications in Makefile logic >> claimed in 6888701. If this is such a problem then why are we just >> now getting around to fixing it? > > I have been trying to change some of the Makefiles to use the GNU make > functions and everything is easier when knowing that a file ending in > .java is really input for javac. Filtering is easier. > > We have at least 3 conventions being used for processing java source > files: > *-template.java, *X-*.java, and *.java.template. By far the easiest one > to deal with in build scripts (make and ant) is the *.template > convention. > I'm just trying to normalize this to one convention that is the easiest > to deal with in build scripts and for IDEs. > > I know these files have been around for ages, and if IDE's treated > them as > valid java sources files back then, I suspect the newer IDE's might have > figured out by now that they are not java source files. > NetBeans will let you open any file, and when I open these files with the > *.java suffix, I get hundreds of error indicators, but when opened as > *.java.template files, they appear as normal files with no error > indications. > NetBeans doesn't know what these files really are anyway. > > The complications in the Makefiles is that every time you want a list of > java sources from a directory to compile, you have to have a special > exclude > list to remove all these files: X-*.java *-X-*.java *-template.java > It's a pain, in make files or in ant scripts. > > -kto > >> >> - Mark From gnu_andrew at member.fsf.org Mon Oct 12 10:14:58 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Mon, 12 Oct 2009 18:14:58 +0100 Subject: 6856630: Restructure jaxp/jaxws repository In-Reply-To: <4ACF6ECC.7070407@sun.com> References: <4AB80C37.6000108@sun.com> <17c6771e0910071424n3b12402bg80ed2f56210fb6e3@mail.gmail.com> <17c6771e0910090726r14a12ee4wadb5cc4e9fd141@mail.gmail.com> <4ACF6ECC.7070407@sun.com> Message-ID: <17c6771e0910121014w6fcd23e9rf5d594173e594ec3@mail.gmail.com> 2009/10/9 Kelly O'Hair : > I can't see the webrev right now due to the server issues. > > As soon as I can look at it I'll let you know. > > At first I wondered if it should be named ALT_JDK7_DROP_DIR, > but then I thought not, and I should have used jdk-drops > instead of jdk7-drops, getting the version out of the directory. > The file names should make them unique enough. > > So your change may be fine as is, as soon as I can see it. ;^) > I can access it fine from here now. > And I apologize for not creating an ALT_* setting before... my oversight. > No problem; easily fixed. > -kto > > Andrew John Hughes wrote: >> >> 2009/10/7 Andrew John Hughes : >>> >>> 2009/9/22 Kelly O'Hair : >>>> >>>> This 6856630 change has been integrated into the build >>>> forest jaxp and jaxws repositories: >>>> >>>> http://hg.openjdk.java.net/jdk7/build/jaxws/rev/ae2bec597586 >>>> http://hg.openjdk.java.net/jdk7/build/jaxp/rev/534e23823a1b >>>> >>>> Assuming we get successful test builds of the build forest, these >>>> changes will get integrated into the jdk7 master forest. >>>> >>>> Notes: >>>> ?* The jaxws (and jaf) and jaxp sources have been extracted and >>>> ? put into separate source zip files. These zip files represent >>>> ? the source deliveries into the jdk7 project. Selection of >>>> ? the bundles is determined by the properties in the files >>>> ? jax*/jax*.properties and jax*/build-defs.xml. >>>> ? The current 3 source drop bundles are: >>>> ? ? jdk7-jaf-2009_08_28.zip >>>> ? ? jdk7-jaxp-2009_08_28.zip >>>> ? ? jdk7-jaxws-2009_08_28.zip >>>> ? If not found in the /java/devtools/share/jdk7-drops directory, >>>> ? the ant scripts will look for them at >>>> ? ? http://kenai.com/projects/jdk7-drops/downloads >>>> ? a temporary site for now until the JAX* teams engage. >>>> >>>> ?* The original jaxp/src and jaxws/src files are still there, >>>> ? but should not be used unless the drop source bundles are >>>> ? unavailable (currently the drop bundles contain the exact >>>> ? same files). A warning will be issued if they are used. >>>> ? Eventually the original jaxp/src and jaxws/src files will >>>> ? be deleted from the jdk7 repositories. >>>> >>>> ?* 'ant source' or 'cd make && make source' will get the drop >>>> ? bundles and populate the drop source area. But this should >>>> ? happen automatically. >>>> >>>> Please ask questions, this is kind of a big change and anything >>>> can go wrong, please let me know if there are problems. >>>> >>>> -kto >>>> >>>> >>> Hi Kelly, >>> >>> This patch is now in b73 and I'm trying to get IcedTea7 to build with >>> it. ?How do I specify the location of the zips to use? >>> >>> Thanks, >>> -- >>> Andrew :-) >>> >>> Free Java Software Engineer >>> Red Hat, Inc. (http://www.redhat.com) >>> >>> Support Free Java! >>> Contribute to GNU Classpath and the OpenJDK >>> http://www.gnu.org/software/classpath >>> http://openjdk.java.net >>> >>> PGP Key: 94EFD9D8 (http://subkeys.pgp.net) >>> Fingerprint: F8EF F1EA 401E 2E60 15FA ?7927 142C 2591 94EF D9D8 >>> >> >> I found a number of issues with the current version: >> >> * The drop zips are expected to be in a share/jdk7-drops subdirectory >> of the devtools directory. ?This doesn't really work outside Sun's >> internal setup. ?I've added support for ALT_DROP_DIR which can be used >> to specify an exact path to the zips. ?If this is not set, the old >> devtools behaviour is used. >> * The zips are being downloaded and extracted in the source directory, >> which could be read only. ?I've changed this so they are written to >> the build directory like everything else. >> >> The webrev for these changes is here: >> >> http://cr.openjdk.java.net/~andrew/drops/webrev.01/ >> >> I've committed this to IcedTea already. ?Does this look ok for build also? > -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From Kelly.Ohair at Sun.COM Mon Oct 12 11:35:51 2009 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Mon, 12 Oct 2009 11:35:51 -0700 Subject: Need reviewer - Fixing -D quotes In-Reply-To: <4AD28CD4.8090000@sun.com> References: <4AD27A4F.8020408@sun.com> <4AD28CD4.8090000@sun.com> Message-ID: <4AD37707.2090604@sun.com> Jonathan Gibbons wrote: > Kelly O'Hair wrote: >> >> 6888709: Change use of -DX=\""Y\"" to -DX='"Y"', consistently for all >> platforms >> >> http://cr.openjdk.java.net/~ohair/openjdk7/jdk7-build-quotes-6888709/webrev/ >> >> >> -kto > > For the record, you changed some quoting of { } as well, but still looks > good to me. Mea culpa. Yes, when I got into the -DJAVA_ARGS= stuff, and the launcher magic, I simplified it a bit so the '' happened with the -D. --- How old is 'sh' now? I think 30 years from now we will still be dealing with quoting nightmares. :^( -kto > > -- Jon From gnu_andrew at member.fsf.org Mon Oct 12 13:18:03 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Mon, 12 Oct 2009 21:18:03 +0100 Subject: 6856630: Restructure jaxp/jaxws repository In-Reply-To: <4AD36C3F.2010501@sun.com> References: <4AB80C37.6000108@sun.com> <17c6771e0910071424n3b12402bg80ed2f56210fb6e3@mail.gmail.com> <17c6771e0910090726r14a12ee4wadb5cc4e9fd141@mail.gmail.com> <4ACF6ECC.7070407@sun.com> <17c6771e0910121014w6fcd23e9rf5d594173e594ec3@mail.gmail.com> <4AD36C3F.2010501@sun.com> Message-ID: <17c6771e0910121318m26e53de3gb3bbea964b70f4eb@mail.gmail.com> 2009/10/12 Kelly O'Hair : > I saw the webrev for a while, and now I can't :^(, but I saw enough... > >>> Andrew John Hughes wrote: >>>> >>>> 2009/10/7 Andrew John Hughes : > > ...[snip]... >>>> >>>> I found a number of issues with the current version: >>>> >>>> * The drop zips are expected to be in a share/jdk7-drops subdirectory >>>> of the devtools directory. ?This doesn't really work outside Sun's >>>> internal setup. ?I've added support for ALT_DROP_DIR which can be used >>>> to specify an exact path to the zips. ?If this is not set, the old >>>> devtools behaviour is used. > > I'm concerned about the name dropdir (your master copy location) vs. > drop.dir > (destination for the exploded contents) in the property names. Seems > confusing. > I hesitate to go on a name hunt, but what about ALT_DROP_BUNDLE_DIR and > drop.bundle.dir? > Yes, I noticed drop.dir after posting the webrev and agree it's confusing. Would just making them ALT_DROPS_DIR and drops.dir not be sufficient? drop.bundle seems a little verbose and both mean the same thing to me at least. >>>> * The zips are being downloaded and extracted in the source directory, >>>> which could be read only. ?I've changed this so they are written to >>>> the build directory like everything else. > > It turns out that we need this drop.dir to be in the source area if > we want the openjdk source zip bundles, created by RE, to include > the drop sources. These source bundles are created by bundling up > everything in the forest, prior to building, so the drop.dir needs > to be in the forest somehow. Otherwise, the bundling logic has to > merge two separate source trees, or different roots. > I was given a requirement that the openjdk source bundles include these > drop sources, easiest answer was drop.dir in the repo. > Not an unsurmountable problem, I avoided the more complicated path. > > I know that becomes an issue if the repository or source is in a > read-only area, but that's not the only situation in the openjdk I suspect. > I assumed someone building from a read-only area could set > drop.dir to some other location. > Would it not make more sense for RE to set the drop.dir property into the source directory, given it's that build that's abnormal (needing to distribute a post build tree in effect)? > Not sure what to say. > > How important is it for the community that the openjdk source bundles > include these drop sources? e.g. ones at > http://download.java.net/openjdk/jdk7/ > If they are not included, when the openjdk source bundles are built, > they will need to download the jaxp and jaxws drop bundles at build time. > I obviously can't speak for everyone, but for IcedTea7 we don't even use the download bundles any more. We grab from the IcedTea forest instead, which allows patches which didn't make a bxx release to be applied there once and used in releases. We did this for the security fixes with Milestone 4/1.11. I've already added downloading of the jaxp, jaxws and jaf bundles to the IcedTea build; it's this process that resulted in this webrev. This has two advantages; we check all the zips/tarballs at the same point in the build (the JAXP and JAXWS builds are then pointed at the directory IcedTea uses for them) and we check the MD5 sums of the downloads or pre-existing zips. I don't know if the latter could be incorporated into the OpenJDK build somehow. At present, there's no guarantee that these zips are valid. The rules look like this: stamps/download-jaxp-drop.stamp: mkdir -p drops if USE_ALT_JAXP_DROP_ZIP ln -sf $(ALT_JAXP_DROP_ZIP) drops/$(JAXP_DROP_ZIP) endif if ! echo "$(JAXP_DROP_MD5SUM) drops/$(JAXP_DROP_ZIP)" \ | $(MD5SUM) --check ; \ then \ if [ -f drops/$(JAXP_DROP_ZIP) ] ; \ then \ mv drops/$(JAXP_DROP_ZIP) drops/$(JAXP_DROP_ZIP).old ; \ fi ; \ $(WGET) $(DROP_URL)/$(JAXP_DROP_ZIP) -O drops/$(JAXP_DROP_ZIP); \ fi ; mkdir -p stamps touch stamps/download-jaxp-drop.stamp ALT_JAXP_DROP_ZIP gets set if the user specifies --with-jaxp-drop-zip= to configure. WGET and MD5SUM are the respective binaries as located by configure and DROP_URL is the kenai.com URL as in the jaxws.properties and jaxp.properties files: DROP_URL = http://kenai.com/projects/jdk7-drops/downloads/download JAXWS_DROP_ZIP = jdk7-jaxws-2009_09_28.zip JAXWS_DROP_MD5SUM = debb949440c5a15ce999cfefbbc56526 JAF_DROP_ZIP = jdk7-jaf-2009_08_28.zip JAF_DROP_MD5SUM = eb8cb7a4a7f14e211fbe2354878a2472 JAXP_DROP_ZIP = jdk7-jaxp-2009_09_28.zip JAXP_DROP_MD5SUM = 8800970d03bab1fff188dcfafc346f5d > -kto > >>>> >>>> The webrev for these changes is here: >>>> >>>> http://cr.openjdk.java.net/~andrew/drops/webrev.01/ >>>> >>>> I've committed this to IcedTea already. ?Does this look ok for build >>>> also? >> >> >> > -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From Tim.Bell at Sun.COM Mon Oct 12 11:15:09 2009 From: Tim.Bell at Sun.COM (Tim Bell) Date: Mon, 12 Oct 2009 11:15:09 -0700 Subject: Need reviewer - Fixing -D quotes In-Reply-To: <4AD28CD4.8090000@sun.com> References: <4AD27A4F.8020408@sun.com> <4AD28CD4.8090000@sun.com> Message-ID: <4AD3722D.2040702@sun.com> Looks good to me as well- Tim Jonathan Gibbons wrote: > Kelly O'Hair wrote: >> 6888709: Change use of -DX=\""Y\"" to -DX='"Y"', consistently for all >> platforms >> >> http://cr.openjdk.java.net/~ohair/openjdk7/jdk7-build-quotes-6888709/webrev/ >> >> >> -kto > > For the record, you changed some quoting of { } as well, but still looks > good to me. > > -- Jon From Kelly.Ohair at Sun.COM Mon Oct 12 10:49:51 2009 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Mon, 12 Oct 2009 10:49:51 -0700 Subject: 6856630: Restructure jaxp/jaxws repository In-Reply-To: <17c6771e0910121014w6fcd23e9rf5d594173e594ec3@mail.gmail.com> References: <4AB80C37.6000108@sun.com> <17c6771e0910071424n3b12402bg80ed2f56210fb6e3@mail.gmail.com> <17c6771e0910090726r14a12ee4wadb5cc4e9fd141@mail.gmail.com> <4ACF6ECC.7070407@sun.com> <17c6771e0910121014w6fcd23e9rf5d594173e594ec3@mail.gmail.com> Message-ID: <4AD36C3F.2010501@sun.com> I saw the webrev for a while, and now I can't :^(, but I saw enough... >> Andrew John Hughes wrote: >>> 2009/10/7 Andrew John Hughes : ...[snip]... >>> I found a number of issues with the current version: >>> >>> * The drop zips are expected to be in a share/jdk7-drops subdirectory >>> of the devtools directory. This doesn't really work outside Sun's >>> internal setup. I've added support for ALT_DROP_DIR which can be used >>> to specify an exact path to the zips. If this is not set, the old >>> devtools behaviour is used. I'm concerned about the name dropdir (your master copy location) vs. drop.dir (destination for the exploded contents) in the property names. Seems confusing. I hesitate to go on a name hunt, but what about ALT_DROP_BUNDLE_DIR and drop.bundle.dir? >>> * The zips are being downloaded and extracted in the source directory, >>> which could be read only. I've changed this so they are written to >>> the build directory like everything else. It turns out that we need this drop.dir to be in the source area if we want the openjdk source zip bundles, created by RE, to include the drop sources. These source bundles are created by bundling up everything in the forest, prior to building, so the drop.dir needs to be in the forest somehow. Otherwise, the bundling logic has to merge two separate source trees, or different roots. I was given a requirement that the openjdk source bundles include these drop sources, easiest answer was drop.dir in the repo. Not an unsurmountable problem, I avoided the more complicated path. I know that becomes an issue if the repository or source is in a read-only area, but that's not the only situation in the openjdk I suspect. I assumed someone building from a read-only area could set drop.dir to some other location. Not sure what to say. How important is it for the community that the openjdk source bundles include these drop sources? e.g. ones at http://download.java.net/openjdk/jdk7/ If they are not included, when the openjdk source bundles are built, they will need to download the jaxp and jaxws drop bundles at build time. -kto >>> >>> The webrev for these changes is here: >>> >>> http://cr.openjdk.java.net/~andrew/drops/webrev.01/ >>> >>> I've committed this to IcedTea already. Does this look ok for build also? > > > From gbenson at redhat.com Wed Oct 14 08:31:48 2009 From: gbenson at redhat.com (Gary Benson) Date: Wed, 14 Oct 2009 16:31:48 +0100 Subject: Review request: Zero buildsystem changes In-Reply-To: <20091009115839.GC3506@redhat.com> References: <20091009115839.GC3506@redhat.com> Message-ID: <20091014153147.GC3468@redhat.com> Hi all, As an update to my previous message, the HotSpot part of this patch was tested and pushed to hotspot-comp last night, so the remaining code for review is this: http://cr.openjdk.java.net/~gbenson/zero-11-build/ I'm going on vacation on Friday 16, returning Monday 26, so could anyone replying off-list please Cc gnu_andrew at member.fsf.org, who is going to handle this in my absence. We'd love to see this in in time for Milestone 5, and we'd hate to miss the boat because an email was sitting in my inbox unread! Thanks, Gary Gary Benson wrote: > Hi all, > > Zero is an interpreter-only port of HotSpot that uses no assembler and > can trivially be built on any Linux system. The following two webrevs > add Zero support to OpenJDK: > > http://cr.openjdk.java.net/~gbenson/zero-11-build/ > http://cr.openjdk.java.net/~gbenson/zero-11-hotspot/ > > The bulk of the changes are in the zero-11-hotspot webrev, which has > been through a couple of review cycles and is (hopefully!) about to > be tested with JPRT and pushed. > > The zero-11-build webrev contains a small number of changes, mostly > to makefiles, that are required in order to build OpenJDK with Zero. > Is this the right list to review these changes? > > Cheers, > Gary > > -- > http://gbenson.net/ > > > Build Instructions > ================== > > There are a number of environment variables that need setting before > running make, but if you are using jdk/make/jdk_generic_profile.sh > to set up your environment then you only need to set one, and a build > can be as simple as: > > export ZERO_BUILD=true > . jdk/make/jdk_generic_profile.sh > gmake sanity && gmake > > The mandatory environment variable does the following: > > ZERO_BUILD > Setting ZERO_BUILD to "true" will cause the Zero interpreter to > be used. If ZERO_BUILD is unset, or set to any other value than > "true", the standard, platform-specific interpreter will be used. > > Of the other environment variables the following are required when > ZERO_BUILD is set to "true". These are set by > jdk/make/jdk_generic_profile.sh based on the result of uname -m: > > ZERO_LIBARCH > This is the name of the architecture-specific subdirectory under > $JAVA_HOME/jre/lib. Typically this will be the same as the output > of uname -m, although there are some exceptions: "amd64" instead > of "x86_64", for example, and "i386" instead of "i686". > > ZERO_ARCHDEF > The value of ZERO_ARCHDEF will be passed to the C++ compiler using > -D${ZERO_ARCHDEF} to allow conditionalized platform-specific code. > This is typically set to ZERO_LIBARCH converted to uppercase but, > again, there are exceptions. "i386" becomes "IA32", to match what > HotSpot already does, and on platforms with both 32- and 64-bit > variants ZERO_ARCHDEF corresponds to the 32-bit version, so both > ppc and ppc64 have ZERO_ARCHDEF set to "PPC". > > ZERO_ENDIANNESS > This is set to "little" or "big". > > ARCH_DATA_MODEL > This is set to "32" or "64". > > ZERO_ARCHFLAG > This is a flag that will be passed to the C++ compiler and to the > linker to instruct them to generate code for the particular > platform. This is required for platforms with both 32- and 64-bit > variants where the compiler needs to be told which variant to > build for. ZERO_ARCHFLAG will typically be set to "-m32" or > "-m64", except on 31-bit zSeries where it will be set to "-m31". > > Zero uses one external library, libffi, for JNI method invocation. > The following two variables are used to tell the compiler and linker > how to find libffi. These can be set by the user, but if left unset > then jdk/make/jdk_generic_profile.sh will attempt to set them using > pkg-config or, failing that, by supplying defaults pointing to the > standard locations: > > LIBFFI_CFLAGS > Flags to be passed to the C++ compiler to build against libffi. > If unset (and pkg-config is not installed, or if libffi is not > built with pkg-config) then this defaults to "". > > LIBFFI_LIBS > Flags to be passed to the linker to link against libffi. If > unset (and pkg-config is not installed, or if libffi is not > built with pkg-config) then this defaults to "-lffi". -- http://gbenson.net/ From mr at sun.com Wed Oct 14 12:27:17 2009 From: mr at sun.com (Mark Reinhold) Date: Wed, 14 Oct 2009 12:27:17 -0700 Subject: Need reviewer In-Reply-To: kelly.ohair@sun.com; Mon, 12 Oct 2009 09:12:06 PDT; <4AD35556.1070507@sun.com> Message-ID: <20091014192717.A09097D2@eggemoggin.niobe.net> Okay, I can live with this. (At the risk of stating the obvious: Please be sure to use hg mv when you rename these files, otherwise the historical changeset trail will be broken.) - Mark From Kelly.Ohair at Sun.COM Wed Oct 14 12:46:22 2009 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Wed, 14 Oct 2009 12:46:22 -0700 Subject: Need reviewer In-Reply-To: <20091014192717.A09097D2@eggemoggin.niobe.net> References: <20091014192717.A09097D2@eggemoggin.niobe.net> Message-ID: <4AD62A8E.2060604@sun.com> Mark Reinhold wrote: > Okay, I can live with this. > Thanks. > (At the risk of stating the obvious: Please be sure to use hg mv when > you rename these files, otherwise the historical changeset trail will > be broken.) Will do. -kto > > - Mark From xiomara.jayasena at sun.com Wed Oct 14 13:14:33 2009 From: xiomara.jayasena at sun.com (xiomara.jayasena at sun.com) Date: Wed, 14 Oct 2009 20:14:33 +0000 Subject: hg: jdk7/build: Added tag jdk7-b73 for changeset 3ac6dcf78232 Message-ID: <20091014201433.21E85415F9@hg.openjdk.java.net> Changeset: 2c88089b6e1c Author: xdono Date: 2009-10-02 11:26 -0700 URL: http://hg.openjdk.java.net/jdk7/build/rev/2c88089b6e1c Added tag jdk7-b73 for changeset 3ac6dcf78232 ! .hgtags From xiomara.jayasena at sun.com Wed Oct 14 13:14:37 2009 From: xiomara.jayasena at sun.com (xiomara.jayasena at sun.com) Date: Wed, 14 Oct 2009 20:14:37 +0000 Subject: hg: jdk7/build/corba: Added tag jdk7-b73 for changeset b751c528c555 Message-ID: <20091014201438.F0E54415FA@hg.openjdk.java.net> Changeset: 5d0cf59a3203 Author: xdono Date: 2009-10-02 11:26 -0700 URL: http://hg.openjdk.java.net/jdk7/build/corba/rev/5d0cf59a3203 Added tag jdk7-b73 for changeset b751c528c555 ! .hgtags From xiomara.jayasena at sun.com Wed Oct 14 13:16:04 2009 From: xiomara.jayasena at sun.com (xiomara.jayasena at sun.com) Date: Wed, 14 Oct 2009 20:16:04 +0000 Subject: hg: jdk7/build/hotspot: 53 new changesets Message-ID: <20091014201753.698F1415FC@hg.openjdk.java.net> Changeset: 489a4f8dcd0f Author: twisti Date: 2009-08-27 06:17 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/489a4f8dcd0f 6865583: Verbose CIPrintMethodCodes asserts when ldc an empty String Summary: ldc seems to load an empty String and that leads to an assert on offset < length, which are both zero. Reviewed-by: kvn, never ! src/share/vm/classfile/javaClasses.cpp Changeset: 8fe1963e3964 Author: kvn Date: 2009-08-28 11:19 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/8fe1963e3964 6875577: CTW fails with /hotspot/src/share/vm/opto/memnode.cpp Summary: Fix do_null_check to check for unloaded klass for all oop pointers. Reviewed-by: never, cfang ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/library_call.cpp Changeset: 1fbd5d696bf4 Author: twisti Date: 2009-08-31 02:24 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/1fbd5d696bf4 6875967: CTW fails with./generated/adfiles/ad_sparc.cpp:6711 Reviewed-by: cfang, never ! src/cpu/sparc/vm/sparc.ad Changeset: ace8397c8563 Author: cfang Date: 2009-08-31 08:31 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/ace8397c8563 6876276: assert(!is_visited,"visit only once") Summary: schedule the superword loads based on dependence constraints Reviewed-by: kvn, never ! src/share/vm/opto/superword.cpp ! test/compiler/6636138/Test1.java ! test/compiler/6636138/Test2.java Changeset: ff1a29907b6c Author: never Date: 2009-08-31 17:07 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/ff1a29907b6c 6855215: Calculation error (NaN) after about 1500 calculations Reviewed-by: kvn ! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp ! src/cpu/x86/vm/c1_LinearScan_x86.cpp ! src/share/vm/c1/c1_LIR.cpp ! src/share/vm/c1/c1_LIR.hpp + test/compiler/6855215/Test6855215.java Changeset: 0f1c19b7a52d Author: kvn Date: 2009-09-08 10:42 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/0f1c19b7a52d 6875619: CTW fails with /hotspot/src/share/vm/opto/type.hpp Summary: In load_array_length() cast array's type to TypeOopPtr when calling make_ideal_length() method. Reviewed-by: never ! src/share/vm/opto/graphKit.cpp Changeset: 26fbe81d30cf Author: kvn Date: 2009-09-08 16:56 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/26fbe81d30cf 6880052: SIGSEGV in GraphKit::null_check_common() Summary: Check that a klass is not NULL before the is_loaded() call. Reviewed-by: never ! src/share/vm/opto/graphKit.cpp Changeset: 9a4e87ba1a90 Author: kvn Date: 2009-09-09 16:28 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/9a4e87ba1a90 6880533: test/compiler/6865031/Test.java miss -XX:+IgnoreUnrecognizedVMOptions Summary: Add missing test option -XX:+IgnoreUnrecognizedVMOptions. Reviewed-by: never ! test/compiler/6865031/Test.java Changeset: 159d56b94894 Author: kvn Date: 2009-09-10 10:36 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/159d56b94894 6880574: C2 assert in escape.cpp:445 on linux-amd64 Summary: Look through chained AddP nodes in get_addp_base(). Reviewed-by: jrose ! src/share/vm/opto/escape.cpp Changeset: c7e94e8fff43 Author: kvn Date: 2009-09-10 18:18 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/c7e94e8fff43 6880053: assert(alloc_obj->as_CheckCastPP()->type() != TypeInstPtr::NOTNULL) Summary: Removed second CheckCastPP and use MembarCPUOrder after arraycopy to cloned object. Reviewed-by: never ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/type.cpp ! src/share/vm/opto/type.hpp Changeset: a6f533fc33e0 Author: kvn Date: 2009-09-14 11:45 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/a6f533fc33e0 Merge Changeset: eb058abd0562 Author: ysr Date: 2009-09-15 16:50 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/eb058abd0562 6861557: G1: assert(top() == bottom() || zfs == Allocated,"Region must be empty, or ...") Summary: Druing heap shrinking, check for emptiness of a region before modifying its ZF status. Reviewed-by: tonyp ! src/share/vm/gc_implementation/g1/heapRegionSeq.cpp Changeset: d7c9544cc141 Author: apetrusenko Date: 2009-09-18 06:02 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/d7c9544cc141 Merge Changeset: aafa4232dfd7 Author: asaha Date: 2009-08-28 08:54 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/aafa4232dfd7 6821003: Update hotspot windows os_win32 for windows 7 Reviewed-by: xlu ! src/os/windows/vm/os_windows.cpp Changeset: 9601152ccfc1 Author: dcubed Date: 2009-08-28 12:25 -0600 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/9601152ccfc1 6875393: 2/3 JNI itable index cache is broken Summary: Add missing initialization of cache size. Reviewed-by: tbell ! src/share/vm/oops/instanceKlass.cpp Changeset: 75e30968ebe1 Author: dcubed Date: 2009-08-28 12:32 -0600 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/75e30968ebe1 Merge ! src/share/vm/oops/instanceKlass.cpp Changeset: df97b1cf46d8 Author: dcubed Date: 2009-08-28 15:03 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/df97b1cf46d8 Merge Changeset: bb287c042e99 Author: apangin Date: 2009-08-30 15:33 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/bb287c042e99 Merge Changeset: 6918603297f7 Author: poonam Date: 2009-09-01 23:34 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/6918603297f7 6858208: jvm crash when specifying TypeProfileWidth=0 on jdk 6.0 Summary: Add an explicit check for TypeProfileWidth == 0 in record_klass_in_profile_helper() functions. Reviewed-by: never, coleenp ! src/cpu/sparc/vm/interp_masm_sparc.cpp ! src/cpu/x86/vm/interp_masm_x86_32.cpp ! src/cpu/x86/vm/interp_masm_x86_64.cpp Changeset: 5fdbe2cdf565 Author: andrew Date: 2009-09-08 09:01 +0100 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/5fdbe2cdf565 6879689: Fix warning about ignored return value when compiling with -O2 Summary: Store the return value of fwrite and check it matches the size of the array. Reviewed-by: twisti, dholmes ! src/share/vm/adlc/archDesc.cpp Changeset: 0804a88ed4f5 Author: andrew Date: 2009-09-08 09:02 +0100 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/0804a88ed4f5 Merge Changeset: 682194ca1d8d Author: acorn Date: 2009-09-10 09:04 -0400 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/682194ca1d8d Merge - src/share/vm/gc_implementation/shared/coTracker.cpp - src/share/vm/gc_implementation/shared/coTracker.hpp - src/share/vm/gc_implementation/shared/gcOverheadReporter.cpp - src/share/vm/gc_implementation/shared/gcOverheadReporter.hpp ! src/share/vm/oops/instanceKlass.cpp Changeset: 0fc81f0a8ca8 Author: andrew Date: 2009-09-12 12:50 +0100 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/0fc81f0a8ca8 6873059: Explicitly use -source 6 -target 6 when compiling with the boot jdk Summary: The build fails if the bootstrap JDK defaults to <1.5 Reviewed-by: jcoomes ! make/linux/makefiles/jvmti.make ! make/linux/makefiles/rules.make ! make/linux/makefiles/sa.make ! make/linux/makefiles/top.make ! make/solaris/makefiles/jvmti.make ! make/solaris/makefiles/rules.make ! make/solaris/makefiles/sa.make ! make/solaris/makefiles/top.make ! make/windows/makefiles/generated.make ! make/windows/makefiles/jvmti.make ! make/windows/makefiles/rules.make ! make/windows/makefiles/sa.make ! make/windows/projectfiles/common/Makefile Changeset: e5b31fd85b72 Author: acorn Date: 2009-09-15 16:28 -0400 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/e5b31fd85b72 Merge Changeset: ad6585fd4087 Author: acorn Date: 2009-09-04 12:53 -0400 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/ad6585fd4087 6830542: Performance: JVM_DefineClass already verified. Reviewed-by: kamg, phh ! make/linux/makefiles/mapfile-vers-debug ! make/linux/makefiles/mapfile-vers-product ! make/solaris/makefiles/mapfile-vers ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/classfile/classLoader.cpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/verifier.cpp ! src/share/vm/classfile/verifier.hpp ! src/share/vm/code/dependencies.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/instanceKlassKlass.cpp ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvm.h ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 26b774d693aa Author: acorn Date: 2009-09-16 09:10 -0400 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/26b774d693aa Merge ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp - src/share/vm/gc_implementation/shared/coTracker.cpp - src/share/vm/gc_implementation/shared/coTracker.hpp - src/share/vm/gc_implementation/shared/gcOverheadReporter.cpp - src/share/vm/gc_implementation/shared/gcOverheadReporter.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/instanceKlassKlass.cpp Changeset: 83c29a26f67c Author: acorn Date: 2009-09-16 15:42 -0400 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/83c29a26f67c 6879572: SA fails _is_marked_dependent not found Reviewed-by: kamg, dcubed ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/code/dependencies.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/instanceKlassKlass.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 723131383de6 Author: acorn Date: 2009-09-18 15:14 -0400 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/723131383de6 Merge Changeset: 74a5db69c1fe Author: dcubed Date: 2009-09-21 09:30 -0600 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/74a5db69c1fe 6419370: 4/4 new jmethodID code has tiny holes in synchronization Summary: Fix races in jmethodID cache and JNI itable index cache. Reviewed-by: ikrylov, acorn ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/methodOop.hpp Changeset: d72ba3205918 Author: acorn Date: 2009-09-21 18:10 -0400 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/d72ba3205918 Merge Changeset: 87770dcf831b Author: dcubed Date: 2009-09-22 21:12 -0600 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/87770dcf831b 6876794: 4/4 sp07t002 hangs very intermittently Summary: remove over locking by VMThread on "is thread suspended?" check Reviewed-by: dholmes, acorn, andrew ! src/share/vm/runtime/safepoint.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp Changeset: c3c4a1d3801a Author: andrew Date: 2009-09-23 11:36 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/c3c4a1d3801a 6884552: remove some unnecessary #ifdef's introduced in the fix for 4957990 Summary: Removed the unnecessary #ifdef's which were interfering with the build of the Zero-assembler port Reviewed-by: ysr, jcoomes ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/shared/markSweep.cpp Changeset: 1af62b6ca0f9 Author: apetrusenko Date: 2009-09-25 04:39 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/1af62b6ca0f9 Merge Changeset: 7a102acc9f17 Author: trims Date: 2009-09-25 12:17 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/7a102acc9f17 Merge ! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp ! src/share/vm/gc_implementation/shared/markSweep.cpp ! src/share/vm/prims/jvm.h Changeset: faf94d94786b Author: trims Date: 2009-09-25 12:19 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/faf94d94786b 6885900: Bump the HS17 build number to 02 Summary: Update the HS17 build number to 02 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 6ddec5389232 Author: xdono Date: 2009-10-02 11:26 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/6ddec5389232 Added tag jdk7-b73 for changeset faf94d94786b ! .hgtags Changeset: 685e959d09ea Author: cfang Date: 2009-09-14 09:49 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/685e959d09ea 6877254: Server vm crashes with no branches off of store slice" when run with CMS and UseSuperWord(default) Summary: design StoreCMNode::Ideal to promote its oopStore input if the input is a MergeMem node Reviewed-by: kvn, never ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/graphKit.hpp ! src/share/vm/opto/idealKit.cpp ! src/share/vm/opto/idealKit.hpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/memnode.hpp ! src/share/vm/opto/superword.cpp + test/compiler/6877254/Test.java Changeset: 62001a362ce9 Author: kvn Date: 2009-09-14 12:14 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/62001a362ce9 6827605: new String intrinsics may prevent EA scalar replacement 6875866: Intrinsic for String.indexOf() is broken on x86 with SSE4.2 Summary: Modify String intrinsic methods to pass char[] pointers instead of string oops. Reviewed-by: never ! 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.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/adlc/formssel.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/matcher.cpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/memnode.hpp + test/compiler/6875866/Test.java Changeset: 00977607da34 Author: cfang Date: 2009-09-15 11:09 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/00977607da34 6879921: CTW failure jdk6_18/hotspot/src/share/vm/utilities/globalDefinitions.cpp:268 Summary: filter out non-primitives before deciding whether two ops can be packed Reviewed-by: kvn, never ! src/share/vm/opto/superword.cpp Changeset: 7e309ecb83ce Author: kvn Date: 2009-09-15 19:03 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/7e309ecb83ce 6879362: assert(!klass_is_exact(),"only non-exact klass") Summary: Do nothing for AddP node which has type not related to the type of allocated object. Reviewed-by: never ! src/share/vm/opto/escape.cpp Changeset: 148e5441d916 Author: jrose Date: 2009-09-15 21:53 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/148e5441d916 6863023: need non-perm oops in code cache for JSR 292 Summary: Make a special root-list for those few nmethods which might contain non-perm oops. Reviewed-by: twisti, kvn, never, jmasa, ysr ! agent/src/share/classes/sun/jvm/hotspot/code/CodeCache.java ! agent/src/share/classes/sun/jvm/hotspot/code/NMethod.java ! 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/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_InstructionPrinter.cpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/c1/c1_ValueType.cpp ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/ci/ciEnv.hpp ! src/share/vm/ci/ciObject.cpp ! src/share/vm/ci/ciObject.hpp ! src/share/vm/ci/ciObjectFactory.cpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/code/codeBlob.hpp ! src/share/vm/code/codeCache.cpp ! src/share/vm/code/codeCache.hpp ! src/share/vm/code/debugInfoRec.cpp ! src/share/vm/code/dependencies.cpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/nmethod.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsOopClosures.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp ! src/share/vm/gc_implementation/includeDB_gc_parallelScavenge ! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.cpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.hpp ! src/share/vm/gc_implementation/parallelScavenge/pcTasks.cpp ! src/share/vm/gc_implementation/parallelScavenge/pcTasks.hpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.hpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp ! src/share/vm/gc_implementation/parallelScavenge/psTasks.cpp ! src/share/vm/gc_implementation/parallelScavenge/psTasks.hpp ! src/share/vm/gc_implementation/shared/markSweep.cpp ! src/share/vm/gc_implementation/shared/markSweep.hpp ! src/share/vm/gc_interface/collectedHeap.hpp ! src/share/vm/memory/defNewGeneration.cpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/genCollectedHeap.hpp ! src/share/vm/memory/genMarkSweep.cpp ! src/share/vm/memory/iterator.cpp ! src/share/vm/memory/iterator.hpp ! src/share/vm/memory/sharedHeap.cpp ! src/share/vm/memory/sharedHeap.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/oop.hpp ! src/share/vm/oops/oop.inline2.hpp ! src/share/vm/opto/output.cpp ! src/share/vm/opto/parse.hpp ! src/share/vm/opto/parse2.cpp ! src/share/vm/opto/parse3.cpp ! src/share/vm/opto/type.cpp ! src/share/vm/opto/type.hpp ! src/share/vm/prims/jvmtiTagMap.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/frame.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/sweeper.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/runtime/vmThread.cpp ! src/share/vm/runtime/vmThread.hpp ! src/share/vm/utilities/debug.cpp Changeset: be094e0c089a Author: jrose Date: 2009-09-15 22:50 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/be094e0c089a Merge Changeset: 3a2aa26bdc58 Author: never Date: 2009-09-16 11:06 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/3a2aa26bdc58 6854812: 6.0_14-b08 crashes with a SIGSEGV Reviewed-by: kvn, twisti ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/ci/ciMethod.hpp ! src/share/vm/ci/ciTypeFlow.cpp ! src/share/vm/opto/parse1.cpp Changeset: 6a8ccac44f41 Author: kvn Date: 2009-09-18 09:57 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/6a8ccac44f41 6820514: meet not symmetric failure in ctw Summary: Add missing instance_id meet. Reviewed-by: never ! src/share/vm/opto/type.cpp ! src/share/vm/opto/type.hpp Changeset: 54b3b351d6f9 Author: jrose Date: 2009-09-23 23:56 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/54b3b351d6f9 Merge ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/code/dependencies.cpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/nmethod.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsOopClosures.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp ! src/share/vm/gc_implementation/includeDB_gc_parallelScavenge ! src/share/vm/gc_implementation/parallelScavenge/pcTasks.cpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.hpp - src/share/vm/gc_implementation/shared/coTracker.cpp - src/share/vm/gc_implementation/shared/coTracker.hpp - src/share/vm/gc_implementation/shared/gcOverheadReporter.cpp - src/share/vm/gc_implementation/shared/gcOverheadReporter.hpp ! src/share/vm/gc_implementation/shared/markSweep.cpp ! src/share/vm/gc_implementation/shared/markSweep.hpp ! src/share/vm/gc_interface/collectedHeap.hpp ! src/share/vm/memory/genMarkSweep.cpp ! src/share/vm/memory/iterator.cpp ! src/share/vm/memory/iterator.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/sweeper.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 753cf9794df9 Author: jrose Date: 2009-09-23 23:57 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/753cf9794df9 6885169: merge of 4957990 and 6863023 causes conflict on do_nmethods Summary: After mechanically merging changes, some by-hand adjustments are needed. Reviewed-by: ysr ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/nmethod.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsOopClosures.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/shared/markSweep.hpp ! src/share/vm/memory/iterator.cpp ! src/share/vm/memory/iterator.hpp Changeset: ddd6f1182ae3 Author: kvn Date: 2009-09-25 13:26 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/ddd6f1182ae3 6883468: C2 compiler enters infinite loop in PhaseIterGVN::transform Summary: Avoid ideal transformation ping-pong between AddPNode::Ideal() and CastX2PNode::Ideal(). Reviewed-by: cfang ! src/share/vm/opto/connode.cpp Changeset: d6b9fd78f389 Author: cfang Date: 2009-09-28 17:14 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/d6b9fd78f389 6886353: For DeoptimizeALot, JTreg tests should "IgnoreUnrecognizedVMOptions on a product build Summary: Add IgnoreUnrecognizedVMOptions for JTreg tests (on a product build) to pass with DeoptimizeALot Reviewed-by: kvn ! test/compiler/6823453/Test.java ! test/compiler/6833129/Test.java Changeset: 46b819ba120b Author: jrose Date: 2009-09-30 13:25 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/46b819ba120b Merge ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/shared/markSweep.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp Changeset: a0107ba3bc53 Author: johnc Date: 2009-10-01 15:56 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/a0107ba3bc53 6887186: G1: Incorrect code generated for G1 pre-barrier by C1 on SPARC Summary: Modify operand passed to C1 pre-barrier to be the operand representing the address of the object field that is being stored. Reviewed-by: never ! src/cpu/sparc/vm/c1_LIRGenerator_sparc.cpp Changeset: 708275a44e4a Author: tonyp Date: 2009-10-03 10:53 -0400 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/708275a44e4a Merge ! src/cpu/sparc/vm/c1_LIRGenerator_sparc.cpp Changeset: a1423fe86a18 Author: trims Date: 2009-10-09 15:18 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/a1423fe86a18 Merge ! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp ! src/share/vm/ci/ciObjectFactory.cpp ! src/share/vm/code/nmethod.hpp ! src/share/vm/gc_implementation/parallelScavenge/pcTasks.cpp ! src/share/vm/gc_implementation/shared/markSweep.cpp ! src/share/vm/gc_implementation/shared/markSweep.hpp ! src/share/vm/memory/genMarkSweep.cpp ! src/share/vm/memory/iterator.cpp ! src/share/vm/memory/iterator.hpp ! src/share/vm/opto/idealKit.cpp ! src/share/vm/opto/idealKit.hpp ! src/share/vm/runtime/sweeper.cpp Changeset: f4b900403d6e Author: trims Date: 2009-10-09 15:21 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/f4b900403d6e 6890293: Bump the HS17 build number to 03 Summary: Update the HS17 build number to 03 Reviewed-by: jcoomes ! make/hotspot_version From xiomara.jayasena at sun.com Wed Oct 14 13:21:57 2009 From: xiomara.jayasena at sun.com (xiomara.jayasena at sun.com) Date: Wed, 14 Oct 2009 20:21:57 +0000 Subject: hg: jdk7/build/jaxp: Added tag jdk7-b73 for changeset feb05980f9f2 Message-ID: <20091014202159.830BE415FE@hg.openjdk.java.net> Changeset: ea7b88c676dd Author: xdono Date: 2009-10-02 11:26 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jaxp/rev/ea7b88c676dd Added tag jdk7-b73 for changeset feb05980f9f2 ! .hgtags From xiomara.jayasena at sun.com Wed Oct 14 13:22:04 2009 From: xiomara.jayasena at sun.com (xiomara.jayasena at sun.com) Date: Wed, 14 Oct 2009 20:22:04 +0000 Subject: hg: jdk7/build/jaxws: Added tag jdk7-b73 for changeset 558985e26fe1 Message-ID: <20091014202205.898F7415FF@hg.openjdk.java.net> Changeset: f4466e1b6080 Author: xdono Date: 2009-10-02 11:26 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jaxws/rev/f4466e1b6080 Added tag jdk7-b73 for changeset 558985e26fe1 ! .hgtags From xiomara.jayasena at sun.com Wed Oct 14 13:26:08 2009 From: xiomara.jayasena at sun.com (xiomara.jayasena at sun.com) Date: Wed, 14 Oct 2009 20:26:08 +0000 Subject: hg: jdk7/build/jdk: 99 new changesets Message-ID: <20091014204730.51AC541607@hg.openjdk.java.net> Changeset: fdf11ce72e8e Author: mchung Date: 2009-08-06 11:25 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/fdf11ce72e8e 4917309: (cl) Reduce internal usage of ClassNotFoundExceptions during class-loading Summary: Change findBootstrapClass to return null instead of throwing CNFE if class not found Reviewed-by: alanb, dholmes, iris ! src/share/classes/java/lang/ClassLoader.java ! src/share/javavm/export/jvm.h ! src/share/native/java/lang/ClassLoader.c Changeset: 3323e6c925f9 Author: mchung Date: 2009-08-06 16:35 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/3323e6c925f9 6864028: Update the java launcher to use the new entry point JVM_FindClassFromBootLoader Summary: Update the java launcher to use the new entry point JVM_FindClassFromBootLoader Reviewed-by: ksrini ! src/share/bin/java.h ! src/solaris/bin/java_md.c ! src/windows/bin/java_md.c Changeset: 1f1c824e6244 Author: mchung Date: 2009-08-24 10:33 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/1f1c824e6244 Merge - src/share/classes/com/sun/crypto/provider/JarVerifier.java - src/share/classes/javax/swing/plaf/basic/DesktopIconMover.java - src/share/classes/sun/nio/ch/AbstractFuture.java - src/share/classes/sun/security/pkcs11/JarVerifier.java - src/windows/classes/sun/security/mscapi/JarVerifier.java Changeset: 799731b1cd03 Author: mchung Date: 2009-08-27 12:58 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/799731b1cd03 Merge - src/share/native/java/util/zip/zlib-1.1.3/ChangeLog - src/share/native/java/util/zip/zlib-1.1.3/README - src/share/native/java/util/zip/zlib-1.1.3/compress.c - src/share/native/java/util/zip/zlib-1.1.3/deflate.c - src/share/native/java/util/zip/zlib-1.1.3/deflate.h - src/share/native/java/util/zip/zlib-1.1.3/doc/algorithm.doc - src/share/native/java/util/zip/zlib-1.1.3/example.c - src/share/native/java/util/zip/zlib-1.1.3/gzio.c - src/share/native/java/util/zip/zlib-1.1.3/infblock.c - src/share/native/java/util/zip/zlib-1.1.3/infblock.h - src/share/native/java/util/zip/zlib-1.1.3/infcodes.c - src/share/native/java/util/zip/zlib-1.1.3/infcodes.h - src/share/native/java/util/zip/zlib-1.1.3/inffast.c - src/share/native/java/util/zip/zlib-1.1.3/inffast.h - src/share/native/java/util/zip/zlib-1.1.3/inffixed.h - src/share/native/java/util/zip/zlib-1.1.3/inflate.c - src/share/native/java/util/zip/zlib-1.1.3/inftrees.c - src/share/native/java/util/zip/zlib-1.1.3/inftrees.h - src/share/native/java/util/zip/zlib-1.1.3/infutil.c - src/share/native/java/util/zip/zlib-1.1.3/infutil.h - src/share/native/java/util/zip/zlib-1.1.3/minigzip.c - src/share/native/java/util/zip/zlib-1.1.3/trees.c - src/share/native/java/util/zip/zlib-1.1.3/trees.h - src/share/native/java/util/zip/zlib-1.1.3/uncompr.c - src/share/native/java/util/zip/zlib-1.1.3/zadler32.c - src/share/native/java/util/zip/zlib-1.1.3/zconf.h - src/share/native/java/util/zip/zlib-1.1.3/zcrc32.c - src/share/native/java/util/zip/zlib-1.1.3/zlib.h - src/share/native/java/util/zip/zlib-1.1.3/zutil.c - src/share/native/java/util/zip/zlib-1.1.3/zutil.h - test/java/util/concurrent/LinkedBlockingQueue/LastElement.java - test/java/util/concurrent/LinkedBlockingQueue/OfferRemoveLoops.java Changeset: dfb5cf81d8cd Author: mchung Date: 2009-09-03 16:09 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/dfb5cf81d8cd Merge Changeset: b9b7f56bdfa3 Author: mchung Date: 2009-09-04 15:44 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/b9b7f56bdfa3 Merge Changeset: 466915134131 Author: mchung Date: 2009-09-08 12:59 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/466915134131 Merge Changeset: 0d50d40a4a39 Author: martin Date: 2009-09-08 14:33 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/0d50d40a4a39 6850958: Honor -XX:OnOutOfMemoryError when array size exceeds VM limit Summary: Test hotspot/jvmti fix 6850957 using ProcessBuilder test infrastructure Reviewed-by: tbell, dholmes, alanb, ysr ! test/java/lang/ProcessBuilder/Basic.java Changeset: 8252729d51a3 Author: mullan Date: 2009-09-09 09:54 -0400 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/8252729d51a3 6745437: Add option to only check revocation of end-entity certificate in a chain of certificates 6869739: Cannot check revocation of single certificate without validating the entire chain Reviewed-by: xuelei + src/share/classes/sun/security/action/GetBooleanSecurityPropertyAction.java ! src/share/classes/sun/security/provider/certpath/Builder.java ! src/share/classes/sun/security/provider/certpath/CertId.java ! src/share/classes/sun/security/provider/certpath/CrlRevocationChecker.java ! src/share/classes/sun/security/provider/certpath/DistributionPointFetcher.java ! src/share/classes/sun/security/provider/certpath/ForwardBuilder.java + src/share/classes/sun/security/provider/certpath/OCSP.java ! src/share/classes/sun/security/provider/certpath/OCSPChecker.java ! src/share/classes/sun/security/provider/certpath/OCSPRequest.java ! src/share/classes/sun/security/provider/certpath/OCSPResponse.java ! src/share/classes/sun/security/provider/certpath/PKIXCertPathValidator.java ! src/share/classes/sun/security/provider/certpath/SunCertPathBuilder.java ! src/share/classes/sun/security/x509/AccessDescription.java Changeset: 7b85ef3d752e Author: mullan Date: 2009-09-09 09:59 -0400 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/7b85ef3d752e Merge Changeset: f1eb4c28b313 Author: lancea Date: 2009-09-09 20:15 -0400 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/f1eb4c28b313 6737212: Fixed javadoc warning messages in RowSet classes Reviewed-by: darcy ! src/share/classes/com/sun/rowset/JdbcRowSetResourceBundle.java ! src/share/classes/com/sun/rowset/JoinRowSetImpl.java ! src/share/classes/com/sun/rowset/internal/WebRowSetXmlReader.java ! src/share/classes/javax/sql/rowset/BaseRowSet.java Changeset: 46406871599c Author: sherman Date: 2009-09-11 16:36 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/46406871599c 6881337: ZipEntry.setComment() was accidentally changed back to old spec/impl in jdk7-b64 Summary: restored the correct spec and implementation of setComment Reviewed-by: martin ! src/share/classes/java/util/zip/ZipEntry.java Changeset: 020a0fed38c9 Author: martin Date: 2009-09-12 15:30 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/020a0fed38c9 6881442: (reflect) Race condition in Class.getName() Summary: only read "name" field racily once Reviewed-by: darcy ! src/share/classes/java/lang/Class.java Changeset: 060c4c7082ef Author: alanb Date: 2009-09-14 15:29 +0100 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/060c4c7082ef 6529758: JVMTI Waiters demo crashes. Double free. Reviewed-by: ohair, tbell ! src/share/demo/jvmti/waiters/Agent.cpp ! src/share/demo/jvmti/waiters/Agent.hpp ! src/share/demo/jvmti/waiters/Monitor.cpp ! src/share/demo/jvmti/waiters/Monitor.hpp Changeset: aac01ec2cec4 Author: alanb Date: 2009-09-14 17:47 +0100 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/aac01ec2cec4 6876541: (file) Files.walkFileTree(...): no SecurityException if read access to the starting file is denied Reviewed-by: chegar ! src/share/classes/java/nio/file/FileTreeWalker.java ! src/share/classes/java/nio/file/Files.java + test/java/nio/file/Files/WalkWithSecurity.java + test/java/nio/file/Files/denyAll.policy + test/java/nio/file/Files/grantAll.policy + test/java/nio/file/Files/grantTopOnly.policy Changeset: eb19c5dc52bf Author: kevinw Date: 2009-09-14 20:55 +0100 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/eb19c5dc52bf 6842838: 64-bit failure in handling invalid manifest in launcher. Summary: Don't compare with hard-coded 32-bit -1 when checking zip fields. Reviewed-by: ksrini ! src/share/bin/parse_manifest.c + test/tools/launcher/6842838/CreateBadJar.java + test/tools/launcher/6842838/Test6842838.sh Changeset: c7e469ae3edb Author: mchung Date: 2009-09-14 13:37 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/c7e469ae3edb 6878481: Add performance counters in the JDK Summary: Added new performance counters in the JDK to track performance metrics Reviewed-by: alanb, dholmes, iris, forax, andrew ! make/java/java/FILES_java.gmk ! src/share/classes/java/lang/ClassLoader.java ! src/share/classes/java/net/URLClassLoader.java ! src/share/classes/java/util/zip/ZipFile.java + src/share/classes/sun/misc/PerfCounter.java ! src/windows/classes/sun/java2d/d3d/D3DGraphicsDevice.java Changeset: 0a3244fe7142 Author: mchung Date: 2009-09-14 13:38 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/0a3244fe7142 Merge Changeset: f0182203084a Author: dcubed Date: 2009-09-14 18:45 -0600 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/f0182203084a 6862295: JDWP threadid changes during debugging session (leading to ingored breakpoints) Summary: New test for the above fix. Reviewed-by: tbell + test/com/sun/jdi/BreakpointWithFullGC.sh Changeset: f78b7d9973b7 Author: dcubed Date: 2009-09-14 18:54 -0600 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/f78b7d9973b7 Merge Changeset: e8c2dd4b8bac Author: dcubed Date: 2009-09-15 22:11 -0600 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/e8c2dd4b8bac 6882363: 4/4 typos in java.util.logging javadocs Summary: Fix typos, some grammar and some inconsistencies in phrasing. Reviewed-by: tbell ! src/share/classes/java/util/logging/ErrorManager.java ! src/share/classes/java/util/logging/FileHandler.java ! src/share/classes/java/util/logging/Formatter.java ! src/share/classes/java/util/logging/Handler.java ! src/share/classes/java/util/logging/Level.java ! src/share/classes/java/util/logging/LogRecord.java ! src/share/classes/java/util/logging/Logger.java ! src/share/classes/java/util/logging/LoggingMXBean.java ! src/share/classes/java/util/logging/MemoryHandler.java ! src/share/classes/java/util/logging/StreamHandler.java Changeset: 81b85ea694f8 Author: tbell Date: 2009-09-16 09:23 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/81b85ea694f8 Merge Changeset: ee68feef41d2 Author: jccollet Date: 2009-09-18 10:51 +0200 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/ee68feef41d2 6737819: sun.misc.net.DefaultProxySelector doesn't use proxy setting to localhost Summary: Move default nonProxyHosts from hardcoded to property default value Reviewed-by: chegar ! src/share/classes/java/net/doc-files/net-properties.html ! src/share/classes/sun/net/spi/DefaultProxySelector.java ! src/share/lib/net.properties + test/java/net/ProxySelector/B6737819.java Changeset: 39c15c0a71f7 Author: andrew Date: 2009-09-10 19:04 +0100 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/39c15c0a71f7 6882745: Add DISABLE_INTREE_EC option to make new EC provider optional. Summary: Don't build the ec subdirectory when DISABLE_INTREE_EC is defined. Reviewed-by: vinnie ! make/sun/security/Makefile Changeset: f119e21c0ca7 Author: tbell Date: 2009-09-18 08:47 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/f119e21c0ca7 Merge Changeset: c9cbd2a09fd4 Author: chegar Date: 2009-09-18 16:24 +0100 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/c9cbd2a09fd4 6882609: Move default InMemoryCookieStore to java.net Summary: remove static dependency on sun.net.www.protocol.http Reviewed-by: alanb, jccollet ! make/sun/net/FILES_java.gmk ! src/share/classes/java/net/CookieManager.java + src/share/classes/java/net/InMemoryCookieStore.java - src/share/classes/sun/net/www/protocol/http/InMemoryCookieStore.java Changeset: 9cd7133ea287 Author: chegar Date: 2009-09-18 22:18 +0100 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/9cd7133ea287 6882594: Remove static dependancy on NTLM authentication Reviewed-by: alanb, weijun ! make/sun/net/FILES_java.gmk ! src/share/classes/sun/net/www/protocol/http/AuthCache.java ! src/share/classes/sun/net/www/protocol/http/AuthCacheValue.java + src/share/classes/sun/net/www/protocol/http/AuthScheme.java ! src/share/classes/sun/net/www/protocol/http/AuthenticationInfo.java ! src/share/classes/sun/net/www/protocol/http/BasicAuthentication.java ! src/share/classes/sun/net/www/protocol/http/DigestAuthentication.java ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java + src/share/classes/sun/net/www/protocol/http/NTLMAuthenticationProxy.java ! src/share/classes/sun/net/www/protocol/http/NegotiateAuthentication.java ! src/solaris/classes/sun/net/www/protocol/http/NTLMAuthentication.java ! src/windows/classes/sun/net/www/protocol/http/NTLMAuthentication.java Changeset: 45a343706f73 Author: chegar Date: 2009-09-18 22:19 +0100 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/45a343706f73 Merge Changeset: d3281fa8e46c Author: mchung Date: 2009-09-17 14:24 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/d3281fa8e46c 6882376: Add internal support for JRE implementation to eliminate the dependency on logging Summary: Added sun.util.logging.PlatformLogger for JRE implementation to log messages. Reviewed-by: alanb, naoto ! make/java/logging/Makefile ! src/share/classes/java/util/Currency.java ! src/share/classes/java/util/jar/Attributes.java ! src/share/classes/java/util/logging/LogManager.java ! src/share/classes/java/util/logging/LogRecord.java ! src/share/classes/sun/util/LocaleServiceProviderPool.java + src/share/classes/sun/util/logging/PlatformLogger.java ! src/windows/classes/java/util/prefs/WindowsPreferences.java + test/sun/util/logging/PlatformLoggerTest.java Changeset: 7b4e73ca6fd7 Author: mchung Date: 2009-09-18 17:27 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/7b4e73ca6fd7 Merge Changeset: 845fefff00a4 Author: vinnie Date: 2009-09-21 23:01 +0100 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/845fefff00a4 6884175: CR cleanup for 6840752: Provide out-of-the-box support for ECC algorithms Reviewed-by: wetmore ! make/sun/security/ec/Makefile ! make/sun/security/other/Makefile ! src/share/classes/sun/security/ec/ECDHKeyAgreement.java ! src/share/classes/sun/security/ec/ECDSASignature.java ! src/share/classes/sun/security/ec/ECKeyPairGenerator.java ! src/share/classes/sun/security/ec/SunEC.java ! src/share/classes/sun/security/ec/SunECEntries.java ! src/share/native/sun/security/ec/ECC_JNI.cpp - src/share/native/sun/security/ec/ec.c + src/share/native/sun/security/ec/impl/ec.c + src/share/native/sun/security/ec/impl/ec.h + src/share/native/sun/security/ec/impl/ec2.h + src/share/native/sun/security/ec/impl/ec2_163.c + src/share/native/sun/security/ec/impl/ec2_193.c + src/share/native/sun/security/ec/impl/ec2_233.c + src/share/native/sun/security/ec/impl/ec2_aff.c + src/share/native/sun/security/ec/impl/ec2_mont.c + src/share/native/sun/security/ec/impl/ec_naf.c + src/share/native/sun/security/ec/impl/ecc_impl.h + src/share/native/sun/security/ec/impl/ecdecode.c + src/share/native/sun/security/ec/impl/ecl-curve.h + src/share/native/sun/security/ec/impl/ecl-exp.h + src/share/native/sun/security/ec/impl/ecl-priv.h + src/share/native/sun/security/ec/impl/ecl.c + src/share/native/sun/security/ec/impl/ecl.h + src/share/native/sun/security/ec/impl/ecl_curve.c + src/share/native/sun/security/ec/impl/ecl_gf.c + src/share/native/sun/security/ec/impl/ecl_mult.c + src/share/native/sun/security/ec/impl/ecp.h + src/share/native/sun/security/ec/impl/ecp_192.c + src/share/native/sun/security/ec/impl/ecp_224.c + src/share/native/sun/security/ec/impl/ecp_256.c + src/share/native/sun/security/ec/impl/ecp_384.c + src/share/native/sun/security/ec/impl/ecp_521.c + src/share/native/sun/security/ec/impl/ecp_aff.c + src/share/native/sun/security/ec/impl/ecp_jac.c + src/share/native/sun/security/ec/impl/ecp_jm.c + src/share/native/sun/security/ec/impl/ecp_mont.c + src/share/native/sun/security/ec/impl/logtab.h + src/share/native/sun/security/ec/impl/mp_gf2m-priv.h + src/share/native/sun/security/ec/impl/mp_gf2m.c + src/share/native/sun/security/ec/impl/mp_gf2m.h + src/share/native/sun/security/ec/impl/mpi-config.h + src/share/native/sun/security/ec/impl/mpi-priv.h + src/share/native/sun/security/ec/impl/mpi.c + src/share/native/sun/security/ec/impl/mpi.h + src/share/native/sun/security/ec/impl/mplogic.c + src/share/native/sun/security/ec/impl/mplogic.h + src/share/native/sun/security/ec/impl/mpmontg.c + src/share/native/sun/security/ec/impl/mpprime.h + src/share/native/sun/security/ec/impl/oid.c + src/share/native/sun/security/ec/impl/secitem.c + src/share/native/sun/security/ec/impl/secoidt.h ! test/sun/security/ec/TestEC.java + test/sun/security/ec/certs/sunlabscerts.pem + test/sun/security/ec/keystore + test/sun/security/ec/truststore ! test/sun/security/pkcs11/ec/ReadCertificates.java ! test/sun/security/pkcs11/sslecc/CipherTest.java Changeset: 81dffe63c913 Author: weijun Date: 2009-09-22 10:01 +0800 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/81dffe63c913 6877357: IPv6 address does not work Reviewed-by: xuelei, alanb ! src/share/classes/sun/security/krb5/KrbKdcReq.java + test/sun/security/krb5/IPv6.java Changeset: 023063a403ed Author: chegar Date: 2009-09-22 14:42 +0100 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/023063a403ed 6882654: Remove dependency on java.util.concurrent from KeepAlive implementaion Reviewed-by: michaelm ! src/share/classes/sun/net/www/http/KeepAliveCache.java ! src/share/classes/sun/net/www/http/KeepAliveStream.java ! src/share/classes/sun/net/www/http/KeepAliveStreamCleaner.java Changeset: 44ccaa4bb8a0 Author: chegar Date: 2009-09-22 14:49 +0100 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/44ccaa4bb8a0 6882384: Update http protocol handler to use PlatformLogger Reviewed-by: jccollet, alanb ! src/share/classes/sun/net/www/http/HttpCapture.java ! src/share/classes/sun/net/www/http/HttpClient.java ! src/share/classes/sun/net/www/protocol/http/HttpLogFormatter.java ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java ! src/share/classes/sun/net/www/protocol/http/NTLMAuthenticationProxy.java ! src/share/classes/sun/net/www/protocol/http/NegotiateAuthentication.java ! src/share/classes/sun/util/logging/PlatformLogger.java Changeset: b8004f6f4812 Author: kevinw Date: 2009-09-22 17:01 +0100 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/b8004f6f4812 6882768: (launcher) test for 6842838 is broken Summary: Testcase correction. Reviewed-by: ksrini ! test/tools/launcher/6842838/Test6842838.sh Changeset: f708138c9aca Author: kevinw Date: 2009-09-22 17:16 +0100 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/f708138c9aca Merge Changeset: 59b45d636384 Author: xdono Date: 2009-10-02 11:26 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/59b45d636384 Added tag jdk7-b73 for changeset f708138c9aca ! .hgtags Changeset: 8e5d45fc8d1e Author: jgodinez Date: 2009-07-01 12:07 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/8e5d45fc8d1e 6848799: Reg-test java/awt/print/PageFormat/PageFormatFromAttributes.java fails on Rhel_5 Reviewed-by: tdv, prr ! src/solaris/classes/sun/print/IPPPrintService.java + test/java/awt/print/PageFormat/PageFormatFromAttributes.java Changeset: 837bb8760bad Author: yan Date: 2009-07-13 09:37 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/837bb8760bad Merge - src/share/classes/java/nio/file/DirectoryStreamFilters.java - src/share/classes/java/nio/file/FileAction.java - src/share/classes/java/nio/file/spi/AbstractPath.java - src/share/classes/sun/io/ByteToCharMS932DB.java - src/share/classes/sun/io/CharToByteMS932DB.java - src/share/classes/sun/nio/cs/ext/EUC_CN.java - src/share/classes/sun/nio/cs/ext/EUC_KR.java - src/share/classes/sun/nio/cs/ext/GBK.java - src/share/classes/sun/nio/cs/ext/Johab.java - src/share/classes/sun/nio/cs/ext/MS932.java - src/share/classes/sun/nio/cs/ext/MS932DB.java - src/share/classes/sun/nio/cs/ext/MS936.java - src/share/classes/sun/nio/cs/ext/MS949.java - src/share/classes/sun/nio/cs/ext/MS950.java - src/share/classes/sun/nio/fs/AbstractFileStoreSpaceAttributeView.java - src/share/classes/sun/nio/fs/MimeType.java - src/share/classes/sun/swing/AccessibleMethod.java - test/java/nio/file/DirectoryStream/Filters.java - test/java/nio/file/Files/content_type.sh - test/java/nio/file/Path/temporary_files.sh - test/java/nio/file/attribute/Attributes/Basic.java Changeset: a0b315ecdc78 Author: rkennke Date: 2009-07-22 15:52 +0200 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/a0b315ecdc78 6857358: Two testcases are failing in jdk7 b64 pit build with java.security.AccessControlException Summary: Try to load GraphicsEnvironment with bootclassloader first, only then try app classloader. Reviewed-by: prr, tdv, igor ! src/share/classes/java/awt/GraphicsEnvironment.java Changeset: 9fa696ed1f38 Author: jgodinez Date: 2009-07-30 12:25 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/9fa696ed1f38 Merge Changeset: 7fe0497ee5b5 Author: jgodinez Date: 2009-08-04 17:25 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/7fe0497ee5b5 6829673: ThinLineTest: A line < 1 pixel disappears. Reviewed-by: igor, prr Contributed-by: rkennke ! src/share/classes/sun/java2d/pisces/PiscesRenderingEngine.java + test/sun/pisces/ThinLineTest.java Changeset: 64b0c953635d Author: rkennke Date: 2009-08-07 18:31 +0200 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/64b0c953635d 6795908: Refactor FontManager Reviewed-by: prr, igor ! make/sun/awt/FILES_export_windows.gmk ! make/sun/awt/make.depend ! make/sun/awt/mapfile-mawt-vers ! make/sun/awt/mapfile-vers-linux ! make/sun/font/mapfile-vers ! make/sun/font/mapfile-vers.openjdk ! make/sun/headless/mapfile-vers ! make/sun/xawt/mapfile-vers ! src/share/classes/com/sun/java/swing/plaf/gtk/PangoFonts.java ! src/share/classes/com/sun/java/swing/plaf/windows/WindowsLookAndFeel.java ! src/share/classes/java/awt/Component.java ! src/share/classes/java/awt/Font.java ! src/share/classes/java/awt/GraphicsEnvironment.java ! src/share/classes/javax/swing/plaf/nimbus/Defaults.template ! src/share/classes/javax/swing/text/StyleContext.java ! src/share/classes/sun/awt/FontConfiguration.java ! src/share/classes/sun/font/CMap.java ! src/share/classes/sun/font/CompositeFont.java ! src/share/classes/sun/font/CompositeGlyphMapper.java ! src/share/classes/sun/font/FileFont.java ! src/share/classes/sun/font/FileFontStrike.java ! src/share/classes/sun/font/FontDesignMetrics.java ! src/share/classes/sun/font/FontFamily.java ! src/share/classes/sun/font/FontManager.java ! src/share/classes/sun/font/FontManagerNativeLibrary.java ! src/share/classes/sun/font/FontResolver.java ! src/share/classes/sun/font/FontScaler.java ! src/share/classes/sun/font/FreetypeFontScaler.java ! src/share/classes/sun/font/GlyphLayout.java ! src/share/classes/sun/font/PhysicalStrike.java ! src/share/classes/sun/font/StandardGlyphVector.java ! src/share/classes/sun/font/StrikeCache.java ! src/share/classes/sun/font/TrueTypeFont.java ! src/share/classes/sun/font/TrueTypeGlyphMapper.java ! src/share/classes/sun/font/Type1Font.java ! src/share/classes/sun/font/Type1GlyphMapper.java ! src/share/classes/sun/java2d/SunGraphics2D.java ! src/share/classes/sun/java2d/SunGraphicsEnvironment.java ! src/share/classes/sun/print/PSPrinterJob.java ! src/share/classes/sun/print/PathGraphics.java ! src/share/classes/sun/swing/SwingUtilities2.java ! src/share/native/sun/font/sunFont.c ! src/share/native/sun/font/sunfontids.h ! src/solaris/classes/sun/awt/X11/XToolkit.java ! src/solaris/classes/sun/awt/X11GraphicsEnvironment.java ! src/solaris/classes/sun/awt/motif/MFontConfiguration.java ! src/solaris/classes/sun/awt/motif/MToolkit.java ! src/solaris/classes/sun/font/FcFontConfiguration.java ! src/solaris/classes/sun/font/NativeFont.java ! src/solaris/classes/sun/font/NativeStrike.java ! src/solaris/native/sun/awt/fontpath.c ! src/windows/classes/sun/awt/Win32GraphicsEnvironment.java ! src/windows/classes/sun/awt/windows/WFontConfiguration.java ! src/windows/classes/sun/awt/windows/WPathGraphics.java ! src/windows/classes/sun/awt/windows/WPrinterJob.java ! src/windows/classes/sun/awt/windows/WToolkit.java ! src/windows/native/sun/font/fontpath.c ! src/windows/native/sun/windows/awt_Win32GraphicsEnv.cpp Changeset: 92607d652d7a Author: rkennke Date: 2009-08-07 19:36 +0200 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/92607d652d7a 6869705: Missing files of CR6795908, FontManager refactoring Reviewed-by: prr, igor + src/share/classes/sun/font/FontAccess.java + src/share/classes/sun/font/FontManagerFactory.java + src/share/classes/sun/font/FontManagerForSGE.java + src/share/classes/sun/font/FontUtilities.java + src/share/classes/sun/font/SunFontManager.java + src/solaris/classes/sun/awt/X11FontManager.java + src/solaris/classes/sun/font/FontConfigManager.java + src/windows/classes/sun/awt/Win32FontManager.java Changeset: 11b38980893c Author: rkennke Date: 2009-08-12 17:21 +0200 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/11b38980893c 6870238: Font2DTest fails on Debian after FontManager refactoring Summary: Use fontManager field instead of querying the FontManagerFactory Reviewed-by: igor, prr ! src/solaris/classes/sun/font/FcFontConfiguration.java Changeset: a389af17df10 Author: prr Date: 2009-08-14 14:25 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/a389af17df10 6867603: sun.font.FontManager.getDefaultPlatformFont throws NPE in OpenJDK on Solaris 10 10/08 Reviewed-by: igor, jgodinez ! src/solaris/classes/sun/font/FontConfigManager.java ! src/solaris/native/sun/awt/fontpath.c Changeset: e90f58148115 Author: jgodinez Date: 2009-09-16 19:36 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/e90f58148115 Merge - make/javax/swing/plaf/nimbus/Makefile - make/tools/swing-nimbus/Makefile - make/tools/swing-nimbus/classes/org/jdesktop/beans/AbstractBean.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/BezierControlPoint.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/BlendingMode.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/Canvas.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/ControlPoint.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/Designer.jibx.xml - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/DoubleBean.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/EllipseShape.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/GraphicsHelper.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/Layer.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/LayerContainer.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/PaintedShape.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/PathShape.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/RectangleShape.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/SimpleShape.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/TemplateLayer.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/DropShadowEffect.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/Effect.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/EffectUtils.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/EffectUtilsTemp.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/InnerGlowEffect.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/InnerShadowEffect.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/OuterGlowEffect.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/ShadowEffect.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/font/Typeface.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/jibxhelpers/CanvasMapper.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/jibxhelpers/ColorMapper.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/jibxhelpers/DimensionMapper.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/jibxhelpers/InsetsMapper.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/AbstractGradient.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/Gradient.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/GradientStop.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/Matte.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/PaintModel.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/RadialGradient.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/Texture.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/utils/HasPath.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/utils/HasResources.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/utils/HasUIDefaults.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/generator/DefaultsGenerator.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/generator/Generator.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/generator/GeneratorUtils.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/generator/ObjectCodeConvertors.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/generator/PainterGenerator.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/generator/TemplateWriter.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/CustomUIDefault.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/HasUIStyle.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/PainterBorder.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/SynthModel.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/SynthModel.jibx.xml - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIBorder.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIColor.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIComponent.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIDefault.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIDimension.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIFont.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIIcon.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIIconRegion.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIInsets.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIPaint.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIProperty.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIRegion.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIState.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIStateType.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIStyle.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/jibxhelpers/BorderMapper.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/jibxhelpers/ClassConverter.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/jibxhelpers/ClassMapper.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/jibxhelpers/FontMapper.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/jibxhelpers/UIPropertyMapper.java - src/share/classes/com/sun/crypto/provider/JarVerifier.java ! src/share/classes/com/sun/java/swing/plaf/windows/WindowsLookAndFeel.java ! src/share/classes/java/awt/Component.java - src/share/classes/javax/swing/plaf/basic/DesktopIconMover.java ! src/share/classes/javax/swing/plaf/nimbus/Defaults.template - src/share/classes/sun/nio/ch/AbstractFuture.java - src/share/classes/sun/security/pkcs11/JarVerifier.java ! src/share/classes/sun/swing/SwingUtilities2.java - src/share/native/java/util/zip/zlib-1.1.3/ChangeLog - src/share/native/java/util/zip/zlib-1.1.3/README - src/share/native/java/util/zip/zlib-1.1.3/compress.c - src/share/native/java/util/zip/zlib-1.1.3/deflate.c - src/share/native/java/util/zip/zlib-1.1.3/deflate.h - src/share/native/java/util/zip/zlib-1.1.3/doc/algorithm.doc - src/share/native/java/util/zip/zlib-1.1.3/example.c - src/share/native/java/util/zip/zlib-1.1.3/gzio.c - src/share/native/java/util/zip/zlib-1.1.3/infblock.c - src/share/native/java/util/zip/zlib-1.1.3/infblock.h - src/share/native/java/util/zip/zlib-1.1.3/infcodes.c - src/share/native/java/util/zip/zlib-1.1.3/infcodes.h - src/share/native/java/util/zip/zlib-1.1.3/inffast.c - src/share/native/java/util/zip/zlib-1.1.3/inffast.h - src/share/native/java/util/zip/zlib-1.1.3/inffixed.h - src/share/native/java/util/zip/zlib-1.1.3/inflate.c - src/share/native/java/util/zip/zlib-1.1.3/inftrees.c - src/share/native/java/util/zip/zlib-1.1.3/inftrees.h - src/share/native/java/util/zip/zlib-1.1.3/infutil.c - src/share/native/java/util/zip/zlib-1.1.3/infutil.h - src/share/native/java/util/zip/zlib-1.1.3/minigzip.c - src/share/native/java/util/zip/zlib-1.1.3/trees.c - src/share/native/java/util/zip/zlib-1.1.3/trees.h - src/share/native/java/util/zip/zlib-1.1.3/uncompr.c - src/share/native/java/util/zip/zlib-1.1.3/zadler32.c - src/share/native/java/util/zip/zlib-1.1.3/zconf.h - src/share/native/java/util/zip/zlib-1.1.3/zcrc32.c - src/share/native/java/util/zip/zlib-1.1.3/zlib.h - src/share/native/java/util/zip/zlib-1.1.3/zutil.c - src/share/native/java/util/zip/zlib-1.1.3/zutil.h ! src/solaris/classes/sun/awt/X11/XToolkit.java - src/windows/classes/sun/security/mscapi/JarVerifier.java - test/java/util/concurrent/ConcurrentLinkedQueue/ConcurrentQueueLoops.java - test/java/util/concurrent/ConcurrentLinkedQueue/LoopHelpers.java - test/java/util/concurrent/LinkedBlockingQueue/LastElement.java - test/java/util/concurrent/LinkedBlockingQueue/OfferRemoveLoops.java Changeset: 27d58a02bb9d Author: srl Date: 2009-09-28 11:52 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/27d58a02bb9d 6795060: VM crash on Linux in ICU layout library when processing \u0DDD (Sinhalese) Reviewed-by: igor, prr ! src/share/native/sun/font/layout/IndicClassTables.cpp + test/java/awt/font/TextLayout/TestSinhalaChar.java Changeset: e6ced7714609 Author: jgodinez Date: 2009-09-29 09:02 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/e6ced7714609 Merge - src/share/classes/sun/net/www/protocol/http/InMemoryCookieStore.java - src/share/native/sun/security/ec/ec.c Changeset: c74d38ef118c Author: srl Date: 2009-09-29 14:06 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/c74d38ef118c 6501644: sync LayoutEngine *code* structure to match ICU Reviewed-by: prr ! make/sun/font/Makefile ! src/share/native/sun/font/layout/AlternateSubstSubtables.cpp ! src/share/native/sun/font/layout/AlternateSubstSubtables.h ! src/share/native/sun/font/layout/AnchorTables.cpp ! src/share/native/sun/font/layout/AnchorTables.h ! src/share/native/sun/font/layout/ArabicLayoutEngine.cpp ! src/share/native/sun/font/layout/ArabicLayoutEngine.h ! src/share/native/sun/font/layout/ArabicShaping.cpp ! src/share/native/sun/font/layout/ArabicShaping.h ! src/share/native/sun/font/layout/AttachmentPosnSubtables.h ! src/share/native/sun/font/layout/CanonData.cpp ! src/share/native/sun/font/layout/CanonShaping.cpp ! src/share/native/sun/font/layout/CanonShaping.h ! src/share/native/sun/font/layout/CharSubstitutionFilter.h ! src/share/native/sun/font/layout/ClassDefinitionTables.cpp ! src/share/native/sun/font/layout/ClassDefinitionTables.h ! src/share/native/sun/font/layout/ContextualGlyphInsertion.h ! src/share/native/sun/font/layout/ContextualGlyphSubstProc.cpp ! src/share/native/sun/font/layout/ContextualGlyphSubstProc.h ! src/share/native/sun/font/layout/ContextualGlyphSubstitution.h ! src/share/native/sun/font/layout/ContextualSubstSubtables.cpp ! src/share/native/sun/font/layout/ContextualSubstSubtables.h ! src/share/native/sun/font/layout/CoverageTables.cpp ! src/share/native/sun/font/layout/CoverageTables.h ! src/share/native/sun/font/layout/CursiveAttachmentSubtables.cpp ! src/share/native/sun/font/layout/CursiveAttachmentSubtables.h ! src/share/native/sun/font/layout/DefaultCharMapper.h ! src/share/native/sun/font/layout/DeviceTables.cpp ! src/share/native/sun/font/layout/DeviceTables.h ! src/share/native/sun/font/layout/ExtensionSubtables.cpp ! src/share/native/sun/font/layout/ExtensionSubtables.h ! src/share/native/sun/font/layout/Features.cpp ! src/share/native/sun/font/layout/Features.h ! src/share/native/sun/font/layout/GDEFMarkFilter.cpp ! src/share/native/sun/font/layout/GDEFMarkFilter.h ! src/share/native/sun/font/layout/GXLayoutEngine.cpp ! src/share/native/sun/font/layout/GXLayoutEngine.h ! src/share/native/sun/font/layout/GlyphDefinitionTables.cpp ! src/share/native/sun/font/layout/GlyphDefinitionTables.h ! src/share/native/sun/font/layout/GlyphIterator.cpp ! src/share/native/sun/font/layout/GlyphIterator.h ! src/share/native/sun/font/layout/GlyphLookupTables.cpp ! src/share/native/sun/font/layout/GlyphLookupTables.h ! src/share/native/sun/font/layout/GlyphPositionAdjustments.cpp ! src/share/native/sun/font/layout/GlyphPositionAdjustments.h ! src/share/native/sun/font/layout/GlyphPositioningTables.cpp ! src/share/native/sun/font/layout/GlyphPositioningTables.h ! src/share/native/sun/font/layout/GlyphPosnLookupProc.cpp ! src/share/native/sun/font/layout/GlyphPosnLookupProc.h ! src/share/native/sun/font/layout/GlyphSubstLookupProc.cpp ! src/share/native/sun/font/layout/GlyphSubstLookupProc.h ! src/share/native/sun/font/layout/GlyphSubstitutionTables.cpp ! src/share/native/sun/font/layout/GlyphSubstitutionTables.h ! src/share/native/sun/font/layout/HanLayoutEngine.cpp ! src/share/native/sun/font/layout/HanLayoutEngine.h ! src/share/native/sun/font/layout/IndicClassTables.cpp ! src/share/native/sun/font/layout/IndicLayoutEngine.cpp ! src/share/native/sun/font/layout/IndicLayoutEngine.h ! src/share/native/sun/font/layout/IndicRearrangement.h ! src/share/native/sun/font/layout/IndicRearrangementProcessor.cpp ! src/share/native/sun/font/layout/IndicRearrangementProcessor.h ! src/share/native/sun/font/layout/IndicReordering.cpp ! src/share/native/sun/font/layout/IndicReordering.h ! src/share/native/sun/font/layout/KernTable.cpp ! src/share/native/sun/font/layout/KernTable.h ! src/share/native/sun/font/layout/KhmerLayoutEngine.cpp ! src/share/native/sun/font/layout/KhmerLayoutEngine.h ! src/share/native/sun/font/layout/KhmerReordering.cpp ! src/share/native/sun/font/layout/KhmerReordering.h ! src/share/native/sun/font/layout/LEFontInstance.cpp ! src/share/native/sun/font/layout/LEFontInstance.h ! src/share/native/sun/font/layout/LEGlyphFilter.h ! src/share/native/sun/font/layout/LEGlyphStorage.cpp ! src/share/native/sun/font/layout/LEGlyphStorage.h ! src/share/native/sun/font/layout/LEInsertionList.cpp ! src/share/native/sun/font/layout/LEInsertionList.h ! src/share/native/sun/font/layout/LELanguages.h ! src/share/native/sun/font/layout/LEScripts.h + src/share/native/sun/font/layout/LEStandalone.h ! src/share/native/sun/font/layout/LESwaps.h ! src/share/native/sun/font/layout/LETypes.h ! src/share/native/sun/font/layout/LayoutEngine.cpp ! src/share/native/sun/font/layout/LayoutEngine.h ! src/share/native/sun/font/layout/LayoutTables.h ! src/share/native/sun/font/layout/LigatureSubstProc.cpp ! src/share/native/sun/font/layout/LigatureSubstProc.h ! src/share/native/sun/font/layout/LigatureSubstSubtables.cpp ! src/share/native/sun/font/layout/LigatureSubstSubtables.h ! src/share/native/sun/font/layout/LigatureSubstitution.h ! src/share/native/sun/font/layout/LookupProcessor.cpp ! src/share/native/sun/font/layout/LookupProcessor.h ! src/share/native/sun/font/layout/LookupTables.cpp ! src/share/native/sun/font/layout/LookupTables.h ! src/share/native/sun/font/layout/Lookups.cpp ! src/share/native/sun/font/layout/Lookups.h ! src/share/native/sun/font/layout/MPreFixups.cpp ! src/share/native/sun/font/layout/MPreFixups.h ! src/share/native/sun/font/layout/MarkArrays.cpp ! src/share/native/sun/font/layout/MarkArrays.h ! src/share/native/sun/font/layout/MarkToBasePosnSubtables.cpp ! src/share/native/sun/font/layout/MarkToBasePosnSubtables.h ! src/share/native/sun/font/layout/MarkToLigaturePosnSubtables.cpp ! src/share/native/sun/font/layout/MarkToLigaturePosnSubtables.h ! src/share/native/sun/font/layout/MarkToMarkPosnSubtables.cpp ! src/share/native/sun/font/layout/MarkToMarkPosnSubtables.h ! src/share/native/sun/font/layout/MirroredCharData.cpp ! src/share/native/sun/font/layout/MorphStateTables.h ! src/share/native/sun/font/layout/MorphTables.cpp ! src/share/native/sun/font/layout/MorphTables.h ! src/share/native/sun/font/layout/MultipleSubstSubtables.cpp ! src/share/native/sun/font/layout/MultipleSubstSubtables.h ! src/share/native/sun/font/layout/NonContextualGlyphSubst.h ! src/share/native/sun/font/layout/NonContextualGlyphSubstProc.cpp ! src/share/native/sun/font/layout/NonContextualGlyphSubstProc.h ! src/share/native/sun/font/layout/OpenTypeLayoutEngine.cpp ! src/share/native/sun/font/layout/OpenTypeLayoutEngine.h ! src/share/native/sun/font/layout/OpenTypeTables.h ! src/share/native/sun/font/layout/OpenTypeUtilities.cpp ! src/share/native/sun/font/layout/OpenTypeUtilities.h ! src/share/native/sun/font/layout/PairPositioningSubtables.cpp ! src/share/native/sun/font/layout/PairPositioningSubtables.h ! src/share/native/sun/font/layout/ScriptAndLanguage.cpp ! src/share/native/sun/font/layout/ScriptAndLanguage.h ! src/share/native/sun/font/layout/ScriptAndLanguageTags.cpp ! src/share/native/sun/font/layout/ScriptAndLanguageTags.h ! src/share/native/sun/font/layout/SegmentArrayProcessor.cpp ! src/share/native/sun/font/layout/SegmentArrayProcessor.h ! src/share/native/sun/font/layout/SegmentSingleProcessor.cpp ! src/share/native/sun/font/layout/SegmentSingleProcessor.h ! src/share/native/sun/font/layout/ShapingTypeData.cpp ! src/share/native/sun/font/layout/SimpleArrayProcessor.cpp ! src/share/native/sun/font/layout/SimpleArrayProcessor.h ! src/share/native/sun/font/layout/SinglePositioningSubtables.cpp ! src/share/native/sun/font/layout/SinglePositioningSubtables.h ! src/share/native/sun/font/layout/SingleSubstitutionSubtables.cpp ! src/share/native/sun/font/layout/SingleSubstitutionSubtables.h ! src/share/native/sun/font/layout/SingleTableProcessor.cpp ! src/share/native/sun/font/layout/SingleTableProcessor.h ! src/share/native/sun/font/layout/StateTableProcessor.cpp ! src/share/native/sun/font/layout/StateTableProcessor.h ! src/share/native/sun/font/layout/StateTables.h ! src/share/native/sun/font/layout/SubstitutionLookups.cpp ! src/share/native/sun/font/layout/SubstitutionLookups.h ! src/share/native/sun/font/layout/SubtableProcessor.cpp ! src/share/native/sun/font/layout/SubtableProcessor.h ! src/share/native/sun/font/layout/ThaiLayoutEngine.cpp ! src/share/native/sun/font/layout/ThaiLayoutEngine.h ! src/share/native/sun/font/layout/ThaiShaping.cpp ! src/share/native/sun/font/layout/ThaiShaping.h ! src/share/native/sun/font/layout/ThaiStateTables.cpp ! src/share/native/sun/font/layout/TrimmedArrayProcessor.cpp ! src/share/native/sun/font/layout/TrimmedArrayProcessor.h ! src/share/native/sun/font/layout/ValueRecords.cpp ! src/share/native/sun/font/layout/ValueRecords.h Changeset: e8a764450aa7 Author: srl Date: 2009-09-29 15:31 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/e8a764450aa7 Merge - src/share/classes/sun/net/www/protocol/http/InMemoryCookieStore.java - src/share/native/sun/security/ec/ec.c Changeset: e8b1b4c00e8a Author: srl Date: 2009-09-29 16:32 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/e8b1b4c00e8a 6886718: missing license info Reviewed-by: igor, prr ! test/java/awt/font/TextLayout/TestSinhalaChar.java Changeset: ec67b240b727 Author: mchung Date: 2009-09-29 16:03 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/ec67b240b727 6879044: Eliminate the dependency on logging from the AWT/2D/Swing classes Summary: Replace calls to Logger with sun.util.logging.PlatformLogger Reviewed-by: prr, art, alexp, dcherepanov, igor, dav, anthony ! src/share/classes/java/awt/AWTEvent.java ! src/share/classes/java/awt/AttributeValue.java ! src/share/classes/java/awt/Component.java ! src/share/classes/java/awt/Container.java ! src/share/classes/java/awt/ContainerOrderFocusTraversalPolicy.java ! src/share/classes/java/awt/Cursor.java ! src/share/classes/java/awt/DefaultKeyboardFocusManager.java ! src/share/classes/java/awt/EventDispatchThread.java ! src/share/classes/java/awt/EventQueue.java ! src/share/classes/java/awt/KeyboardFocusManager.java ! src/share/classes/java/awt/SplashScreen.java ! src/share/classes/java/awt/Toolkit.java ! src/share/classes/java/awt/Window.java ! src/share/classes/java/awt/event/InputEvent.java ! src/share/classes/javax/swing/BufferStrategyPaintManager.java ! src/share/classes/javax/swing/SortingFocusTraversalPolicy.java ! src/share/classes/sun/awt/AWTAutoShutdown.java ! src/share/classes/sun/awt/AppContext.java ! src/share/classes/sun/awt/ComponentAccessor.java ! src/share/classes/sun/awt/DebugSettings.java ! src/share/classes/sun/awt/FontConfiguration.java ! src/share/classes/sun/awt/KeyboardFocusManagerPeerImpl.java ! src/share/classes/sun/awt/ScrollPaneWheelScroller.java ! src/share/classes/sun/awt/SunDisplayChanger.java ! src/share/classes/sun/awt/SunGraphicsCallback.java ! src/share/classes/sun/awt/SunToolkit.java ! src/share/classes/sun/awt/WindowAccessor.java ! src/share/classes/sun/awt/datatransfer/DataTransferer.java ! src/share/classes/sun/awt/dnd/SunDropTargetContextPeer.java ! src/share/classes/sun/awt/im/InputContext.java ! src/share/classes/sun/font/FontUtilities.java ! src/share/classes/sun/font/SunFontManager.java ! src/share/classes/sun/font/TrueTypeFont.java ! src/share/classes/sun/java2d/SunGraphicsEnvironment.java ! src/solaris/classes/sun/awt/X11/InfoWindow.java ! src/solaris/classes/sun/awt/X11/ListHelper.java ! src/solaris/classes/sun/awt/X11/UnsafeXDisposerRecord.java ! src/solaris/classes/sun/awt/X11/XAWTXSettings.java ! src/solaris/classes/sun/awt/X11/XBaseMenuWindow.java ! src/solaris/classes/sun/awt/X11/XBaseWindow.java ! src/solaris/classes/sun/awt/X11/XCheckboxMenuItemPeer.java ! src/solaris/classes/sun/awt/X11/XCheckboxPeer.java ! src/solaris/classes/sun/awt/X11/XChoicePeer.java ! src/solaris/classes/sun/awt/X11/XComponentPeer.java ! src/solaris/classes/sun/awt/X11/XContentWindow.java ! src/solaris/classes/sun/awt/X11/XDecoratedPeer.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/XDropTargetContextPeer.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/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/XFileDialogPeer.java ! src/solaris/classes/sun/awt/X11/XFocusProxyWindow.java ! src/solaris/classes/sun/awt/X11/XFramePeer.java ! src/solaris/classes/sun/awt/X11/XIconWindow.java ! src/solaris/classes/sun/awt/X11/XInputMethod.java ! src/solaris/classes/sun/awt/X11/XKeyboardFocusManagerPeer.java ! src/solaris/classes/sun/awt/X11/XKeysym.java ! src/solaris/classes/sun/awt/X11/XListPeer.java ! src/solaris/classes/sun/awt/X11/XMSelection.java ! src/solaris/classes/sun/awt/X11/XMenuBarPeer.java ! src/solaris/classes/sun/awt/X11/XMenuItemPeer.java ! src/solaris/classes/sun/awt/X11/XMenuPeer.java ! src/solaris/classes/sun/awt/X11/XMenuWindow.java ! src/solaris/classes/sun/awt/X11/XNETProtocol.java ! src/solaris/classes/sun/awt/X11/XPopupMenuPeer.java ! src/solaris/classes/sun/awt/X11/XProtocol.java ! src/solaris/classes/sun/awt/X11/XQueryTree.java ! src/solaris/classes/sun/awt/X11/XScrollbar.java ! src/solaris/classes/sun/awt/X11/XScrollbarPeer.java ! src/solaris/classes/sun/awt/X11/XSystemTrayPeer.java ! src/solaris/classes/sun/awt/X11/XTextFieldPeer.java ! src/solaris/classes/sun/awt/X11/XToolkit.java ! src/solaris/classes/sun/awt/X11/XTrayIconPeer.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/XWrapperBase.java ! src/solaris/classes/sun/awt/X11/generator/WrapperGenerator.java ! src/solaris/classes/sun/awt/X11/keysym2ucs.h ! src/solaris/classes/sun/awt/X11FontManager.java ! src/solaris/classes/sun/awt/X11GraphicsEnvironment.java ! src/solaris/classes/sun/awt/X11InputMethod.java ! src/solaris/classes/sun/awt/motif/MFontConfiguration.java ! src/solaris/classes/sun/awt/motif/MToolkit.java ! src/solaris/classes/sun/font/FcFontConfiguration.java ! src/solaris/classes/sun/font/FontConfigManager.java ! src/windows/classes/sun/awt/windows/WComponentPeer.java ! src/windows/classes/sun/awt/windows/WDesktopProperties.java ! src/windows/classes/sun/awt/windows/WMenuItemPeer.java ! src/windows/classes/sun/awt/windows/WPanelPeer.java ! src/windows/classes/sun/awt/windows/WScrollPanePeer.java ! src/windows/classes/sun/awt/windows/WToolkit.java ! src/windows/classes/sun/awt/windows/WWindowPeer.java Changeset: 5b52851b0927 Author: mchung Date: 2009-09-29 22:49 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/5b52851b0927 Merge Changeset: 633806cdab51 Author: jgodinez Date: 2009-10-05 18:22 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/633806cdab51 Merge Changeset: c715b68cdcaf Author: darcy Date: 2009-09-22 16:11 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/c715b68cdcaf 6468534: (reflect) Exception types cannot be parameterized, rephrase getGenericExceptionTypes. Reviewed-by: alanb ! src/share/classes/java/lang/reflect/Constructor.java ! src/share/classes/java/lang/reflect/Method.java Changeset: bbb543254c63 Author: martin Date: 2009-09-22 18:30 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/bbb543254c63 4245470: algorithm of java.lang.Byte.hashCode() is not specified Summary: Specify some hashCode methods are equivalent to intValue Reviewed-by: darcy ! src/share/classes/java/lang/Byte.java ! src/share/classes/java/lang/Character.java ! src/share/classes/java/lang/Short.java + test/java/lang/HashCode.java Changeset: eb92c939b8a7 Author: martin Date: 2009-09-22 18:30 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/eb92c939b8a7 6582946: Add suite of compare(T, T) methods for ints, longs etc Reviewed-by: darcy Contributed-by: kevinb at google.com ! src/share/classes/java/lang/Boolean.java ! src/share/classes/java/lang/Byte.java ! src/share/classes/java/lang/Character.java ! src/share/classes/java/lang/Integer.java ! src/share/classes/java/lang/Long.java ! src/share/classes/java/lang/Short.java + test/java/lang/Compare.java Changeset: bd928aefe692 Author: weijun Date: 2009-09-24 21:35 +0800 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/bd928aefe692 6885166: regression test for 6877357 (IPv6 address does not work) error (timed out) Reviewed-by: xuelei ! test/sun/security/krb5/IPv6.java Changeset: 5b1aaf2d7504 Author: ptisnovs Date: 2009-09-30 11:49 +0200 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/5b1aaf2d7504 6884837: JTReg test SetOutgoingIf is not correct Summary: Added check of network interfaces status Reviewed-by: alanb, chegar ! test/java/net/MulticastSocket/SetOutgoingIf.java Changeset: dd724911c90a Author: michaelm Date: 2009-09-29 10:00 +0100 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/dd724911c90a 6886108: Test case B4933582 binding to fixed port number Reviewed-by: chegar ! test/java/net/Authenticator/B4933582.java ! test/sun/net/www/httptest/HttpTransaction.java ! test/sun/security/ssl/sun/net/www/httpstest/HttpTransaction.java Changeset: 896cbd9c91f4 Author: michaelm Date: 2009-10-01 11:25 +0100 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/896cbd9c91f4 Merge Changeset: 527ad9cbc9cf Author: weijun Date: 2009-10-02 18:44 +0800 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/527ad9cbc9cf 6324292: keytool -help is unhelpful Reviewed-by: xuelei, mullan ! src/share/classes/sun/security/tools/KeyTool.java ! src/share/classes/sun/security/util/Resources.java + test/sun/security/tools/keytool/newhelp.sh Changeset: 56bad48e2810 Author: weijun Date: 2009-10-02 18:47 +0800 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/56bad48e2810 6862679: ESC: AD Authentication with user with umlauts fails Reviewed-by: valeriep, mullan ! src/share/classes/sun/security/krb5/Credentials.java ! src/share/classes/sun/security/krb5/KrbAsReq.java ! src/share/classes/sun/security/krb5/PrincipalName.java ! src/share/classes/sun/security/krb5/Realm.java ! src/share/classes/sun/security/krb5/internal/ETypeInfo.java ! src/share/classes/sun/security/krb5/internal/ETypeInfo2.java ! src/share/classes/sun/security/krb5/internal/KRBError.java ! src/share/classes/sun/security/krb5/internal/crypto/Des.java + src/share/classes/sun/security/krb5/internal/util/KerberosString.java ! src/windows/classes/sun/security/krb5/internal/tools/Kinit.java + test/sun/security/krb5/RFC396xTest.java Changeset: a2d24418be6c Author: weijun Date: 2009-10-02 18:49 +0800 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/a2d24418be6c 6874472: display address lists for tickets in klist tool Reviewed-by: valeriep ! src/windows/classes/sun/security/krb5/internal/tools/Klist.java Changeset: a6046f6e720e Author: weijun Date: 2009-10-02 18:49 +0800 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/a6046f6e720e 6868579: RFE: jarsigner to support reading password from environment variable Reviewed-by: xuelei, wetmore ! src/share/classes/sun/security/tools/JarSigner.java ! src/share/classes/sun/security/tools/KeyTool.java ! src/share/classes/sun/security/util/Resources.java + test/sun/security/tools/jarsigner/passtype.sh Changeset: f0fdc4dd97d5 Author: michaelm Date: 2009-10-02 13:57 +0100 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/f0fdc4dd97d5 6870935: DIGEST proxy authentication fails to connect to URLs with no trailing slash Reviewed-by: chegar ! src/share/classes/sun/net/www/protocol/http/AuthenticationInfo.java ! src/share/classes/sun/net/www/protocol/http/BasicAuthentication.java ! src/share/classes/sun/net/www/protocol/http/DigestAuthentication.java ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java ! src/share/classes/sun/net/www/protocol/http/NegotiateAuthentication.java ! src/solaris/classes/sun/net/www/protocol/http/NTLMAuthentication.java ! src/windows/classes/sun/net/www/protocol/http/NTLMAuthentication.java + test/java/net/Authenticator/B6870935.java Changeset: e782a9564eae Author: michaelm Date: 2009-10-02 13:59 +0100 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/e782a9564eae Merge Changeset: 9fcca0aae3da Author: tbell Date: 2009-10-02 08:49 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/9fcca0aae3da 6787605: OpenSolaris doesn't have /usr/ucb/ps so ShellScaffold fails Reviewed-by: dcubed ! test/com/sun/jdi/ShellScaffold.sh Changeset: 97f17e6d0560 Author: alanb Date: 2009-10-04 15:42 +0100 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/97f17e6d0560 6884800: (file) Path.newInputStream does not usefully implement available() Reviewed-by: martin, chegar ! src/share/classes/sun/nio/ch/ChannelInputStream.java ! test/java/nio/channels/Channels/Basic.java Changeset: a4f31836660a Author: alanb Date: 2009-10-05 16:45 +0100 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/a4f31836660a 6854954: Eliminate static dependency on java.awt.AWTPermission Reviewed-by: mullan, mchung, anthony ! src/share/classes/java/awt/Dialog.java ! src/share/classes/java/awt/MouseInfo.java ! src/share/classes/java/awt/Robot.java ! src/share/classes/java/awt/SystemTray.java ! src/share/classes/java/awt/Toolkit.java ! src/share/classes/java/awt/Window.java ! src/share/classes/java/lang/SecurityManager.java ! src/share/classes/javax/swing/JPopupMenu.java + src/share/classes/sun/awt/AWTPermissionFactory.java ! src/share/classes/sun/security/provider/PolicyFile.java + src/share/classes/sun/security/util/PermissionFactory.java ! src/share/classes/sun/security/util/SecurityConstants.java Changeset: 54118c8e0ebe Author: vinnie Date: 2009-10-05 23:42 +0100 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/54118c8e0ebe 6885204: JSSE should not require Kerberos to be present Reviewed-by: wetmore, alanb ! src/share/classes/com/sun/net/ssl/internal/www/protocol/https/DelegateHttpsURLConnection.java ! src/share/classes/sun/net/www/protocol/https/HttpsClient.java ! src/share/classes/sun/security/ssl/CipherSuite.java ! src/share/classes/sun/security/ssl/JsseJce.java Changeset: c499401bc138 Author: mchung Date: 2009-10-05 18:15 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/c499401bc138 6612680: Remove classloader dependency on jkernel Summary: Add a new sun.misc.BootClassLoaderHook that DownloadManager will implement Reviewed-by: alanb, forax, igor ! make/sun/jkernel/Makefile ! src/share/classes/java/awt/color/ICC_Profile.java ! src/share/classes/java/lang/ClassLoader.java ! src/share/classes/java/util/zip/ZipEntry.java ! src/share/classes/sun/jkernel/DownloadManager.java + src/share/classes/sun/misc/BootClassLoaderHook.java ! src/share/classes/sun/misc/Launcher.java ! src/share/classes/sun/misc/VM.java ! src/share/native/sun/misc/VM.c Changeset: 572791538be5 Author: darcy Date: 2009-10-06 13:31 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/572791538be5 5062288: (reflect) Core reflection uses raw types when it could be using wildcards Reviewed-by: alanb ! src/share/classes/java/lang/Class.java ! src/share/classes/java/lang/Package.java ! src/share/classes/java/lang/reflect/AccessibleObject.java ! src/share/classes/java/lang/reflect/Constructor.java ! src/share/classes/java/lang/reflect/Field.java ! src/share/classes/java/lang/reflect/Method.java ! src/share/classes/java/lang/reflect/Proxy.java ! src/share/classes/java/lang/reflect/ReflectAccess.java ! src/share/classes/sun/reflect/LangReflectAccess.java ! src/share/classes/sun/reflect/annotation/AnnotationInvocationHandler.java ! src/share/classes/sun/reflect/annotation/AnnotationParser.java ! src/share/classes/sun/reflect/annotation/AnnotationType.java Changeset: 1b81fc851b20 Author: mchung Date: 2009-10-06 15:14 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/1b81fc851b20 6888802: sun.misc.BootClassLoaderHook.getBootstrapPaths stack overflow Summary: Fixed sun.misc.BootClassLoaderHook.getBootstrapPaths calls hook.getAdditionalBootstrapPaths Reviewed-by: alanb, tbell ! src/share/classes/sun/misc/BootClassLoaderHook.java + test/sun/misc/BootClassLoaderHook/TestHook.java Changeset: f69b40e43bff Author: kamg Date: 2009-10-06 22:01 -0400 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/f69b40e43bff 6885916: Memory leak in inferencing verifier (libverify.so) Summary: Use the memory management already present to track allocated memory Reviewed-by: coleenp, acorn ! src/share/native/common/check_code.c Changeset: f864c15f6779 Author: chegar Date: 2009-10-07 17:23 +0100 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/f864c15f6779 6887364: SetOutgoingIf.java fails if run on multihomed machine without PIv6 on all interfaces Reviewed-by: alanb ! test/java/net/MulticastSocket/SetOutgoingIf.java Changeset: 777714bd992a Author: tbell Date: 2009-10-07 13:53 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/777714bd992a 6888888: new javah throws NullPointerException when building in jdk/make/java/nio Summary: Use the bootstrap javah during the build until bug-ID 6889255 is fixed Reviewed-by: jjg ! make/common/shared/Defs-java.gmk Changeset: e7ad502130ba Author: darcy Date: 2009-10-07 14:04 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/e7ad502130ba 6480728: Byte.valueOf(byte) returns a cached value but Byte.valueOf(String) 6655735: Integer.toString() and String.valueOf(int) contain slow delegations Reviewed-by: lancea ! src/share/classes/java/lang/Byte.java ! src/share/classes/java/lang/Double.java ! src/share/classes/java/lang/Float.java ! src/share/classes/java/lang/Integer.java ! src/share/classes/java/lang/Long.java ! src/share/classes/java/lang/Short.java ! src/share/classes/java/lang/String.java Changeset: 405fd587f13f Author: tbell Date: 2009-10-07 14:15 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/405fd587f13f Merge ! src/share/classes/java/awt/Toolkit.java ! src/share/classes/java/awt/Window.java Changeset: 317ac0bf2285 Author: anthony Date: 2009-09-15 16:15 +0400 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/317ac0bf2285 6868255: Requirements for correct operating of the HW/LW Mixing feature need to be specified Summary: The specification is updated Reviewed-by: art, dcherepanov ! src/share/classes/java/awt/Component.java ! src/share/classes/java/awt/Container.java Changeset: 986ec552383f Author: yan Date: 2009-09-22 01:20 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/986ec552383f Merge - make/javax/swing/plaf/nimbus/Makefile - make/tools/swing-nimbus/Makefile - make/tools/swing-nimbus/classes/org/jdesktop/beans/AbstractBean.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/BezierControlPoint.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/BlendingMode.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/Canvas.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/ControlPoint.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/Designer.jibx.xml - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/DoubleBean.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/EllipseShape.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/GraphicsHelper.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/Layer.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/LayerContainer.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/PaintedShape.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/PathShape.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/RectangleShape.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/SimpleShape.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/TemplateLayer.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/DropShadowEffect.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/Effect.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/EffectUtils.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/EffectUtilsTemp.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/InnerGlowEffect.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/InnerShadowEffect.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/OuterGlowEffect.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/effects/ShadowEffect.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/font/Typeface.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/jibxhelpers/CanvasMapper.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/jibxhelpers/ColorMapper.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/jibxhelpers/DimensionMapper.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/jibxhelpers/InsetsMapper.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/AbstractGradient.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/Gradient.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/GradientStop.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/Matte.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/PaintModel.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/RadialGradient.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/paint/Texture.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/utils/HasPath.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/utils/HasResources.java - make/tools/swing-nimbus/classes/org/jdesktop/swingx/designer/utils/HasUIDefaults.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/generator/DefaultsGenerator.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/generator/Generator.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/generator/GeneratorUtils.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/generator/ObjectCodeConvertors.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/generator/PainterGenerator.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/generator/TemplateWriter.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/CustomUIDefault.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/HasUIStyle.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/PainterBorder.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/SynthModel.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/SynthModel.jibx.xml - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIBorder.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIColor.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIComponent.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIDefault.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIDimension.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIFont.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIIcon.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIIconRegion.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIInsets.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIPaint.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIProperty.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIRegion.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIState.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIStateType.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/UIStyle.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/jibxhelpers/BorderMapper.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/jibxhelpers/ClassConverter.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/jibxhelpers/ClassMapper.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/jibxhelpers/FontMapper.java - make/tools/swing-nimbus/classes/org/jdesktop/synthdesigner/synthmodel/jibxhelpers/UIPropertyMapper.java - src/share/classes/sun/nio/ch/AbstractFuture.java - src/share/native/java/util/zip/zlib-1.1.3/ChangeLog - src/share/native/java/util/zip/zlib-1.1.3/README - src/share/native/java/util/zip/zlib-1.1.3/compress.c - src/share/native/java/util/zip/zlib-1.1.3/deflate.c - src/share/native/java/util/zip/zlib-1.1.3/deflate.h - src/share/native/java/util/zip/zlib-1.1.3/doc/algorithm.doc - src/share/native/java/util/zip/zlib-1.1.3/example.c - src/share/native/java/util/zip/zlib-1.1.3/gzio.c - src/share/native/java/util/zip/zlib-1.1.3/infblock.c - src/share/native/java/util/zip/zlib-1.1.3/infblock.h - src/share/native/java/util/zip/zlib-1.1.3/infcodes.c - src/share/native/java/util/zip/zlib-1.1.3/infcodes.h - src/share/native/java/util/zip/zlib-1.1.3/inffast.c - src/share/native/java/util/zip/zlib-1.1.3/inffast.h - src/share/native/java/util/zip/zlib-1.1.3/inffixed.h - src/share/native/java/util/zip/zlib-1.1.3/inflate.c - src/share/native/java/util/zip/zlib-1.1.3/inftrees.c - src/share/native/java/util/zip/zlib-1.1.3/inftrees.h - src/share/native/java/util/zip/zlib-1.1.3/infutil.c - src/share/native/java/util/zip/zlib-1.1.3/infutil.h - src/share/native/java/util/zip/zlib-1.1.3/minigzip.c - src/share/native/java/util/zip/zlib-1.1.3/trees.c - src/share/native/java/util/zip/zlib-1.1.3/trees.h - src/share/native/java/util/zip/zlib-1.1.3/uncompr.c - src/share/native/java/util/zip/zlib-1.1.3/zadler32.c - src/share/native/java/util/zip/zlib-1.1.3/zconf.h - src/share/native/java/util/zip/zlib-1.1.3/zcrc32.c - src/share/native/java/util/zip/zlib-1.1.3/zlib.h - src/share/native/java/util/zip/zlib-1.1.3/zutil.c - src/share/native/java/util/zip/zlib-1.1.3/zutil.h - test/java/util/concurrent/LinkedBlockingQueue/LastElement.java - test/java/util/concurrent/LinkedBlockingQueue/OfferRemoveLoops.java Changeset: b6980b0d8440 Author: dcherepanov Date: 2009-09-30 13:21 +0400 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/b6980b0d8440 6853592: VM test nsk.regression.b4261880 fails with "X Error of failed request: BadWindow" inconsistently. Reviewed-by: art, anthony ! src/solaris/classes/sun/awt/X11/XToolkit.java Changeset: a21d00087df9 Author: dcherepanov Date: 2009-09-30 15:48 +0400 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/a21d00087df9 6878284: Sometimes test/javax/swing/system/6799345/TestShutdown.java "hangs" Reviewed-by: art, ant ! src/share/classes/java/awt/EventQueue.java ! src/share/classes/sun/awt/AWTAutoShutdown.java Changeset: cf3f9c09ba1d Author: anthony Date: 2009-10-01 14:48 +0400 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/cf3f9c09ba1d 6886868: giflib has a memory leak in the MakeMapObject() function Summary: free() the object before returning NULL Reviewed-by: art, dcherepanov ! src/share/native/sun/awt/giflib/gifalloc.c Changeset: 80db944866a9 Author: anthony Date: 2009-10-01 15:06 +0400 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/80db944866a9 6862611: Reg testcase closed/java/awt/Component/NativeInLightShow/NativeInLightShow.html fails Summary: The recursiveShowHeavyweightChildren() must be invoked unconditionally in mixOnShowing() Reviewed-by: art, dcherepanov ! src/share/classes/java/awt/Container.java Changeset: 4358934555bc Author: yan Date: 2009-10-06 23:40 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/4358934555bc Merge ! src/share/classes/java/awt/Component.java ! src/share/classes/java/awt/Container.java ! src/share/classes/java/awt/EventQueue.java ! src/share/classes/sun/awt/AWTAutoShutdown.java ! src/solaris/classes/sun/awt/X11/XToolkit.java Changeset: 6216604c05e2 Author: alexp Date: 2009-09-09 17:32 +0400 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/6216604c05e2 6878792: Sample provided in javax.swing.JLayer class description is not usable Reviewed-by: rupashka ! src/share/classes/javax/swing/JLayer.java Changeset: afd85f72784b Author: peterz Date: 2009-09-10 12:30 +0400 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/afd85f72784b 6827786: Mnemonic cycling for multiple equal mnemonic armed menu items stops when encountering a submenu Reviewed-by: alexp ! src/share/classes/javax/swing/plaf/basic/BasicMenuUI.java ! src/share/classes/javax/swing/plaf/basic/BasicPopupMenuUI.java Changeset: 51ccbb892a1f Author: alexp Date: 2009-09-15 16:26 +0400 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/51ccbb892a1f 6875716: JLayer.remove((Component)null) should behave consistently in (not) throwing NPE Reviewed-by: rupashka ! src/share/classes/javax/swing/JLayer.java + test/javax/swing/JLayer/6875716/bug6875716.java Changeset: a64dbe61a984 Author: gsm Date: 2009-09-16 16:15 +0400 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/a64dbe61a984 4337267: Arabic Numeral Shaping Reviewed-by: peterz ! src/share/classes/javax/swing/text/TextLayoutStrategy.java ! src/share/classes/sun/swing/SwingUtilities2.java + test/javax/swing/JComponent/4337267/bug4337267.java Changeset: 481c01572c62 Author: alexp Date: 2009-09-17 19:08 +0400 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/481c01572c62 4833524: BasicTreeUI.isToggleSelectionEvent() does not properly handle popup triggers Reviewed-by: rupashka ! src/share/classes/javax/swing/plaf/basic/BasicComboBoxUI.java ! src/share/classes/javax/swing/plaf/basic/BasicComboPopup.java ! src/share/classes/javax/swing/plaf/basic/BasicFileChooserUI.java ! src/share/classes/javax/swing/plaf/basic/BasicGraphicsUtils.java ! src/share/classes/javax/swing/plaf/basic/BasicListUI.java ! src/share/classes/javax/swing/plaf/basic/BasicTableUI.java ! src/share/classes/javax/swing/plaf/basic/BasicTreeUI.java ! src/share/classes/javax/swing/text/DefaultCaret.java Changeset: 1c7abc800502 Author: rupashka Date: 2009-09-18 15:11 +0400 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/1c7abc800502 6840086: JFileChooser lacks icons on top right when running on Windows 7 Reviewed-by: peterz, uta ! src/share/classes/sun/awt/shell/ShellFolderManager.java ! src/windows/classes/sun/awt/shell/Win32ShellFolder2.java ! src/windows/classes/sun/awt/shell/Win32ShellFolderManager2.java ! src/windows/native/sun/windows/ShellFolder2.cpp + test/javax/swing/JFileChooser/6840086/bug6840086.java Changeset: fa71ca7a3655 Author: yan Date: 2009-09-21 01:26 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/fa71ca7a3655 Merge - src/share/classes/sun/nio/ch/AbstractFuture.java - src/share/native/java/util/zip/zlib-1.1.3/ChangeLog - src/share/native/java/util/zip/zlib-1.1.3/README - src/share/native/java/util/zip/zlib-1.1.3/compress.c - src/share/native/java/util/zip/zlib-1.1.3/deflate.c - src/share/native/java/util/zip/zlib-1.1.3/deflate.h - src/share/native/java/util/zip/zlib-1.1.3/doc/algorithm.doc - src/share/native/java/util/zip/zlib-1.1.3/example.c - src/share/native/java/util/zip/zlib-1.1.3/gzio.c - src/share/native/java/util/zip/zlib-1.1.3/infblock.c - src/share/native/java/util/zip/zlib-1.1.3/infblock.h - src/share/native/java/util/zip/zlib-1.1.3/infcodes.c - src/share/native/java/util/zip/zlib-1.1.3/infcodes.h - src/share/native/java/util/zip/zlib-1.1.3/inffast.c - src/share/native/java/util/zip/zlib-1.1.3/inffast.h - src/share/native/java/util/zip/zlib-1.1.3/inffixed.h - src/share/native/java/util/zip/zlib-1.1.3/inflate.c - src/share/native/java/util/zip/zlib-1.1.3/inftrees.c - src/share/native/java/util/zip/zlib-1.1.3/inftrees.h - src/share/native/java/util/zip/zlib-1.1.3/infutil.c - src/share/native/java/util/zip/zlib-1.1.3/infutil.h - src/share/native/java/util/zip/zlib-1.1.3/minigzip.c - src/share/native/java/util/zip/zlib-1.1.3/trees.c - src/share/native/java/util/zip/zlib-1.1.3/trees.h - src/share/native/java/util/zip/zlib-1.1.3/uncompr.c - src/share/native/java/util/zip/zlib-1.1.3/zadler32.c - src/share/native/java/util/zip/zlib-1.1.3/zconf.h - src/share/native/java/util/zip/zlib-1.1.3/zcrc32.c - src/share/native/java/util/zip/zlib-1.1.3/zlib.h - src/share/native/java/util/zip/zlib-1.1.3/zutil.c - src/share/native/java/util/zip/zlib-1.1.3/zutil.h - test/java/util/concurrent/LinkedBlockingQueue/LastElement.java - test/java/util/concurrent/LinkedBlockingQueue/OfferRemoveLoops.java Changeset: 9d78c3d9def2 Author: alexp Date: 2009-09-21 17:58 +0400 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/9d78c3d9def2 6883341: SWAT: jdk7-b72 swat build(2009-09-17) threw exceptions when running Java2D demo by clicking Paint ta Reviewed-by: peterz ! src/share/classes/sun/swing/SwingUtilities2.java + test/javax/swing/JMenuItem/6883341/bug6883341.java Changeset: 6115613a3386 Author: peterz Date: 2009-09-23 21:14 +0400 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/6115613a3386 6857888: closed/javax/swing/JMenuItem/6458123/bug6458123.java fails with InvocationTargetException. Reviewed-by: alexp ! src/share/classes/javax/swing/plaf/nimbus/skin.laf ! src/share/classes/javax/swing/plaf/synth/SynthGraphicsUtils.java Changeset: d5045dd60c29 Author: rupashka Date: 2009-10-06 17:01 +0400 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/d5045dd60c29 6489130: FileChooserDemo hung by keeping pressing Enter key Reviewed-by: alexp ! src/share/classes/javax/swing/JFileChooser.java + test/javax/swing/JFileChooser/6489130/bug6489130.java Changeset: dca0ab1a1ac3 Author: yan Date: 2009-10-06 23:44 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/dca0ab1a1ac3 Merge ! src/share/classes/sun/swing/SwingUtilities2.java Changeset: 77f213891ce3 Author: lana Date: 2009-10-13 15:25 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/77f213891ce3 Merge From xiomara.jayasena at sun.com Wed Oct 14 13:53:05 2009 From: xiomara.jayasena at sun.com (xiomara.jayasena at sun.com) Date: Wed, 14 Oct 2009 20:53:05 +0000 Subject: hg: jdk7/build/langtools: 16 new changesets Message-ID: <20091014205334.BFAAD41609@hg.openjdk.java.net> Changeset: ebb6ad5a95bb Author: jjg Date: 2009-09-08 13:53 -0700 URL: http://hg.openjdk.java.net/jdk7/build/langtools/rev/ebb6ad5a95bb 5093723: REGRESSION: ClassCastException in SingleIndexWriter Reviewed-by: jjg Contributed-by: ahe at google.com ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/resources/standard.properties + test/com/sun/javadoc/5093723/DocumentedClass.java + test/com/sun/javadoc/5093723/T5093723.java + test/com/sun/javadoc/5093723/UndocumentedClass.java Changeset: 071a4e36cd87 Author: jjg Date: 2009-09-08 14:08 -0700 URL: http://hg.openjdk.java.net/jdk7/build/langtools/rev/071a4e36cd87 6709246: ClassCastException in javadoc Reviewed-by: jjg Contributed-by: ahe at google.com ! src/share/classes/com/sun/tools/javadoc/AnnotationDescImpl.java + test/tools/javadoc/annotations/missing/Main.java + test/tools/javadoc/annotations/missing/somepackage/MissingAnnotationClass.java Changeset: f8be8bf150c3 Author: jjg Date: 2009-09-14 17:13 -0700 URL: http://hg.openjdk.java.net/jdk7/build/langtools/rev/f8be8bf150c3 6881317: regression: NPE in CloseableURLClassLoader Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/file/CloseableURLClassLoader.java Changeset: 9dd34ed62341 Author: jjg Date: 2009-09-15 12:20 -0700 URL: http://hg.openjdk.java.net/jdk7/build/langtools/rev/9dd34ed62341 6882235: invalid exponent causes silent javac crash Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java + test/tools/javac/T6882235.java + test/tools/javac/T6882235.out Changeset: 69eaccd3ea85 Author: jjg Date: 2009-09-15 18:36 -0700 URL: http://hg.openjdk.java.net/jdk7/build/langtools/rev/69eaccd3ea85 6860965: Project Coin: binary literals 6860973: Project Coin: Underscores in literals Summary: [Portions contributed by Bruce Chapman] Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/code/Source.java ! src/share/classes/com/sun/tools/javac/parser/Scanner.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! test/tools/javac/enum/6384542/T6384542.out + test/tools/javac/literals/BadBinaryLiterals.6.out + test/tools/javac/literals/BadBinaryLiterals.7.out + test/tools/javac/literals/BadBinaryLiterals.java + test/tools/javac/literals/BadUnderscoreLiterals.6.out + test/tools/javac/literals/BadUnderscoreLiterals.7.out + test/tools/javac/literals/BadUnderscoreLiterals.java + test/tools/javac/literals/BinaryLiterals.java + test/tools/javac/literals/UnderscoreLiterals.java Changeset: 5dd400fd62d9 Author: tbell Date: 2009-09-18 08:48 -0700 URL: http://hg.openjdk.java.net/jdk7/build/langtools/rev/5dd400fd62d9 Merge Changeset: 789ee1acf107 Author: darcy Date: 2009-09-21 21:08 -0700 URL: http://hg.openjdk.java.net/jdk7/build/langtools/rev/789ee1acf107 6884227: Clarify ordering requirements of javax.lang.model.TypeElement.getEnclosedElements Reviewed-by: ahe ! src/share/classes/javax/lang/model/element/TypeElement.java Changeset: 9596dff46093 Author: tbell Date: 2009-09-25 14:24 -0700 URL: http://hg.openjdk.java.net/jdk7/build/langtools/rev/9596dff46093 Merge Changeset: d498d6ef9c6c Author: xdono Date: 2009-10-02 11:26 -0700 URL: http://hg.openjdk.java.net/jdk7/build/langtools/rev/d498d6ef9c6c Added tag jdk7-b73 for changeset 9596dff46093 ! .hgtags Changeset: e992e602788e Author: darcy Date: 2009-09-23 18:29 -0700 URL: http://hg.openjdk.java.net/jdk7/build/langtools/rev/e992e602788e 6517779: javax.lang.model.util.Elements.getConstantExpression() doesn't throw any exception 6517907: javax.lang.model.util.Elements.getConstantExpression() with negative byte value fails Summary: Fix various problems with Elements.getConstantExpression() Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/util/Constants.java ! src/share/classes/com/sun/tools/javac/util/Convert.java + test/tools/javac/processing/model/util/elements/Foo.java + test/tools/javac/processing/model/util/elements/TestGetConstantExpression.java Changeset: 49359d0e6a9c Author: jjg Date: 2009-09-23 18:48 -0700 URL: http://hg.openjdk.java.net/jdk7/build/langtools/rev/49359d0e6a9c 6410637: Make decision on deprecated methods in DefaultFileManager and BaseFileObject. 6747645: ZipFileObject.getName is incorrectly deprecated 6885123: JavaFileObject getName issues Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/apt/mirror/util/SourcePositionImpl.java ! src/share/classes/com/sun/tools/javac/file/BaseFileObject.java ! src/share/classes/com/sun/tools/javac/file/JavacFileManager.java - src/share/classes/com/sun/tools/javac/file/Old199.java ! src/share/classes/com/sun/tools/javac/file/RegularFileObject.java ! src/share/classes/com/sun/tools/javac/file/SymbolArchive.java ! src/share/classes/com/sun/tools/javac/file/ZipArchive.java ! src/share/classes/com/sun/tools/javac/file/ZipFileIndexArchive.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java ! src/share/classes/com/sun/tools/javac/util/AbstractDiagnosticFormatter.java ! src/share/classes/com/sun/tools/javac/util/DiagnosticSource.java ! src/share/classes/com/sun/tools/javac/util/JCDiagnostic.java ! src/share/classes/com/sun/tools/javac/util/Log.java ! src/share/classes/com/sun/tools/javac/util/RawDiagnosticFormatter.java ! src/share/classes/com/sun/tools/javadoc/SourcePositionImpl.java ! src/share/classes/javax/tools/SimpleJavaFileObject.java + test/tools/javac/4241573/T4241573.java ! test/tools/javac/6589361/T6589361.java ! test/tools/javac/Diagnostics/6769027/T6769027.java ! test/tools/javac/T6705935.java ! test/tools/javac/api/6411310/T6411310.java + test/tools/javac/api/6411310/Test.java ! test/tools/javac/api/6733837/T6733837.java Changeset: c287d51c57da Author: jjg Date: 2009-09-23 19:15 -0700 URL: http://hg.openjdk.java.net/jdk7/build/langtools/rev/c287d51c57da 6572945: javah should be written as an annotation processor, not a doclet Reviewed-by: darcy ! make/build.xml ! src/share/classes/com/sun/tools/javah/Gen.java + src/share/classes/com/sun/tools/javah/InternalError.java ! src/share/classes/com/sun/tools/javah/JNI.java + src/share/classes/com/sun/tools/javah/JavahFileManager.java + src/share/classes/com/sun/tools/javah/JavahTask.java + src/share/classes/com/sun/tools/javah/JavahTool.java ! src/share/classes/com/sun/tools/javah/LLNI.java ! src/share/classes/com/sun/tools/javah/Main.java - src/share/classes/com/sun/tools/javah/MainDoclet.java ! src/share/classes/com/sun/tools/javah/Mangle.java + src/share/classes/com/sun/tools/javah/NativeHeaderTool.java ! src/share/classes/com/sun/tools/javah/TypeSignature.java ! src/share/classes/com/sun/tools/javah/Util.java - src/share/classes/com/sun/tools/javah/resources/Linux_ppc.properties - src/share/classes/com/sun/tools/javah/resources/Linux_sparc.properties - src/share/classes/com/sun/tools/javah/resources/SunOS_sparc.properties - src/share/classes/com/sun/tools/javah/resources/SunOS_sparcv9.properties ! src/share/classes/com/sun/tools/javah/resources/l10n.properties - src/share/classes/com/sun/tools/javah/resources/win32_x86.properties ! src/share/classes/com/sun/tools/javap/DisassemblerTool.java + test/tools/javah/6572945/T6572945.java + test/tools/javah/6572945/TestClass1.java + test/tools/javah/6572945/TestClass2.java + test/tools/javah/6572945/TestClass3.java + test/tools/javah/6572945/gold/jni.dir.1/TestClass1.h + test/tools/javah/6572945/gold/jni.dir.1/TestClass1_Inner1.h + test/tools/javah/6572945/gold/jni.dir.1/TestClass1_Inner2.h + test/tools/javah/6572945/gold/jni.dir.1/TestClass2.h + test/tools/javah/6572945/gold/jni.file.1 + test/tools/javah/6572945/gold/jni.file.2 + test/tools/javah/6572945/gold/jni.file.3 ! test/tools/javah/MissingParamClassTest.sh + test/tools/javah/compareTest/CompareTest.java + test/tools/javah/compareTest/CompareTest.sh + test/tools/javah/compareTest/FindNativeFiles.java + test/tools/javah/compareTest/README Changeset: d0f541480556 Author: darcy Date: 2009-09-24 16:00 -0700 URL: http://hg.openjdk.java.net/jdk7/build/langtools/rev/d0f541480556 6337964: should ignore last comma in annotation array Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java + test/tools/javac/annotations/pos/TrailingComma.java Changeset: 4776a869fdfa Author: tbell Date: 2009-09-25 22:04 -0700 URL: http://hg.openjdk.java.net/jdk7/build/langtools/rev/4776a869fdfa Merge ! src/share/classes/com/sun/tools/javac/file/BaseFileObject.java ! src/share/classes/com/sun/tools/javac/file/JavacFileManager.java - src/share/classes/com/sun/tools/javac/file/Old199.java ! src/share/classes/com/sun/tools/javac/file/RegularFileObject.java ! src/share/classes/com/sun/tools/javac/file/SymbolArchive.java ! src/share/classes/com/sun/tools/javac/file/ZipArchive.java ! src/share/classes/com/sun/tools/javac/file/ZipFileIndexArchive.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java - src/share/classes/com/sun/tools/javah/MainDoclet.java - src/share/classes/com/sun/tools/javah/resources/Linux_ppc.properties - src/share/classes/com/sun/tools/javah/resources/Linux_sparc.properties - src/share/classes/com/sun/tools/javah/resources/SunOS_sparc.properties - src/share/classes/com/sun/tools/javah/resources/SunOS_sparcv9.properties - src/share/classes/com/sun/tools/javah/resources/win32_x86.properties ! test/tools/javah/MissingParamClassTest.sh Changeset: c6d0c55b1aba Author: jjg Date: 2009-09-28 16:48 -0700 URL: http://hg.openjdk.java.net/jdk7/build/langtools/rev/c6d0c55b1aba 6886348: apt incorrectly uses Scope.table Reviewed-by: darcy ! src/share/classes/com/sun/tools/apt/comp/Apt.java Changeset: 1a66b08deed0 Author: tbell Date: 2009-10-07 14:14 -0700 URL: http://hg.openjdk.java.net/jdk7/build/langtools/rev/1a66b08deed0 Merge - src/share/classes/com/sun/tools/javac/file/Old199.java - src/share/classes/com/sun/tools/javah/MainDoclet.java - src/share/classes/com/sun/tools/javah/resources/Linux_ppc.properties - src/share/classes/com/sun/tools/javah/resources/Linux_sparc.properties - src/share/classes/com/sun/tools/javah/resources/SunOS_sparc.properties - src/share/classes/com/sun/tools/javah/resources/SunOS_sparcv9.properties - src/share/classes/com/sun/tools/javah/resources/win32_x86.properties From vincent.ryan at sun.com Wed Oct 14 15:57:53 2009 From: vincent.ryan at sun.com (vincent.ryan at sun.com) Date: Wed, 14 Oct 2009 22:57:53 +0000 Subject: hg: jdk7/build/jdk: 6891632: Remove duplicate ECC source files Message-ID: <20091014225805.BFC124162D@hg.openjdk.java.net> Changeset: eacb36e30327 Author: vinnie Date: 2009-10-14 23:41 +0100 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/eacb36e30327 6891632: Remove duplicate ECC source files Reviewed-by: wetmore - src/share/native/sun/security/ec/ec.h - src/share/native/sun/security/ec/ec2.h - src/share/native/sun/security/ec/ec2_163.c - src/share/native/sun/security/ec/ec2_193.c - src/share/native/sun/security/ec/ec2_233.c - src/share/native/sun/security/ec/ec2_aff.c - src/share/native/sun/security/ec/ec2_mont.c - src/share/native/sun/security/ec/ec_naf.c - src/share/native/sun/security/ec/ecc_impl.h - src/share/native/sun/security/ec/ecdecode.c - src/share/native/sun/security/ec/ecl-curve.h - src/share/native/sun/security/ec/ecl-exp.h - src/share/native/sun/security/ec/ecl-priv.h - src/share/native/sun/security/ec/ecl.c - src/share/native/sun/security/ec/ecl.h - src/share/native/sun/security/ec/ecl_curve.c - src/share/native/sun/security/ec/ecl_gf.c - src/share/native/sun/security/ec/ecl_mult.c - src/share/native/sun/security/ec/ecp.h - src/share/native/sun/security/ec/ecp_192.c - src/share/native/sun/security/ec/ecp_224.c - src/share/native/sun/security/ec/ecp_256.c - src/share/native/sun/security/ec/ecp_384.c - src/share/native/sun/security/ec/ecp_521.c - src/share/native/sun/security/ec/ecp_aff.c - src/share/native/sun/security/ec/ecp_jac.c - src/share/native/sun/security/ec/ecp_jm.c - src/share/native/sun/security/ec/ecp_mont.c - src/share/native/sun/security/ec/logtab.h - src/share/native/sun/security/ec/mp_gf2m-priv.h - src/share/native/sun/security/ec/mp_gf2m.c - src/share/native/sun/security/ec/mp_gf2m.h - src/share/native/sun/security/ec/mpi-config.h - src/share/native/sun/security/ec/mpi-priv.h - src/share/native/sun/security/ec/mpi.c - src/share/native/sun/security/ec/mpi.h - src/share/native/sun/security/ec/mplogic.c - src/share/native/sun/security/ec/mplogic.h - src/share/native/sun/security/ec/mpmontg.c - src/share/native/sun/security/ec/mpprime.h - src/share/native/sun/security/ec/oid.c - src/share/native/sun/security/ec/secitem.c - src/share/native/sun/security/ec/secoidt.h From Tim.Bell at Sun.COM Wed Oct 14 21:14:16 2009 From: Tim.Bell at Sun.COM (Tim Bell) Date: Wed, 14 Oct 2009 21:14:16 -0700 Subject: Review request: Zero buildsystem changes In-Reply-To: <20091014153147.GC3468@redhat.com> References: <20091009115839.GC3506@redhat.com> <20091014153147.GC3468@redhat.com> Message-ID: <4AD6A198.9050903@sun.com> Gary Benson wrote: > As an update to my previous message, the HotSpot part of this patch > was tested and pushed to hotspot-comp last night, so the remaining > code for review is this: > > http://cr.openjdk.java.net/~gbenson/zero-11-build/ > > I'm going on vacation on Friday 16, returning Monday 26, so could > anyone replying off-list please Cc gnu_andrew at member.fsf.org, who > is going to handle this in my absence. We'd love to see this in > in time for Milestone 5, and we'd hate to miss the boat because > an email was sitting in my inbox unread! (Adding Andrew as requested). These changes look OK to Kelly and myself. Also, my test run on our internal build farm called JPRT (a full control build of everything after adding your patch) worked: > JPRT: [sfbay] job notification - success with job 2009-10-14-203220.tbell.zero-11-build How would you like to proceed? With the hotspot work, Tom Rodriguez (AKA 'never') did the push as an agent for you via JPRT because that is a hotspot requirement. I am willing to do that as well for the JDK changes, or you could create the changeset and push yourself. We are not quite as strict about requiring a JPRT grid build before pushing on the JDK side. I wish we were, but so far I have not won that contest :-) I filed bug ID 6891677 "java/build integrate zero assembler JDK changes" for this, but it may not be visible externally for a day or two. Let me know - I'd be glad to help get this changeset in. Tim From Alan.Bateman at Sun.COM Thu Oct 15 02:15:04 2009 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Thu, 15 Oct 2009 10:15:04 +0100 Subject: Need reviewer In-Reply-To: <4AD62A8E.2060604@sun.com> References: <20091014192717.A09097D2@eggemoggin.niobe.net> <4AD62A8E.2060604@sun.com> Message-ID: <4AD6E818.1050202@sun.com> Kelly O'Hair wrote: > > > Mark Reinhold wrote: >> Okay, I can live with this. >> > > Thanks. > >> (At the risk of stating the obvious: Please be sure to use hg mv when >> you rename these files, otherwise the historical changeset trail will >> be broken.) > > Will do. > > -kto Sorry, I wasn't paying attention to this thread. Renaming these sources to -template is okay with me (although I kinda liked the -X convention). -Alan. From gnu_andrew at member.fsf.org Thu Oct 15 06:13:05 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Thu, 15 Oct 2009 14:13:05 +0100 Subject: Fix for 6888888 breaks the build Message-ID: <17c6771e0910150613w40d870d1ne20047231788a6d2@mail.gmail.com> The fix for bug 6888888: http://hg.openjdk.java.net/jdk7/build/jdk/rev/777714bd992a breaks the build as it tries to use javah from ALT_JDK_IMPORT_DIR (via JAVA_TOOLS_DIR) which is not set on normal builds. The README tells the user to set ALT_BOOTDIR and changing JAVA_TOOLS_DIR to be set to BOOTDIR makes the build work again: http://cr.openjdk.java.net/~andrew/javah/webrev.01/ Ok to push? -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From ahughes at redhat.com Thu Oct 15 06:15:32 2009 From: ahughes at redhat.com (ahughes at redhat.com) Date: Thu, 15 Oct 2009 13:15:32 +0000 Subject: hg: jdk7/build: 6891677: java/build integrate zero assembler JDK changes Message-ID: <20091015131533.04C4D4171F@hg.openjdk.java.net> Changeset: 608937d41381 Author: gbenson Date: 2009-10-15 13:26 +0100 URL: http://hg.openjdk.java.net/jdk7/build/rev/608937d41381 6891677: java/build integrate zero assembler JDK changes Summary: Build changes for the Zero assembler port Reviewed-by: ohair, tbell ! make/hotspot-rules.gmk From ahughes at redhat.com Thu Oct 15 06:15:54 2009 From: ahughes at redhat.com (ahughes at redhat.com) Date: Thu, 15 Oct 2009 13:15:54 +0000 Subject: hg: jdk7/build/corba: 6891677: java/build integrate zero assembler JDK changes Message-ID: <20091015131555.5E5B541722@hg.openjdk.java.net> Changeset: 34a68fa0680b Author: gbenson Date: 2009-10-15 13:28 +0100 URL: http://hg.openjdk.java.net/jdk7/build/corba/rev/34a68fa0680b 6891677: java/build integrate zero assembler JDK changes Summary: Build changes for the Zero assembler port Reviewed-by: ohair, tbell ! make/common/Defs-linux.gmk ! make/common/shared/Compiler-gcc.gmk From ahughes at redhat.com Thu Oct 15 06:17:46 2009 From: ahughes at redhat.com (ahughes at redhat.com) Date: Thu, 15 Oct 2009 13:17:46 +0000 Subject: hg: jdk7/build/jdk: 6891677: java/build integrate zero assembler JDK changes Message-ID: <20091015131758.D242D41723@hg.openjdk.java.net> Changeset: e2de121c27c4 Author: gbenson Date: 2009-10-15 13:27 +0100 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/e2de121c27c4 6891677: java/build integrate zero assembler JDK changes Summary: Build changes for the Zero assembler port Reviewed-by: ohair, tbell ! make/common/Defs-linux.gmk ! make/common/Program.gmk ! make/java/instrument/Makefile ! make/java/jli/Makefile ! make/java/redist/Makefile ! make/javax/sound/SoundDefs.gmk ! make/jdk_generic_profile.sh ! src/share/native/com/sun/media/sound/SoundDefs.h + src/solaris/bin/ergo_zero.c + src/solaris/bin/zero/jvm.cfg From gnu_andrew at member.fsf.org Thu Oct 15 06:23:07 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Thu, 15 Oct 2009 14:23:07 +0100 Subject: Review request: Zero buildsystem changes In-Reply-To: <4AD6A198.9050903@sun.com> References: <20091009115839.GC3506@redhat.com> <20091014153147.GC3468@redhat.com> <4AD6A198.9050903@sun.com> Message-ID: <17c6771e0910150623i15f2d125y47686dbb578eb190@mail.gmail.com> 2009/10/15 Tim Bell : > Gary Benson wrote: > >> As an update to my previous message, the HotSpot part of this patch >> was tested and pushed to hotspot-comp last night, so the remaining >> code for review is this: >> >> ? http://cr.openjdk.java.net/~gbenson/zero-11-build/ >> >> I'm going on vacation on Friday 16, returning Monday 26, so could >> anyone replying off-list please Cc gnu_andrew at member.fsf.org, who >> is going to handle this in my absence. ?We'd love to see this in >> in time for Milestone 5, and we'd hate to miss the boat because >> an email was sitting in my inbox unread! > > (Adding Andrew as requested). > > These changes look OK to Kelly and myself. ?Also, my test run on our > internal build farm called JPRT (a full control build of everything after > adding your patch) worked: > >> JPRT: [sfbay] job notification - success with job 2009-10-14-203220.tbell.zero-11-build > > How would you like to proceed? ?With the hotspot work, Tom Rodriguez (AKA 'never') > did the push as an agent for you via JPRT because that is a hotspot requirement. > > I am willing to do that as well for the JDK changes, or you could create > the changeset and push yourself. ?We are not quite as strict about requiring > a JPRT grid build before pushing on the JDK side. ?I wish we were, but so > far I have not won that contest :-) > > > I filed bug ID 6891677 "java/build integrate zero assembler JDK changes" for > this, but it may not be visible externally for a day or two. > > Let me know - I'd be glad to help get this changeset in. > > Tim > > Pushed on Gary's behalf: http://hg.openjdk.java.net/jdk7/build/rev/608937d41381 http://hg.openjdk.java.net/jdk7/build/corba/rev/34a68fa0680b http://hg.openjdk.java.net/jdk7/build/jdk/rev/e2de121c27c4 Thanks, -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From gbenson at redhat.com Thu Oct 15 06:28:05 2009 From: gbenson at redhat.com (Gary Benson) Date: Thu, 15 Oct 2009 14:28:05 +0100 Subject: Review request: Zero buildsystem changes In-Reply-To: <17c6771e0910150623i15f2d125y47686dbb578eb190@mail.gmail.com> References: <20091009115839.GC3506@redhat.com> <20091014153147.GC3468@redhat.com> <4AD6A198.9050903@sun.com> <17c6771e0910150623i15f2d125y47686dbb578eb190@mail.gmail.com> Message-ID: <20091015132805.GH3556@redhat.com> Andrew John Hughes wrote: > 2009/10/15 Tim Bell : > > Gary Benson wrote: > > > As an update to my previous message, the HotSpot part of this > > > patch was tested and pushed to hotspot-comp last night, so the > > > remaining code for review is this: > > > > > > ? http://cr.openjdk.java.net/~gbenson/zero-11-build/ > > > > > > I'm going on vacation on Friday 16, returning Monday 26, so > > > could anyone replying off-list please Cc > > > gnu_andrew at member.fsf.org, who is going to handle this in my > > > absence. ?We'd love to see this in in time for Milestone 5, and > > > we'd hate to miss the boat because an email was sitting in my > > > inbox unread! > > > > (Adding Andrew as requested). > > > > These changes look OK to Kelly and myself. ?Also, my test run on > > our internal build farm called JPRT (a full control build of > > everything after adding your patch) worked: > > > > > JPRT: [sfbay] job notification - success with job 2009-10-14-203220.tbell.zero-11-build > > > > How would you like to proceed? ?With the hotspot work, Tom > > Rodriguez (AKA 'never') did the push as an agent for you via JPRT > > because that is a hotspot requirement. > > > > I am willing to do that as well for the JDK changes, or you could > > create the changeset and push yourself. ?We are not quite as > > strict about requiring a JPRT grid build before pushing on the JDK > > side. ?I wish we were, but so far I have not won that contest :-) > > > > I filed bug ID 6891677 "java/build integrate zero assembler JDK changes" for > > this, but it may not be visible externally for a day or two. > > > > Let me know - I'd be glad to help get this changeset in. > > Pushed on Gary's behalf: > > http://hg.openjdk.java.net/jdk7/build/rev/608937d41381 > http://hg.openjdk.java.net/jdk7/build/corba/rev/34a68fa0680b > http://hg.openjdk.java.net/jdk7/build/jdk/rev/e2de121c27c4 Tim, Andrew, many thanks :) Cheers, Gary -- http://gbenson.net/ From Tim.Bell at Sun.COM Thu Oct 15 07:33:53 2009 From: Tim.Bell at Sun.COM (Tim Bell) Date: Thu, 15 Oct 2009 07:33:53 -0700 Subject: Fix for 6888888 breaks the build In-Reply-To: <17c6771e0910150613w40d870d1ne20047231788a6d2@mail.gmail.com> References: <17c6771e0910150613w40d870d1ne20047231788a6d2@mail.gmail.com> Message-ID: <4AD732D1.1060409@sun.com> Andrew John Hughes wrote: > The fix for bug 6888888: > > http://hg.openjdk.java.net/jdk7/build/jdk/rev/777714bd992a > > breaks the build as it tries to use javah from ALT_JDK_IMPORT_DIR (via > JAVA_TOOLS_DIR) which is not set on normal builds. > The README tells the user to set ALT_BOOTDIR and changing > JAVA_TOOLS_DIR to be set to BOOTDIR makes the build work again: Sorry about that - my mistake. As Andrew pointed out on IRC: you can work around the bug by setting ALT_JDK_IMPORT_DIR to the same as ALT_BOOTDIR Jon Gibbons has a fix to 6889255 out for review, which will remove the 6888888 workaround: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6889255 http://cr.openjdk.java.net/~jjg/6889255-classreader.1 > http://cr.openjdk.java.net/~andrew/javah/webrev.01/ > > Ok to push? Unfortunately it is too late to fix in b74, and hopefully 6889255 will be fixed in b75. If not, I will come back to your patch. Tim From gnu_andrew at member.fsf.org Thu Oct 15 08:05:18 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Thu, 15 Oct 2009 16:05:18 +0100 Subject: Fix for 6888888 breaks the build In-Reply-To: <4AD732D1.1060409@sun.com> References: <17c6771e0910150613w40d870d1ne20047231788a6d2@mail.gmail.com> <4AD732D1.1060409@sun.com> Message-ID: <17c6771e0910150805i6d6b1318h4333e89cd2037bde@mail.gmail.com> 2009/10/15 Tim Bell : > Andrew John Hughes wrote: >> The fix for bug 6888888: >> >> http://hg.openjdk.java.net/jdk7/build/jdk/rev/777714bd992a >> >> breaks the build as it tries to use javah from ALT_JDK_IMPORT_DIR (via >> JAVA_TOOLS_DIR) which is not set on normal builds. >> The README tells the user to set ALT_BOOTDIR and changing >> JAVA_TOOLS_DIR to be set to BOOTDIR makes the build work again: > > Sorry about that - my mistake. > > As Andrew pointed out on IRC: > > ? you can work around the bug by setting ALT_JDK_IMPORT_DIR to the same as ALT_BOOTDIR > > Jon Gibbons has a fix to 6889255 out for review, which will remove the 6888888 > workaround: > ? http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6889255 > ? http://cr.openjdk.java.net/~jjg/6889255-classreader.1 > >> http://cr.openjdk.java.net/~andrew/javah/webrev.01/ >> >> Ok to push? > > Unfortunately it is too late to fix in b74, and hopefully 6889255 will be > fixed in b75. ?If not, I will come back to your patch. > > Tim > I think there's still an issue here that makes this patch worth pushing. The 6888888 fix didn't cause the bug, but merely made it visible to a lot more people. So 6889255 will only hide it again. The build uses JAVA_TOOLS_DIR for javac, javah and javadoc: # If no explicit tools, use boot tools (add VM flags in this case) JAVAC_CMD = $(JAVA_TOOLS_DIR)/javac $(JAVAC_JVM_FLAGS) \ $(JAVACFLAGS) JAVAH_CMD = $(JAVA_TOOLS_DIR)/javah \ $(JAVAHFLAGS) JAVADOC_CMD = $(JAVA_TOOLS_DIR)/javadoc $(JAVA_TOOLS_FLAGS:%=-J%) but only when LANGTOOLS_DIST is not defined. Normally, langtools is built first so LANGTOOLS_DIST is defined. What your fix for 6888888 did was cause the setting for JAVAH to get used in all cases and, as JAVA_TOOLS_DIR defaults to ALT_JDK_IMPORT_PATH rather than BOOTDIR this fails in many cases as the user sets ALT_BOOTDIR not ALT_JDK_IMPORT_PATH. In jdk_generic_profile, it seems ALT_JDK_IMPORT_PATH is set to ${jdk_instances}/${importjdk} if it exists. On Solaris, ${jdk_instances} is set to /usr/jdk/instances which probably explains why Sun engineers building on Solaris may not see this bug either. ${jdk_instances} is set to /opt/java on GNU/Linux, whereas distros tend to have standardised on /usr/lib/jvm. It's simply "C:" on Windows. As mentioned on IRC, release engineering are setting ALT_JDK_IMPORT_PATH explicitly so also would never see this bug. As we presumably want the tools from the bootstrap JDK, and not from 'the import JDK to be used to get hotspot VM if not built', I suggest we switch to BOOTDIR by default by applying this patch. -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From Jonathan.Gibbons at Sun.COM Thu Oct 15 08:57:52 2009 From: Jonathan.Gibbons at Sun.COM (Jonathan Gibbons) Date: Thu, 15 Oct 2009 08:57:52 -0700 Subject: Fix for 6888888 breaks the build In-Reply-To: <17c6771e0910150805i6d6b1318h4333e89cd2037bde@mail.gmail.com> References: <17c6771e0910150613w40d870d1ne20047231788a6d2@mail.gmail.com> <4AD732D1.1060409@sun.com> <17c6771e0910150805i6d6b1318h4333e89cd2037bde@mail.gmail.com> Message-ID: <4AD74680.3030000@sun.com> Andrew John Hughes wrote: > 2009/10/15 Tim Bell : > >> Andrew John Hughes wrote: >> >>> The fix for bug 6888888: >>> >>> http://hg.openjdk.java.net/jdk7/build/jdk/rev/777714bd992a >>> >>> breaks the build as it tries to use javah from ALT_JDK_IMPORT_DIR (via >>> JAVA_TOOLS_DIR) which is not set on normal builds. >>> The README tells the user to set ALT_BOOTDIR and changing >>> JAVA_TOOLS_DIR to be set to BOOTDIR makes the build work again: >>> >> Sorry about that - my mistake. >> >> As Andrew pointed out on IRC: >> >> you can work around the bug by setting ALT_JDK_IMPORT_DIR to the same as ALT_BOOTDIR >> >> Jon Gibbons has a fix to 6889255 out for review, which will remove the 6888888 >> workaround: >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6889255 >> http://cr.openjdk.java.net/~jjg/6889255-classreader.1 >> >> >>> http://cr.openjdk.java.net/~andrew/javah/webrev.01/ >>> >>> Ok to push? >>> >> Unfortunately it is too late to fix in b74, and hopefully 6889255 will be >> fixed in b75. If not, I will come back to your patch. >> >> Tim >> >> > > > I think there's still an issue here that makes this patch worth > pushing. The 6888888 fix didn't cause the bug, but merely made it > visible to a lot more people. So 6889255 will only hide it again. > The build uses JAVA_TOOLS_DIR for javac, javah and javadoc: > > # If no explicit tools, use boot tools (add VM flags in this case) > JAVAC_CMD = $(JAVA_TOOLS_DIR)/javac $(JAVAC_JVM_FLAGS) \ > $(JAVACFLAGS) > JAVAH_CMD = $(JAVA_TOOLS_DIR)/javah \ > $(JAVAHFLAGS) > JAVADOC_CMD = $(JAVA_TOOLS_DIR)/javadoc $(JAVA_TOOLS_FLAGS:%=-J%) > > > but only when LANGTOOLS_DIST is not defined. Normally, langtools is > built first so LANGTOOLS_DIST is defined. What your fix for 6888888 > did was cause the setting for JAVAH to get used in all cases and, as > JAVA_TOOLS_DIR defaults to ALT_JDK_IMPORT_PATH rather than BOOTDIR > this fails in many cases as the user sets ALT_BOOTDIR not > ALT_JDK_IMPORT_PATH. > > In jdk_generic_profile, it seems ALT_JDK_IMPORT_PATH is set to > ${jdk_instances}/${importjdk} if it exists. On Solaris, > ${jdk_instances} is set to /usr/jdk/instances which probably explains > why Sun engineers building on Solaris may not see this bug either. > ${jdk_instances} is set to /opt/java on GNU/Linux, whereas distros > tend to have standardised on /usr/lib/jvm. It's simply "C:" on > Windows. As mentioned on IRC, release engineering are setting > ALT_JDK_IMPORT_PATH explicitly so also would never see this bug. > > As we presumably want the tools from the bootstrap JDK, and not from > 'the import JDK to be used to get hotspot VM if not built', I suggest > we switch to BOOTDIR by default by applying this patch. > This probably explains problems I've reported informally to Kelly a while back, but never got around to formally investigating. FWIW, this fix does not interfere with the fix for 6889255 coming up, and this fix seems like a good idea to me. -- Jon -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/build-dev/attachments/20091015/05e56f10/attachment.html From Tim.Bell at Sun.COM Thu Oct 15 09:18:53 2009 From: Tim.Bell at Sun.COM (Tim Bell) Date: Thu, 15 Oct 2009 09:18:53 -0700 Subject: Fix for 6888888 breaks the build In-Reply-To: <4AD74680.3030000@sun.com> References: <17c6771e0910150613w40d870d1ne20047231788a6d2@mail.gmail.com> <4AD732D1.1060409@sun.com> <17c6771e0910150805i6d6b1318h4333e89cd2037bde@mail.gmail.com> <4AD74680.3030000@sun.com> Message-ID: <4AD74B6D.60709@sun.com> > Andrew John Hughes wrote: (snip!) >> I think there's still an issue here that makes this patch worth >> pushing. The 6888888 fix didn't cause the bug, but merely made it >> visible to a lot more people. So 6889255 will only hide it again. >> The build uses JAVA_TOOLS_DIR for javac, javah and javadoc: >> >> # If no explicit tools, use boot tools (add VM flags in this case) >> JAVAC_CMD = $(JAVA_TOOLS_DIR)/javac $(JAVAC_JVM_FLAGS) \ >> $(JAVACFLAGS) >> JAVAH_CMD = $(JAVA_TOOLS_DIR)/javah \ >> $(JAVAHFLAGS) >> JAVADOC_CMD = $(JAVA_TOOLS_DIR)/javadoc $(JAVA_TOOLS_FLAGS:%=-J%) >> >> >> but only when LANGTOOLS_DIST is not defined. Normally, langtools is >> built first so LANGTOOLS_DIST is defined. What your fix for 6888888 >> did was cause the setting for JAVAH to get used in all cases and, as >> JAVA_TOOLS_DIR defaults to ALT_JDK_IMPORT_PATH rather than BOOTDIR >> this fails in many cases as the user sets ALT_BOOTDIR not >> ALT_JDK_IMPORT_PATH. >> >> In jdk_generic_profile, it seems ALT_JDK_IMPORT_PATH is set to >> ${jdk_instances}/${importjdk} if it exists. On Solaris, >> ${jdk_instances} is set to /usr/jdk/instances which probably explains >> why Sun engineers building on Solaris may not see this bug either. >> ${jdk_instances} is set to /opt/java on GNU/Linux, whereas distros >> tend to have standardised on /usr/lib/jvm. It's simply "C:" on >> Windows. As mentioned on IRC, release engineering are setting >> ALT_JDK_IMPORT_PATH explicitly so also would never see this bug. >> >> As we presumably want the tools from the bootstrap JDK, and not from >> 'the import JDK to be used to get hotspot VM if not built', I suggest >> we switch to BOOTDIR by default by applying this patch. >> Jonathan Gibbons wrote: > This probably explains problems I've reported informally to Kelly a > while back, but never got around to formally investigating. FWIW, > this fix does not interfere with the fix for 6889255 coming up, and this > fix seems like a good idea to me. OK - I filed a new bug report: 6892021 "Build tools from ALT_JDK_IMPORT_PATH versus BOOTDIR" with a pointer to this email thread. Kelly - do you have an opinion on this? Thanks- Tim From Kelly.Ohair at Sun.COM Fri Oct 16 15:06:39 2009 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Fri, 16 Oct 2009 15:06:39 -0700 Subject: Fix for 6888888 breaks the build In-Reply-To: <4AD74B6D.60709@sun.com> References: <17c6771e0910150613w40d870d1ne20047231788a6d2@mail.gmail.com> <4AD732D1.1060409@sun.com> <17c6771e0910150805i6d6b1318h4333e89cd2037bde@mail.gmail.com> <4AD74680.3030000@sun.com> <4AD74B6D.60709@sun.com> Message-ID: <4AD8EE6F.3030900@sun.com> Tim Bell wrote: >> Andrew John Hughes wrote: > (snip!) >>> I think there's still an issue here that makes this patch worth >>> pushing. The 6888888 fix didn't cause the bug, but merely made it >>> visible to a lot more people. So 6889255 will only hide it again. >>> The build uses JAVA_TOOLS_DIR for javac, javah and javadoc: >>> >>> # If no explicit tools, use boot tools (add VM flags in this case) >>> JAVAC_CMD = $(JAVA_TOOLS_DIR)/javac $(JAVAC_JVM_FLAGS) \ >>> $(JAVACFLAGS) >>> JAVAH_CMD = $(JAVA_TOOLS_DIR)/javah \ >>> $(JAVAHFLAGS) >>> JAVADOC_CMD = $(JAVA_TOOLS_DIR)/javadoc $(JAVA_TOOLS_FLAGS:%=-J%) >>> >>> >>> but only when LANGTOOLS_DIST is not defined. Normally, langtools is >>> built first so LANGTOOLS_DIST is defined. What your fix for 6888888 >>> did was cause the setting for JAVAH to get used in all cases and, as >>> JAVA_TOOLS_DIR defaults to ALT_JDK_IMPORT_PATH rather than BOOTDIR >>> this fails in many cases as the user sets ALT_BOOTDIR not >>> ALT_JDK_IMPORT_PATH. >>> >>> In jdk_generic_profile, it seems ALT_JDK_IMPORT_PATH is set to >>> ${jdk_instances}/${importjdk} if it exists. On Solaris, >>> ${jdk_instances} is set to /usr/jdk/instances which probably explains >>> why Sun engineers building on Solaris may not see this bug either. >>> ${jdk_instances} is set to /opt/java on GNU/Linux, whereas distros >>> tend to have standardised on /usr/lib/jvm. It's simply "C:" on >>> Windows. As mentioned on IRC, release engineering are setting >>> ALT_JDK_IMPORT_PATH explicitly so also would never see this bug. >>> >>> As we presumably want the tools from the bootstrap JDK, and not from >>> 'the import JDK to be used to get hotspot VM if not built', I suggest >>> we switch to BOOTDIR by default by applying this patch. >>> > > Jonathan Gibbons wrote: > >> This probably explains problems I've reported informally to Kelly a >> while back, but never got around to formally investigating. FWIW, >> this fix does not interfere with the fix for 6889255 coming up, and this >> fix seems like a good idea to me. > > OK - I filed a new bug report: > 6892021 "Build tools from ALT_JDK_IMPORT_PATH versus BOOTDIR" > with a pointer to this email thread. > > Kelly - do you have an opinion on this? The goal was that a full jdk build would never need a ALT_JDK_IMPORT_PATH at all. And all class files would have been created by the LANGTOOLS_DIST compiler (hotspot was a special case, using the ALT_BOOTDIR to compile). But no class files would ever be created by the javac in ALT_BOOTDIR. ALT_JDK_IMPORT_PATH was supposed to only come into play when someone was doing what I called a 'partial build', and it provided the missing pieces, including a jdk7 flavored javac compiler. The other tools were less well defined in their use. The jar tool in ALT_BOOTDIR is always used to build jars as I recall. The javah and javadoc story I'm not so sure about. I thought they would have followed the same rules as javac. Not sure my ramblings are helping here.... :^( -kto > > Thanks- > > Tim From kelly.ohair at sun.com Tue Oct 20 16:15:55 2009 From: kelly.ohair at sun.com (kelly.ohair at sun.com) Date: Tue, 20 Oct 2009 23:15:55 +0000 Subject: hg: jdk7/build: 2 new changesets Message-ID: <20091020231555.A8ADB41F8C@hg.openjdk.java.net> Changeset: d1516b9f2395 Author: xdono Date: 2009-10-15 16:40 -0700 URL: http://hg.openjdk.java.net/jdk7/build/rev/d1516b9f2395 Added tag jdk7-b74 for changeset 2c88089b6e1c ! .hgtags Changeset: e193078b911e Author: ohair Date: 2009-10-20 16:14 -0700 URL: http://hg.openjdk.java.net/jdk7/build/rev/e193078b911e Merge From kelly.ohair at sun.com Tue Oct 20 16:15:59 2009 From: kelly.ohair at sun.com (kelly.ohair at sun.com) Date: Tue, 20 Oct 2009 23:15:59 +0000 Subject: hg: jdk7/build/corba: 2 new changesets Message-ID: <20091020231602.8672B41F8D@hg.openjdk.java.net> Changeset: 0fb137085952 Author: xdono Date: 2009-10-15 16:40 -0700 URL: http://hg.openjdk.java.net/jdk7/build/corba/rev/0fb137085952 Added tag jdk7-b74 for changeset 5d0cf59a3203 ! .hgtags Changeset: 3adebc594b44 Author: ohair Date: 2009-10-20 16:14 -0700 URL: http://hg.openjdk.java.net/jdk7/build/corba/rev/3adebc594b44 Merge From kelly.ohair at sun.com Tue Oct 20 16:18:33 2009 From: kelly.ohair at sun.com (kelly.ohair at sun.com) Date: Tue, 20 Oct 2009 23:18:33 +0000 Subject: hg: jdk7/build/jaxp: Added tag jdk7-b74 for changeset ea7b88c676dd Message-ID: <20091020231836.91A6341F90@hg.openjdk.java.net> Changeset: 555fb78ee4ce Author: xdono Date: 2009-10-15 16:40 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jaxp/rev/555fb78ee4ce Added tag jdk7-b74 for changeset ea7b88c676dd ! .hgtags From kelly.ohair at sun.com Tue Oct 20 16:18:41 2009 From: kelly.ohair at sun.com (kelly.ohair at sun.com) Date: Tue, 20 Oct 2009 23:18:41 +0000 Subject: hg: jdk7/build/jaxws: Added tag jdk7-b74 for changeset f4466e1b6080 Message-ID: <20091020231843.E117541F91@hg.openjdk.java.net> Changeset: fcf2b8b5d606 Author: xdono Date: 2009-10-15 16:40 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jaxws/rev/fcf2b8b5d606 Added tag jdk7-b74 for changeset f4466e1b6080 ! .hgtags From kelly.ohair at sun.com Tue Oct 20 16:18:50 2009 From: kelly.ohair at sun.com (kelly.ohair at sun.com) Date: Tue, 20 Oct 2009 23:18:50 +0000 Subject: hg: jdk7/build/jdk: 2 new changesets Message-ID: <20091020231926.39F5E41F92@hg.openjdk.java.net> Changeset: 99dfeece98e2 Author: xdono Date: 2009-10-15 16:40 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/99dfeece98e2 Added tag jdk7-b74 for changeset eacb36e30327 ! .hgtags Changeset: bbf84ba4414c Author: ohair Date: 2009-10-20 16:15 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/bbf84ba4414c Merge From kelly.ohair at sun.com Tue Oct 20 16:22:38 2009 From: kelly.ohair at sun.com (kelly.ohair at sun.com) Date: Tue, 20 Oct 2009 23:22:38 +0000 Subject: hg: jdk7/build/langtools: Added tag jdk7-b74 for changeset 1a66b08deed0 Message-ID: <20091020232242.A030F41F94@hg.openjdk.java.net> Changeset: 79c13af9217e Author: xdono Date: 2009-10-15 16:40 -0700 URL: http://hg.openjdk.java.net/jdk7/build/langtools/rev/79c13af9217e Added tag jdk7-b74 for changeset 1a66b08deed0 ! .hgtags From kelly.ohair at sun.com Tue Oct 20 16:23:51 2009 From: kelly.ohair at sun.com (kelly.ohair at sun.com) Date: Tue, 20 Oct 2009 23:23:51 +0000 Subject: hg: jdk7/build/hotspot: Added tag jdk7-b74 for changeset f4b900403d6e Message-ID: <20091020232356.9D29041F95@hg.openjdk.java.net> Changeset: 411c9c4ca96a Author: xdono Date: 2009-10-15 16:40 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/411c9c4ca96a Added tag jdk7-b74 for changeset f4b900403d6e ! .hgtags From Kelly.Ohair at Sun.COM Thu Oct 22 15:24:00 2009 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Thu, 22 Oct 2009 15:24:00 -0700 Subject: 6856630: Restructure jaxp/jaxws repository In-Reply-To: <17c6771e0910121318m26e53de3gb3bbea964b70f4eb@mail.gmail.com> References: <4AB80C37.6000108@sun.com> <17c6771e0910071424n3b12402bg80ed2f56210fb6e3@mail.gmail.com> <17c6771e0910090726r14a12ee4wadb5cc4e9fd141@mail.gmail.com> <4ACF6ECC.7070407@sun.com> <17c6771e0910121014w6fcd23e9rf5d594173e594ec3@mail.gmail.com> <4AD36C3F.2010501@sun.com> <17c6771e0910121318m26e53de3gb3bbea964b70f4eb@mail.gmail.com> Message-ID: <4AE0DB80.90107@sun.com> Andrew, Sorry I'm so slow on this, ... I'm looking at updating the jaxp bundle. The webrev is: http://cr.openjdk.java.net/~ohair/openjdk7/jdk7-tl-jaxp-6861589/webrev/ Updated jaxp source bundle, and complete removal of anything that would use the original source. The final changeset will also delete the jaxp/src directory so we never accidently use it. It also adds a md5 checksum check on the bundle in the ant script, a property value contains the expected checksum. I'm not done, so I could add more if you want me to add the changes mentioned here... The merge should be trivial. One snag is that I plan on pushing this to the TL forest so that the TL integrator (Tim Bell) can get the appropriate tests done on the jaxp changes. In the future jaxp changes will probably be going through the TL area. ... a few more comments below... Andrew John Hughes wrote: > 2009/10/12 Kelly O'Hair : >> I saw the webrev for a while, and now I can't :^(, but I saw enough... >> >>>> Andrew John Hughes wrote: >>>>> 2009/10/7 Andrew John Hughes : >> ...[snip]... >>>>> I found a number of issues with the current version: >>>>> >>>>> * The drop zips are expected to be in a share/jdk7-drops subdirectory >>>>> of the devtools directory. This doesn't really work outside Sun's >>>>> internal setup. I've added support for ALT_DROP_DIR which can be used >>>>> to specify an exact path to the zips. If this is not set, the old >>>>> devtools behaviour is used. >> I'm concerned about the name dropdir (your master copy location) vs. >> drop.dir >> (destination for the exploded contents) in the property names. Seems >> confusing. >> I hesitate to go on a name hunt, but what about ALT_DROP_BUNDLE_DIR and >> drop.bundle.dir? >> > > Yes, I noticed drop.dir after posting the webrev and agree it's > confusing. Would just making them ALT_DROPS_DIR and drops.dir not be > sufficient? drop.bundle seems a little verbose and both mean the same > thing to me at least. I'm ok with ALT_DROPS_DIR and drops.dir. > >>>>> * The zips are being downloaded and extracted in the source directory, >>>>> which could be read only. I've changed this so they are written to >>>>> the build directory like everything else. >> It turns out that we need this drop.dir to be in the source area if >> we want the openjdk source zip bundles, created by RE, to include >> the drop sources. These source bundles are created by bundling up >> everything in the forest, prior to building, so the drop.dir needs >> to be in the forest somehow. Otherwise, the bundling logic has to >> merge two separate source trees, or different roots. >> I was given a requirement that the openjdk source bundles include these >> drop sources, easiest answer was drop.dir in the repo. >> Not an unsurmountable problem, I avoided the more complicated path. >> >> I know that becomes an issue if the repository or source is in a >> read-only area, but that's not the only situation in the openjdk I suspect. >> I assumed someone building from a read-only area could set >> drop.dir to some other location. >> > > Would it not make more sense for RE to set the drop.dir property into > the source directory, given it's that build that's abnormal (needing > to distribute a post build tree in effect)? I will look into that. You have convinced me. ;^) > >> Not sure what to say. >> >> How important is it for the community that the openjdk source bundles >> include these drop sources? e.g. ones at >> http://download.java.net/openjdk/jdk7/ >> If they are not included, when the openjdk source bundles are built, >> they will need to download the jaxp and jaxws drop bundles at build time. >> > > I obviously can't speak for everyone, but for IcedTea7 we don't even > use the download bundles any more. We grab from the IcedTea forest > instead, which allows patches which didn't make a bxx release to be > applied there once and used in releases. We did this for the security > fixes with Milestone 4/1.11. > > I've already added downloading of the jaxp, jaxws and jaf bundles to > the IcedTea build; it's this process that resulted in this webrev. > This has two advantages; we check all the zips/tarballs at the same > point in the build (the JAXP and JAXWS builds are then pointed at the > directory IcedTea uses for them) and we check the MD5 sums of the > downloads or pre-existing zips. I don't know if the latter could be > incorporated into the OpenJDK build somehow. At present, there's no > guarantee that these zips are valid. > > The rules look like this: > > stamps/download-jaxp-drop.stamp: > mkdir -p drops > if USE_ALT_JAXP_DROP_ZIP > ln -sf $(ALT_JAXP_DROP_ZIP) drops/$(JAXP_DROP_ZIP) > endif > if ! echo "$(JAXP_DROP_MD5SUM) drops/$(JAXP_DROP_ZIP)" \ > | $(MD5SUM) --check ; \ > then \ > if [ -f drops/$(JAXP_DROP_ZIP) ] ; \ > then \ > mv drops/$(JAXP_DROP_ZIP) drops/$(JAXP_DROP_ZIP).old ; \ > fi ; \ > $(WGET) $(DROP_URL)/$(JAXP_DROP_ZIP) -O > drops/$(JAXP_DROP_ZIP); \ > fi ; > mkdir -p stamps > touch stamps/download-jaxp-drop.stamp > > ALT_JAXP_DROP_ZIP gets set if the user specifies > --with-jaxp-drop-zip= to configure. WGET and MD5SUM are the > respective binaries as located by configure and DROP_URL is the > kenai.com URL as in the jaxws.properties and jaxp.properties files: > > DROP_URL = http://kenai.com/projects/jdk7-drops/downloads/download > JAXWS_DROP_ZIP = jdk7-jaxws-2009_09_28.zip > JAXWS_DROP_MD5SUM = debb949440c5a15ce999cfefbbc56526 > JAF_DROP_ZIP = jdk7-jaf-2009_08_28.zip > JAF_DROP_MD5SUM = eb8cb7a4a7f14e211fbe2354878a2472 > JAXP_DROP_ZIP = jdk7-jaxp-2009_09_28.zip > JAXP_DROP_MD5SUM = 8800970d03bab1fff188dcfafc346f5d Ah... so my checksum logic in the ant script will serve as a double check. Unless you are changing the bundles and rebundling them... nobody does that, ... do they??? Ah, if they do, they would need to change the property value holding the checksum. -kto > >> -kto >> >>>>> The webrev for these changes is here: >>>>> >>>>> http://cr.openjdk.java.net/~andrew/drops/webrev.01/ >>>>> >>>>> I've committed this to IcedTea already. Does this look ok for build >>>>> also? >>> >>> > > > From Kelly.Ohair at Sun.COM Thu Oct 22 17:42:45 2009 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Thu, 22 Oct 2009 17:42:45 -0700 Subject: 6856630: Restructure jaxp/jaxws repository In-Reply-To: <4AE0DB80.90107@sun.com> References: <4AB80C37.6000108@sun.com> <17c6771e0910071424n3b12402bg80ed2f56210fb6e3@mail.gmail.com> <17c6771e0910090726r14a12ee4wadb5cc4e9fd141@mail.gmail.com> <4ACF6ECC.7070407@sun.com> <17c6771e0910121014w6fcd23e9rf5d594173e594ec3@mail.gmail.com> <4AD36C3F.2010501@sun.com> <17c6771e0910121318m26e53de3gb3bbea964b70f4eb@mail.gmail.com> <4AE0DB80.90107@sun.com> Message-ID: <4AE0FC05.8080802@sun.com> Sigh... if I'm changing jaxp, might as well change jaxws too.... keep them in sync. I effectively included the drop.dir change you wanted with these webrevs: http://cr.openjdk.java.net/~ohair/openjdk7/jdk7-tl-jaxp/webrev/ http://cr.openjdk.java.net/~ohair/openjdk7/jdk7-tl-jaxws/webrev/ In both cases, any use of the original source is being removed, and the changeset I create will probably just delete the "src/" directory. I'm using a different directory name when the dropped sources are baked in by our RE people, "drop_included" (should have called these batteries so I could use "batteries_included". ;^) So there are two properties drop.expanded.dir and drop.included.dir, and the drop.dir property is conditional set in the ant script. But I did not add the ALT_DROPS_DIR change. Do you want me to include that, or do you want to make that change separately? -kto From Jonathan.Gibbons at Sun.COM Thu Oct 22 17:49:47 2009 From: Jonathan.Gibbons at Sun.COM (Jonathan Gibbons) Date: Thu, 22 Oct 2009 17:49:47 -0700 Subject: 6856630: Restructure jaxp/jaxws repository In-Reply-To: <4AE0DB80.90107@sun.com> References: <4AB80C37.6000108@sun.com> <17c6771e0910071424n3b12402bg80ed2f56210fb6e3@mail.gmail.com> <17c6771e0910090726r14a12ee4wadb5cc4e9fd141@mail.gmail.com> <4ACF6ECC.7070407@sun.com> <17c6771e0910121014w6fcd23e9rf5d594173e594ec3@mail.gmail.com> <4AD36C3F.2010501@sun.com> <17c6771e0910121318m26e53de3gb3bbea964b70f4eb@mail.gmail.com> <4AE0DB80.90107@sun.com> Message-ID: <4AE0FDAB.1080305@sun.com> Kelly O'Hair wrote: > Andrew, > > Sorry I'm so slow on this, ... > > I'm looking at updating the jaxp bundle. The webrev is: > > http://cr.openjdk.java.net/~ohair/openjdk7/jdk7-tl-jaxp-6861589/webrev/ > > Updated jaxp source bundle, and complete removal of anything > that would use the original source. The final changeset will also > delete the jaxp/src directory so we never accidently use it. > It also adds a md5 checksum check on the bundle in the ant script, > a property value contains the expected checksum. > > I'm not done, so I could add more if you want me to add the changes > mentioned here... The merge should be trivial. > > One snag is that I plan on pushing this to the TL forest so that > the TL integrator (Tim Bell) can get the appropriate tests done > on the jaxp changes. In the future jaxp changes will probably > be going through the TL area. > > ... a few more comments below... > > Andrew John Hughes wrote: >> 2009/10/12 Kelly O'Hair : >>> I saw the webrev for a while, and now I can't :^(, but I saw enough... >>> >>>>> Andrew John Hughes wrote: >>>>>> 2009/10/7 Andrew John Hughes : >>> ...[snip]... >>>>>> I found a number of issues with the current version: >>>>>> >>>>>> * The drop zips are expected to be in a share/jdk7-drops >>>>>> subdirectory >>>>>> of the devtools directory. This doesn't really work outside Sun's >>>>>> internal setup. I've added support for ALT_DROP_DIR which can be >>>>>> used >>>>>> to specify an exact path to the zips. If this is not set, the old >>>>>> devtools behaviour is used. >>> I'm concerned about the name dropdir (your master copy location) vs. >>> drop.dir >>> (destination for the exploded contents) in the property names. Seems >>> confusing. >>> I hesitate to go on a name hunt, but what about ALT_DROP_BUNDLE_DIR and >>> drop.bundle.dir? >>> >> >> Yes, I noticed drop.dir after posting the webrev and agree it's >> confusing. Would just making them ALT_DROPS_DIR and drops.dir not be >> sufficient? drop.bundle seems a little verbose and both mean the same >> thing to me at least. > > I'm ok with ALT_DROPS_DIR and drops.dir. > >> >>>>>> * The zips are being downloaded and extracted in the source >>>>>> directory, >>>>>> which could be read only. I've changed this so they are written to >>>>>> the build directory like everything else. >>> It turns out that we need this drop.dir to be in the source area if >>> we want the openjdk source zip bundles, created by RE, to include >>> the drop sources. These source bundles are created by bundling up >>> everything in the forest, prior to building, so the drop.dir needs >>> to be in the forest somehow. Otherwise, the bundling logic has to >>> merge two separate source trees, or different roots. >>> I was given a requirement that the openjdk source bundles include these >>> drop sources, easiest answer was drop.dir in the repo. >>> Not an unsurmountable problem, I avoided the more complicated path. >>> >>> I know that becomes an issue if the repository or source is in a >>> read-only area, but that's not the only situation in the openjdk I >>> suspect. >>> I assumed someone building from a read-only area could set >>> drop.dir to some other location. >>> >> >> Would it not make more sense for RE to set the drop.dir property into >> the source directory, given it's that build that's abnormal (needing >> to distribute a post build tree in effect)? > > I will look into that. You have convinced me. ;^) > >> >>> Not sure what to say. >>> >>> How important is it for the community that the openjdk source bundles >>> include these drop sources? e.g. ones at >>> http://download.java.net/openjdk/jdk7/ >>> If they are not included, when the openjdk source bundles are built, >>> they will need to download the jaxp and jaxws drop bundles at build >>> time. >>> >> >> I obviously can't speak for everyone, but for IcedTea7 we don't even >> use the download bundles any more. We grab from the IcedTea forest >> instead, which allows patches which didn't make a bxx release to be >> applied there once and used in releases. We did this for the security >> fixes with Milestone 4/1.11. >> >> I've already added downloading of the jaxp, jaxws and jaf bundles to >> the IcedTea build; it's this process that resulted in this webrev. >> This has two advantages; we check all the zips/tarballs at the same >> point in the build (the JAXP and JAXWS builds are then pointed at the >> directory IcedTea uses for them) and we check the MD5 sums of the >> downloads or pre-existing zips. I don't know if the latter could be >> incorporated into the OpenJDK build somehow. At present, there's no >> guarantee that these zips are valid. >> >> The rules look like this: >> >> stamps/download-jaxp-drop.stamp: >> mkdir -p drops >> if USE_ALT_JAXP_DROP_ZIP >> ln -sf $(ALT_JAXP_DROP_ZIP) drops/$(JAXP_DROP_ZIP) >> endif >> if ! echo "$(JAXP_DROP_MD5SUM) drops/$(JAXP_DROP_ZIP)" \ >> | $(MD5SUM) --check ; \ >> then \ >> if [ -f drops/$(JAXP_DROP_ZIP) ] ; \ >> then \ >> mv drops/$(JAXP_DROP_ZIP) drops/$(JAXP_DROP_ZIP).old ; \ >> fi ; \ >> $(WGET) $(DROP_URL)/$(JAXP_DROP_ZIP) -O >> drops/$(JAXP_DROP_ZIP); \ >> fi ; >> mkdir -p stamps >> touch stamps/download-jaxp-drop.stamp >> >> ALT_JAXP_DROP_ZIP gets set if the user specifies >> --with-jaxp-drop-zip= to configure. WGET and MD5SUM are the >> respective binaries as located by configure and DROP_URL is the >> kenai.com URL as in the jaxws.properties and jaxp.properties files: >> >> DROP_URL = http://kenai.com/projects/jdk7-drops/downloads/download >> JAXWS_DROP_ZIP = jdk7-jaxws-2009_09_28.zip >> JAXWS_DROP_MD5SUM = debb949440c5a15ce999cfefbbc56526 >> JAF_DROP_ZIP = jdk7-jaf-2009_08_28.zip >> JAF_DROP_MD5SUM = eb8cb7a4a7f14e211fbe2354878a2472 >> JAXP_DROP_ZIP = jdk7-jaxp-2009_09_28.zip >> JAXP_DROP_MD5SUM = 8800970d03bab1fff188dcfafc346f5d > > Ah... so my checksum logic in the ant script will serve as a > double check. > > Unless you are changing the bundles and rebundling them... > nobody does that, ... do they??? > Ah, if they do, they would need to change the property value > holding the checksum. > > -kto > >> >>> -kto >>> >>>>>> The webrev for these changes is here: >>>>>> >>>>>> http://cr.openjdk.java.net/~andrew/drops/webrev.01/ >>>>>> >>>>>> I've committed this to IcedTea already. Does this look ok for build >>>>>> also? >>>> >>>> >> >> >> Kelly, Does all this mean we can somewhat simplify the list of forests on hg.o.j.n, by removing jdk7/{corba,jaxp,jaxws} and the corresponding -gate forests? -- Jon From Weijun.Wang at Sun.COM Thu Oct 22 18:05:43 2009 From: Weijun.Wang at Sun.COM (Max (Weijun) Wang) Date: Fri, 23 Oct 2009 09:05:43 +0800 Subject: No subject Message-ID: <0A946DB0-8ABB-4E53-98B7-6E145B0D1D6D@sun.com> Hi Martin I've just changed my Linux box to a x86_64 one, and my first build of JDK 7 shows these errors: ... cc1plus: warnings being treated as errors /media/sda6/space/work/myjdk/hotspot/src/cpu/x86/vm/ methodHandles_x86.cpp: In function ?void trace_method_handle_stub(const char*, oopDesc*, intptr_t*, intptr_t*)?: /media/sda6/space/work/myjdk/hotspot/src/cpu/x86/vm/ methodHandles_x86.cpp:276: error: format ?%016lx? expects type ?long unsigned int?, but argument 3 has type ?void*? /media/sda6/space/work/myjdk/hotspot/src/cpu/x86/vm/ methodHandles_x86.cpp:276: error: format ?%016lx? expects type ?long unsigned int?, but argument 4 has type ?intptr_t*? make[7]: *** [methodHandles_x86.o] Error 1 ... What am I missing here? and, do you have any private patches to share? Thanks Max From martinrb at google.com Thu Oct 22 20:48:11 2009 From: martinrb at google.com (Martin Buchholz) Date: Thu, 22 Oct 2009 20:48:11 -0700 Subject: In-Reply-To: <0A946DB0-8ABB-4E53-98B7-6E145B0D1D6D@sun.com> References: <0A946DB0-8ABB-4E53-98B7-6E145B0D1D6D@sun.com> Message-ID: <1ccfd1c10910222048m5e2093e9ndc388cd65e90069c@mail.gmail.com> Hi Max, Sounds to me like you're using a very recent gcc. My policy has been to use a stodgy gcc, and let other folks use bleeding edge. Fedora/Ubuntu hackers are more likely to dogfood their gcc.... so check out the icedtea patch set. I wish that Openjdk release engineering maintained buildability by a broad range of compilers through regular testing. Martin On Thu, Oct 22, 2009 at 18:05, Max (Weijun) Wang wrote: > Hi Martin > > I've just changed my Linux box to a x86_64 one, and my first build of JDK 7 > shows these errors: > > ... > cc1plus: warnings being treated as errors > /media/sda6/space/work/myjdk/hotspot/src/cpu/x86/vm/methodHandles_x86.cpp: > In function ?void trace_method_handle_stub(const char*, oopDesc*, intptr_t*, > intptr_t*)?: > /media/sda6/space/work/myjdk/hotspot/src/cpu/x86/vm/methodHandles_x86.cpp:276: > error: format ?%016lx? expects type ?long unsigned int?, but argument 3 has > type ?void*? > /media/sda6/space/work/myjdk/hotspot/src/cpu/x86/vm/methodHandles_x86.cpp:276: > error: format ?%016lx? expects type ?long unsigned int?, but argument 4 has > type ?intptr_t*? > make[7]: *** [methodHandles_x86.o] Error 1 > ... > > What am I missing here? and, do you have any private patches to share? > > Thanks > Max > > From Weijun.Wang at Sun.COM Thu Oct 22 20:51:04 2009 From: Weijun.Wang at Sun.COM (Weijun Wang) Date: Fri, 23 Oct 2009 11:51:04 +0800 Subject: hotspot build failure on ubuntu x86_64 In-Reply-To: <1ccfd1c10910222048m5e2093e9ndc388cd65e90069c@mail.gmail.com> References: <0A946DB0-8ABB-4E53-98B7-6E145B0D1D6D@sun.com> <1ccfd1c10910222048m5e2093e9ndc388cd65e90069c@mail.gmail.com> Message-ID: <4AE12828.2020603@sun.com> Martin Buchholz wrote: > Hi Max, > > Sounds to me like you're using a very recent gcc. Probably, I'm using the gcc of 'apt-get install' on this 9.04. > My policy has been to use a stodgy gcc, > and let other folks use bleeding edge. > Fedora/Ubuntu hackers are more likely > to dogfood their gcc.... so check out the > icedtea patch set. Ok, I'll go have a look. Thanks Max > > I wish that Openjdk release engineering maintained > buildability by a broad range of compilers > through regular testing. > > Martin > > On Thu, Oct 22, 2009 at 18:05, Max (Weijun) Wang wrote: >> Hi Martin >> >> I've just changed my Linux box to a x86_64 one, and my first build of JDK 7 >> shows these errors: >> >> ... >> cc1plus: warnings being treated as errors >> /media/sda6/space/work/myjdk/hotspot/src/cpu/x86/vm/methodHandles_x86.cpp: >> In function ?void trace_method_handle_stub(const char*, oopDesc*, intptr_t*, >> intptr_t*)?: >> /media/sda6/space/work/myjdk/hotspot/src/cpu/x86/vm/methodHandles_x86.cpp:276: >> error: format ?%016lx? expects type ?long unsigned int?, but argument 3 has >> type ?void*? >> /media/sda6/space/work/myjdk/hotspot/src/cpu/x86/vm/methodHandles_x86.cpp:276: >> error: format ?%016lx? expects type ?long unsigned int?, but argument 4 has >> type ?intptr_t*? >> make[7]: *** [methodHandles_x86.o] Error 1 >> ... >> >> What am I missing here? and, do you have any private patches to share? >> >> Thanks >> Max >> >> From Weijun.Wang at Sun.COM Thu Oct 22 23:32:26 2009 From: Weijun.Wang at Sun.COM (Weijun Wang) Date: Fri, 23 Oct 2009 14:32:26 +0800 Subject: hotspot build failure on ubuntu x86_64 In-Reply-To: <4AE12828.2020603@sun.com> References: <0A946DB0-8ABB-4E53-98B7-6E145B0D1D6D@sun.com> <1ccfd1c10910222048m5e2093e9ndc388cd65e90069c@mail.gmail.com> <4AE12828.2020603@sun.com> Message-ID: <4AE14DFA.4000601@sun.com> Hi Martin Since the error line is only a printf message, I just remove the line. And now everything builds fine! I'll see if the PTR_FORMAT macro is used in other places and why there's no problem there. Thanks Max Weijun Wang wrote: > > Martin Buchholz wrote: >> Hi Max, >> >> Sounds to me like you're using a very recent gcc. > > Probably, I'm using the gcc of 'apt-get install' on this 9.04. > >> My policy has been to use a stodgy gcc, >> and let other folks use bleeding edge. >> Fedora/Ubuntu hackers are more likely >> to dogfood their gcc.... so check out the >> icedtea patch set. > > Ok, I'll go have a look. > > Thanks > Max > >> I wish that Openjdk release engineering maintained >> buildability by a broad range of compilers >> through regular testing. >> >> Martin >> >> On Thu, Oct 22, 2009 at 18:05, Max (Weijun) Wang wrote: >>> Hi Martin >>> >>> I've just changed my Linux box to a x86_64 one, and my first build of JDK 7 >>> shows these errors: >>> >>> ... >>> cc1plus: warnings being treated as errors >>> /media/sda6/space/work/myjdk/hotspot/src/cpu/x86/vm/methodHandles_x86.cpp: >>> In function ?void trace_method_handle_stub(const char*, oopDesc*, intptr_t*, >>> intptr_t*)?: >>> /media/sda6/space/work/myjdk/hotspot/src/cpu/x86/vm/methodHandles_x86.cpp:276: >>> error: format ?%016lx? expects type ?long unsigned int?, but argument 3 has >>> type ?void*? >>> /media/sda6/space/work/myjdk/hotspot/src/cpu/x86/vm/methodHandles_x86.cpp:276: >>> error: format ?%016lx? expects type ?long unsigned int?, but argument 4 has >>> type ?intptr_t*? >>> make[7]: *** [methodHandles_x86.o] Error 1 >>> ... >>> >>> What am I missing here? and, do you have any private patches to share? >>> >>> Thanks >>> Max >>> >>> From John.Rose at Sun.COM Fri Oct 23 00:20:41 2009 From: John.Rose at Sun.COM (John Rose) Date: Fri, 23 Oct 2009 00:20:41 -0700 Subject: printf errors compiling with new gcc In-Reply-To: <0A946DB0-8ABB-4E53-98B7-6E145B0D1D6D@sun.com> References: <0A946DB0-8ABB-4E53-98B7-6E145B0D1D6D@sun.com> Message-ID: We talked about this on the bsd-port mailing list. It may be due to new error checks in GCC 4.2. On Mac, even after those compile-time errors are fixed, GCC 4.2 does not build a usable hotspot. After upgrading to Snow Leopard (10.6), I had to back the gcc to 4.0 for building hotspot. HTH -- John On Oct 22, 2009, at 6:05 PM, Max (Weijun) Wang wrote: > Hi Martin > > I've just changed my Linux box to a x86_64 one, and my first build > of JDK 7 shows these errors: > > ... > cc1plus: warnings being treated as errors > /media/sda6/space/work/myjdk/hotspot/src/cpu/x86/vm/ > methodHandles_x86.cpp: In function ?void trace_method_handle_stub > (const char*, oopDesc*, intptr_t*, intptr_t*)?: > /media/sda6/space/work/myjdk/hotspot/src/cpu/x86/vm/ > methodHandles_x86.cpp:276: error: format ?%016lx? expects type ?long > unsigned int?, but argument 3 has type ?void*? > /media/sda6/space/work/myjdk/hotspot/src/cpu/x86/vm/ > methodHandles_x86.cpp:276: error: format ?%016lx? expects type ?long > unsigned int?, but argument 4 has type ?intptr_t*? > make[7]: *** [methodHandles_x86.o] Error 1 > ... > > What am I missing here? and, do you have any private patches to share? > > Thanks > Max > From gnu_andrew at member.fsf.org Fri Oct 23 05:16:19 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Fri, 23 Oct 2009 13:16:19 +0100 Subject: 6856630: Restructure jaxp/jaxws repository In-Reply-To: <4AE0FC05.8080802@sun.com> References: <4AB80C37.6000108@sun.com> <17c6771e0910071424n3b12402bg80ed2f56210fb6e3@mail.gmail.com> <17c6771e0910090726r14a12ee4wadb5cc4e9fd141@mail.gmail.com> <4ACF6ECC.7070407@sun.com> <17c6771e0910121014w6fcd23e9rf5d594173e594ec3@mail.gmail.com> <4AD36C3F.2010501@sun.com> <17c6771e0910121318m26e53de3gb3bbea964b70f4eb@mail.gmail.com> <4AE0DB80.90107@sun.com> <4AE0FC05.8080802@sun.com> Message-ID: <17c6771e0910230516p3de79681p436f28b7c51be2f8@mail.gmail.com> 2009/10/23 Kelly O'Hair : > > Sigh... if I'm changing jaxp, might as well change jaxws too.... > keep them in sync. > > I effectively included the drop.dir change you wanted with these > webrevs: > > http://cr.openjdk.java.net/~ohair/openjdk7/jdk7-tl-jaxp/webrev/ > http://cr.openjdk.java.net/~ohair/openjdk7/jdk7-tl-jaxws/webrev/ > > In both cases, any use of the original source is being removed, and > the changeset I create will probably just delete the "src/" directory. > Good, makes things clearer. > I'm using a different directory name when the dropped sources are > baked in by our RE people, "drop_included" (should have called these > batteries so I could use "batteries_included". ;^) > Ok, I think it makes the build.xml more complicated than necessary, given you could just set drop.dir for builds which include the source, but I'm happy enough with it. > So there are two properties drop.expanded.dir and drop.included.dir, > and the drop.dir property is conditional set in the ant script. > > But I did not add the ALT_DROPS_DIR change. > Do you want me to include that, or do you want to make that change > separately? > There's already three changes in this one changeset: * Removing the original source option * Adding drop.expanded (which seems similar to the original source option except you can specify the directory) * Checksumming so I'd rather we had the ALT_DROPS_DIR in a separate one, but I don't mind who commits it. I also notice the URL changes -- why? > -kto > Thanks, -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From Christian.Thalinger at Sun.COM Fri Oct 23 08:46:15 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Fri, 23 Oct 2009 17:46:15 +0200 Subject: hotspot build failure on ubuntu x86_64 In-Reply-To: <4AE14DFA.4000601@sun.com> References: <0A946DB0-8ABB-4E53-98B7-6E145B0D1D6D@sun.com> <1ccfd1c10910222048m5e2093e9ndc388cd65e90069c@mail.gmail.com> <4AE12828.2020603@sun.com> <4AE14DFA.4000601@sun.com> Message-ID: <1256312775.833.41.camel@macbook> On Fri, 2009-10-23 at 14:32 +0800, Weijun Wang wrote: > Hi Martin > > Since the error line is only a printf message, I just remove the line. > And now everything builds fine! > > I'll see if the PTR_FORMAT macro is used in other places and why there's > no problem there. This line is part of the new JSR 292 code and a fix for the build issue will be commited (with all other JSR 292 stuff) before M5. Sorry for the inconvenience. -- Christian From Kelly.Ohair at Sun.COM Fri Oct 23 09:23:40 2009 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Fri, 23 Oct 2009 09:23:40 -0700 Subject: 6856630: Restructure jaxp/jaxws repository In-Reply-To: <4AE0FDAB.1080305@sun.com> References: <4AB80C37.6000108@sun.com> <17c6771e0910071424n3b12402bg80ed2f56210fb6e3@mail.gmail.com> <17c6771e0910090726r14a12ee4wadb5cc4e9fd141@mail.gmail.com> <4ACF6ECC.7070407@sun.com> <17c6771e0910121014w6fcd23e9rf5d594173e594ec3@mail.gmail.com> <4AD36C3F.2010501@sun.com> <17c6771e0910121318m26e53de3gb3bbea964b70f4eb@mail.gmail.com> <4AE0DB80.90107@sun.com> <4AE0FDAB.1080305@sun.com> Message-ID: <4AE1D88C.5040408@sun.com> Jonathan Gibbons wrote: > Kelly O'Hair wrote: >> Andrew, >> >> Sorry I'm so slow on this, ... >> >> I'm looking at updating the jaxp bundle. The webrev is: >> >> http://cr.openjdk.java.net/~ohair/openjdk7/jdk7-tl-jaxp-6861589/webrev/ >> >> Updated jaxp source bundle, and complete removal of anything >> that would use the original source. The final changeset will also >> delete the jaxp/src directory so we never accidently use it. >> It also adds a md5 checksum check on the bundle in the ant script, >> a property value contains the expected checksum. >> >> I'm not done, so I could add more if you want me to add the changes >> mentioned here... The merge should be trivial. >> >> One snag is that I plan on pushing this to the TL forest so that >> the TL integrator (Tim Bell) can get the appropriate tests done >> on the jaxp changes. In the future jaxp changes will probably >> be going through the TL area. >> >> ... a few more comments below... >> >> Andrew John Hughes wrote: >>> 2009/10/12 Kelly O'Hair : >>>> I saw the webrev for a while, and now I can't :^(, but I saw enough... >>>> >>>>>> Andrew John Hughes wrote: >>>>>>> 2009/10/7 Andrew John Hughes : >>>> ...[snip]... >>>>>>> I found a number of issues with the current version: >>>>>>> >>>>>>> * The drop zips are expected to be in a share/jdk7-drops >>>>>>> subdirectory >>>>>>> of the devtools directory. This doesn't really work outside Sun's >>>>>>> internal setup. I've added support for ALT_DROP_DIR which can be >>>>>>> used >>>>>>> to specify an exact path to the zips. If this is not set, the old >>>>>>> devtools behaviour is used. >>>> I'm concerned about the name dropdir (your master copy location) vs. >>>> drop.dir >>>> (destination for the exploded contents) in the property names. Seems >>>> confusing. >>>> I hesitate to go on a name hunt, but what about ALT_DROP_BUNDLE_DIR and >>>> drop.bundle.dir? >>>> >>> >>> Yes, I noticed drop.dir after posting the webrev and agree it's >>> confusing. Would just making them ALT_DROPS_DIR and drops.dir not be >>> sufficient? drop.bundle seems a little verbose and both mean the same >>> thing to me at least. >> >> I'm ok with ALT_DROPS_DIR and drops.dir. >> >>> >>>>>>> * The zips are being downloaded and extracted in the source >>>>>>> directory, >>>>>>> which could be read only. I've changed this so they are written to >>>>>>> the build directory like everything else. >>>> It turns out that we need this drop.dir to be in the source area if >>>> we want the openjdk source zip bundles, created by RE, to include >>>> the drop sources. These source bundles are created by bundling up >>>> everything in the forest, prior to building, so the drop.dir needs >>>> to be in the forest somehow. Otherwise, the bundling logic has to >>>> merge two separate source trees, or different roots. >>>> I was given a requirement that the openjdk source bundles include these >>>> drop sources, easiest answer was drop.dir in the repo. >>>> Not an unsurmountable problem, I avoided the more complicated path. >>>> >>>> I know that becomes an issue if the repository or source is in a >>>> read-only area, but that's not the only situation in the openjdk I >>>> suspect. >>>> I assumed someone building from a read-only area could set >>>> drop.dir to some other location. >>>> >>> >>> Would it not make more sense for RE to set the drop.dir property into >>> the source directory, given it's that build that's abnormal (needing >>> to distribute a post build tree in effect)? >> >> I will look into that. You have convinced me. ;^) >> >>> >>>> Not sure what to say. >>>> >>>> How important is it for the community that the openjdk source bundles >>>> include these drop sources? e.g. ones at >>>> http://download.java.net/openjdk/jdk7/ >>>> If they are not included, when the openjdk source bundles are built, >>>> they will need to download the jaxp and jaxws drop bundles at build >>>> time. >>>> >>> >>> I obviously can't speak for everyone, but for IcedTea7 we don't even >>> use the download bundles any more. We grab from the IcedTea forest >>> instead, which allows patches which didn't make a bxx release to be >>> applied there once and used in releases. We did this for the security >>> fixes with Milestone 4/1.11. >>> >>> I've already added downloading of the jaxp, jaxws and jaf bundles to >>> the IcedTea build; it's this process that resulted in this webrev. >>> This has two advantages; we check all the zips/tarballs at the same >>> point in the build (the JAXP and JAXWS builds are then pointed at the >>> directory IcedTea uses for them) and we check the MD5 sums of the >>> downloads or pre-existing zips. I don't know if the latter could be >>> incorporated into the OpenJDK build somehow. At present, there's no >>> guarantee that these zips are valid. >>> >>> The rules look like this: >>> >>> stamps/download-jaxp-drop.stamp: >>> mkdir -p drops >>> if USE_ALT_JAXP_DROP_ZIP >>> ln -sf $(ALT_JAXP_DROP_ZIP) drops/$(JAXP_DROP_ZIP) >>> endif >>> if ! echo "$(JAXP_DROP_MD5SUM) drops/$(JAXP_DROP_ZIP)" \ >>> | $(MD5SUM) --check ; \ >>> then \ >>> if [ -f drops/$(JAXP_DROP_ZIP) ] ; \ >>> then \ >>> mv drops/$(JAXP_DROP_ZIP) drops/$(JAXP_DROP_ZIP).old ; \ >>> fi ; \ >>> $(WGET) $(DROP_URL)/$(JAXP_DROP_ZIP) -O >>> drops/$(JAXP_DROP_ZIP); \ >>> fi ; >>> mkdir -p stamps >>> touch stamps/download-jaxp-drop.stamp >>> >>> ALT_JAXP_DROP_ZIP gets set if the user specifies >>> --with-jaxp-drop-zip= to configure. WGET and MD5SUM are the >>> respective binaries as located by configure and DROP_URL is the >>> kenai.com URL as in the jaxws.properties and jaxp.properties files: >>> >>> DROP_URL = http://kenai.com/projects/jdk7-drops/downloads/download >>> JAXWS_DROP_ZIP = jdk7-jaxws-2009_09_28.zip >>> JAXWS_DROP_MD5SUM = debb949440c5a15ce999cfefbbc56526 >>> JAF_DROP_ZIP = jdk7-jaf-2009_08_28.zip >>> JAF_DROP_MD5SUM = eb8cb7a4a7f14e211fbe2354878a2472 >>> JAXP_DROP_ZIP = jdk7-jaxp-2009_09_28.zip >>> JAXP_DROP_MD5SUM = 8800970d03bab1fff188dcfafc346f5d >> >> Ah... so my checksum logic in the ant script will serve as a >> double check. >> >> Unless you are changing the bundles and rebundling them... >> nobody does that, ... do they??? >> Ah, if they do, they would need to change the property value >> holding the checksum. >> >> -kto >> >>> >>>> -kto >>>> >>>>>>> The webrev for these changes is here: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~andrew/drops/webrev.01/ >>>>>>> >>>>>>> I've committed this to IcedTea already. Does this look ok for build >>>>>>> also? >>>>> >>>>> >>> >>> >>> > Kelly, > > Does all this mean we can somewhat simplify the list of forests on > hg.o.j.n, by removing jdk7/{corba,jaxp,jaxws} and the corresponding > -gate forests? > > -- Jon No. Not yet. In theory, what little logic is left in jaxp and jaxws (corba has not changed), could be folded up into the top repo or the jdk repo, and you could empty out jaxp and jaxws repos entirely. But I had no plans to do so. What this does is leave a small set of ant scripts and a Makefile over it, in these repos. The build logic is about all that is there, and it will get the jaxp or jaxws source bundle drops, and build them. This change will delete the original sources from the repo, to guarantee they are no longer used. The detailed management of those sources is completely under the control of the jaxp and jaxws teams/projects. The selection of which drop bundles the jdk7 project uses is defined in the jaxp/jaxp.properties and jaxws/jaxws.properties files. -kto From Jonathan.Gibbons at Sun.COM Fri Oct 23 09:39:16 2009 From: Jonathan.Gibbons at Sun.COM (Jonathan Gibbons) Date: Fri, 23 Oct 2009 09:39:16 -0700 Subject: 6856630: Restructure jaxp/jaxws repository In-Reply-To: <4AE1D88C.5040408@sun.com> References: <4AB80C37.6000108@sun.com> <17c6771e0910071424n3b12402bg80ed2f56210fb6e3@mail.gmail.com> <17c6771e0910090726r14a12ee4wadb5cc4e9fd141@mail.gmail.com> <4ACF6ECC.7070407@sun.com> <17c6771e0910121014w6fcd23e9rf5d594173e594ec3@mail.gmail.com> <4AD36C3F.2010501@sun.com> <17c6771e0910121318m26e53de3gb3bbea964b70f4eb@mail.gmail.com> <4AE0DB80.90107@sun.com> <4AE0FDAB.1080305@sun.com> <4AE1D88C.5040408@sun.com> Message-ID: <4AE1DC34.30707@sun.com> Kelly O'Hair wrote: > > > Jonathan Gibbons wrote: >> Kelly O'Hair wrote: >>> Andrew, >>> >>> Sorry I'm so slow on this, ... >>> >>> I'm looking at updating the jaxp bundle. The webrev is: >>> >>> http://cr.openjdk.java.net/~ohair/openjdk7/jdk7-tl-jaxp-6861589/webrev/ >>> >>> Updated jaxp source bundle, and complete removal of anything >>> that would use the original source. The final changeset will also >>> delete the jaxp/src directory so we never accidently use it. >>> It also adds a md5 checksum check on the bundle in the ant script, >>> a property value contains the expected checksum. >>> >>> I'm not done, so I could add more if you want me to add the changes >>> mentioned here... The merge should be trivial. >>> >>> One snag is that I plan on pushing this to the TL forest so that >>> the TL integrator (Tim Bell) can get the appropriate tests done >>> on the jaxp changes. In the future jaxp changes will probably >>> be going through the TL area. >>> >>> ... a few more comments below... >>> >>> Andrew John Hughes wrote: >>>> 2009/10/12 Kelly O'Hair : >>>>> I saw the webrev for a while, and now I can't :^(, but I saw >>>>> enough... >>>>> >>>>>>> Andrew John Hughes wrote: >>>>>>>> 2009/10/7 Andrew John Hughes : >>>>> ...[snip]... >>>>>>>> I found a number of issues with the current version: >>>>>>>> >>>>>>>> * The drop zips are expected to be in a share/jdk7-drops >>>>>>>> subdirectory >>>>>>>> of the devtools directory. This doesn't really work outside Sun's >>>>>>>> internal setup. I've added support for ALT_DROP_DIR which can >>>>>>>> be used >>>>>>>> to specify an exact path to the zips. If this is not set, the old >>>>>>>> devtools behaviour is used. >>>>> I'm concerned about the name dropdir (your master copy location) vs. >>>>> drop.dir >>>>> (destination for the exploded contents) in the property names. Seems >>>>> confusing. >>>>> I hesitate to go on a name hunt, but what about >>>>> ALT_DROP_BUNDLE_DIR and >>>>> drop.bundle.dir? >>>>> >>>> >>>> Yes, I noticed drop.dir after posting the webrev and agree it's >>>> confusing. Would just making them ALT_DROPS_DIR and drops.dir not be >>>> sufficient? drop.bundle seems a little verbose and both mean the same >>>> thing to me at least. >>> >>> I'm ok with ALT_DROPS_DIR and drops.dir. >>> >>>> >>>>>>>> * The zips are being downloaded and extracted in the source >>>>>>>> directory, >>>>>>>> which could be read only. I've changed this so they are >>>>>>>> written to >>>>>>>> the build directory like everything else. >>>>> It turns out that we need this drop.dir to be in the source area if >>>>> we want the openjdk source zip bundles, created by RE, to include >>>>> the drop sources. These source bundles are created by bundling up >>>>> everything in the forest, prior to building, so the drop.dir needs >>>>> to be in the forest somehow. Otherwise, the bundling logic has to >>>>> merge two separate source trees, or different roots. >>>>> I was given a requirement that the openjdk source bundles include >>>>> these >>>>> drop sources, easiest answer was drop.dir in the repo. >>>>> Not an unsurmountable problem, I avoided the more complicated path. >>>>> >>>>> I know that becomes an issue if the repository or source is in a >>>>> read-only area, but that's not the only situation in the openjdk I >>>>> suspect. >>>>> I assumed someone building from a read-only area could set >>>>> drop.dir to some other location. >>>>> >>>> >>>> Would it not make more sense for RE to set the drop.dir property into >>>> the source directory, given it's that build that's abnormal (needing >>>> to distribute a post build tree in effect)? >>> >>> I will look into that. You have convinced me. ;^) >>> >>>> >>>>> Not sure what to say. >>>>> >>>>> How important is it for the community that the openjdk source bundles >>>>> include these drop sources? e.g. ones at >>>>> http://download.java.net/openjdk/jdk7/ >>>>> If they are not included, when the openjdk source bundles are built, >>>>> they will need to download the jaxp and jaxws drop bundles at >>>>> build time. >>>>> >>>> >>>> I obviously can't speak for everyone, but for IcedTea7 we don't even >>>> use the download bundles any more. We grab from the IcedTea forest >>>> instead, which allows patches which didn't make a bxx release to be >>>> applied there once and used in releases. We did this for the security >>>> fixes with Milestone 4/1.11. >>>> >>>> I've already added downloading of the jaxp, jaxws and jaf bundles to >>>> the IcedTea build; it's this process that resulted in this webrev. >>>> This has two advantages; we check all the zips/tarballs at the same >>>> point in the build (the JAXP and JAXWS builds are then pointed at the >>>> directory IcedTea uses for them) and we check the MD5 sums of the >>>> downloads or pre-existing zips. I don't know if the latter could be >>>> incorporated into the OpenJDK build somehow. At present, there's no >>>> guarantee that these zips are valid. >>>> >>>> The rules look like this: >>>> >>>> stamps/download-jaxp-drop.stamp: >>>> mkdir -p drops >>>> if USE_ALT_JAXP_DROP_ZIP >>>> ln -sf $(ALT_JAXP_DROP_ZIP) drops/$(JAXP_DROP_ZIP) >>>> endif >>>> if ! echo "$(JAXP_DROP_MD5SUM) drops/$(JAXP_DROP_ZIP)" \ >>>> | $(MD5SUM) --check ; \ >>>> then \ >>>> if [ -f drops/$(JAXP_DROP_ZIP) ] ; \ >>>> then \ >>>> mv drops/$(JAXP_DROP_ZIP) drops/$(JAXP_DROP_ZIP).old ; \ >>>> fi ; \ >>>> $(WGET) $(DROP_URL)/$(JAXP_DROP_ZIP) -O >>>> drops/$(JAXP_DROP_ZIP); \ >>>> fi ; >>>> mkdir -p stamps >>>> touch stamps/download-jaxp-drop.stamp >>>> >>>> ALT_JAXP_DROP_ZIP gets set if the user specifies >>>> --with-jaxp-drop-zip= to configure. WGET and MD5SUM are the >>>> respective binaries as located by configure and DROP_URL is the >>>> kenai.com URL as in the jaxws.properties and jaxp.properties files: >>>> >>>> DROP_URL = http://kenai.com/projects/jdk7-drops/downloads/download >>>> JAXWS_DROP_ZIP = jdk7-jaxws-2009_09_28.zip >>>> JAXWS_DROP_MD5SUM = debb949440c5a15ce999cfefbbc56526 >>>> JAF_DROP_ZIP = jdk7-jaf-2009_08_28.zip >>>> JAF_DROP_MD5SUM = eb8cb7a4a7f14e211fbe2354878a2472 >>>> JAXP_DROP_ZIP = jdk7-jaxp-2009_09_28.zip >>>> JAXP_DROP_MD5SUM = 8800970d03bab1fff188dcfafc346f5d >>> >>> Ah... so my checksum logic in the ant script will serve as a >>> double check. >>> >>> Unless you are changing the bundles and rebundling them... >>> nobody does that, ... do they??? >>> Ah, if they do, they would need to change the property value >>> holding the checksum. >>> >>> -kto >>> >>>> >>>>> -kto >>>>> >>>>>>>> The webrev for these changes is here: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~andrew/drops/webrev.01/ >>>>>>>> >>>>>>>> I've committed this to IcedTea already. Does this look ok for >>>>>>>> build >>>>>>>> also? >>>>>> >>>>>> >>>> >>>> >>>> >> Kelly, >> >> Does all this mean we can somewhat simplify the list of forests on >> hg.o.j.n, by removing jdk7/{corba,jaxp,jaxws} and the corresponding >> -gate forests? >> >> -- Jon > > No. Not yet. In theory, what little logic is left in jaxp and jaxws > (corba has not changed), could be folded up into the top repo > or the jdk repo, and you could empty out jaxp and jaxws repos > entirely. But I had no plans to do so. > > What this does is leave a small set of ant scripts and a > Makefile over it, in these repos. The build logic is about all > that is there, and it will get the jaxp or jaxws source bundle drops, > and build them. This change will delete the original sources from > the repo, to guarantee they are no longer used. > The detailed management of those sources is completely under > the control of the jaxp and jaxws teams/projects. > > The selection of which drop bundles the jdk7 project uses is defined in > the jaxp/jaxp.properties and jaxws/jaxws.properties files. > > -kto Kelly, I was not referring to the jaxp/jaxws/corba repositories in each forest. It seemed like we had (mostly unused) forests for integrating jaxp,jaxws,corba stuff. Specifically: *jdk7/jaxp* jaxp build-dev at openjdk.java.net 20 months ago RSS | zip | gz | bz2 *jdk7/jaxp-gate* jaxp (gate) build-dev at openjdk.java.net 20 months ago RSS | zip | gz | bz2 *jdk7/jaxp-gate/corba* jaxp (gate) build-dev at openjdk.java.net 20 months ago RSS | zip | gz | bz2 *jdk7/jaxp-gate/hotspot* jaxp (gate) build-dev at openjdk.java.net 20 months ago RSS | zip | gz | bz2 *jdk7/jaxp-gate/jaxp* jaxp (gate) build-dev at openjdk.java.net 20 months ago RSS | zip | gz | bz2 *jdk7/jaxp-gate/jaxws* jaxp (gate) build-dev at openjdk.java.net 20 months ago RSS | zip | gz | bz2 *jdk7/jaxp-gate/jdk* jaxp (gate) build-dev at openjdk.java.net 20 months ago RSS | zip | gz | bz2 *jdk7/jaxp-gate/langtools* jaxp (gate) build-dev at openjdk.java.net 20 months ago RSS | zip | gz | bz2 *jdk7/jaxp/corba* jaxp build-dev at openjdk.java.net 20 months ago RSS | zip | gz | bz2 *jdk7/jaxp/hotspot* jaxp build-dev at openjdk.java.net 20 months ago RSS | zip | gz | bz2 *jdk7/jaxp/jaxp* jaxp build-dev at openjdk.java.net 20 months ago RSS | zip | gz | bz2 *jdk7/jaxp/jaxws* jaxp build-dev at openjdk.java.net 20 months ago RSS | zip | gz | bz2 *jdk7/jaxp/jdk* jaxp build-dev at openjdk.java.net 20 months ago RSS | zip | gz | bz2 *jdk7/jaxp/langtools* jaxp build-dev at openjdk.java.net 20 months ago RSS | zip | gz | bz2 *jdk7/jaxws* jaxws build-dev at openjdk.java.net 20 months ago RSS | zip | gz | bz2 *jdk7/jaxws-gate* jaxws (gate) build-dev at openjdk.java.net 20 months ago RSS | zip | gz | bz2 *jdk7/jaxws-gate/corba* jaxws (gate) build-dev at openjdk.java.net 20 months ago RSS | zip | gz | bz2 *jdk7/jaxws-gate/hotspot* jaxws (gate) build-dev at openjdk.java.net 20 months ago RSS | zip | gz | bz2 *jdk7/jaxws-gate/jaxp* jaxws (gate) build-dev at openjdk.java.net 20 months ago RSS | zip | gz | bz2 *jdk7/jaxws-gate/jaxws* jaxws (gate) build-dev at openjdk.java.net 20 months ago RSS | zip | gz | bz2 *jdk7/jaxws-gate/jdk* jaxws (gate) build-dev at openjdk.java.net 20 months ago RSS | zip | gz | bz2 *jdk7/jaxws-gate/langtools* jaxws (gate) build-dev at openjdk.java.net 20 months ago RSS | zip | gz | bz2 *jdk7/jaxws/corba* jaxws build-dev at openjdk.java.net 20 months ago RSS | zip | gz | bz2 *jdk7/jaxws/hotspot* jaxws build-dev at openjdk.java.net 20 months ago RSS | zip | gz | bz2 *jdk7/jaxws/jaxp* jaxws build-dev at openjdk.java.net 20 months ago RSS | zip | gz | bz2 *jdk7/jaxws/jaxws* jaxws build-dev at openjdk.java.net 20 months ago RSS | zip | gz | bz2 *jdk7/jaxws/jdk* jaxws build-dev at openjdk.java.net 20 months ago RSS | zip | gz | bz2 *jdk7/jaxws/langtools* jaxws build-dev at openjdk.java.net 20 months ago RSS | zip | gz | bz2 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/build-dev/attachments/20091023/6d9d9590/attachment-0001.html From Kelly.Ohair at Sun.COM Fri Oct 23 09:39:52 2009 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Fri, 23 Oct 2009 09:39:52 -0700 Subject: 6856630: Restructure jaxp/jaxws repository In-Reply-To: <17c6771e0910230516p3de79681p436f28b7c51be2f8@mail.gmail.com> References: <4AB80C37.6000108@sun.com> <17c6771e0910071424n3b12402bg80ed2f56210fb6e3@mail.gmail.com> <17c6771e0910090726r14a12ee4wadb5cc4e9fd141@mail.gmail.com> <4ACF6ECC.7070407@sun.com> <17c6771e0910121014w6fcd23e9rf5d594173e594ec3@mail.gmail.com> <4AD36C3F.2010501@sun.com> <17c6771e0910121318m26e53de3gb3bbea964b70f4eb@mail.gmail.com> <4AE0DB80.90107@sun.com> <4AE0FC05.8080802@sun.com> <17c6771e0910230516p3de79681p436f28b7c51be2f8@mail.gmail.com> Message-ID: <4AE1DC58.5090506@sun.com> Andrew John Hughes wrote: > 2009/10/23 Kelly O'Hair : >> Sigh... if I'm changing jaxp, might as well change jaxws too.... >> keep them in sync. >> >> I effectively included the drop.dir change you wanted with these >> webrevs: >> >> http://cr.openjdk.java.net/~ohair/openjdk7/jdk7-tl-jaxp/webrev/ >> http://cr.openjdk.java.net/~ohair/openjdk7/jdk7-tl-jaxws/webrev/ >> >> In both cases, any use of the original source is being removed, and >> the changeset I create will probably just delete the "src/" directory. >> > > Good, makes things clearer. > >> I'm using a different directory name when the dropped sources are >> baked in by our RE people, "drop_included" (should have called these >> batteries so I could use "batteries_included". ;^) >> > > Ok, I think it makes the build.xml more complicated than necessary, > given you could just set drop.dir for builds which include the source, > but I'm happy enough with it. There are problems with building from the source bundles that included the drop sources. I need to protect the drop_included sources from being deleted with an 'ant clobber' or 'make clobber'. Putting them in separately named directory was obvious, but what wasn't obvious was how to make that a permanent and protected source area when building with a source bundle. Baking in the idea of a drop_included directory was the only way to protect drop_included from being deleted accidently, and also make it the higher priority source location, when it exists, the drop bundles and drop area should not be needed. > >> So there are two properties drop.expanded.dir and drop.included.dir, >> and the drop.dir property is conditional set in the ant script. >> >> But I did not add the ALT_DROPS_DIR change. >> Do you want me to include that, or do you want to make that change >> separately? >> > > There's already three changes in this one changeset: > > * Removing the original source option > * Adding drop.expanded (which seems similar to the original source > option except you can specify the directory) > * Checksumming > > so I'd rather we had the ALT_DROPS_DIR in a separate one, but I don't > mind who commits it. OK. I'll hold off on the ALT_DROPS_DIR. > > I also notice the URL changes -- why? The jaxp source bundle is being updated. The kenai.com urls were mine, and somewhat temporary. The jaxp/jaxws teams get to pick where these bundles will live. With java.net, I think adding a new file creates a new url. :^( So I suspect, every bundle update may create a new url, but I just use what they give me. I'll try and separate these changes into different changesets, but will need to file separate bugs. -kto > >> -kto >> > > Thanks, From Kelly.Ohair at Sun.COM Fri Oct 23 09:52:00 2009 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Fri, 23 Oct 2009 09:52:00 -0700 Subject: 6856630: Restructure jaxp/jaxws repository In-Reply-To: <4AE1DC34.30707@sun.com> References: <4AB80C37.6000108@sun.com> <17c6771e0910071424n3b12402bg80ed2f56210fb6e3@mail.gmail.com> <17c6771e0910090726r14a12ee4wadb5cc4e9fd141@mail.gmail.com> <4ACF6ECC.7070407@sun.com> <17c6771e0910121014w6fcd23e9rf5d594173e594ec3@mail.gmail.com> <4AD36C3F.2010501@sun.com> <17c6771e0910121318m26e53de3gb3bbea964b70f4eb@mail.gmail.com> <4AE0DB80.90107@sun.com> <4AE0FDAB.1080305@sun.com> <4AE1D88C.5040408@sun.com> <4AE1DC34.30707@sun.com> Message-ID: <4AE1DF30.2030207@sun.com> Jonathan Gibbons wrote: > Kelly O'Hair wrote: >> >> >> Jonathan Gibbons wrote: >>> Kelly O'Hair wrote: >>>> Andrew, >>>> >>>> Sorry I'm so slow on this, ... >>>> >>>> I'm looking at updating the jaxp bundle. The webrev is: >>>> >>>> http://cr.openjdk.java.net/~ohair/openjdk7/jdk7-tl-jaxp-6861589/webrev/ >>>> >>>> Updated jaxp source bundle, and complete removal of anything >>>> that would use the original source. The final changeset will also >>>> delete the jaxp/src directory so we never accidently use it. >>>> It also adds a md5 checksum check on the bundle in the ant script, >>>> a property value contains the expected checksum. >>>> >>>> I'm not done, so I could add more if you want me to add the changes >>>> mentioned here... The merge should be trivial. >>>> >>>> One snag is that I plan on pushing this to the TL forest so that >>>> the TL integrator (Tim Bell) can get the appropriate tests done >>>> on the jaxp changes. In the future jaxp changes will probably >>>> be going through the TL area. >>>> >>>> ... a few more comments below... >>>> >>>> Andrew John Hughes wrote: >>>>> 2009/10/12 Kelly O'Hair : >>>>>> I saw the webrev for a while, and now I can't :^(, but I saw >>>>>> enough... >>>>>> >>>>>>>> Andrew John Hughes wrote: >>>>>>>>> 2009/10/7 Andrew John Hughes : >>>>>> ...[snip]... >>>>>>>>> I found a number of issues with the current version: >>>>>>>>> >>>>>>>>> * The drop zips are expected to be in a share/jdk7-drops >>>>>>>>> subdirectory >>>>>>>>> of the devtools directory. This doesn't really work outside Sun's >>>>>>>>> internal setup. I've added support for ALT_DROP_DIR which can >>>>>>>>> be used >>>>>>>>> to specify an exact path to the zips. If this is not set, the old >>>>>>>>> devtools behaviour is used. >>>>>> I'm concerned about the name dropdir (your master copy location) vs. >>>>>> drop.dir >>>>>> (destination for the exploded contents) in the property names. Seems >>>>>> confusing. >>>>>> I hesitate to go on a name hunt, but what about >>>>>> ALT_DROP_BUNDLE_DIR and >>>>>> drop.bundle.dir? >>>>>> >>>>> >>>>> Yes, I noticed drop.dir after posting the webrev and agree it's >>>>> confusing. Would just making them ALT_DROPS_DIR and drops.dir not be >>>>> sufficient? drop.bundle seems a little verbose and both mean the same >>>>> thing to me at least. >>>> >>>> I'm ok with ALT_DROPS_DIR and drops.dir. >>>> >>>>> >>>>>>>>> * The zips are being downloaded and extracted in the source >>>>>>>>> directory, >>>>>>>>> which could be read only. I've changed this so they are >>>>>>>>> written to >>>>>>>>> the build directory like everything else. >>>>>> It turns out that we need this drop.dir to be in the source area if >>>>>> we want the openjdk source zip bundles, created by RE, to include >>>>>> the drop sources. These source bundles are created by bundling up >>>>>> everything in the forest, prior to building, so the drop.dir needs >>>>>> to be in the forest somehow. Otherwise, the bundling logic has to >>>>>> merge two separate source trees, or different roots. >>>>>> I was given a requirement that the openjdk source bundles include >>>>>> these >>>>>> drop sources, easiest answer was drop.dir in the repo. >>>>>> Not an unsurmountable problem, I avoided the more complicated path. >>>>>> >>>>>> I know that becomes an issue if the repository or source is in a >>>>>> read-only area, but that's not the only situation in the openjdk I >>>>>> suspect. >>>>>> I assumed someone building from a read-only area could set >>>>>> drop.dir to some other location. >>>>>> >>>>> >>>>> Would it not make more sense for RE to set the drop.dir property into >>>>> the source directory, given it's that build that's abnormal (needing >>>>> to distribute a post build tree in effect)? >>>> >>>> I will look into that. You have convinced me. ;^) >>>> >>>>> >>>>>> Not sure what to say. >>>>>> >>>>>> How important is it for the community that the openjdk source bundles >>>>>> include these drop sources? e.g. ones at >>>>>> http://download.java.net/openjdk/jdk7/ >>>>>> If they are not included, when the openjdk source bundles are built, >>>>>> they will need to download the jaxp and jaxws drop bundles at >>>>>> build time. >>>>>> >>>>> >>>>> I obviously can't speak for everyone, but for IcedTea7 we don't even >>>>> use the download bundles any more. We grab from the IcedTea forest >>>>> instead, which allows patches which didn't make a bxx release to be >>>>> applied there once and used in releases. We did this for the security >>>>> fixes with Milestone 4/1.11. >>>>> >>>>> I've already added downloading of the jaxp, jaxws and jaf bundles to >>>>> the IcedTea build; it's this process that resulted in this webrev. >>>>> This has two advantages; we check all the zips/tarballs at the same >>>>> point in the build (the JAXP and JAXWS builds are then pointed at the >>>>> directory IcedTea uses for them) and we check the MD5 sums of the >>>>> downloads or pre-existing zips. I don't know if the latter could be >>>>> incorporated into the OpenJDK build somehow. At present, there's no >>>>> guarantee that these zips are valid. >>>>> >>>>> The rules look like this: >>>>> >>>>> stamps/download-jaxp-drop.stamp: >>>>> mkdir -p drops >>>>> if USE_ALT_JAXP_DROP_ZIP >>>>> ln -sf $(ALT_JAXP_DROP_ZIP) drops/$(JAXP_DROP_ZIP) >>>>> endif >>>>> if ! echo "$(JAXP_DROP_MD5SUM) drops/$(JAXP_DROP_ZIP)" \ >>>>> | $(MD5SUM) --check ; \ >>>>> then \ >>>>> if [ -f drops/$(JAXP_DROP_ZIP) ] ; \ >>>>> then \ >>>>> mv drops/$(JAXP_DROP_ZIP) drops/$(JAXP_DROP_ZIP).old ; \ >>>>> fi ; \ >>>>> $(WGET) $(DROP_URL)/$(JAXP_DROP_ZIP) -O >>>>> drops/$(JAXP_DROP_ZIP); \ >>>>> fi ; >>>>> mkdir -p stamps >>>>> touch stamps/download-jaxp-drop.stamp >>>>> >>>>> ALT_JAXP_DROP_ZIP gets set if the user specifies >>>>> --with-jaxp-drop-zip= to configure. WGET and MD5SUM are the >>>>> respective binaries as located by configure and DROP_URL is the >>>>> kenai.com URL as in the jaxws.properties and jaxp.properties files: >>>>> >>>>> DROP_URL = http://kenai.com/projects/jdk7-drops/downloads/download >>>>> JAXWS_DROP_ZIP = jdk7-jaxws-2009_09_28.zip >>>>> JAXWS_DROP_MD5SUM = debb949440c5a15ce999cfefbbc56526 >>>>> JAF_DROP_ZIP = jdk7-jaf-2009_08_28.zip >>>>> JAF_DROP_MD5SUM = eb8cb7a4a7f14e211fbe2354878a2472 >>>>> JAXP_DROP_ZIP = jdk7-jaxp-2009_09_28.zip >>>>> JAXP_DROP_MD5SUM = 8800970d03bab1fff188dcfafc346f5d >>>> >>>> Ah... so my checksum logic in the ant script will serve as a >>>> double check. >>>> >>>> Unless you are changing the bundles and rebundling them... >>>> nobody does that, ... do they??? >>>> Ah, if they do, they would need to change the property value >>>> holding the checksum. >>>> >>>> -kto >>>> >>>>> >>>>>> -kto >>>>>> >>>>>>>>> The webrev for these changes is here: >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~andrew/drops/webrev.01/ >>>>>>>>> >>>>>>>>> I've committed this to IcedTea already. Does this look ok for >>>>>>>>> build >>>>>>>>> also? >>>>>>> >>>>>>> >>>>> >>>>> >>>>> >>> Kelly, >>> >>> Does all this mean we can somewhat simplify the list of forests on >>> hg.o.j.n, by removing jdk7/{corba,jaxp,jaxws} and the corresponding >>> -gate forests? >>> >>> -- Jon >> >> No. Not yet. In theory, what little logic is left in jaxp and jaxws >> (corba has not changed), could be folded up into the top repo >> or the jdk repo, and you could empty out jaxp and jaxws repos >> entirely. But I had no plans to do so. >> >> What this does is leave a small set of ant scripts and a >> Makefile over it, in these repos. The build logic is about all >> that is there, and it will get the jaxp or jaxws source bundle drops, >> and build them. This change will delete the original sources from >> the repo, to guarantee they are no longer used. >> The detailed management of those sources is completely under >> the control of the jaxp and jaxws teams/projects. >> >> The selection of which drop bundles the jdk7 project uses is defined in >> the jaxp/jaxp.properties and jaxws/jaxws.properties files. >> >> -kto > Kelly, > > I was not referring to the jaxp/jaxws/corba repositories in each > forest. It seemed like we had (mostly unused) forests for integrating > jaxp,jaxws,corba stuff. Specifically: > > > *jdk7/jaxp* jaxp > build-dev at openjdk.java.net 20 months ago RSS > | zip > | gz > | bz2 > > *jdk7/jaxp-gate* jaxp > (gate) build-dev at openjdk.java.net 20 months ago RSS > | zip > | gz > | bz2 > > *jdk7/jaxp-gate/corba* > jaxp (gate) > build-dev at openjdk.java.net 20 months ago RSS > | zip > | gz > | > bz2 > *jdk7/jaxp-gate/hotspot* > jaxp (gate) > build-dev at openjdk.java.net 20 months ago RSS > | zip > | gz > | > bz2 > *jdk7/jaxp-gate/jaxp* > jaxp (gate) > build-dev at openjdk.java.net 20 months ago RSS > | zip > | gz > | > bz2 > *jdk7/jaxp-gate/jaxws* > jaxp (gate) > build-dev at openjdk.java.net 20 months ago RSS > | zip > | gz > | > bz2 > *jdk7/jaxp-gate/jdk* > jaxp (gate) build-dev at openjdk.java.net 20 months ago RSS > | zip > | gz > | bz2 > > *jdk7/jaxp-gate/langtools* > jaxp (gate) > build-dev at openjdk.java.net 20 months ago RSS > | zip > | > gz > > | bz2 > > *jdk7/jaxp/corba* jaxp > build-dev at openjdk.java.net 20 months ago RSS > | zip > | gz > | bz2 > > *jdk7/jaxp/hotspot* > jaxp build-dev at openjdk.java.net 20 months ago RSS > | zip > | gz > | bz2 > > *jdk7/jaxp/jaxp* jaxp > build-dev at openjdk.java.net 20 months ago RSS > | zip > | gz > | bz2 > > *jdk7/jaxp/jaxws* jaxp > build-dev at openjdk.java.net 20 months ago RSS > | zip > | gz > | bz2 > > *jdk7/jaxp/jdk* jaxp > build-dev at openjdk.java.net 20 months ago RSS > | zip > | gz > | bz2 > > *jdk7/jaxp/langtools* > jaxp > build-dev at openjdk.java.net 20 months ago RSS > | zip > | gz > | > bz2 > *jdk7/jaxws* jaxws > build-dev at openjdk.java.net 20 months ago RSS > | zip > | gz > | bz2 > > *jdk7/jaxws-gate* jaxws > (gate) build-dev at openjdk.java.net 20 months ago RSS > | zip > | gz > | bz2 > > *jdk7/jaxws-gate/corba* > jaxws (gate) > build-dev at openjdk.java.net 20 months ago RSS > | zip > | gz > | > bz2 > *jdk7/jaxws-gate/hotspot* > jaxws (gate) > build-dev at openjdk.java.net 20 months ago RSS > | zip > | > gz > > | bz2 > > *jdk7/jaxws-gate/jaxp* > jaxws (gate) > build-dev at openjdk.java.net 20 months ago RSS > | zip > | gz > | > bz2 > *jdk7/jaxws-gate/jaxws* > jaxws (gate) > build-dev at openjdk.java.net 20 months ago RSS > | zip > | gz > | > bz2 > *jdk7/jaxws-gate/jdk* > jaxws (gate) > build-dev at openjdk.java.net 20 months ago RSS > | zip > | gz > | > bz2 > *jdk7/jaxws-gate/langtools* > jaxws (gate) > build-dev at openjdk.java.net 20 months ago RSS > | zip > | > gz > > | bz2 > > *jdk7/jaxws/corba* > jaxws build-dev at openjdk.java.net 20 months ago RSS > | zip > | gz > | bz2 > > *jdk7/jaxws/hotspot* > jaxws build-dev at openjdk.java.net 20 months ago RSS > | zip > | gz > | bz2 > > *jdk7/jaxws/jaxp* jaxws > build-dev at openjdk.java.net 20 months ago RSS > | zip > | gz > | bz2 > > *jdk7/jaxws/jaxws* > jaxws build-dev at openjdk.java.net 20 months ago RSS > | zip > | gz > | bz2 > > *jdk7/jaxws/jdk* jaxws > build-dev at openjdk.java.net 20 months ago RSS > | zip > | gz > | bz2 > > *jdk7/jaxws/langtools* > jaxws > build-dev at openjdk.java.net 20 months ago RSS > | zip > | gz > | > bz2 > > > DOH! Sorry... Yes, these jaxp and jaxws forests can probably go away, we won't be using them. The current plan is that jaxp/jaxws changes (new bundles) will go through the TL forest. -kto From Kelly.Ohair at Sun.COM Mon Oct 26 11:23:53 2009 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Mon, 26 Oct 2009 11:23:53 -0700 Subject: [Fwd: Boot cycle builds] Message-ID: <4AE5E939.6010804@sun.com> FYI... -------- Original Message -------- Subject: Boot cycle builds Date: Mon, 26 Oct 2009 11:21:22 -0700 From: Kelly O'Hair To: jdk7-gk at openjdk.java.net Heads up... As soon as we can do a jdk7 boot cycle build again, I plan on changing the default build to include a boot cycle build (where the jdk7 image is built, then used as the boot jdk to build it again). I consider it critical that boot cycle builds work, and I see no other course than requiring it as part of a default jdk7 build. It can be turned off with SKIP_BOOT_CYCLE=true, but I hope the integrators and everyone will be careful when it is turned off. Depending on your build situation, this could add 20-30 minutes (maybe more) to your jdk7 build, which is painful I know, but so is finding out that the jdk you just built doesn't work. Comments are welcome. -kto From gnu_andrew at member.fsf.org Mon Oct 26 13:05:03 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Mon, 26 Oct 2009 20:05:03 +0000 Subject: [Fwd: Boot cycle builds] In-Reply-To: <4AE5E939.6010804@sun.com> References: <4AE5E939.6010804@sun.com> Message-ID: <17c6771e0910261305y7964ca4fu8317b74d6651dafd@mail.gmail.com> 2009/10/26 Kelly O'Hair : > > FYI... > > -------- Original Message -------- > Subject: Boot cycle builds > Date: Mon, 26 Oct 2009 11:21:22 -0700 > From: Kelly O'Hair > To: jdk7-gk at openjdk.java.net > > > Heads up... > > As soon as we can do a jdk7 boot cycle build again, I plan on changing > the default build to include a boot cycle build > (where the jdk7 image is built, then used as the boot jdk to build > it again). > > I consider it critical that boot cycle builds work, and I see > no other course than requiring it as part of a default jdk7 build. > > It can be turned off with SKIP_BOOT_CYCLE=true, but I hope the > integrators and everyone will be careful when it is turned off. > > Depending on your build situation, this could add 20-30 minutes > (maybe more) to your jdk7 build, which is painful I know, but > so is finding out that the jdk you just built doesn't work. > > Comments are welcome. > > -kto > > IcedTea does just this for a full bootstrap (the default) and it would be good to see the Sun developers applying the same level of testing to their builds. I would ask that we wait until the end of the current milestone (this week I believe) before adding this though. -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From gnu_andrew at member.fsf.org Mon Oct 26 13:16:39 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Mon, 26 Oct 2009 20:16:39 +0000 Subject: Fix for 6888888 breaks the build In-Reply-To: <4AD8EE6F.3030900@sun.com> References: <17c6771e0910150613w40d870d1ne20047231788a6d2@mail.gmail.com> <4AD732D1.1060409@sun.com> <17c6771e0910150805i6d6b1318h4333e89cd2037bde@mail.gmail.com> <4AD74680.3030000@sun.com> <4AD74B6D.60709@sun.com> <4AD8EE6F.3030900@sun.com> Message-ID: <17c6771e0910261316o600ab388tb272b2629ce98409@mail.gmail.com> 2009/10/16 Kelly O'Hair : > > Tim Bell wrote: >>> >>> Andrew John Hughes wrote: >> >> (snip!) >>>> >>>> I think there's still an issue here that makes this patch worth >>>> pushing. ? The 6888888 fix didn't cause the bug, but merely made it >>>> visible to a lot more people. ?So 6889255 will only hide it again. >>>> The build uses JAVA_TOOLS_DIR for javac, javah and javadoc: >>>> >>>> ?# If no explicit tools, use boot tools (add VM flags in this case) >>>> ?JAVAC_CMD ? ? = $(JAVA_TOOLS_DIR)/javac $(JAVAC_JVM_FLAGS) \ >>>> ? ? ? ? ? ? ? ? ?$(JAVACFLAGS) >>>> ?JAVAH_CMD ? ? = $(JAVA_TOOLS_DIR)/javah \ >>>> ? ? ? ? ? ? ? ? ?$(JAVAHFLAGS) >>>> ?JAVADOC_CMD ? = $(JAVA_TOOLS_DIR)/javadoc $(JAVA_TOOLS_FLAGS:%=-J%) >>>> >>>> >>>> but only when LANGTOOLS_DIST is not defined. ?Normally, langtools is >>>> built first so LANGTOOLS_DIST is defined. ?What your fix for 6888888 >>>> did was cause the setting for JAVAH to get used in all cases and, as >>>> JAVA_TOOLS_DIR defaults to ALT_JDK_IMPORT_PATH rather than BOOTDIR >>>> this fails in many cases as the user sets ALT_BOOTDIR not >>>> ALT_JDK_IMPORT_PATH. >>>> >>>> In jdk_generic_profile, it seems ALT_JDK_IMPORT_PATH is set to >>>> ${jdk_instances}/${importjdk} if it exists. ?On Solaris, >>>> ${jdk_instances} is set to /usr/jdk/instances which probably explains >>>> why Sun engineers building on Solaris may not see this bug either. >>>> ${jdk_instances} is set to /opt/java on GNU/Linux, whereas distros >>>> tend to have standardised on /usr/lib/jvm. ?It's simply "C:" on >>>> Windows. ?As mentioned on IRC, release engineering are setting >>>> ALT_JDK_IMPORT_PATH explicitly so also would never see this bug. >>>> >>>> As we presumably want the tools from the bootstrap JDK, and not from >>>> 'the import JDK to be used to get hotspot VM if not built', I suggest >>>> we switch to BOOTDIR by default by applying this patch. >>>> >> >> Jonathan Gibbons wrote: >> >>> This probably explains problems I've reported informally to Kelly a >>> while back, but never got around to formally investigating. ? ? FWIW, >>> this fix does not interfere with the fix for 6889255 coming up, and this >>> fix seems like a good idea to me. >> >> OK - I filed a new bug report: >> ?6892021 "Build tools from ALT_JDK_IMPORT_PATH versus BOOTDIR" >> with a pointer to this email thread. >> >> Kelly - do you have an opinion on this? > > The goal was that a full jdk build would never need a ALT_JDK_IMPORT_PATH > at all. And all class files would have been created by the LANGTOOLS_DIST > compiler (hotspot was a special case, using the ALT_BOOTDIR to compile). > But no class files would ever be created by the javac in ALT_BOOTDIR. > > ALT_JDK_IMPORT_PATH was supposed to only come into play when someone > was doing what I called a 'partial build', and it provided the missing > pieces, including a jdk7 flavored javac compiler. > > The other tools were less well defined in their use. > The jar tool in ALT_BOOTDIR is always used to build jars as I recall. > > The javah and javadoc story I'm not so sure about. I thought they would > have followed the same rules as javac. > > Not sure my ramblings are helping here.... ?:^( > > -kto > >> >> Thanks- >> >> Tim > Did we come to a decision on this? I was reminded of it today because none of the forests will build for me (except IcedTea which I've patched) due to this bug. If we don't want to change from using ALT_JDK_IMPORT_PATH, we could at least make it default to the BOOTDIR rather than a deliberately broken path. Though I still fail to see the need to point to two different JDKs simultaneously... -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From gnu_andrew at member.fsf.org Mon Oct 26 13:45:50 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Mon, 26 Oct 2009 20:45:50 +0000 Subject: Fix for 6888888 breaks the build In-Reply-To: <17c6771e0910261316o600ab388tb272b2629ce98409@mail.gmail.com> References: <17c6771e0910150613w40d870d1ne20047231788a6d2@mail.gmail.com> <4AD732D1.1060409@sun.com> <17c6771e0910150805i6d6b1318h4333e89cd2037bde@mail.gmail.com> <4AD74680.3030000@sun.com> <4AD74B6D.60709@sun.com> <4AD8EE6F.3030900@sun.com> <17c6771e0910261316o600ab388tb272b2629ce98409@mail.gmail.com> Message-ID: <17c6771e0910261345r531fd54eg1cafa401e71116fa@mail.gmail.com> 2009/10/26 Andrew John Hughes : > 2009/10/16 Kelly O'Hair : >> >> Tim Bell wrote: >>>> >>>> Andrew John Hughes wrote: >>> >>> (snip!) >>>>> >>>>> I think there's still an issue here that makes this patch worth >>>>> pushing. ? The 6888888 fix didn't cause the bug, but merely made it >>>>> visible to a lot more people. ?So 6889255 will only hide it again. >>>>> The build uses JAVA_TOOLS_DIR for javac, javah and javadoc: >>>>> >>>>> ?# If no explicit tools, use boot tools (add VM flags in this case) >>>>> ?JAVAC_CMD ? ? = $(JAVA_TOOLS_DIR)/javac $(JAVAC_JVM_FLAGS) \ >>>>> ? ? ? ? ? ? ? ? ?$(JAVACFLAGS) >>>>> ?JAVAH_CMD ? ? = $(JAVA_TOOLS_DIR)/javah \ >>>>> ? ? ? ? ? ? ? ? ?$(JAVAHFLAGS) >>>>> ?JAVADOC_CMD ? = $(JAVA_TOOLS_DIR)/javadoc $(JAVA_TOOLS_FLAGS:%=-J%) >>>>> >>>>> >>>>> but only when LANGTOOLS_DIST is not defined. ?Normally, langtools is >>>>> built first so LANGTOOLS_DIST is defined. ?What your fix for 6888888 >>>>> did was cause the setting for JAVAH to get used in all cases and, as >>>>> JAVA_TOOLS_DIR defaults to ALT_JDK_IMPORT_PATH rather than BOOTDIR >>>>> this fails in many cases as the user sets ALT_BOOTDIR not >>>>> ALT_JDK_IMPORT_PATH. >>>>> >>>>> In jdk_generic_profile, it seems ALT_JDK_IMPORT_PATH is set to >>>>> ${jdk_instances}/${importjdk} if it exists. ?On Solaris, >>>>> ${jdk_instances} is set to /usr/jdk/instances which probably explains >>>>> why Sun engineers building on Solaris may not see this bug either. >>>>> ${jdk_instances} is set to /opt/java on GNU/Linux, whereas distros >>>>> tend to have standardised on /usr/lib/jvm. ?It's simply "C:" on >>>>> Windows. ?As mentioned on IRC, release engineering are setting >>>>> ALT_JDK_IMPORT_PATH explicitly so also would never see this bug. >>>>> >>>>> As we presumably want the tools from the bootstrap JDK, and not from >>>>> 'the import JDK to be used to get hotspot VM if not built', I suggest >>>>> we switch to BOOTDIR by default by applying this patch. >>>>> >>> >>> Jonathan Gibbons wrote: >>> >>>> This probably explains problems I've reported informally to Kelly a >>>> while back, but never got around to formally investigating. ? ? FWIW, >>>> this fix does not interfere with the fix for 6889255 coming up, and this >>>> fix seems like a good idea to me. >>> >>> OK - I filed a new bug report: >>> ?6892021 "Build tools from ALT_JDK_IMPORT_PATH versus BOOTDIR" >>> with a pointer to this email thread. >>> >>> Kelly - do you have an opinion on this? >> >> The goal was that a full jdk build would never need a ALT_JDK_IMPORT_PATH >> at all. And all class files would have been created by the LANGTOOLS_DIST >> compiler (hotspot was a special case, using the ALT_BOOTDIR to compile). >> But no class files would ever be created by the javac in ALT_BOOTDIR. >> >> ALT_JDK_IMPORT_PATH was supposed to only come into play when someone >> was doing what I called a 'partial build', and it provided the missing >> pieces, including a jdk7 flavored javac compiler. >> >> The other tools were less well defined in their use. >> The jar tool in ALT_BOOTDIR is always used to build jars as I recall. >> >> The javah and javadoc story I'm not so sure about. I thought they would >> have followed the same rules as javac. >> >> Not sure my ramblings are helping here.... ?:^( >> >> -kto >> >>> >>> Thanks- >>> >>> Tim >> > > Did we come to a decision on this? I was reminded of it today because > none of the forests will build for me (except IcedTea which I've > patched) due to this bug. > > If we don't want to change from using ALT_JDK_IMPORT_PATH, we could at > least make it default to the BOOTDIR rather than a deliberately broken > path. ?Though I still fail to see the need to point to two different > JDKs simultaneously... > -- > Andrew :-) > > Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > Support Free Java! > Contribute to GNU Classpath and the OpenJDK > http://www.gnu.org/software/classpath > http://openjdk.java.net > > PGP Key: 94EFD9D8 (http://subkeys.pgp.net) > Fingerprint: F8EF F1EA 401E 2E60 15FA ?7927 142C 2591 94EF D9D8 > I take it this is the error: # Running javah: /mnt/builder/icedtea7/bootstrap/jdk1.6.0/bin/javah -bootclasspath /mnt/builder/icedtea7/openjdk/build/linux-amd64/classes -d /mnt/builder/icedtea7/openjdk/build/linux-amd64/tmp/sun/sun.security.pkcs11/j2pkcs11/CClassHeaders/ \ sun.security.pkcs11.wrapper.PKCS11 sun.security.pkcs11.Secmod An exception has occurred in the compiler (1.7.0_0). Please file a bug at the Java Developer Connection (http://java.sun.com/webapps/bugreport) after checking the Bug Parade for duplicates. Include your program and the following diagnostic in your report. Thank you. java.lang.NullPointerException at com.sun.tools.javac.code.Symbol$MethodSymbol.params(Symbol.java:1226) at com.sun.tools.javac.code.Symbol$MethodSymbol.getParameters(Symbol.java:1252) at com.sun.tools.javac.code.Symbol$MethodSymbol.getParameters(Symbol.java:1) at javax.lang.model.util.ElementScanner6.visitExecutable(ElementScanner6.java:191) at com.sun.tools.javac.code.Symbol$MethodSymbol.accept(Symbol.java:1260) at javax.lang.model.util.ElementScanner6.scan(ElementScanner6.java:139) at com.sun.tools.javac.processing.JavacProcessingEnvironment$ComputeAnnotationSet.scan(JavacProcessingEnvironment.java:767) at com.sun.tools.javac.processing.JavacProcessingEnvironment$ComputeAnnotationSet.scan(JavacProcessingEnvironment.java:1) at javax.lang.model.util.ElementScanner6.scan(ElementScanner6.java:129) at javax.lang.model.util.ElementScanner6.visitType(ElementScanner6.java:169) at com.sun.tools.javac.code.Symbol$ClassSymbol.accept(Symbol.java:874) at javax.lang.model.util.ElementScanner6.scan(ElementScanner6.java:139) at com.sun.tools.javac.processing.JavacProcessingEnvironment$ComputeAnnotationSet.scan(JavacProcessingEnvironment.java:767) at com.sun.tools.javac.processing.JavacProcessingEnvironment$ComputeAnnotationSet.scan(JavacProcessingEnvironment.java:1) at javax.lang.model.util.ElementScanner6.scan(ElementScanner6.java:129) at javax.lang.model.util.ElementScanner6.visitType(ElementScanner6.java:169) at com.sun.tools.javac.code.Symbol$ClassSymbol.accept(Symbol.java:874) at javax.lang.model.util.ElementScanner6.scan(ElementScanner6.java:139) at com.sun.tools.javac.processing.JavacProcessingEnvironment$ComputeAnnotationSet.scan(JavacProcessingEnvironment.java:767) at com.sun.tools.javac.processing.JavacProcessingEnvironment.doProcessing(JavacProcessingEnvironment.java:825) at com.sun.tools.javac.main.JavaCompiler.processAnnotations(JavaCompiler.java:1070) at com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:806) at com.sun.tools.javac.main.Main.compile(Main.java:400) at com.sun.tools.javac.api.JavacTaskImpl.call(JavacTaskImpl.java:139) at com.sun.tools.javah.JavahTask.run(JavahTask.java:482) at com.sun.tools.javah.JavahTask.run(JavahTask.java:319) at com.sun.tools.javah.Main.main(Main.java:46) Should have clicked with me earlier, but I presume this also stops a full bootstrap as well as the FontManager issue (/mnt/builder/icedtea7/bootstrap/jdk1.6.0/bin/javah above is the just-built OpenJDK). Looks like IcedTea won't be able to support b74. I hope RE learn from this and do a full bootstrap before promoting b75, especially as that one is supposed to be the milestone. b74 certainly gets the award for most broken promoted build so far. -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From Jonathan.Gibbons at Sun.COM Mon Oct 26 13:54:02 2009 From: Jonathan.Gibbons at Sun.COM (Jonathan Gibbons) Date: Mon, 26 Oct 2009 13:54:02 -0700 Subject: Fix for 6888888 breaks the build In-Reply-To: <17c6771e0910261345r531fd54eg1cafa401e71116fa@mail.gmail.com> References: <17c6771e0910150613w40d870d1ne20047231788a6d2@mail.gmail.com> <4AD732D1.1060409@sun.com> <17c6771e0910150805i6d6b1318h4333e89cd2037bde@mail.gmail.com> <4AD74680.3030000@sun.com> <4AD74B6D.60709@sun.com> <4AD8EE6F.3030900@sun.com> <17c6771e0910261316o600ab388tb272b2629ce98409@mail.gmail.com> <17c6771e0910261345r531fd54eg1cafa401e71116fa@mail.gmail.com> Message-ID: <4AE60C6A.2040604@sun.com> Andrew John Hughes wrote: > 2009/10/26 Andrew John Hughes : > >> 2009/10/16 Kelly O'Hair : >> >>> Tim Bell wrote: >>> >>>>> Andrew John Hughes wrote: >>>>> >>>> (snip!) >>>> >>>>>> I think there's still an issue here that makes this patch worth >>>>>> pushing. The 6888888 fix didn't cause the bug, but merely made it >>>>>> visible to a lot more people. So 6889255 will only hide it again. >>>>>> The build uses JAVA_TOOLS_DIR for javac, javah and javadoc: >>>>>> >>>>>> # If no explicit tools, use boot tools (add VM flags in this case) >>>>>> JAVAC_CMD = $(JAVA_TOOLS_DIR)/javac $(JAVAC_JVM_FLAGS) \ >>>>>> $(JAVACFLAGS) >>>>>> JAVAH_CMD = $(JAVA_TOOLS_DIR)/javah \ >>>>>> $(JAVAHFLAGS) >>>>>> JAVADOC_CMD = $(JAVA_TOOLS_DIR)/javadoc $(JAVA_TOOLS_FLAGS:%=-J%) >>>>>> >>>>>> >>>>>> but only when LANGTOOLS_DIST is not defined. Normally, langtools is >>>>>> built first so LANGTOOLS_DIST is defined. What your fix for 6888888 >>>>>> did was cause the setting for JAVAH to get used in all cases and, as >>>>>> JAVA_TOOLS_DIR defaults to ALT_JDK_IMPORT_PATH rather than BOOTDIR >>>>>> this fails in many cases as the user sets ALT_BOOTDIR not >>>>>> ALT_JDK_IMPORT_PATH. >>>>>> >>>>>> In jdk_generic_profile, it seems ALT_JDK_IMPORT_PATH is set to >>>>>> ${jdk_instances}/${importjdk} if it exists. On Solaris, >>>>>> ${jdk_instances} is set to /usr/jdk/instances which probably explains >>>>>> why Sun engineers building on Solaris may not see this bug either. >>>>>> ${jdk_instances} is set to /opt/java on GNU/Linux, whereas distros >>>>>> tend to have standardised on /usr/lib/jvm. It's simply "C:" on >>>>>> Windows. As mentioned on IRC, release engineering are setting >>>>>> ALT_JDK_IMPORT_PATH explicitly so also would never see this bug. >>>>>> >>>>>> As we presumably want the tools from the bootstrap JDK, and not from >>>>>> 'the import JDK to be used to get hotspot VM if not built', I suggest >>>>>> we switch to BOOTDIR by default by applying this patch. >>>>>> >>>>>> >>>> Jonathan Gibbons wrote: >>>> >>>> >>>>> This probably explains problems I've reported informally to Kelly a >>>>> while back, but never got around to formally investigating. FWIW, >>>>> this fix does not interfere with the fix for 6889255 coming up, and this >>>>> fix seems like a good idea to me. >>>>> >>>> OK - I filed a new bug report: >>>> 6892021 "Build tools from ALT_JDK_IMPORT_PATH versus BOOTDIR" >>>> with a pointer to this email thread. >>>> >>>> Kelly - do you have an opinion on this? >>>> >>> The goal was that a full jdk build would never need a ALT_JDK_IMPORT_PATH >>> at all. And all class files would have been created by the LANGTOOLS_DIST >>> compiler (hotspot was a special case, using the ALT_BOOTDIR to compile). >>> But no class files would ever be created by the javac in ALT_BOOTDIR. >>> >>> ALT_JDK_IMPORT_PATH was supposed to only come into play when someone >>> was doing what I called a 'partial build', and it provided the missing >>> pieces, including a jdk7 flavored javac compiler. >>> >>> The other tools were less well defined in their use. >>> The jar tool in ALT_BOOTDIR is always used to build jars as I recall. >>> >>> The javah and javadoc story I'm not so sure about. I thought they would >>> have followed the same rules as javac. >>> >>> Not sure my ramblings are helping here.... :^( >>> >>> -kto >>> >>> >>>> Thanks- >>>> >>>> Tim >>>> >> Did we come to a decision on this? I was reminded of it today because >> none of the forests will build for me (except IcedTea which I've >> patched) due to this bug. >> >> If we don't want to change from using ALT_JDK_IMPORT_PATH, we could at >> least make it default to the BOOTDIR rather than a deliberately broken >> path. Though I still fail to see the need to point to two different >> JDKs simultaneously... >> -- >> Andrew :-) >> >> Free Java Software Engineer >> Red Hat, Inc. (http://www.redhat.com) >> >> Support Free Java! >> Contribute to GNU Classpath and the OpenJDK >> http://www.gnu.org/software/classpath >> http://openjdk.java.net >> >> PGP Key: 94EFD9D8 (http://subkeys.pgp.net) >> Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 >> >> > > I take it this is the error: > > # Running javah: > /mnt/builder/icedtea7/bootstrap/jdk1.6.0/bin/javah -bootclasspath > /mnt/builder/icedtea7/openjdk/build/linux-amd64/classes -d > /mnt/builder/icedtea7/openjdk/build/linux-amd64/tmp/sun/sun.security.pkcs11/j2pkcs11/CClassHeaders/ > \ > sun.security.pkcs11.wrapper.PKCS11 sun.security.pkcs11.Secmod > An exception has occurred in the compiler (1.7.0_0). Please file a bug > at the Java Developer Connection > (http://java.sun.com/webapps/bugreport) after checking the Bug Parade > for duplicates. Include your program and the following diagnostic in > your report. Thank you. > java.lang.NullPointerException > at com.sun.tools.javac.code.Symbol$MethodSymbol.params(Symbol.java:1226) > at com.sun.tools.javac.code.Symbol$MethodSymbol.getParameters(Symbol.java:1252) > at com.sun.tools.javac.code.Symbol$MethodSymbol.getParameters(Symbol.java:1) > at javax.lang.model.util.ElementScanner6.visitExecutable(ElementScanner6.java:191) > at com.sun.tools.javac.code.Symbol$MethodSymbol.accept(Symbol.java:1260) > at javax.lang.model.util.ElementScanner6.scan(ElementScanner6.java:139) > at com.sun.tools.javac.processing.JavacProcessingEnvironment$ComputeAnnotationSet.scan(JavacProcessingEnvironment.java:767) > at com.sun.tools.javac.processing.JavacProcessingEnvironment$ComputeAnnotationSet.scan(JavacProcessingEnvironment.java:1) > at javax.lang.model.util.ElementScanner6.scan(ElementScanner6.java:129) > at javax.lang.model.util.ElementScanner6.visitType(ElementScanner6.java:169) > at com.sun.tools.javac.code.Symbol$ClassSymbol.accept(Symbol.java:874) > at javax.lang.model.util.ElementScanner6.scan(ElementScanner6.java:139) > at com.sun.tools.javac.processing.JavacProcessingEnvironment$ComputeAnnotationSet.scan(JavacProcessingEnvironment.java:767) > at com.sun.tools.javac.processing.JavacProcessingEnvironment$ComputeAnnotationSet.scan(JavacProcessingEnvironment.java:1) > at javax.lang.model.util.ElementScanner6.scan(ElementScanner6.java:129) > at javax.lang.model.util.ElementScanner6.visitType(ElementScanner6.java:169) > at com.sun.tools.javac.code.Symbol$ClassSymbol.accept(Symbol.java:874) > at javax.lang.model.util.ElementScanner6.scan(ElementScanner6.java:139) > at com.sun.tools.javac.processing.JavacProcessingEnvironment$ComputeAnnotationSet.scan(JavacProcessingEnvironment.java:767) > at com.sun.tools.javac.processing.JavacProcessingEnvironment.doProcessing(JavacProcessingEnvironment.java:825) > at com.sun.tools.javac.main.JavaCompiler.processAnnotations(JavaCompiler.java:1070) > at com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:806) > at com.sun.tools.javac.main.Main.compile(Main.java:400) > at com.sun.tools.javac.api.JavacTaskImpl.call(JavacTaskImpl.java:139) > at com.sun.tools.javah.JavahTask.run(JavahTask.java:482) > at com.sun.tools.javah.JavahTask.run(JavahTask.java:319) > at com.sun.tools.javah.Main.main(Main.java:46) > > Should have clicked with me earlier, but I presume this also stops a > full bootstrap as well as the FontManager issue > (/mnt/builder/icedtea7/bootstrap/jdk1.6.0/bin/javah above is the > just-built OpenJDK). Looks like IcedTea won't be able to support b74. > I hope RE learn from this and do a full bootstrap before promoting > b75, especially as that one is supposed to be the milestone. b74 > certainly gets the award for most broken promoted build so far. > Andrew, This should now be fixed. -- Jon -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/build-dev/attachments/20091026/f19065df/attachment-0001.html From gnu_andrew at member.fsf.org Mon Oct 26 14:07:10 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Mon, 26 Oct 2009 21:07:10 +0000 Subject: [Fwd: Boot cycle builds] In-Reply-To: <17c6771e0910261305y7964ca4fu8317b74d6651dafd@mail.gmail.com> References: <4AE5E939.6010804@sun.com> <17c6771e0910261305y7964ca4fu8317b74d6651dafd@mail.gmail.com> Message-ID: <17c6771e0910261407p621835bau53b7aa48a1826361@mail.gmail.com> 2009/10/26 Andrew John Hughes : > 2009/10/26 Kelly O'Hair : >> >> FYI... >> >> -------- Original Message -------- >> Subject: Boot cycle builds >> Date: Mon, 26 Oct 2009 11:21:22 -0700 >> From: Kelly O'Hair >> To: jdk7-gk at openjdk.java.net >> >> >> Heads up... >> >> As soon as we can do a jdk7 boot cycle build again, I plan on changing >> the default build to include a boot cycle build >> (where the jdk7 image is built, then used as the boot jdk to build >> it again). >> >> I consider it critical that boot cycle builds work, and I see >> no other course than requiring it as part of a default jdk7 build. >> >> It can be turned off with SKIP_BOOT_CYCLE=true, but I hope the >> integrators and everyone will be careful when it is turned off. >> >> Depending on your build situation, this could add 20-30 minutes >> (maybe more) to your jdk7 build, which is painful I know, but >> so is finding out that the jdk you just built doesn't work. >> >> Comments are welcome. >> >> -kto >> >> > > IcedTea does just this for a full bootstrap (the default) and it would > be good to see the Sun developers applying the same level of testing > to their builds. > > I would ask that we wait until the end of the current milestone (this > week I believe) before adding this though. > -- > Andrew :-) > > Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > Support Free Java! > Contribute to GNU Classpath and the OpenJDK > http://www.gnu.org/software/classpath > http://openjdk.java.net > > PGP Key: 94EFD9D8 (http://subkeys.pgp.net) > Fingerprint: F8EF F1EA 401E 2E60 15FA ?7927 142C 2591 94EF D9D8 > To add to that, I think just having RE doing a full bootstrap would have prevented the issues we've just hit with b74 (for the uninitiated, changes to both javah and sun.awt.FontManager broke the build). -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From gnu_andrew at member.fsf.org Mon Oct 26 14:12:40 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Mon, 26 Oct 2009 21:12:40 +0000 Subject: Fix for 6888888 breaks the build In-Reply-To: <4AE60C6A.2040604@sun.com> References: <17c6771e0910150613w40d870d1ne20047231788a6d2@mail.gmail.com> <4AD732D1.1060409@sun.com> <17c6771e0910150805i6d6b1318h4333e89cd2037bde@mail.gmail.com> <4AD74680.3030000@sun.com> <4AD74B6D.60709@sun.com> <4AD8EE6F.3030900@sun.com> <17c6771e0910261316o600ab388tb272b2629ce98409@mail.gmail.com> <17c6771e0910261345r531fd54eg1cafa401e71116fa@mail.gmail.com> <4AE60C6A.2040604@sun.com> Message-ID: <17c6771e0910261412p394dc567m441af1a80dc21c85@mail.gmail.com> 2009/10/26 Jonathan Gibbons : > Andrew John Hughes wrote: > > 2009/10/26 Andrew John Hughes : > > > 2009/10/16 Kelly O'Hair : > > > Tim Bell wrote: > > > Andrew John Hughes wrote: > > > (snip!) > > > I think there's still an issue here that makes this patch worth > pushing. ? The 6888888 fix didn't cause the bug, but merely made it > visible to a lot more people. ?So 6889255 will only hide it again. > The build uses JAVA_TOOLS_DIR for javac, javah and javadoc: > > ?# If no explicit tools, use boot tools (add VM flags in this case) > ?JAVAC_CMD ? ? = $(JAVA_TOOLS_DIR)/javac $(JAVAC_JVM_FLAGS) \ > ? ? ? ? ? ? ? ? ?$(JAVACFLAGS) > ?JAVAH_CMD ? ? = $(JAVA_TOOLS_DIR)/javah \ > ? ? ? ? ? ? ? ? ?$(JAVAHFLAGS) > ?JAVADOC_CMD ? = $(JAVA_TOOLS_DIR)/javadoc $(JAVA_TOOLS_FLAGS:%=-J%) > > > but only when LANGTOOLS_DIST is not defined. ?Normally, langtools is > built first so LANGTOOLS_DIST is defined. ?What your fix for 6888888 > did was cause the setting for JAVAH to get used in all cases and, as > JAVA_TOOLS_DIR defaults to ALT_JDK_IMPORT_PATH rather than BOOTDIR > this fails in many cases as the user sets ALT_BOOTDIR not > ALT_JDK_IMPORT_PATH. > > In jdk_generic_profile, it seems ALT_JDK_IMPORT_PATH is set to > ${jdk_instances}/${importjdk} if it exists. ?On Solaris, > ${jdk_instances} is set to /usr/jdk/instances which probably explains > why Sun engineers building on Solaris may not see this bug either. > ${jdk_instances} is set to /opt/java on GNU/Linux, whereas distros > tend to have standardised on /usr/lib/jvm. ?It's simply "C:" on > Windows. ?As mentioned on IRC, release engineering are setting > ALT_JDK_IMPORT_PATH explicitly so also would never see this bug. > > As we presumably want the tools from the bootstrap JDK, and not from > 'the import JDK to be used to get hotspot VM if not built', I suggest > we switch to BOOTDIR by default by applying this patch. > > > > Jonathan Gibbons wrote: > > > > This probably explains problems I've reported informally to Kelly a > while back, but never got around to formally investigating. ? ? FWIW, > this fix does not interfere with the fix for 6889255 coming up, and this > fix seems like a good idea to me. > > > OK - I filed a new bug report: > ?6892021 "Build tools from ALT_JDK_IMPORT_PATH versus BOOTDIR" > with a pointer to this email thread. > > Kelly - do you have an opinion on this? > > > The goal was that a full jdk build would never need a ALT_JDK_IMPORT_PATH > at all. And all class files would have been created by the LANGTOOLS_DIST > compiler (hotspot was a special case, using the ALT_BOOTDIR to compile). > But no class files would ever be created by the javac in ALT_BOOTDIR. > > ALT_JDK_IMPORT_PATH was supposed to only come into play when someone > was doing what I called a 'partial build', and it provided the missing > pieces, including a jdk7 flavored javac compiler. > > The other tools were less well defined in their use. > The jar tool in ALT_BOOTDIR is always used to build jars as I recall. > > The javah and javadoc story I'm not so sure about. I thought they would > have followed the same rules as javac. > > Not sure my ramblings are helping here.... ?:^( > > -kto > > > > Thanks- > > Tim > > > Did we come to a decision on this? I was reminded of it today because > none of the forests will build for me (except IcedTea which I've > patched) due to this bug. > > If we don't want to change from using ALT_JDK_IMPORT_PATH, we could at > least make it default to the BOOTDIR rather than a deliberately broken > path. ?Though I still fail to see the need to point to two different > JDKs simultaneously... > -- > Andrew :-) > > Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > Support Free Java! > Contribute to GNU Classpath and the OpenJDK > http://www.gnu.org/software/classpath > http://openjdk.java.net > > PGP Key: 94EFD9D8 (http://subkeys.pgp.net) > Fingerprint: F8EF F1EA 401E 2E60 15FA ?7927 142C 2591 94EF D9D8 > > > > I take it this is the error: > > # Running javah: > /mnt/builder/icedtea7/bootstrap/jdk1.6.0/bin/javah -bootclasspath > /mnt/builder/icedtea7/openjdk/build/linux-amd64/classes -d > /mnt/builder/icedtea7/openjdk/build/linux-amd64/tmp/sun/sun.security.pkcs11/j2pkcs11/CClassHeaders/ > \ > sun.security.pkcs11.wrapper.PKCS11 sun.security.pkcs11.Secmod > An exception has occurred in the compiler (1.7.0_0). Please file a bug > at the Java Developer Connection > (http://java.sun.com/webapps/bugreport) after checking the Bug Parade > for duplicates. Include your program and the following diagnostic in > your report. Thank you. > java.lang.NullPointerException > at com.sun.tools.javac.code.Symbol$MethodSymbol.params(Symbol.java:1226) > at > com.sun.tools.javac.code.Symbol$MethodSymbol.getParameters(Symbol.java:1252) > at > com.sun.tools.javac.code.Symbol$MethodSymbol.getParameters(Symbol.java:1) > at > javax.lang.model.util.ElementScanner6.visitExecutable(ElementScanner6.java:191) > at com.sun.tools.javac.code.Symbol$MethodSymbol.accept(Symbol.java:1260) > at javax.lang.model.util.ElementScanner6.scan(ElementScanner6.java:139) > at > com.sun.tools.javac.processing.JavacProcessingEnvironment$ComputeAnnotationSet.scan(JavacProcessingEnvironment.java:767) > at > com.sun.tools.javac.processing.JavacProcessingEnvironment$ComputeAnnotationSet.scan(JavacProcessingEnvironment.java:1) > at javax.lang.model.util.ElementScanner6.scan(ElementScanner6.java:129) > at > javax.lang.model.util.ElementScanner6.visitType(ElementScanner6.java:169) > at com.sun.tools.javac.code.Symbol$ClassSymbol.accept(Symbol.java:874) > at javax.lang.model.util.ElementScanner6.scan(ElementScanner6.java:139) > at > com.sun.tools.javac.processing.JavacProcessingEnvironment$ComputeAnnotationSet.scan(JavacProcessingEnvironment.java:767) > at > com.sun.tools.javac.processing.JavacProcessingEnvironment$ComputeAnnotationSet.scan(JavacProcessingEnvironment.java:1) > at javax.lang.model.util.ElementScanner6.scan(ElementScanner6.java:129) > at > javax.lang.model.util.ElementScanner6.visitType(ElementScanner6.java:169) > at com.sun.tools.javac.code.Symbol$ClassSymbol.accept(Symbol.java:874) > at javax.lang.model.util.ElementScanner6.scan(ElementScanner6.java:139) > at > com.sun.tools.javac.processing.JavacProcessingEnvironment$ComputeAnnotationSet.scan(JavacProcessingEnvironment.java:767) > at > com.sun.tools.javac.processing.JavacProcessingEnvironment.doProcessing(JavacProcessingEnvironment.java:825) > at > com.sun.tools.javac.main.JavaCompiler.processAnnotations(JavaCompiler.java:1070) > at com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:806) > at com.sun.tools.javac.main.Main.compile(Main.java:400) > at com.sun.tools.javac.api.JavacTaskImpl.call(JavacTaskImpl.java:139) > at com.sun.tools.javah.JavahTask.run(JavahTask.java:482) > at com.sun.tools.javah.JavahTask.run(JavahTask.java:319) > at com.sun.tools.javah.Main.main(Main.java:46) > > Should have clicked with me earlier, but I presume this also stops a > full bootstrap as well as the FontManager issue > (/mnt/builder/icedtea7/bootstrap/jdk1.6.0/bin/javah above is the > just-built OpenJDK). Looks like IcedTea won't be able to support b74. > I hope RE learn from this and do a full bootstrap before promoting > b75, especially as that one is supposed to be the milestone. b74 > certainly gets the award for most broken promoted build so far. > > > Andrew, > > This should now be fixed. > > -- Jon > That's excellent news. Do you happen to know which changeset(s) fix the issue? I can then pull them into IcedTea ahead of time. -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From ahughes at redhat.com Mon Oct 26 14:51:16 2009 From: ahughes at redhat.com (ahughes at redhat.com) Date: Mon, 26 Oct 2009 21:51:16 +0000 Subject: hg: jdk7/build/jdk: 6895287: disable building fontchecker Message-ID: <20091026215138.AC0F941C44@hg.openjdk.java.net> Changeset: 9bc5338675e0 Author: andrew Date: 2009-10-26 21:42 +0000 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/9bc5338675e0 6895287: disable building fontchecker Summary: Changes to FontManager break bootstrap due to the fontchecker tool Reviewed-by: prr ! make/tools/Makefile - make/tools/fontchecker/Makefile - make/tools/src/build/tools/fontchecker/FontCheckDummy.java - make/tools/src/build/tools/fontchecker/FontChecker.java - make/tools/src/build/tools/fontchecker/FontCheckerConstants.java - make/tools/src/build/tools/fontchecker/FontFileFilter.java - make/tools/src/build/tools/fontchecker/README.txt From Jonathan.Gibbons at Sun.COM Mon Oct 26 15:36:53 2009 From: Jonathan.Gibbons at Sun.COM (Jonathan Gibbons) Date: Mon, 26 Oct 2009 15:36:53 -0700 Subject: [Fwd: Boot cycle builds] In-Reply-To: <17c6771e0910261407p621835bau53b7aa48a1826361@mail.gmail.com> References: <4AE5E939.6010804@sun.com> <17c6771e0910261305y7964ca4fu8317b74d6651dafd@mail.gmail.com> <17c6771e0910261407p621835bau53b7aa48a1826361@mail.gmail.com> Message-ID: <4AE62485.3060109@sun.com> Andrew John Hughes wrote: > 2009/10/26 Andrew John Hughes : > >> 2009/10/26 Kelly O'Hair : >> >>> FYI... >>> >>> -------- Original Message -------- >>> Subject: Boot cycle builds >>> Date: Mon, 26 Oct 2009 11:21:22 -0700 >>> From: Kelly O'Hair >>> To: jdk7-gk at openjdk.java.net >>> >>> >>> Heads up... >>> >>> As soon as we can do a jdk7 boot cycle build again, I plan on changing >>> the default build to include a boot cycle build >>> (where the jdk7 image is built, then used as the boot jdk to build >>> it again). >>> >>> I consider it critical that boot cycle builds work, and I see >>> no other course than requiring it as part of a default jdk7 build. >>> >>> It can be turned off with SKIP_BOOT_CYCLE=true, but I hope the >>> integrators and everyone will be careful when it is turned off. >>> >>> Depending on your build situation, this could add 20-30 minutes >>> (maybe more) to your jdk7 build, which is painful I know, but >>> so is finding out that the jdk you just built doesn't work. >>> >>> Comments are welcome. >>> >>> -kto >>> >>> >>> >> IcedTea does just this for a full bootstrap (the default) and it would >> be good to see the Sun developers applying the same level of testing >> to their builds. >> >> I would ask that we wait until the end of the current milestone (this >> week I believe) before adding this though. >> -- >> Andrew :-) >> >> Free Java Software Engineer >> Red Hat, Inc. (http://www.redhat.com) >> >> Support Free Java! >> Contribute to GNU Classpath and the OpenJDK >> http://www.gnu.org/software/classpath >> http://openjdk.java.net >> >> PGP Key: 94EFD9D8 (http://subkeys.pgp.net) >> Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 >> >> > > To add to that, I think just having RE doing a full bootstrap would > have prevented the issues we've just hit with b74 (for the > uninitiated, changes to both javah and sun.awt.FontManager broke the > build). > Andrew, The full bootstrap would not have uncovered the issues with the changes to javah. I did full bootstrap builds. The issue arose with fastdebug builds. -- Jon -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/build-dev/attachments/20091026/a245fbdc/attachment.html From Jonathan.Gibbons at Sun.COM Mon Oct 26 15:46:08 2009 From: Jonathan.Gibbons at Sun.COM (Jonathan Gibbons) Date: Mon, 26 Oct 2009 15:46:08 -0700 Subject: Fix for 6888888 breaks the build In-Reply-To: <17c6771e0910261412p394dc567m441af1a80dc21c85@mail.gmail.com> References: <17c6771e0910150613w40d870d1ne20047231788a6d2@mail.gmail.com> <4AD732D1.1060409@sun.com> <17c6771e0910150805i6d6b1318h4333e89cd2037bde@mail.gmail.com> <4AD74680.3030000@sun.com> <4AD74B6D.60709@sun.com> <4AD8EE6F.3030900@sun.com> <17c6771e0910261316o600ab388tb272b2629ce98409@mail.gmail.com> <17c6771e0910261345r531fd54eg1cafa401e71116fa@mail.gmail.com> <4AE60C6A.2040604@sun.com> <17c6771e0910261412p394dc567m441af1a80dc21c85@mail.gmail.com> Message-ID: <4AE626B0.70302@sun.com> Andrew John Hughes wrote: > 2009/10/26 Jonathan Gibbons : > >> Andrew John Hughes wrote: >> >> 2009/10/26 Andrew John Hughes : >> >> >> 2009/10/16 Kelly O'Hair : >> >> >> Tim Bell wrote: >> >> >> Andrew John Hughes wrote: >> >> >> (snip!) >> >> >> I think there's still an issue here that makes this patch worth >> pushing. The 6888888 fix didn't cause the bug, but merely made it >> visible to a lot more people. So 6889255 will only hide it again. >> The build uses JAVA_TOOLS_DIR for javac, javah and javadoc: >> >> # If no explicit tools, use boot tools (add VM flags in this case) >> JAVAC_CMD = $(JAVA_TOOLS_DIR)/javac $(JAVAC_JVM_FLAGS) \ >> $(JAVACFLAGS) >> JAVAH_CMD = $(JAVA_TOOLS_DIR)/javah \ >> $(JAVAHFLAGS) >> JAVADOC_CMD = $(JAVA_TOOLS_DIR)/javadoc $(JAVA_TOOLS_FLAGS:%=-J%) >> >> >> but only when LANGTOOLS_DIST is not defined. Normally, langtools is >> built first so LANGTOOLS_DIST is defined. What your fix for 6888888 >> did was cause the setting for JAVAH to get used in all cases and, as >> JAVA_TOOLS_DIR defaults to ALT_JDK_IMPORT_PATH rather than BOOTDIR >> this fails in many cases as the user sets ALT_BOOTDIR not >> ALT_JDK_IMPORT_PATH. >> >> In jdk_generic_profile, it seems ALT_JDK_IMPORT_PATH is set to >> ${jdk_instances}/${importjdk} if it exists. On Solaris, >> ${jdk_instances} is set to /usr/jdk/instances which probably explains >> why Sun engineers building on Solaris may not see this bug either. >> ${jdk_instances} is set to /opt/java on GNU/Linux, whereas distros >> tend to have standardised on /usr/lib/jvm. It's simply "C:" on >> Windows. As mentioned on IRC, release engineering are setting >> ALT_JDK_IMPORT_PATH explicitly so also would never see this bug. >> >> As we presumably want the tools from the bootstrap JDK, and not from >> 'the import JDK to be used to get hotspot VM if not built', I suggest >> we switch to BOOTDIR by default by applying this patch. >> >> >> >> Jonathan Gibbons wrote: >> >> >> >> This probably explains problems I've reported informally to Kelly a >> while back, but never got around to formally investigating. FWIW, >> this fix does not interfere with the fix for 6889255 coming up, and this >> fix seems like a good idea to me. >> >> >> OK - I filed a new bug report: >> 6892021 "Build tools from ALT_JDK_IMPORT_PATH versus BOOTDIR" >> with a pointer to this email thread. >> >> Kelly - do you have an opinion on this? >> >> >> The goal was that a full jdk build would never need a ALT_JDK_IMPORT_PATH >> at all. And all class files would have been created by the LANGTOOLS_DIST >> compiler (hotspot was a special case, using the ALT_BOOTDIR to compile). >> But no class files would ever be created by the javac in ALT_BOOTDIR. >> >> ALT_JDK_IMPORT_PATH was supposed to only come into play when someone >> was doing what I called a 'partial build', and it provided the missing >> pieces, including a jdk7 flavored javac compiler. >> >> The other tools were less well defined in their use. >> The jar tool in ALT_BOOTDIR is always used to build jars as I recall. >> >> The javah and javadoc story I'm not so sure about. I thought they would >> have followed the same rules as javac. >> >> Not sure my ramblings are helping here.... :^( >> >> -kto >> >> >> >> Thanks- >> >> Tim >> >> >> Did we come to a decision on this? I was reminded of it today because >> none of the forests will build for me (except IcedTea which I've >> patched) due to this bug. >> >> If we don't want to change from using ALT_JDK_IMPORT_PATH, we could at >> least make it default to the BOOTDIR rather than a deliberately broken >> path. Though I still fail to see the need to point to two different >> JDKs simultaneously... >> -- >> Andrew :-) >> >> Free Java Software Engineer >> Red Hat, Inc. (http://www.redhat.com) >> >> Support Free Java! >> Contribute to GNU Classpath and the OpenJDK >> http://www.gnu.org/software/classpath >> http://openjdk.java.net >> >> PGP Key: 94EFD9D8 (http://subkeys.pgp.net) >> Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 >> >> >> >> I take it this is the error: >> >> # Running javah: >> /mnt/builder/icedtea7/bootstrap/jdk1.6.0/bin/javah -bootclasspath >> /mnt/builder/icedtea7/openjdk/build/linux-amd64/classes -d >> /mnt/builder/icedtea7/openjdk/build/linux-amd64/tmp/sun/sun.security.pkcs11/j2pkcs11/CClassHeaders/ >> \ >> sun.security.pkcs11.wrapper.PKCS11 sun.security.pkcs11.Secmod >> An exception has occurred in the compiler (1.7.0_0). Please file a bug >> at the Java Developer Connection >> (http://java.sun.com/webapps/bugreport) after checking the Bug Parade >> for duplicates. Include your program and the following diagnostic in >> your report. Thank you. >> java.lang.NullPointerException >> at com.sun.tools.javac.code.Symbol$MethodSymbol.params(Symbol.java:1226) >> at >> com.sun.tools.javac.code.Symbol$MethodSymbol.getParameters(Symbol.java:1252) >> at >> com.sun.tools.javac.code.Symbol$MethodSymbol.getParameters(Symbol.java:1) >> at >> javax.lang.model.util.ElementScanner6.visitExecutable(ElementScanner6.java:191) >> at com.sun.tools.javac.code.Symbol$MethodSymbol.accept(Symbol.java:1260) >> at javax.lang.model.util.ElementScanner6.scan(ElementScanner6.java:139) >> at >> com.sun.tools.javac.processing.JavacProcessingEnvironment$ComputeAnnotationSet.scan(JavacProcessingEnvironment.java:767) >> at >> com.sun.tools.javac.processing.JavacProcessingEnvironment$ComputeAnnotationSet.scan(JavacProcessingEnvironment.java:1) >> at javax.lang.model.util.ElementScanner6.scan(ElementScanner6.java:129) >> at >> javax.lang.model.util.ElementScanner6.visitType(ElementScanner6.java:169) >> at com.sun.tools.javac.code.Symbol$ClassSymbol.accept(Symbol.java:874) >> at javax.lang.model.util.ElementScanner6.scan(ElementScanner6.java:139) >> at >> com.sun.tools.javac.processing.JavacProcessingEnvironment$ComputeAnnotationSet.scan(JavacProcessingEnvironment.java:767) >> at >> com.sun.tools.javac.processing.JavacProcessingEnvironment$ComputeAnnotationSet.scan(JavacProcessingEnvironment.java:1) >> at javax.lang.model.util.ElementScanner6.scan(ElementScanner6.java:129) >> at >> javax.lang.model.util.ElementScanner6.visitType(ElementScanner6.java:169) >> at com.sun.tools.javac.code.Symbol$ClassSymbol.accept(Symbol.java:874) >> at javax.lang.model.util.ElementScanner6.scan(ElementScanner6.java:139) >> at >> com.sun.tools.javac.processing.JavacProcessingEnvironment$ComputeAnnotationSet.scan(JavacProcessingEnvironment.java:767) >> at >> com.sun.tools.javac.processing.JavacProcessingEnvironment.doProcessing(JavacProcessingEnvironment.java:825) >> at >> com.sun.tools.javac.main.JavaCompiler.processAnnotations(JavaCompiler.java:1070) >> at com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:806) >> at com.sun.tools.javac.main.Main.compile(Main.java:400) >> at com.sun.tools.javac.api.JavacTaskImpl.call(JavacTaskImpl.java:139) >> at com.sun.tools.javah.JavahTask.run(JavahTask.java:482) >> at com.sun.tools.javah.JavahTask.run(JavahTask.java:319) >> at com.sun.tools.javah.Main.main(Main.java:46) >> >> Should have clicked with me earlier, but I presume this also stops a >> full bootstrap as well as the FontManager issue >> (/mnt/builder/icedtea7/bootstrap/jdk1.6.0/bin/javah above is the >> just-built OpenJDK). Looks like IcedTea won't be able to support b74. >> I hope RE learn from this and do a full bootstrap before promoting >> b75, especially as that one is supposed to be the milestone. b74 >> certainly gets the award for most broken promoted build so far. >> >> >> Andrew, >> >> This should now be fixed. >> >> -- Jon >> >> > > That's excellent news. Do you happen to know which changeset(s) fix > the issue? I can then pull them into IcedTea ahead of time. > Andrew, Here's the fix: Changeset: 2485f5641ed0 Author: jjg Date: 2009-10-19 13:38 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/2485f5641ed0 6889255: javac MethodSymbol throws NPE if ClassReader does not read parameter names correctly Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java + test/tools/javac/6889255/T6889255.java -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/build-dev/attachments/20091026/5d162877/attachment-0001.html From gnu_andrew at member.fsf.org Mon Oct 26 18:18:14 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Tue, 27 Oct 2009 01:18:14 +0000 Subject: [Fwd: Boot cycle builds] In-Reply-To: <4AE62485.3060109@sun.com> References: <4AE5E939.6010804@sun.com> <17c6771e0910261305y7964ca4fu8317b74d6651dafd@mail.gmail.com> <17c6771e0910261407p621835bau53b7aa48a1826361@mail.gmail.com> <4AE62485.3060109@sun.com> Message-ID: <17c6771e0910261818l434a940ax8ae16bc4c5f0e3e5@mail.gmail.com> 2009/10/26 Jonathan Gibbons : > Andrew John Hughes wrote: > > 2009/10/26 Andrew John Hughes : > > > 2009/10/26 Kelly O'Hair : > > > FYI... > > -------- Original Message -------- > Subject: Boot cycle builds > Date: Mon, 26 Oct 2009 11:21:22 -0700 > From: Kelly O'Hair > To: jdk7-gk at openjdk.java.net > > > Heads up... > > As soon as we can do a jdk7 boot cycle build again, I plan on changing > the default build to include a boot cycle build > (where the jdk7 image is built, then used as the boot jdk to build > it again). > > I consider it critical that boot cycle builds work, and I see > no other course than requiring it as part of a default jdk7 build. > > It can be turned off with SKIP_BOOT_CYCLE=true, but I hope the > integrators and everyone will be careful when it is turned off. > > Depending on your build situation, this could add 20-30 minutes > (maybe more) to your jdk7 build, which is painful I know, but > so is finding out that the jdk you just built doesn't work. > > Comments are welcome. > > -kto > > > > > IcedTea does just this for a full bootstrap (the default) and it would > be good to see the Sun developers applying the same level of testing > to their builds. > > I would ask that we wait until the end of the current milestone (this > week I believe) before adding this though. > -- > Andrew :-) > > Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > Support Free Java! > Contribute to GNU Classpath and the OpenJDK > http://www.gnu.org/software/classpath > http://openjdk.java.net > > PGP Key: 94EFD9D8 (http://subkeys.pgp.net) > Fingerprint: F8EF F1EA 401E 2E60 15FA ?7927 142C 2591 94EF D9D8 > > > > To add to that, I think just having RE doing a full bootstrap would > have prevented the issues we've just hit with b74 (for the > uninitiated, changes to both javah and sun.awt.FontManager broke the > build). > > > Andrew, > > The full bootstrap would not have uncovered the issues with the changes to > javah. I did full bootstrap builds. The issue arose with fastdebug builds. > > -- Jon > Strange; I did see the error when bootstrapping via IcedTea. -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From Jonathan.Gibbons at Sun.COM Mon Oct 26 19:07:17 2009 From: Jonathan.Gibbons at Sun.COM (Jonathan Gibbons) Date: Mon, 26 Oct 2009 19:07:17 -0700 Subject: [Fwd: Boot cycle builds] In-Reply-To: <17c6771e0910261818l434a940ax8ae16bc4c5f0e3e5@mail.gmail.com> References: <4AE5E939.6010804@sun.com> <17c6771e0910261305y7964ca4fu8317b74d6651dafd@mail.gmail.com> <17c6771e0910261407p621835bau53b7aa48a1826361@mail.gmail.com> <4AE62485.3060109@sun.com> <17c6771e0910261818l434a940ax8ae16bc4c5f0e3e5@mail.gmail.com> Message-ID: <4AE655D5.4050909@sun.com> Andrew John Hughes wrote: > 2009/10/26 Jonathan Gibbons : > >> Andrew John Hughes wrote: >> >> 2009/10/26 Andrew John Hughes : >> >> >> 2009/10/26 Kelly O'Hair : >> >> >> FYI... >> >> -------- Original Message -------- >> Subject: Boot cycle builds >> Date: Mon, 26 Oct 2009 11:21:22 -0700 >> From: Kelly O'Hair >> To: jdk7-gk at openjdk.java.net >> >> >> Heads up... >> >> As soon as we can do a jdk7 boot cycle build again, I plan on changing >> the default build to include a boot cycle build >> (where the jdk7 image is built, then used as the boot jdk to build >> it again). >> >> I consider it critical that boot cycle builds work, and I see >> no other course than requiring it as part of a default jdk7 build. >> >> It can be turned off with SKIP_BOOT_CYCLE=true, but I hope the >> integrators and everyone will be careful when it is turned off. >> >> Depending on your build situation, this could add 20-30 minutes >> (maybe more) to your jdk7 build, which is painful I know, but >> so is finding out that the jdk you just built doesn't work. >> >> Comments are welcome. >> >> -kto >> >> >> >> >> IcedTea does just this for a full bootstrap (the default) and it would >> be good to see the Sun developers applying the same level of testing >> to their builds. >> >> I would ask that we wait until the end of the current milestone (this >> week I believe) before adding this though. >> -- >> Andrew :-) >> >> Free Java Software Engineer >> Red Hat, Inc. (http://www.redhat.com) >> >> Support Free Java! >> Contribute to GNU Classpath and the OpenJDK >> http://www.gnu.org/software/classpath >> http://openjdk.java.net >> >> PGP Key: 94EFD9D8 (http://subkeys.pgp.net) >> Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 >> >> >> >> To add to that, I think just having RE doing a full bootstrap would >> have prevented the issues we've just hit with b74 (for the >> uninitiated, changes to both javah and sun.awt.FontManager broke the >> build). >> >> >> Andrew, >> >> The full bootstrap would not have uncovered the issues with the changes to >> javah. I did full bootstrap builds. The issue arose with fastdebug builds. >> >> -- Jon >> >> > > Strange; I did see the error when bootstrapping via IcedTea. > Andrew, The fault shows up if you use the javac -g option. That is not the case in normal JDK builds, with or without the bootstrap build. -- Jon -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/build-dev/attachments/20091026/8ac5c448/attachment.html From gnu_andrew at member.fsf.org Tue Oct 27 04:55:10 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Tue, 27 Oct 2009 11:55:10 +0000 Subject: [Fwd: Boot cycle builds] In-Reply-To: <4AE655D5.4050909@sun.com> References: <4AE5E939.6010804@sun.com> <17c6771e0910261305y7964ca4fu8317b74d6651dafd@mail.gmail.com> <17c6771e0910261407p621835bau53b7aa48a1826361@mail.gmail.com> <4AE62485.3060109@sun.com> <17c6771e0910261818l434a940ax8ae16bc4c5f0e3e5@mail.gmail.com> <4AE655D5.4050909@sun.com> Message-ID: <17c6771e0910270455r58096ef9pd4e8d6842d08b707@mail.gmail.com> 2009/10/27 Jonathan Gibbons : > Andrew John Hughes wrote: > > 2009/10/26 Jonathan Gibbons : > > > Andrew John Hughes wrote: > > 2009/10/26 Andrew John Hughes : > > > 2009/10/26 Kelly O'Hair : > > > FYI... > > -------- Original Message -------- > Subject: Boot cycle builds > Date: Mon, 26 Oct 2009 11:21:22 -0700 > From: Kelly O'Hair > To: jdk7-gk at openjdk.java.net > > > Heads up... > > As soon as we can do a jdk7 boot cycle build again, I plan on changing > the default build to include a boot cycle build > (where the jdk7 image is built, then used as the boot jdk to build > it again). > > I consider it critical that boot cycle builds work, and I see > no other course than requiring it as part of a default jdk7 build. > > It can be turned off with SKIP_BOOT_CYCLE=true, but I hope the > integrators and everyone will be careful when it is turned off. > > Depending on your build situation, this could add 20-30 minutes > (maybe more) to your jdk7 build, which is painful I know, but > so is finding out that the jdk you just built doesn't work. > > Comments are welcome. > > -kto > > > > > IcedTea does just this for a full bootstrap (the default) and it would > be good to see the Sun developers applying the same level of testing > to their builds. > > I would ask that we wait until the end of the current milestone (this > week I believe) before adding this though. > -- > Andrew :-) > > Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > Support Free Java! > Contribute to GNU Classpath and the OpenJDK > http://www.gnu.org/software/classpath > http://openjdk.java.net > > PGP Key: 94EFD9D8 (http://subkeys.pgp.net) > Fingerprint: F8EF F1EA 401E 2E60 15FA ?7927 142C 2591 94EF D9D8 > > > > To add to that, I think just having RE doing a full bootstrap would > have prevented the issues we've just hit with b74 (for the > uninitiated, changes to both javah and sun.awt.FontManager broke the > build). > > > Andrew, > > The full bootstrap would not have uncovered the issues with the changes to > javah. I did full bootstrap builds. The issue arose with fastdebug builds. > > -- Jon > > > > Strange; I did see the error when bootstrapping via IcedTea. > > > Andrew, > > The fault shows up if you use the javac -g option. That is not the case in > normal JDK builds, with or without the bootstrap build. > > -- Jon > Aaaah! DEBUG_CLASSFILES="true" also turns this on and is standard for all IcedTea builds. It was introduced in an OpenJDK patch from Andrew Haley, but prior to that we were manually patching in -g options. We don't ship stuff without debugging information. -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From gnu_andrew at member.fsf.org Tue Oct 27 18:02:56 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Wed, 28 Oct 2009 01:02:56 +0000 Subject: 6856630: Restructure jaxp/jaxws repository In-Reply-To: <4AE1DF30.2030207@sun.com> References: <4AB80C37.6000108@sun.com> <4ACF6ECC.7070407@sun.com> <17c6771e0910121014w6fcd23e9rf5d594173e594ec3@mail.gmail.com> <4AD36C3F.2010501@sun.com> <17c6771e0910121318m26e53de3gb3bbea964b70f4eb@mail.gmail.com> <4AE0DB80.90107@sun.com> <4AE0FDAB.1080305@sun.com> <4AE1D88C.5040408@sun.com> <4AE1DC34.30707@sun.com> <4AE1DF30.2030207@sun.com> Message-ID: <17c6771e0910271802n54a67e2cq4d547c592d817e94@mail.gmail.com> 2009/10/23 Kelly O'Hair : > > > Jonathan Gibbons wrote: >> >> Kelly O'Hair wrote: >>> >>> >>> Jonathan Gibbons wrote: >>>> >>>> Kelly O'Hair wrote: >>>>> >>>>> Andrew, >>>>> >>>>> Sorry I'm so slow on this, ... >>>>> >>>>> I'm looking at updating the jaxp bundle. The webrev is: >>>>> >>>>> http://cr.openjdk.java.net/~ohair/openjdk7/jdk7-tl-jaxp-6861589/webrev/ >>>>> >>>>> Updated jaxp source bundle, and complete removal of anything >>>>> that would use the original source. The final changeset will also >>>>> delete the jaxp/src directory so we never accidently use it. >>>>> It also adds a md5 checksum check on the bundle in the ant script, >>>>> a property value contains the expected checksum. >>>>> >>>>> I'm not done, so I could add more if you want me to add the changes >>>>> mentioned here... The merge should be trivial. >>>>> >>>>> One snag is that I plan on pushing this to the TL forest so that >>>>> the TL integrator (Tim Bell) can get the appropriate tests done >>>>> on the jaxp changes. In the future jaxp changes will probably >>>>> be going through the TL area. >>>>> >>>>> ... ?a few more comments below... >>>>> >>>>> Andrew John Hughes wrote: >>>>>> >>>>>> 2009/10/12 Kelly O'Hair : >>>>>>> >>>>>>> I saw the webrev for a while, and now I can't :^(, but I saw >>>>>>> enough... >>>>>>> >>>>>>>>> Andrew John Hughes wrote: >>>>>>>>>> >>>>>>>>>> 2009/10/7 Andrew John Hughes : >>>>>>> >>>>>>> ...[snip]... >>>>>>>>>> >>>>>>>>>> I found a number of issues with the current version: >>>>>>>>>> >>>>>>>>>> * The drop zips are expected to be in a share/jdk7-drops >>>>>>>>>> subdirectory >>>>>>>>>> of the devtools directory. ?This doesn't really work outside Sun's >>>>>>>>>> internal setup. ?I've added support for ALT_DROP_DIR which can be >>>>>>>>>> used >>>>>>>>>> to specify an exact path to the zips. ?If this is not set, the old >>>>>>>>>> devtools behaviour is used. >>>>>>> >>>>>>> I'm concerned about the name dropdir (your master copy location) vs. >>>>>>> drop.dir >>>>>>> (destination for the exploded contents) in the property names. Seems >>>>>>> confusing. >>>>>>> I hesitate to go on a name hunt, but what about ALT_DROP_BUNDLE_DIR >>>>>>> and >>>>>>> drop.bundle.dir? >>>>>>> >>>>>> >>>>>> Yes, I noticed drop.dir after posting the webrev and agree it's >>>>>> confusing. ?Would just making them ALT_DROPS_DIR and drops.dir not be >>>>>> sufficient? ?drop.bundle seems a little verbose and both mean the same >>>>>> thing to me at least. >>>>> >>>>> I'm ok with ALT_DROPS_DIR and drops.dir. >>>>> >>>>>> >>>>>>>>>> * The zips are being downloaded and extracted in the source >>>>>>>>>> directory, >>>>>>>>>> which could be read only. ?I've changed this so they are written >>>>>>>>>> to >>>>>>>>>> the build directory like everything else. >>>>>>> >>>>>>> It turns out that we need this drop.dir to be in the source area if >>>>>>> we want the openjdk source zip bundles, created by RE, to include >>>>>>> the drop sources. These source bundles are created by bundling up >>>>>>> everything in the forest, prior to building, so the drop.dir needs >>>>>>> to be in the forest somehow. Otherwise, the bundling logic has to >>>>>>> merge two separate source trees, or different roots. >>>>>>> I was given a requirement that the openjdk source bundles include >>>>>>> these >>>>>>> drop sources, easiest answer was drop.dir in the repo. >>>>>>> Not an unsurmountable problem, I avoided the more complicated path. >>>>>>> >>>>>>> I know that becomes an issue if the repository or source is in a >>>>>>> read-only area, but that's not the only situation in the openjdk I >>>>>>> suspect. >>>>>>> I assumed someone building from a read-only area could set >>>>>>> drop.dir to some other location. >>>>>>> >>>>>> >>>>>> Would it not make more sense for RE to set the drop.dir property into >>>>>> the source directory, given it's that build that's abnormal (needing >>>>>> to distribute a post build tree in effect)? >>>>> >>>>> I will look into that. You have convinced me. ;^) >>>>> >>>>>> >>>>>>> Not sure what to say. >>>>>>> >>>>>>> How important is it for the community that the openjdk source bundles >>>>>>> include these drop sources? e.g. ones at >>>>>>> http://download.java.net/openjdk/jdk7/ >>>>>>> If they are not included, when the openjdk source bundles are built, >>>>>>> they will need to download the jaxp and jaxws drop bundles at build >>>>>>> time. >>>>>>> >>>>>> >>>>>> I obviously can't speak for everyone, but for IcedTea7 we don't even >>>>>> use the download bundles any more. ?We grab from the IcedTea forest >>>>>> instead, which allows patches which didn't make a bxx release to be >>>>>> applied there once and used in releases. ?We did this for the security >>>>>> fixes with Milestone 4/1.11. >>>>>> >>>>>> I've already added downloading of the jaxp, jaxws and jaf bundles to >>>>>> the IcedTea build; it's this process that resulted in this webrev. >>>>>> This has two advantages; we check all the zips/tarballs at the same >>>>>> point in the build (the JAXP and JAXWS builds are then pointed at the >>>>>> directory IcedTea uses for them) and we check the MD5 sums of the >>>>>> downloads or pre-existing zips. ?I don't know if the latter could be >>>>>> incorporated into the OpenJDK build somehow. ?At present, there's no >>>>>> guarantee that these zips are valid. >>>>>> >>>>>> The rules look like this: >>>>>> >>>>>> stamps/download-jaxp-drop.stamp: >>>>>> ? ? ? ?mkdir -p drops >>>>>> if USE_ALT_JAXP_DROP_ZIP >>>>>> ? ? ? ?ln -sf $(ALT_JAXP_DROP_ZIP) drops/$(JAXP_DROP_ZIP) >>>>>> endif >>>>>> ? ? ? ?if ! echo "$(JAXP_DROP_MD5SUM) ?drops/$(JAXP_DROP_ZIP)" \ >>>>>> ? ? ? ? ?| $(MD5SUM) --check ; \ >>>>>> ? ? ? ?then \ >>>>>> ? ? ? ? ?if [ -f drops/$(JAXP_DROP_ZIP) ] ; \ >>>>>> ? ? ? ? ?then \ >>>>>> ? ? ? ? ? ?mv drops/$(JAXP_DROP_ZIP) drops/$(JAXP_DROP_ZIP).old ; \ >>>>>> ? ? ? ? ?fi ; \ >>>>>> ? ? ? ? ?$(WGET) $(DROP_URL)/$(JAXP_DROP_ZIP) -O >>>>>> drops/$(JAXP_DROP_ZIP); \ >>>>>> ? ? ? ?fi ; >>>>>> ? ? ? ?mkdir -p stamps >>>>>> ? ?touch stamps/download-jaxp-drop.stamp >>>>>> >>>>>> ALT_JAXP_DROP_ZIP gets set if the user specifies >>>>>> --with-jaxp-drop-zip= to configure. ?WGET and MD5SUM are the >>>>>> respective binaries as located by configure and DROP_URL is the >>>>>> kenai.com URL as in the jaxws.properties and jaxp.properties files: >>>>>> >>>>>> DROP_URL = http://kenai.com/projects/jdk7-drops/downloads/download >>>>>> JAXWS_DROP_ZIP = jdk7-jaxws-2009_09_28.zip >>>>>> JAXWS_DROP_MD5SUM = debb949440c5a15ce999cfefbbc56526 >>>>>> JAF_DROP_ZIP = jdk7-jaf-2009_08_28.zip >>>>>> JAF_DROP_MD5SUM = eb8cb7a4a7f14e211fbe2354878a2472 >>>>>> JAXP_DROP_ZIP = jdk7-jaxp-2009_09_28.zip >>>>>> JAXP_DROP_MD5SUM = 8800970d03bab1fff188dcfafc346f5d >>>>> >>>>> Ah... so my checksum logic in the ant script will serve as a >>>>> double check. >>>>> >>>>> Unless you are changing the bundles and rebundling them... >>>>> nobody does that, ... ?do they??? >>>>> Ah, if they do, they would need to change the property value >>>>> holding the checksum. >>>>> >>>>> -kto >>>>> >>>>>> >>>>>>> -kto >>>>>>> >>>>>>>>>> The webrev for these changes is here: >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~andrew/drops/webrev.01/ >>>>>>>>>> >>>>>>>>>> I've committed this to IcedTea already. ?Does this look ok for >>>>>>>>>> build >>>>>>>>>> also? >>>>>>>> >>>>>>>> >>>>>> >>>>>> >>>>>> >>>> Kelly, >>>> >>>> Does all this mean we can somewhat simplify the list of forests on >>>> hg.o.j.n, by removing jdk7/{corba,jaxp,jaxws} and the corresponding -gate >>>> forests? >>>> >>>> -- Jon >>> >>> No. Not yet. In theory, what little logic is left in jaxp and jaxws >>> (corba has not changed), could be folded up into the top repo >>> or the jdk repo, and you could empty out jaxp and jaxws repos >>> entirely. ?But I had no plans to do so. >>> >>> What this does is leave a small set of ant scripts and a >>> Makefile over it, in these repos. The build logic is about all >>> that is there, and it will get the jaxp or jaxws source bundle drops, >>> and build them. This change will delete the original sources from >>> the repo, to guarantee they are no longer used. >>> The detailed management of those sources is completely under >>> the control of the jaxp and jaxws teams/projects. >>> >>> The selection of which drop bundles the jdk7 project uses is defined in >>> the jaxp/jaxp.properties and jaxws/jaxws.properties files. >>> >>> -kto >> >> Kelly, >> >> I was not referring to the jaxp/jaxws/corba repositories in each forest. >> ?It seemed like we had (mostly unused) forests for integrating >> jaxp,jaxws,corba stuff. Specifically: >> >> >> *jdk7/jaxp* ? ? jaxp >> build-dev at openjdk.java.net ? ? ?20 months ago ? RSS >> | zip >> | gz >> | bz2 >> >> *jdk7/jaxp-gate* ? jaxp >> (gate) ?build-dev at openjdk.java.net ? ? ?20 months ago ? RSS >> | zip >> | gz >> | bz2 >> >> *jdk7/jaxp-gate/corba* >> ? ? ?jaxp (gate) build-dev at openjdk.java.net ? ? ?20 months ago ? RSS >> | zip >> | gz >> | bz2 >> >> *jdk7/jaxp-gate/hotspot* >> ? ?jaxp (gate) >> build-dev at openjdk.java.net ? ? ?20 months ago ? RSS >> | zip >> | gz >> | bz2 >> >> *jdk7/jaxp-gate/jaxp* >> ? ? jaxp (gate) build-dev at openjdk.java.net ? ? ?20 months ago ? RSS >> | zip >> | gz >> | bz2 >> >> *jdk7/jaxp-gate/jaxws* >> ? ? ?jaxp (gate) build-dev at openjdk.java.net ? ? ?20 months ago ? RSS >> | zip >> | gz >> | bz2 >> >> *jdk7/jaxp-gate/jdk* jaxp >> (gate) ? ? build-dev at openjdk.java.net ? ? ?20 months ago ? RSS >> | zip >> | gz >> | bz2 >> >> *jdk7/jaxp-gate/langtools* >> ?jaxp (gate) >> build-dev at openjdk.java.net ? ? ?20 months ago ? RSS >> | zip >> | gz >> | >> bz2 >> >> *jdk7/jaxp/corba* >> jaxp build-dev at openjdk.java.net ? ? ?20 months ago ? RSS >> | zip >> | gz >> | bz2 >> >> *jdk7/jaxp/hotspot* jaxp >> ?build-dev at openjdk.java.net ? ? ?20 months ago ? RSS >> | zip >> | gz >> | bz2 >> >> *jdk7/jaxp/jaxp* ? jaxp >> build-dev at openjdk.java.net ? ? ?20 months ago ? RSS >> | zip >> | gz >> | bz2 >> >> *jdk7/jaxp/jaxws* >> jaxp build-dev at openjdk.java.net ? ? ?20 months ago ? RSS >> | zip >> | gz >> | bz2 >> >> *jdk7/jaxp/jdk* ? ? jaxp >> build-dev at openjdk.java.net ? ? ?20 months ago ? RSS >> | zip >> | gz >> | bz2 >> >> *jdk7/jaxp/langtools* >> ? ? jaxp build-dev at openjdk.java.net ? ? ?20 months ago ? RSS >> | zip >> | gz >> | bz2 >> >> *jdk7/jaxws* ? jaxws >> build-dev at openjdk.java.net ? ? ?20 months ago ? RSS >> | zip >> | gz >> | bz2 >> >> *jdk7/jaxws-gate* >> jaxws (gate) ?build-dev at openjdk.java.net ? ? ?20 months ago ? RSS >> | zip >> | gz >> | bz2 >> >> *jdk7/jaxws-gate/corba* >> ? ? jaxws (gate) >> build-dev at openjdk.java.net ? ? ?20 months ago ? RSS >> | zip >> | gz >> | bz2 >> >> *jdk7/jaxws-gate/hotspot* >> ? jaxws (gate) >> build-dev at openjdk.java.net ? ? ?20 months ago ? RSS >> | zip >> | gz >> | >> bz2 >> *jdk7/jaxws-gate/jaxp* >> ? ? ?jaxws (gate) build-dev at openjdk.java.net ? ? ?20 months ago ? RSS >> | zip >> | gz >> | bz2 >> >> *jdk7/jaxws-gate/jaxws* >> ? ? jaxws (gate) >> build-dev at openjdk.java.net ? ? ?20 months ago ? RSS >> | zip >> | gz >> | bz2 >> >> *jdk7/jaxws-gate/jdk* >> ? ? jaxws (gate) build-dev at openjdk.java.net ? ? ?20 months ago ? RSS >> | zip >> | gz >> | bz2 >> >> *jdk7/jaxws-gate/langtools* >> ? ? ? ? jaxws (gate) >> build-dev at openjdk.java.net ? ? ?20 months ago ? RSS >> | zip >> | gz >> | >> bz2 >> >> *jdk7/jaxws/corba* jaxws >> build-dev at openjdk.java.net ? ? ?20 months ago ? RSS >> | zip >> | gz >> | bz2 >> >> *jdk7/jaxws/hotspot* >> jaxws ? build-dev at openjdk.java.net ? ? ?20 months ago ? RSS >> | zip >> | gz >> | bz2 >> >> *jdk7/jaxws/jaxp* >> jaxws build-dev at openjdk.java.net ? ? ?20 months ago ? RSS >> | zip >> | gz >> | bz2 >> >> *jdk7/jaxws/jaxws* jaxws >> build-dev at openjdk.java.net ? ? ?20 months ago ? RSS >> | zip >> | gz >> | bz2 >> >> *jdk7/jaxws/jdk* ? jaxws >> build-dev at openjdk.java.net ? ? ?20 months ago ? RSS >> | zip >> | gz >> | bz2 >> >> *jdk7/jaxws/langtools* >> ? ? ?jaxws build-dev at openjdk.java.net ? ? ?20 months ago ? RSS >> | zip >> | gz >> | bz2 >> >> >> >> > > DOH! ?Sorry... > > Yes, these jaxp and jaxws forests can probably go away, we won't > be using them. > > The current plan is that jaxp/jaxws changes (new bundles) will go > through the TL forest. > > > -kto > I'm guilty of also thinking that Jonathan was referring to the jaxws and jaxp repositories per forest, rather than the specific forests. On that note, i18n could probably die too because apparently that team always use the swing forest for commits. It would be nice to one day get rid of the jaxp and jaxws trees too. I don't actually see why they were created as trees to begin with, given they've always been upstream and not a source of many commits. The one to actual split up would be jdk, as I can feel Mercurial struggling with it a bit already on jdk7. But I don't know how feasible that is, if at all. Maybe Jigsaw will help there. One thing that does worry me -- what happens when the jaxws or jaxp code needs security updates? -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From Joe.Darcy at Sun.COM Tue Oct 27 18:14:33 2009 From: Joe.Darcy at Sun.COM (Joseph D. Darcy) Date: Tue, 27 Oct 2009 18:14:33 -0700 Subject: 6856630: Restructure jaxp/jaxws repository In-Reply-To: <17c6771e0910271802n54a67e2cq4d547c592d817e94@mail.gmail.com> References: <4AB80C37.6000108@sun.com> <4ACF6ECC.7070407@sun.com> <17c6771e0910121014w6fcd23e9rf5d594173e594ec3@mail.gmail.com> <4AD36C3F.2010501@sun.com> <17c6771e0910121318m26e53de3gb3bbea964b70f4eb@mail.gmail.com> <4AE0DB80.90107@sun.com> <4AE0FDAB.1080305@sun.com> <4AE1D88C.5040408@sun.com> <4AE1DC34.30707@sun.com> <4AE1DF30.2030207@sun.com> <17c6771e0910271802n54a67e2cq4d547c592d817e94@mail.gmail.com> Message-ID: <4AE79AF9.5090206@sun.com> Andrew John Hughes wrote: > 2009/10/23 Kelly O'Hair : > >> Jonathan Gibbons wrote: >> >>> Kelly O'Hair wrote: >>> >>>> Jonathan Gibbons wrote: >>>> >>>>> Kelly O'Hair wrote: >>>>> [big snip] >> DOH! Sorry... >> >> Yes, these jaxp and jaxws forests can probably go away, we won't >> be using them. >> >> The current plan is that jaxp/jaxws changes (new bundles) will go >> through the TL forest. >> >> >> -kto >> >> > > I'm guilty of also thinking that Jonathan was referring to the jaxws > and jaxp repositories per forest, rather than the specific forests. > On that note, i18n could probably die too because apparently that team > always use the swing forest for commits. > > It would be nice to one day get rid of the jaxp and jaxws trees too. > I don't actually see why they were created as trees to begin with, > given they've always been upstream and not a source of many commits. > The one to actual split up would be jdk, as I can feel Mercurial > struggling with it a bit already on jdk7. But I don't know how > feasible that is, if at all. Maybe Jigsaw will help there. > > One thing that does worry me -- what happens when the jaxws or jaxp > code needs security updates? > Yes, the need to support security fixes was considered as part of this new delivery model. Ultimately a revised source bundle with the security fixes will need to be produced. Until then, the fixes can be represented as patches which are applied to the sources before the build. Kelly can speak to the implementation details of the patch mechanism. -Joe From Kelly.Ohair at Sun.COM Wed Oct 28 09:55:19 2009 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Wed, 28 Oct 2009 09:55:19 -0700 Subject: 6856630: Restructure jaxp/jaxws repository In-Reply-To: <4AE79AF9.5090206@sun.com> References: <4AB80C37.6000108@sun.com> <4ACF6ECC.7070407@sun.com> <17c6771e0910121014w6fcd23e9rf5d594173e594ec3@mail.gmail.com> <4AD36C3F.2010501@sun.com> <17c6771e0910121318m26e53de3gb3bbea964b70f4eb@mail.gmail.com> <4AE0DB80.90107@sun.com> <4AE0FDAB.1080305@sun.com> <4AE1D88C.5040408@sun.com> <4AE1DC34.30707@sun.com> <4AE1DF30.2030207@sun.com> <17c6771e0910271802n54a67e2cq4d547c592d817e94@mail.gmail.com> <4AE79AF9.5090206@sun.com> Message-ID: <4AE87777.6000001@sun.com> Joseph D. Darcy wrote: > Andrew John Hughes wrote: >> 2009/10/23 Kelly O'Hair : >> >>> Jonathan Gibbons wrote: >>> >>>> Kelly O'Hair wrote: >>>> >>>>> Jonathan Gibbons wrote: >>>>> >>>>>> Kelly O'Hair wrote: >>>>>> > > [big snip] >>> DOH! Sorry... >>> >>> Yes, these jaxp and jaxws forests can probably go away, we won't >>> be using them. >>> >>> The current plan is that jaxp/jaxws changes (new bundles) will go >>> through the TL forest. >>> >>> >>> -kto >>> >>> >> >> I'm guilty of also thinking that Jonathan was referring to the jaxws >> and jaxp repositories per forest, rather than the specific forests. >> On that note, i18n could probably die too because apparently that team >> always use the swing forest for commits. >> >> It would be nice to one day get rid of the jaxp and jaxws trees too. >> I don't actually see why they were created as trees to begin with, >> given they've always been upstream and not a source of many commits. >> The one to actual split up would be jdk, as I can feel Mercurial >> struggling with it a bit already on jdk7. But I don't know how >> feasible that is, if at all. Maybe Jigsaw will help there. >> >> One thing that does worry me -- what happens when the jaxws or jaxp >> code needs security updates? >> > > Yes, the need to support security fixes was considered as part of this > new delivery model. Ultimately a revised source bundle with the > security fixes will need to be produced. Until then, the fixes can be > represented as patches which are applied to the sources before the > build. Kelly can speak to the implementation details of the patch > mechanism. It's crude, but should serve in an emergency. See the patches/README. After a bundle is unzipped, all patches are applied, none right now. I hope that we can always just get updated bundles. Originally, the jaxp and jaxws (and corba) workspaces were created mainly as a place to move files from (trim) the original "j2se" workspace, and we had no idea where we were going with it all, except that we knew these were out of place in the j2se workspace, which became the jdk repository. The jaxp and jaxws repos could just go away someday, but I'll leave that for another day. ;^) Let's just call it evolution. ;^) -kto > > -Joe From Jonathan.Gibbons at Sun.COM Wed Oct 28 10:04:19 2009 From: Jonathan.Gibbons at Sun.COM (Jonathan Gibbons) Date: Wed, 28 Oct 2009 10:04:19 -0700 Subject: 6856630: Restructure jaxp/jaxws repository In-Reply-To: <4AE87777.6000001@sun.com> References: <4AB80C37.6000108@sun.com> <4ACF6ECC.7070407@sun.com> <17c6771e0910121014w6fcd23e9rf5d594173e594ec3@mail.gmail.com> <4AD36C3F.2010501@sun.com> <17c6771e0910121318m26e53de3gb3bbea964b70f4eb@mail.gmail.com> <4AE0DB80.90107@sun.com> <4AE0FDAB.1080305@sun.com> <4AE1D88C.5040408@sun.com> <4AE1DC34.30707@sun.com> <4AE1DF30.2030207@sun.com> <17c6771e0910271802n54a67e2cq4d547c592d817e94@mail.gmail.com> <4AE79AF9.5090206@sun.com> <4AE87777.6000001@sun.com> Message-ID: <4AE87993.7050306@sun.com> Kelly O'Hair wrote: > > > Joseph D. Darcy wrote: >> Andrew John Hughes wrote: >>> 2009/10/23 Kelly O'Hair : >>> >>>> Jonathan Gibbons wrote: >>>> >>>>> Kelly O'Hair wrote: >>>>> >>>>>> Jonathan Gibbons wrote: >>>>>> >>>>>>> Kelly O'Hair wrote: >>>>>>> >> >> [big snip] >>>> DOH! Sorry... >>>> >>>> Yes, these jaxp and jaxws forests can probably go away, we won't >>>> be using them. >>>> >>>> The current plan is that jaxp/jaxws changes (new bundles) will go >>>> through the TL forest. >>>> >>>> >>>> -kto >>>> >>>> >>> >>> I'm guilty of also thinking that Jonathan was referring to the jaxws >>> and jaxp repositories per forest, rather than the specific forests. >>> On that note, i18n could probably die too because apparently that team >>> always use the swing forest for commits. >>> >>> It would be nice to one day get rid of the jaxp and jaxws trees too. >>> I don't actually see why they were created as trees to begin with, >>> given they've always been upstream and not a source of many commits. >>> The one to actual split up would be jdk, as I can feel Mercurial >>> struggling with it a bit already on jdk7. But I don't know how >>> feasible that is, if at all. Maybe Jigsaw will help there. >>> >>> One thing that does worry me -- what happens when the jaxws or jaxp >>> code needs security updates? >>> >> >> Yes, the need to support security fixes was considered as part of >> this new delivery model. Ultimately a revised source bundle with the >> security fixes will need to be produced. Until then, the fixes can >> be represented as patches which are applied to the sources before the >> build. Kelly can speak to the implementation details of the patch >> mechanism. > > It's crude, but should serve in an emergency. See the patches/README. > After a bundle is unzipped, all patches are applied, none right now. > > I hope that we can always just get updated bundles. > > Originally, the jaxp and jaxws (and corba) workspaces were created > mainly as a place to move files from (trim) the original "j2se" > workspace, > and we had no idea where we were going with it all, except that we > knew these were out of place in the j2se workspace, which became > the jdk repository. > > The jaxp and jaxws repos could just go away someday, but I'll leave > that for another day. ;^) > > Let's just call it evolution. ;^) > > -kto > > >> >> -Joe Presumably, it would be "trivial" to move the files from the jaxp, jaxws repositories into the root repository such that the only perceivable difference would be where the hidden .hg files are. In other words, the current jaxp and jaxws repos simply become subdirectories of the root repository, with no other changes to the makefiles being required. -- Jon From Kelly.Ohair at Sun.COM Wed Oct 28 10:18:52 2009 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Wed, 28 Oct 2009 10:18:52 -0700 Subject: 6856630: Restructure jaxp/jaxws repository In-Reply-To: <4AE87993.7050306@sun.com> References: <4AB80C37.6000108@sun.com> <4ACF6ECC.7070407@sun.com> <17c6771e0910121014w6fcd23e9rf5d594173e594ec3@mail.gmail.com> <4AD36C3F.2010501@sun.com> <17c6771e0910121318m26e53de3gb3bbea964b70f4eb@mail.gmail.com> <4AE0DB80.90107@sun.com> <4AE0FDAB.1080305@sun.com> <4AE1D88C.5040408@sun.com> <4AE1DC34.30707@sun.com> <4AE1DF30.2030207@sun.com> <17c6771e0910271802n54a67e2cq4d547c592d817e94@mail.gmail.com> <4AE79AF9.5090206@sun.com> <4AE87777.6000001@sun.com> <4AE87993.7050306@sun.com> Message-ID: <4AE87CFC.7010206@sun.com> Jonathan Gibbons wrote: > Kelly O'Hair wrote: >> >> >> Joseph D. Darcy wrote: >>> Andrew John Hughes wrote: >>>> 2009/10/23 Kelly O'Hair : >>>> >>>>> Jonathan Gibbons wrote: >>>>> >>>>>> Kelly O'Hair wrote: >>>>>> >>>>>>> Jonathan Gibbons wrote: >>>>>>> >>>>>>>> Kelly O'Hair wrote: >>>>>>>> >>> >>> [big snip] >>>>> DOH! Sorry... >>>>> >>>>> Yes, these jaxp and jaxws forests can probably go away, we won't >>>>> be using them. >>>>> >>>>> The current plan is that jaxp/jaxws changes (new bundles) will go >>>>> through the TL forest. >>>>> >>>>> >>>>> -kto >>>>> >>>>> >>>> >>>> I'm guilty of also thinking that Jonathan was referring to the jaxws >>>> and jaxp repositories per forest, rather than the specific forests. >>>> On that note, i18n could probably die too because apparently that team >>>> always use the swing forest for commits. >>>> >>>> It would be nice to one day get rid of the jaxp and jaxws trees too. >>>> I don't actually see why they were created as trees to begin with, >>>> given they've always been upstream and not a source of many commits. >>>> The one to actual split up would be jdk, as I can feel Mercurial >>>> struggling with it a bit already on jdk7. But I don't know how >>>> feasible that is, if at all. Maybe Jigsaw will help there. >>>> >>>> One thing that does worry me -- what happens when the jaxws or jaxp >>>> code needs security updates? >>>> >>> >>> Yes, the need to support security fixes was considered as part of >>> this new delivery model. Ultimately a revised source bundle with the >>> security fixes will need to be produced. Until then, the fixes can >>> be represented as patches which are applied to the sources before the >>> build. Kelly can speak to the implementation details of the patch >>> mechanism. >> >> It's crude, but should serve in an emergency. See the patches/README. >> After a bundle is unzipped, all patches are applied, none right now. >> >> I hope that we can always just get updated bundles. >> >> Originally, the jaxp and jaxws (and corba) workspaces were created >> mainly as a place to move files from (trim) the original "j2se" >> workspace, >> and we had no idea where we were going with it all, except that we >> knew these were out of place in the j2se workspace, which became >> the jdk repository. >> >> The jaxp and jaxws repos could just go away someday, but I'll leave >> that for another day. ;^) >> >> Let's just call it evolution. ;^) >> >> -kto >> >> >>> >>> -Joe > Presumably, it would be "trivial" to move the files from the jaxp, jaxws > repositories into the root repository such that the only perceivable > difference would be where the hidden .hg files are. In other words, > the current jaxp and jaxws repos simply become subdirectories of the > root repository, with no other changes to the makefiles being required. > > -- Jon Correct. -kto From gnu_andrew at member.fsf.org Wed Oct 28 10:50:02 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Wed, 28 Oct 2009 17:50:02 +0000 Subject: 6856630: Restructure jaxp/jaxws repository In-Reply-To: <4AE87777.6000001@sun.com> References: <4AB80C37.6000108@sun.com> <17c6771e0910121318m26e53de3gb3bbea964b70f4eb@mail.gmail.com> <4AE0DB80.90107@sun.com> <4AE0FDAB.1080305@sun.com> <4AE1D88C.5040408@sun.com> <4AE1DC34.30707@sun.com> <4AE1DF30.2030207@sun.com> <17c6771e0910271802n54a67e2cq4d547c592d817e94@mail.gmail.com> <4AE79AF9.5090206@sun.com> <4AE87777.6000001@sun.com> Message-ID: <17c6771e0910281050j4d315cfcm231573f7b284b07f@mail.gmail.com> 2009/10/28 Kelly O'Hair : > > > Joseph D. Darcy wrote: >> >> Andrew John Hughes wrote: >>> >>> 2009/10/23 Kelly O'Hair : >>> >>>> >>>> Jonathan Gibbons wrote: >>>> >>>>> >>>>> Kelly O'Hair wrote: >>>>> >>>>>> >>>>>> Jonathan Gibbons wrote: >>>>>> >>>>>>> >>>>>>> Kelly O'Hair wrote: >>>>>>> >> >> [big snip] >>>> >>>> DOH! ?Sorry... >>>> >>>> Yes, these jaxp and jaxws forests can probably go away, we won't >>>> be using them. >>>> >>>> The current plan is that jaxp/jaxws changes (new bundles) will go >>>> through the TL forest. >>>> >>>> >>>> -kto >>>> >>>> >>> >>> I'm guilty of also thinking that Jonathan was referring to the jaxws >>> and jaxp repositories per forest, rather than the specific forests. >>> On that note, i18n could probably die too because apparently that team >>> always use the swing forest for commits. >>> >>> It would be nice to one day get rid of the jaxp and jaxws trees too. >>> I don't actually see why they were created as trees to begin with, >>> given they've always been upstream and not a source of many commits. >>> The one to actual split up would be jdk, as I can feel Mercurial >>> struggling with it a bit already on jdk7. ?But I don't know how >>> feasible that is, if at all. ?Maybe Jigsaw will help there. >>> >>> One thing that does worry me -- what happens when the jaxws or jaxp >>> code needs security updates? >>> >> >> Yes, the need to support security fixes was considered as part of this new >> delivery model. ?Ultimately a revised source bundle with the security fixes >> will need to be produced. ?Until then, the fixes can be represented as >> patches which are applied to the sources before the build. ?Kelly can speak >> to the implementation details of the patch mechanism. > > It's crude, but should serve in an emergency. See the patches/README. > After a bundle is unzipped, all patches are applied, none right now. > > I hope that we can always just get updated bundles. > > Originally, the jaxp and jaxws (and corba) workspaces were created > mainly as a place to move files from (trim) the original "j2se" workspace, > and we had no idea where we were going with it all, except that we > knew these were out of place in the j2se workspace, which became > the jdk repository. > > The jaxp and jaxws repos could just go away someday, but I'll leave > that for another day. ;^) > > Let's just call it evolution. ;^) > Oh yes, I'm not saying right now -- something for JDK8 perhaps? :) Certainly, the trivial change Jonathan mentions could be done when creating the jdk8 forests. It would be nice to share the common stuff between jaxp and jaxws too, and I suspect that may be easier if they are in the same toplevel openjdk repository. > -kto > > >> >> -Joe > -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From gnu_andrew at member.fsf.org Wed Oct 28 11:37:03 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Wed, 28 Oct 2009 18:37:03 +0000 Subject: 6856630: Restructure jaxp/jaxws repository In-Reply-To: <17c6771e0910281050j4d315cfcm231573f7b284b07f@mail.gmail.com> References: <4AB80C37.6000108@sun.com> <4AE0DB80.90107@sun.com> <4AE0FDAB.1080305@sun.com> <4AE1D88C.5040408@sun.com> <4AE1DC34.30707@sun.com> <4AE1DF30.2030207@sun.com> <17c6771e0910271802n54a67e2cq4d547c592d817e94@mail.gmail.com> <4AE79AF9.5090206@sun.com> <4AE87777.6000001@sun.com> <17c6771e0910281050j4d315cfcm231573f7b284b07f@mail.gmail.com> Message-ID: <17c6771e0910281137k38935208j606eb869345ada59@mail.gmail.com> 2009/10/28 Andrew John Hughes : > 2009/10/28 Kelly O'Hair : >> >> >> Joseph D. Darcy wrote: >>> >>> Andrew John Hughes wrote: >>>> >>>> 2009/10/23 Kelly O'Hair : >>>> >>>>> >>>>> Jonathan Gibbons wrote: >>>>> >>>>>> >>>>>> Kelly O'Hair wrote: >>>>>> >>>>>>> >>>>>>> Jonathan Gibbons wrote: >>>>>>> >>>>>>>> >>>>>>>> Kelly O'Hair wrote: >>>>>>>> >>> >>> [big snip] >>>>> >>>>> DOH! ?Sorry... >>>>> >>>>> Yes, these jaxp and jaxws forests can probably go away, we won't >>>>> be using them. >>>>> >>>>> The current plan is that jaxp/jaxws changes (new bundles) will go >>>>> through the TL forest. >>>>> >>>>> >>>>> -kto >>>>> >>>>> >>>> >>>> I'm guilty of also thinking that Jonathan was referring to the jaxws >>>> and jaxp repositories per forest, rather than the specific forests. >>>> On that note, i18n could probably die too because apparently that team >>>> always use the swing forest for commits. >>>> >>>> It would be nice to one day get rid of the jaxp and jaxws trees too. >>>> I don't actually see why they were created as trees to begin with, >>>> given they've always been upstream and not a source of many commits. >>>> The one to actual split up would be jdk, as I can feel Mercurial >>>> struggling with it a bit already on jdk7. ?But I don't know how >>>> feasible that is, if at all. ?Maybe Jigsaw will help there. >>>> >>>> One thing that does worry me -- what happens when the jaxws or jaxp >>>> code needs security updates? >>>> >>> >>> Yes, the need to support security fixes was considered as part of this new >>> delivery model. ?Ultimately a revised source bundle with the security fixes >>> will need to be produced. ?Until then, the fixes can be represented as >>> patches which are applied to the sources before the build. ?Kelly can speak >>> to the implementation details of the patch mechanism. >> >> It's crude, but should serve in an emergency. See the patches/README. >> After a bundle is unzipped, all patches are applied, none right now. >> >> I hope that we can always just get updated bundles. >> >> Originally, the jaxp and jaxws (and corba) workspaces were created >> mainly as a place to move files from (trim) the original "j2se" workspace, >> and we had no idea where we were going with it all, except that we >> knew these were out of place in the j2se workspace, which became >> the jdk repository. >> >> The jaxp and jaxws repos could just go away someday, but I'll leave >> that for another day. ;^) >> >> Let's just call it evolution. ;^) >> > > Oh yes, I'm not saying right now -- something for JDK8 perhaps? :) > Certainly, the trivial change Jonathan mentions could be done when > creating the jdk8 forests. > It would be nice to share the common stuff between jaxp and jaxws too, > and I suspect that may be easier if they are in the same toplevel > openjdk repository. > >> -kto >> >> >>> >>> -Joe >> > > > > -- > Andrew :-) > > Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > Support Free Java! > Contribute to GNU Classpath and the OpenJDK > http://www.gnu.org/software/classpath > http://openjdk.java.net > > PGP Key: 94EFD9D8 (http://subkeys.pgp.net) > Fingerprint: F8EF F1EA 401E 2E60 15FA ?7927 142C 2591 94EF D9D8 > I was just testing a webrev for the ALT_DROPS_DIR change on tl and hit this: -jaxp_src-url-bundle: [echo] Downloading from https://jaxp.dev.java.net/files/documents/913/144160/jdk7-jaxp-m5.zip [mkdir] Created dir: /mnt/builder/tl/jaxp/drop/bundles [get] Getting: https://jaxp.dev.java.net/files/documents/913/144160/jdk7-jaxp-m5.zip [get] To: /mnt/builder/tl/jaxp/drop/bundles/jdk7-jaxp-m5.zip.temp [get] Error getting https://jaxp.dev.java.net/files/documents/913/144160/jdk7-jaxp-m5.zip to /mnt/builder/tl/jaxp/drop/bundles/jdk7-jaxp-m5.zip.temp BUILD FAILED javax.net.ssl.SSLException: java.lang.RuntimeException: Unexpected error: java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty at sun.security.ssl.Alerts.getSSLException(Alerts.java:208) at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1627) at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1590) at sun.security.ssl.SSLSocketImpl.handleException(SSLSocketImpl.java:1573) at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1166) at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1143) at sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:423) at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:185) at sun.net.www.protocol.https.HttpsURLConnectionImpl.connect(HttpsURLConnectionImpl.java:153) at org.apache.tools.ant.taskdefs.Get.doGet(Get.java:145) at org.apache.tools.ant.taskdefs.Get.execute(Get.java:78) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288) at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:616) at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106) at org.apache.tools.ant.Task.perform(Task.java:348) at org.apache.tools.ant.Target.execute(Target.java:357) at org.apache.tools.ant.Target.performTasks(Target.java:385) at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1337) at org.apache.tools.ant.Project.executeTarget(Project.java:1306) at org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41) at org.apache.tools.ant.Project.executeTargets(Project.java:1189) at org.apache.tools.ant.Main.runBuild(Main.java:758) at org.apache.tools.ant.Main.startAnt(Main.java:217) at org.apache.tools.ant.launch.Launcher.run(Launcher.java:257) at org.apache.tools.ant.launch.Launcher.main(Launcher.java:104) Firstly, I obviously have to wonder why it's still downloading, but this seems to be caused by the new URL. -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From gnu_andrew at member.fsf.org Wed Oct 28 11:44:38 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Wed, 28 Oct 2009 18:44:38 +0000 Subject: 6856630: Restructure jaxp/jaxws repository In-Reply-To: <17c6771e0910281137k38935208j606eb869345ada59@mail.gmail.com> References: <4AB80C37.6000108@sun.com> <4AE0FDAB.1080305@sun.com> <4AE1D88C.5040408@sun.com> <4AE1DC34.30707@sun.com> <4AE1DF30.2030207@sun.com> <17c6771e0910271802n54a67e2cq4d547c592d817e94@mail.gmail.com> <4AE79AF9.5090206@sun.com> <4AE87777.6000001@sun.com> <17c6771e0910281050j4d315cfcm231573f7b284b07f@mail.gmail.com> <17c6771e0910281137k38935208j606eb869345ada59@mail.gmail.com> Message-ID: <17c6771e0910281144n78c8d643sf608d1ff2804cac0@mail.gmail.com> 2009/10/28 Andrew John Hughes : > 2009/10/28 Andrew John Hughes : >> 2009/10/28 Kelly O'Hair : >>> >>> >>> Joseph D. Darcy wrote: >>>> >>>> Andrew John Hughes wrote: >>>>> >>>>> 2009/10/23 Kelly O'Hair : >>>>> >>>>>> >>>>>> Jonathan Gibbons wrote: >>>>>> >>>>>>> >>>>>>> Kelly O'Hair wrote: >>>>>>> >>>>>>>> >>>>>>>> Jonathan Gibbons wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> Kelly O'Hair wrote: >>>>>>>>> >>>> >>>> [big snip] >>>>>> >>>>>> DOH! ?Sorry... >>>>>> >>>>>> Yes, these jaxp and jaxws forests can probably go away, we won't >>>>>> be using them. >>>>>> >>>>>> The current plan is that jaxp/jaxws changes (new bundles) will go >>>>>> through the TL forest. >>>>>> >>>>>> >>>>>> -kto >>>>>> >>>>>> >>>>> >>>>> I'm guilty of also thinking that Jonathan was referring to the jaxws >>>>> and jaxp repositories per forest, rather than the specific forests. >>>>> On that note, i18n could probably die too because apparently that team >>>>> always use the swing forest for commits. >>>>> >>>>> It would be nice to one day get rid of the jaxp and jaxws trees too. >>>>> I don't actually see why they were created as trees to begin with, >>>>> given they've always been upstream and not a source of many commits. >>>>> The one to actual split up would be jdk, as I can feel Mercurial >>>>> struggling with it a bit already on jdk7. ?But I don't know how >>>>> feasible that is, if at all. ?Maybe Jigsaw will help there. >>>>> >>>>> One thing that does worry me -- what happens when the jaxws or jaxp >>>>> code needs security updates? >>>>> >>>> >>>> Yes, the need to support security fixes was considered as part of this new >>>> delivery model. ?Ultimately a revised source bundle with the security fixes >>>> will need to be produced. ?Until then, the fixes can be represented as >>>> patches which are applied to the sources before the build. ?Kelly can speak >>>> to the implementation details of the patch mechanism. >>> >>> It's crude, but should serve in an emergency. See the patches/README. >>> After a bundle is unzipped, all patches are applied, none right now. >>> >>> I hope that we can always just get updated bundles. >>> >>> Originally, the jaxp and jaxws (and corba) workspaces were created >>> mainly as a place to move files from (trim) the original "j2se" workspace, >>> and we had no idea where we were going with it all, except that we >>> knew these were out of place in the j2se workspace, which became >>> the jdk repository. >>> >>> The jaxp and jaxws repos could just go away someday, but I'll leave >>> that for another day. ;^) >>> >>> Let's just call it evolution. ;^) >>> >> >> Oh yes, I'm not saying right now -- something for JDK8 perhaps? :) >> Certainly, the trivial change Jonathan mentions could be done when >> creating the jdk8 forests. >> It would be nice to share the common stuff between jaxp and jaxws too, >> and I suspect that may be easier if they are in the same toplevel >> openjdk repository. >> >>> -kto >>> >>> >>>> >>>> -Joe >>> >> >> >> >> -- >> Andrew :-) >> >> Free Java Software Engineer >> Red Hat, Inc. (http://www.redhat.com) >> >> Support Free Java! >> Contribute to GNU Classpath and the OpenJDK >> http://www.gnu.org/software/classpath >> http://openjdk.java.net >> >> PGP Key: 94EFD9D8 (http://subkeys.pgp.net) >> Fingerprint: F8EF F1EA 401E 2E60 15FA ?7927 142C 2591 94EF D9D8 >> > > I was just testing a webrev for the ALT_DROPS_DIR change on tl and hit this: > > -jaxp_src-url-bundle: > ? ? [echo] Downloading from > https://jaxp.dev.java.net/files/documents/913/144160/jdk7-jaxp-m5.zip > ? ?[mkdir] Created dir: /mnt/builder/tl/jaxp/drop/bundles > ? ? ?[get] Getting: > https://jaxp.dev.java.net/files/documents/913/144160/jdk7-jaxp-m5.zip > ? ? ?[get] To: /mnt/builder/tl/jaxp/drop/bundles/jdk7-jaxp-m5.zip.temp > ? ? ?[get] Error getting > https://jaxp.dev.java.net/files/documents/913/144160/jdk7-jaxp-m5.zip > to /mnt/builder/tl/jaxp/drop/bundles/jdk7-jaxp-m5.zip.temp > > BUILD FAILED > javax.net.ssl.SSLException: java.lang.RuntimeException: Unexpected > error: java.security.InvalidAlgorithmParameterException: the > trustAnchors parameter must be non-empty > ? ? ? ?at sun.security.ssl.Alerts.getSSLException(Alerts.java:208) > ? ? ? ?at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1627) > ? ? ? ?at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1590) > ? ? ? ?at sun.security.ssl.SSLSocketImpl.handleException(SSLSocketImpl.java:1573) > ? ? ? ?at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1166) > ? ? ? ?at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1143) > ? ? ? ?at sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:423) > ? ? ? ?at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:185) > ? ? ? ?at sun.net.www.protocol.https.HttpsURLConnectionImpl.connect(HttpsURLConnectionImpl.java:153) > ? ? ? ?at org.apache.tools.ant.taskdefs.Get.doGet(Get.java:145) > ? ? ? ?at org.apache.tools.ant.taskdefs.Get.execute(Get.java:78) > ? ? ? ?at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288) > ? ? ? ?at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source) > ? ? ? ?at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > ? ? ? ?at java.lang.reflect.Method.invoke(Method.java:616) > ? ? ? ?at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106) > ? ? ? ?at org.apache.tools.ant.Task.perform(Task.java:348) > ? ? ? ?at org.apache.tools.ant.Target.execute(Target.java:357) > ? ? ? ?at org.apache.tools.ant.Target.performTasks(Target.java:385) > ? ? ? ?at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1337) > ? ? ? ?at org.apache.tools.ant.Project.executeTarget(Project.java:1306) > ? ? ? ?at org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41) > ? ? ? ?at org.apache.tools.ant.Project.executeTargets(Project.java:1189) > ? ? ? ?at org.apache.tools.ant.Main.runBuild(Main.java:758) > ? ? ? ?at org.apache.tools.ant.Main.startAnt(Main.java:217) > ? ? ? ?at org.apache.tools.ant.launch.Launcher.run(Launcher.java:257) > ? ? ? ?at org.apache.tools.ant.launch.Launcher.main(Launcher.java:104) > > Firstly, I obviously have to wonder why it's still downloading, but > this seems to be caused by the new URL. > -- > Andrew :-) > > Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > Support Free Java! > Contribute to GNU Classpath and the OpenJDK > http://www.gnu.org/software/classpath > http://openjdk.java.net > > PGP Key: 94EFD9D8 (http://subkeys.pgp.net) > Fingerprint: F8EF F1EA 401E 2E60 15FA ?7927 142C 2591 94EF D9D8 > That's with IcedTea6 1.6.1. The same happens with my build of OpenJDK6 from earlier today. The drops.dir issue was obviously because the tarball has changed, so shows that it catches such a change. -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From Jonathan.Gibbons at Sun.COM Wed Oct 28 11:45:55 2009 From: Jonathan.Gibbons at Sun.COM (Jonathan Gibbons) Date: Wed, 28 Oct 2009 11:45:55 -0700 Subject: 6856630: Restructure jaxp/jaxws repository In-Reply-To: <17c6771e0910281137k38935208j606eb869345ada59@mail.gmail.com> References: <4AB80C37.6000108@sun.com> <4AE0DB80.90107@sun.com> <4AE0FDAB.1080305@sun.com> <4AE1D88C.5040408@sun.com> <4AE1DC34.30707@sun.com> <4AE1DF30.2030207@sun.com> <17c6771e0910271802n54a67e2cq4d547c592d817e94@mail.gmail.com> <4AE79AF9.5090206@sun.com> <4AE87777.6000001@sun.com> <17c6771e0910281050j4d315cfcm231573f7b284b07f@mail.gmail.com> <17c6771e0910281137k38935208j606eb869345ada59@mail.gmail.com> Message-ID: <4AE89163.3090905@sun.com> Andrew John Hughes wrote: > 2009/10/28 Andrew John Hughes : > >> 2009/10/28 Kelly O'Hair : >> >>> Joseph D. Darcy wrote: >>> >>>> Andrew John Hughes wrote: >>>> >>>>> 2009/10/23 Kelly O'Hair : >>>>> >>>>> >>>>>> Jonathan Gibbons wrote: >>>>>> >>>>>> >>>>>>> Kelly O'Hair wrote: >>>>>>> >>>>>>> >>>>>>>> Jonathan Gibbons wrote: >>>>>>>> >>>>>>>> >>>>>>>>> Kelly O'Hair wrote: >>>>>>>>> >>>>>>>>> >>>> [big snip] >>>> >>>>>> DOH! Sorry... >>>>>> >>>>>> Yes, these jaxp and jaxws forests can probably go away, we won't >>>>>> be using them. >>>>>> >>>>>> The current plan is that jaxp/jaxws changes (new bundles) will go >>>>>> through the TL forest. >>>>>> >>>>>> >>>>>> -kto >>>>>> >>>>>> >>>>>> >>>>> I'm guilty of also thinking that Jonathan was referring to the jaxws >>>>> and jaxp repositories per forest, rather than the specific forests. >>>>> On that note, i18n could probably die too because apparently that team >>>>> always use the swing forest for commits. >>>>> >>>>> It would be nice to one day get rid of the jaxp and jaxws trees too. >>>>> I don't actually see why they were created as trees to begin with, >>>>> given they've always been upstream and not a source of many commits. >>>>> The one to actual split up would be jdk, as I can feel Mercurial >>>>> struggling with it a bit already on jdk7. But I don't know how >>>>> feasible that is, if at all. Maybe Jigsaw will help there. >>>>> >>>>> One thing that does worry me -- what happens when the jaxws or jaxp >>>>> code needs security updates? >>>>> >>>>> >>>> Yes, the need to support security fixes was considered as part of this new >>>> delivery model. Ultimately a revised source bundle with the security fixes >>>> will need to be produced. Until then, the fixes can be represented as >>>> patches which are applied to the sources before the build. Kelly can speak >>>> to the implementation details of the patch mechanism. >>>> >>> It's crude, but should serve in an emergency. See the patches/README. >>> After a bundle is unzipped, all patches are applied, none right now. >>> >>> I hope that we can always just get updated bundles. >>> >>> Originally, the jaxp and jaxws (and corba) workspaces were created >>> mainly as a place to move files from (trim) the original "j2se" workspace, >>> and we had no idea where we were going with it all, except that we >>> knew these were out of place in the j2se workspace, which became >>> the jdk repository. >>> >>> The jaxp and jaxws repos could just go away someday, but I'll leave >>> that for another day. ;^) >>> >>> Let's just call it evolution. ;^) >>> >>> >> Oh yes, I'm not saying right now -- something for JDK8 perhaps? :) >> Certainly, the trivial change Jonathan mentions could be done when >> creating the jdk8 forests. >> It would be nice to share the common stuff between jaxp and jaxws too, >> and I suspect that may be easier if they are in the same toplevel >> openjdk repository. >> >> >>> -kto >>> >>> >>> >>>> -Joe >>>> >> >> -- >> Andrew :-) >> >> Free Java Software Engineer >> Red Hat, Inc. (http://www.redhat.com) >> >> Support Free Java! >> Contribute to GNU Classpath and the OpenJDK >> http://www.gnu.org/software/classpath >> http://openjdk.java.net >> >> PGP Key: 94EFD9D8 (http://subkeys.pgp.net) >> Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 >> >> > > I was just testing a webrev for the ALT_DROPS_DIR change on tl and hit this: > > -jaxp_src-url-bundle: > [echo] Downloading from > https://jaxp.dev.java.net/files/documents/913/144160/jdk7-jaxp-m5.zip > [mkdir] Created dir: /mnt/builder/tl/jaxp/drop/bundles > [get] Getting: > https://jaxp.dev.java.net/files/documents/913/144160/jdk7-jaxp-m5.zip > [get] To: /mnt/builder/tl/jaxp/drop/bundles/jdk7-jaxp-m5.zip.temp > [get] Error getting > https://jaxp.dev.java.net/files/documents/913/144160/jdk7-jaxp-m5.zip > to /mnt/builder/tl/jaxp/drop/bundles/jdk7-jaxp-m5.zip.temp > > BUILD FAILED > javax.net.ssl.SSLException: java.lang.RuntimeException: Unexpected > error: java.security.InvalidAlgorithmParameterException: the > trustAnchors parameter must be non-empty > at sun.security.ssl.Alerts.getSSLException(Alerts.java:208) > at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1627) > at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1590) > at sun.security.ssl.SSLSocketImpl.handleException(SSLSocketImpl.java:1573) > at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1166) > at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1143) > at sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:423) > at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:185) > at sun.net.www.protocol.https.HttpsURLConnectionImpl.connect(HttpsURLConnectionImpl.java:153) > at org.apache.tools.ant.taskdefs.Get.doGet(Get.java:145) > at org.apache.tools.ant.taskdefs.Get.execute(Get.java:78) > at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288) > at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:616) > at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106) > at org.apache.tools.ant.Task.perform(Task.java:348) > at org.apache.tools.ant.Target.execute(Target.java:357) > at org.apache.tools.ant.Target.performTasks(Target.java:385) > at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1337) > at org.apache.tools.ant.Project.executeTarget(Project.java:1306) > at org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41) > at org.apache.tools.ant.Project.executeTargets(Project.java:1189) > at org.apache.tools.ant.Main.runBuild(Main.java:758) > at org.apache.tools.ant.Main.startAnt(Main.java:217) > at org.apache.tools.ant.launch.Launcher.run(Launcher.java:257) > at org.apache.tools.ant.launch.Launcher.main(Launcher.java:104) > > Firstly, I obviously have to wonder why it's still downloading, but > this seems to be caused by the new URL. > I'm curious: is there an option to prevent downloading the source bundle? It seems to me that if you think you've set up the build to not need to download anything, it would be nice if the build failed if the bits were not available, rather than have it try and find the bits. Automatic downloads sound bad, IMO. -- Jon -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/build-dev/attachments/20091028/d4bfea72/attachment.html From gnu_andrew at member.fsf.org Wed Oct 28 12:14:44 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Wed, 28 Oct 2009 19:14:44 +0000 Subject: 6856630: Restructure jaxp/jaxws repository In-Reply-To: <4AE89163.3090905@sun.com> References: <4AB80C37.6000108@sun.com> <4AE1D88C.5040408@sun.com> <4AE1DC34.30707@sun.com> <4AE1DF30.2030207@sun.com> <17c6771e0910271802n54a67e2cq4d547c592d817e94@mail.gmail.com> <4AE79AF9.5090206@sun.com> <4AE87777.6000001@sun.com> <17c6771e0910281050j4d315cfcm231573f7b284b07f@mail.gmail.com> <17c6771e0910281137k38935208j606eb869345ada59@mail.gmail.com> <4AE89163.3090905@sun.com> Message-ID: <17c6771e0910281214x60d5c44bx33524d7729c1b49f@mail.gmail.com> 2009/10/28 Jonathan Gibbons : > Andrew John Hughes wrote: > > 2009/10/28 Andrew John Hughes : > > > 2009/10/28 Kelly O'Hair : > > > Joseph D. Darcy wrote: > > > Andrew John Hughes wrote: > > > 2009/10/23 Kelly O'Hair : > > > > Jonathan Gibbons wrote: > > > > Kelly O'Hair wrote: > > > > Jonathan Gibbons wrote: > > > > Kelly O'Hair wrote: > > > > [big snip] > > > DOH! ?Sorry... > > Yes, these jaxp and jaxws forests can probably go away, we won't > be using them. > > The current plan is that jaxp/jaxws changes (new bundles) will go > through the TL forest. > > > -kto > > > > > I'm guilty of also thinking that Jonathan was referring to the jaxws > and jaxp repositories per forest, rather than the specific forests. > On that note, i18n could probably die too because apparently that team > always use the swing forest for commits. > > It would be nice to one day get rid of the jaxp and jaxws trees too. > I don't actually see why they were created as trees to begin with, > given they've always been upstream and not a source of many commits. > The one to actual split up would be jdk, as I can feel Mercurial > struggling with it a bit already on jdk7. ?But I don't know how > feasible that is, if at all. ?Maybe Jigsaw will help there. > > One thing that does worry me -- what happens when the jaxws or jaxp > code needs security updates? > > > > Yes, the need to support security fixes was considered as part of this new > delivery model. ?Ultimately a revised source bundle with the security fixes > will need to be produced. ?Until then, the fixes can be represented as > patches which are applied to the sources before the build. ?Kelly can speak > to the implementation details of the patch mechanism. > > > It's crude, but should serve in an emergency. See the patches/README. > After a bundle is unzipped, all patches are applied, none right now. > > I hope that we can always just get updated bundles. > > Originally, the jaxp and jaxws (and corba) workspaces were created > mainly as a place to move files from (trim) the original "j2se" workspace, > and we had no idea where we were going with it all, except that we > knew these were out of place in the j2se workspace, which became > the jdk repository. > > The jaxp and jaxws repos could just go away someday, but I'll leave > that for another day. ;^) > > Let's just call it evolution. ;^) > > > > Oh yes, I'm not saying right now -- something for JDK8 perhaps? :) > Certainly, the trivial change Jonathan mentions could be done when > creating the jdk8 forests. > It would be nice to share the common stuff between jaxp and jaxws too, > and I suspect that may be easier if they are in the same toplevel > openjdk repository. > > > > -kto > > > > > -Joe > > > -- > Andrew :-) > > Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > Support Free Java! > Contribute to GNU Classpath and the OpenJDK > http://www.gnu.org/software/classpath > http://openjdk.java.net > > PGP Key: 94EFD9D8 (http://subkeys.pgp.net) > Fingerprint: F8EF F1EA 401E 2E60 15FA ?7927 142C 2591 94EF D9D8 > > > > I was just testing a webrev for the ALT_DROPS_DIR change on tl and hit this: > > -jaxp_src-url-bundle: > [echo] Downloading from > https://jaxp.dev.java.net/files/documents/913/144160/jdk7-jaxp-m5.zip > [mkdir] Created dir: /mnt/builder/tl/jaxp/drop/bundles > [get] Getting: > https://jaxp.dev.java.net/files/documents/913/144160/jdk7-jaxp-m5.zip > [get] To: /mnt/builder/tl/jaxp/drop/bundles/jdk7-jaxp-m5.zip.temp > [get] Error getting > https://jaxp.dev.java.net/files/documents/913/144160/jdk7-jaxp-m5.zip > to /mnt/builder/tl/jaxp/drop/bundles/jdk7-jaxp-m5.zip.temp > > BUILD FAILED > javax.net.ssl.SSLException: java.lang.RuntimeException: Unexpected > error: java.security.InvalidAlgorithmParameterException: the > trustAnchors parameter must be non-empty > at sun.security.ssl.Alerts.getSSLException(Alerts.java:208) > at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1627) > at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1590) > at sun.security.ssl.SSLSocketImpl.handleException(SSLSocketImpl.java:1573) > at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1166) > at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1143) > at > sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:423) > at > sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:185) > at > sun.net.www.protocol.https.HttpsURLConnectionImpl.connect(HttpsURLConnectionImpl.java:153) > at org.apache.tools.ant.taskdefs.Get.doGet(Get.java:145) > at org.apache.tools.ant.taskdefs.Get.execute(Get.java:78) > at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288) > at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:616) > at > org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106) > at org.apache.tools.ant.Task.perform(Task.java:348) > at org.apache.tools.ant.Target.execute(Target.java:357) > at org.apache.tools.ant.Target.performTasks(Target.java:385) > at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1337) > at org.apache.tools.ant.Project.executeTarget(Project.java:1306) > at > org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41) > at org.apache.tools.ant.Project.executeTargets(Project.java:1189) > at org.apache.tools.ant.Main.runBuild(Main.java:758) > at org.apache.tools.ant.Main.startAnt(Main.java:217) > at org.apache.tools.ant.launch.Launcher.run(Launcher.java:257) > at org.apache.tools.ant.launch.Launcher.main(Launcher.java:104) > > Firstly, I obviously have to wonder why it's still downloading, but > this seems to be caused by the new URL. > > > I'm curious: is there an option to prevent downloading the source bundle? > It seems to me that if you think you've set up the build to not need to > download anything, it would be nice if the build failed if the bits were not > available, rather than have it try and find the bits.? Automatic downloads > sound bad, IMO. > > -- Jon > It would be a nice additional option, I don't think it already exists. At present, it happens accidentally in that the JDK crashes instead... :( This is interesting: /mnt/builder/tl/jaxws/build/xml_generated/build-drop-jaxws_src.xml:117: Checksum on file /mnt/builder/tl/jaxws/drop/bundles/jdk7-jaxws-2009_09_28.zip is debb949440c5a15ce999cfefbbc56526, not f5010ebf636db9f465a61a7a74944543 Did the jaxws bundle change without being renamed? -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From Kelly.Ohair at Sun.COM Wed Oct 28 12:30:38 2009 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Wed, 28 Oct 2009 12:30:38 -0700 Subject: 6856630: Restructure jaxp/jaxws repository In-Reply-To: <17c6771e0910281214x60d5c44bx33524d7729c1b49f@mail.gmail.com> References: <4AB80C37.6000108@sun.com> <4AE1D88C.5040408@sun.com> <4AE1DC34.30707@sun.com> <4AE1DF30.2030207@sun.com> <17c6771e0910271802n54a67e2cq4d547c592d817e94@mail.gmail.com> <4AE79AF9.5090206@sun.com> <4AE87777.6000001@sun.com> <17c6771e0910281050j4d315cfcm231573f7b284b07f@mail.gmail.com> <17c6771e0910281137k38935208j606eb869345ada59@mail.gmail.com> <4AE89163.3090905@sun.com> <17c6771e0910281214x60d5c44bx33524d7729c1b49f@mail.gmail.com> Message-ID: <4AE89BDE.4010008@sun.com> Andrew John Hughes wrote: > 2009/10/28 Jonathan Gibbons : >> Andrew John Hughes wrote: >> >> 2009/10/28 Andrew John Hughes : >> >> >> 2009/10/28 Kelly O'Hair : >> >> >> Joseph D. Darcy wrote: >> >> >> Andrew John Hughes wrote: >> >> >> 2009/10/23 Kelly O'Hair : >> >> >> >> Jonathan Gibbons wrote: >> >> >> >> Kelly O'Hair wrote: >> >> >> >> Jonathan Gibbons wrote: >> >> >> >> Kelly O'Hair wrote: >> >> >> >> [big snip] >> >> >> DOH! Sorry... >> >> Yes, these jaxp and jaxws forests can probably go away, we won't >> be using them. >> >> The current plan is that jaxp/jaxws changes (new bundles) will go >> through the TL forest. >> >> >> -kto >> >> >> >> >> I'm guilty of also thinking that Jonathan was referring to the jaxws >> and jaxp repositories per forest, rather than the specific forests. >> On that note, i18n could probably die too because apparently that team >> always use the swing forest for commits. >> >> It would be nice to one day get rid of the jaxp and jaxws trees too. >> I don't actually see why they were created as trees to begin with, >> given they've always been upstream and not a source of many commits. >> The one to actual split up would be jdk, as I can feel Mercurial >> struggling with it a bit already on jdk7. But I don't know how >> feasible that is, if at all. Maybe Jigsaw will help there. >> >> One thing that does worry me -- what happens when the jaxws or jaxp >> code needs security updates? >> >> >> >> Yes, the need to support security fixes was considered as part of this new >> delivery model. Ultimately a revised source bundle with the security fixes >> will need to be produced. Until then, the fixes can be represented as >> patches which are applied to the sources before the build. Kelly can speak >> to the implementation details of the patch mechanism. >> >> >> It's crude, but should serve in an emergency. See the patches/README. >> After a bundle is unzipped, all patches are applied, none right now. >> >> I hope that we can always just get updated bundles. >> >> Originally, the jaxp and jaxws (and corba) workspaces were created >> mainly as a place to move files from (trim) the original "j2se" workspace, >> and we had no idea where we were going with it all, except that we >> knew these were out of place in the j2se workspace, which became >> the jdk repository. >> >> The jaxp and jaxws repos could just go away someday, but I'll leave >> that for another day. ;^) >> >> Let's just call it evolution. ;^) >> >> >> >> Oh yes, I'm not saying right now -- something for JDK8 perhaps? :) >> Certainly, the trivial change Jonathan mentions could be done when >> creating the jdk8 forests. >> It would be nice to share the common stuff between jaxp and jaxws too, >> and I suspect that may be easier if they are in the same toplevel >> openjdk repository. >> >> >> >> -kto >> >> >> >> >> -Joe >> >> >> -- >> Andrew :-) >> >> Free Java Software Engineer >> Red Hat, Inc. (http://www.redhat.com) >> >> Support Free Java! >> Contribute to GNU Classpath and the OpenJDK >> http://www.gnu.org/software/classpath >> http://openjdk.java.net >> >> PGP Key: 94EFD9D8 (http://subkeys.pgp.net) >> Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 >> >> >> >> I was just testing a webrev for the ALT_DROPS_DIR change on tl and hit this: >> >> -jaxp_src-url-bundle: >> [echo] Downloading from >> https://jaxp.dev.java.net/files/documents/913/144160/jdk7-jaxp-m5.zip >> [mkdir] Created dir: /mnt/builder/tl/jaxp/drop/bundles >> [get] Getting: >> https://jaxp.dev.java.net/files/documents/913/144160/jdk7-jaxp-m5.zip >> [get] To: /mnt/builder/tl/jaxp/drop/bundles/jdk7-jaxp-m5.zip.temp >> [get] Error getting >> https://jaxp.dev.java.net/files/documents/913/144160/jdk7-jaxp-m5.zip >> to /mnt/builder/tl/jaxp/drop/bundles/jdk7-jaxp-m5.zip.temp >> >> BUILD FAILED >> javax.net.ssl.SSLException: java.lang.RuntimeException: Unexpected >> error: java.security.InvalidAlgorithmParameterException: the >> trustAnchors parameter must be non-empty >> at sun.security.ssl.Alerts.getSSLException(Alerts.java:208) >> at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1627) >> at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1590) >> at sun.security.ssl.SSLSocketImpl.handleException(SSLSocketImpl.java:1573) >> at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1166) >> at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1143) >> at >> sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:423) >> at >> sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:185) >> at >> sun.net.www.protocol.https.HttpsURLConnectionImpl.connect(HttpsURLConnectionImpl.java:153) >> at org.apache.tools.ant.taskdefs.Get.doGet(Get.java:145) >> at org.apache.tools.ant.taskdefs.Get.execute(Get.java:78) >> at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288) >> at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source) >> at >> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> at java.lang.reflect.Method.invoke(Method.java:616) >> at >> org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106) >> at org.apache.tools.ant.Task.perform(Task.java:348) >> at org.apache.tools.ant.Target.execute(Target.java:357) >> at org.apache.tools.ant.Target.performTasks(Target.java:385) >> at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1337) >> at org.apache.tools.ant.Project.executeTarget(Project.java:1306) >> at >> org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41) >> at org.apache.tools.ant.Project.executeTargets(Project.java:1189) >> at org.apache.tools.ant.Main.runBuild(Main.java:758) >> at org.apache.tools.ant.Main.startAnt(Main.java:217) >> at org.apache.tools.ant.launch.Launcher.run(Launcher.java:257) >> at org.apache.tools.ant.launch.Launcher.main(Launcher.java:104) >> >> Firstly, I obviously have to wonder why it's still downloading, but >> this seems to be caused by the new URL. >> >> >> I'm curious: is there an option to prevent downloading the source bundle? >> It seems to me that if you think you've set up the build to not need to >> download anything, it would be nice if the build failed if the bits were not >> available, rather than have it try and find the bits. Automatic downloads >> sound bad, IMO. >> >> -- Jon >> > > It would be a nice additional option, I don't think it already exists. > At present, it happens accidentally in that the JDK crashes > instead... :( > > This is interesting: > > /mnt/builder/tl/jaxws/build/xml_generated/build-drop-jaxws_src.xml:117: > Checksum on file > /mnt/builder/tl/jaxws/drop/bundles/jdk7-jaxws-2009_09_28.zip is > debb949440c5a15ce999cfefbbc56526, not > f5010ebf636db9f465a61a7a74944543 > > Did the jaxws bundle change without being renamed? I certainly hope not. These are the md5 sums I have on all the bundles: bonsai<11> /usr/bin/sum -x md5 /java/devtools/share/jdk*drops/*.zip 7a50bb540a27cdd0001885630088b758 /java/devtools/share/jdk6-drops/jdk6-jaf-2009_10_27.zip 0bb03bbd7b1b6d87cc65772c6adb2d6a /java/devtools/share/jdk6-drops/jdk6-jaxp-2009_10_27.zip 3ea5728706169498b722b898a1008acf /java/devtools/share/jdk6-drops/jdk6-jaxws-2009_10_27.zip eb8cb7a4a7f14e211fbe2354878a2472 /java/devtools/share/jdk7-drops/jdk7-jaf-2009_08_28.zip d99f4777bc4c42d7759f7c0fcf87ef5d /java/devtools/share/jdk7-drops/jdk7-jaxp-2009_08_28.zip 8800970d03bab1fff188dcfafc346f5d /java/devtools/share/jdk7-drops/jdk7-jaxp-2009_09_28.zip 8b58ce7919cda8e32a9afc5cb4b58bb1 /java/devtools/share/jdk7-drops/jdk7-jaxp-m5.zip debb949440c5a15ce999cfefbbc56526 /java/devtools/share/jdk7-drops/jdk7-jaxws-2009_08_28.zip f5010ebf636db9f465a61a7a74944543 /java/devtools/share/jdk7-drops/jdk7-jaxws-2009_09_28.zip -kto From gnu_andrew at member.fsf.org Wed Oct 28 12:36:00 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Wed, 28 Oct 2009 19:36:00 +0000 Subject: 6856630: Restructure jaxp/jaxws repository In-Reply-To: <4AE89BDE.4010008@sun.com> References: <4AB80C37.6000108@sun.com> <4AE1DF30.2030207@sun.com> <17c6771e0910271802n54a67e2cq4d547c592d817e94@mail.gmail.com> <4AE79AF9.5090206@sun.com> <4AE87777.6000001@sun.com> <17c6771e0910281050j4d315cfcm231573f7b284b07f@mail.gmail.com> <17c6771e0910281137k38935208j606eb869345ada59@mail.gmail.com> <4AE89163.3090905@sun.com> <17c6771e0910281214x60d5c44bx33524d7729c1b49f@mail.gmail.com> <4AE89BDE.4010008@sun.com> Message-ID: <17c6771e0910281236q19668173s6d3af7250eec1e16@mail.gmail.com> 2009/10/28 Kelly O'Hair : > > > Andrew John Hughes wrote: >> >> 2009/10/28 Jonathan Gibbons : >>> >>> Andrew John Hughes wrote: >>> >>> 2009/10/28 Andrew John Hughes : >>> >>> >>> 2009/10/28 Kelly O'Hair : >>> >>> >>> Joseph D. Darcy wrote: >>> >>> >>> Andrew John Hughes wrote: >>> >>> >>> 2009/10/23 Kelly O'Hair : >>> >>> >>> >>> Jonathan Gibbons wrote: >>> >>> >>> >>> Kelly O'Hair wrote: >>> >>> >>> >>> Jonathan Gibbons wrote: >>> >>> >>> >>> Kelly O'Hair wrote: >>> >>> >>> >>> [big snip] >>> >>> >>> DOH! ?Sorry... >>> >>> Yes, these jaxp and jaxws forests can probably go away, we won't >>> be using them. >>> >>> The current plan is that jaxp/jaxws changes (new bundles) will go >>> through the TL forest. >>> >>> >>> -kto >>> >>> >>> >>> >>> I'm guilty of also thinking that Jonathan was referring to the jaxws >>> and jaxp repositories per forest, rather than the specific forests. >>> On that note, i18n could probably die too because apparently that team >>> always use the swing forest for commits. >>> >>> It would be nice to one day get rid of the jaxp and jaxws trees too. >>> I don't actually see why they were created as trees to begin with, >>> given they've always been upstream and not a source of many commits. >>> The one to actual split up would be jdk, as I can feel Mercurial >>> struggling with it a bit already on jdk7. ?But I don't know how >>> feasible that is, if at all. ?Maybe Jigsaw will help there. >>> >>> One thing that does worry me -- what happens when the jaxws or jaxp >>> code needs security updates? >>> >>> >>> >>> Yes, the need to support security fixes was considered as part of this >>> new >>> delivery model. ?Ultimately a revised source bundle with the security >>> fixes >>> will need to be produced. ?Until then, the fixes can be represented as >>> patches which are applied to the sources before the build. ?Kelly can >>> speak >>> to the implementation details of the patch mechanism. >>> >>> >>> It's crude, but should serve in an emergency. See the patches/README. >>> After a bundle is unzipped, all patches are applied, none right now. >>> >>> I hope that we can always just get updated bundles. >>> >>> Originally, the jaxp and jaxws (and corba) workspaces were created >>> mainly as a place to move files from (trim) the original "j2se" >>> workspace, >>> and we had no idea where we were going with it all, except that we >>> knew these were out of place in the j2se workspace, which became >>> the jdk repository. >>> >>> The jaxp and jaxws repos could just go away someday, but I'll leave >>> that for another day. ;^) >>> >>> Let's just call it evolution. ;^) >>> >>> >>> >>> Oh yes, I'm not saying right now -- something for JDK8 perhaps? :) >>> Certainly, the trivial change Jonathan mentions could be done when >>> creating the jdk8 forests. >>> It would be nice to share the common stuff between jaxp and jaxws too, >>> and I suspect that may be easier if they are in the same toplevel >>> openjdk repository. >>> >>> >>> >>> -kto >>> >>> >>> >>> >>> -Joe >>> >>> >>> -- >>> Andrew :-) >>> >>> Free Java Software Engineer >>> Red Hat, Inc. (http://www.redhat.com) >>> >>> Support Free Java! >>> Contribute to GNU Classpath and the OpenJDK >>> http://www.gnu.org/software/classpath >>> http://openjdk.java.net >>> >>> PGP Key: 94EFD9D8 (http://subkeys.pgp.net) >>> Fingerprint: F8EF F1EA 401E 2E60 15FA ?7927 142C 2591 94EF D9D8 >>> >>> >>> >>> I was just testing a webrev for the ALT_DROPS_DIR change on tl and hit >>> this: >>> >>> -jaxp_src-url-bundle: >>> ? ? [echo] Downloading from >>> https://jaxp.dev.java.net/files/documents/913/144160/jdk7-jaxp-m5.zip >>> ? ?[mkdir] Created dir: /mnt/builder/tl/jaxp/drop/bundles >>> ? ? ?[get] Getting: >>> https://jaxp.dev.java.net/files/documents/913/144160/jdk7-jaxp-m5.zip >>> ? ? ?[get] To: /mnt/builder/tl/jaxp/drop/bundles/jdk7-jaxp-m5.zip.temp >>> ? ? ?[get] Error getting >>> https://jaxp.dev.java.net/files/documents/913/144160/jdk7-jaxp-m5.zip >>> to /mnt/builder/tl/jaxp/drop/bundles/jdk7-jaxp-m5.zip.temp >>> >>> BUILD FAILED >>> javax.net.ssl.SSLException: java.lang.RuntimeException: Unexpected >>> error: java.security.InvalidAlgorithmParameterException: the >>> trustAnchors parameter must be non-empty >>> ? ? ? ?at sun.security.ssl.Alerts.getSSLException(Alerts.java:208) >>> ? ? ? ?at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1627) >>> ? ? ? ?at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1590) >>> ? ? ? ?at >>> sun.security.ssl.SSLSocketImpl.handleException(SSLSocketImpl.java:1573) >>> ? ? ? ?at >>> sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1166) >>> ? ? ? ?at >>> sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1143) >>> ? ? ? ?at >>> sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:423) >>> ? ? ? ?at >>> >>> sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:185) >>> ? ? ? ?at >>> >>> sun.net.www.protocol.https.HttpsURLConnectionImpl.connect(HttpsURLConnectionImpl.java:153) >>> ? ? ? ?at org.apache.tools.ant.taskdefs.Get.doGet(Get.java:145) >>> ? ? ? ?at org.apache.tools.ant.taskdefs.Get.execute(Get.java:78) >>> ? ? ? ?at >>> org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288) >>> ? ? ? ?at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source) >>> ? ? ? ?at >>> >>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >>> ? ? ? ?at java.lang.reflect.Method.invoke(Method.java:616) >>> ? ? ? ?at >>> >>> org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106) >>> ? ? ? ?at org.apache.tools.ant.Task.perform(Task.java:348) >>> ? ? ? ?at org.apache.tools.ant.Target.execute(Target.java:357) >>> ? ? ? ?at org.apache.tools.ant.Target.performTasks(Target.java:385) >>> ? ? ? ?at >>> org.apache.tools.ant.Project.executeSortedTargets(Project.java:1337) >>> ? ? ? ?at org.apache.tools.ant.Project.executeTarget(Project.java:1306) >>> ? ? ? ?at >>> >>> org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41) >>> ? ? ? ?at org.apache.tools.ant.Project.executeTargets(Project.java:1189) >>> ? ? ? ?at org.apache.tools.ant.Main.runBuild(Main.java:758) >>> ? ? ? ?at org.apache.tools.ant.Main.startAnt(Main.java:217) >>> ? ? ? ?at org.apache.tools.ant.launch.Launcher.run(Launcher.java:257) >>> ? ? ? ?at org.apache.tools.ant.launch.Launcher.main(Launcher.java:104) >>> >>> Firstly, I obviously have to wonder why it's still downloading, but >>> this seems to be caused by the new URL. >>> >>> >>> I'm curious: is there an option to prevent downloading the source bundle? >>> It seems to me that if you think you've set up the build to not need to >>> download anything, it would be nice if the build failed if the bits were >>> not >>> available, rather than have it try and find the bits. ?Automatic >>> downloads >>> sound bad, IMO. >>> >>> -- Jon >>> >> >> It would be a nice additional option, I don't think it already exists. >> ?At present, it happens accidentally in that the JDK crashes >> instead... :( >> >> This is interesting: >> >> /mnt/builder/tl/jaxws/build/xml_generated/build-drop-jaxws_src.xml:117: >> Checksum on file >> /mnt/builder/tl/jaxws/drop/bundles/jdk7-jaxws-2009_09_28.zip is >> ? ? ? ? ? ? ?debb949440c5a15ce999cfefbbc56526, not >> f5010ebf636db9f465a61a7a74944543 >> >> Did the jaxws bundle change without being renamed? > > I certainly hope not. > > These are the md5 sums I have on all the bundles: > > bonsai<11> /usr/bin/sum -x md5 ?/java/devtools/share/jdk*drops/*.zip > 7a50bb540a27cdd0001885630088b758 > /java/devtools/share/jdk6-drops/jdk6-jaf-2009_10_27.zip > 0bb03bbd7b1b6d87cc65772c6adb2d6a > /java/devtools/share/jdk6-drops/jdk6-jaxp-2009_10_27.zip > 3ea5728706169498b722b898a1008acf > /java/devtools/share/jdk6-drops/jdk6-jaxws-2009_10_27.zip > eb8cb7a4a7f14e211fbe2354878a2472 > /java/devtools/share/jdk7-drops/jdk7-jaf-2009_08_28.zip > d99f4777bc4c42d7759f7c0fcf87ef5d > /java/devtools/share/jdk7-drops/jdk7-jaxp-2009_08_28.zip > 8800970d03bab1fff188dcfafc346f5d > /java/devtools/share/jdk7-drops/jdk7-jaxp-2009_09_28.zip > 8b58ce7919cda8e32a9afc5cb4b58bb1 > /java/devtools/share/jdk7-drops/jdk7-jaxp-m5.zip > debb949440c5a15ce999cfefbbc56526 > /java/devtools/share/jdk7-drops/jdk7-jaxws-2009_08_28.zip > f5010ebf636db9f465a61a7a74944543 > /java/devtools/share/jdk7-drops/jdk7-jaxws-2009_09_28.zip > > -kto > Ok it appears I have 08_28 masquerading as 09_28. Thanks. -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From gnu_andrew at member.fsf.org Wed Oct 28 14:29:01 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Wed, 28 Oct 2009 21:29:01 +0000 Subject: 6856630: Restructure jaxp/jaxws repository In-Reply-To: <17c6771e0910281236q19668173s6d3af7250eec1e16@mail.gmail.com> References: <4AB80C37.6000108@sun.com> <17c6771e0910271802n54a67e2cq4d547c592d817e94@mail.gmail.com> <4AE79AF9.5090206@sun.com> <4AE87777.6000001@sun.com> <17c6771e0910281050j4d315cfcm231573f7b284b07f@mail.gmail.com> <17c6771e0910281137k38935208j606eb869345ada59@mail.gmail.com> <4AE89163.3090905@sun.com> <17c6771e0910281214x60d5c44bx33524d7729c1b49f@mail.gmail.com> <4AE89BDE.4010008@sun.com> <17c6771e0910281236q19668173s6d3af7250eec1e16@mail.gmail.com> Message-ID: <17c6771e0910281429rcd4f529ye4e81ce2f2da25d3@mail.gmail.com> 2009/10/28 Andrew John Hughes : > 2009/10/28 Kelly O'Hair : >> >> >> Andrew John Hughes wrote: >>> >>> 2009/10/28 Jonathan Gibbons : >>>> >>>> Andrew John Hughes wrote: >>>> >>>> 2009/10/28 Andrew John Hughes : >>>> >>>> >>>> 2009/10/28 Kelly O'Hair : >>>> >>>> >>>> Joseph D. Darcy wrote: >>>> >>>> >>>> Andrew John Hughes wrote: >>>> >>>> >>>> 2009/10/23 Kelly O'Hair : >>>> >>>> >>>> >>>> Jonathan Gibbons wrote: >>>> >>>> >>>> >>>> Kelly O'Hair wrote: >>>> >>>> >>>> >>>> Jonathan Gibbons wrote: >>>> >>>> >>>> >>>> Kelly O'Hair wrote: >>>> >>>> >>>> >>>> [big snip] >>>> >>>> >>>> DOH! ?Sorry... >>>> >>>> Yes, these jaxp and jaxws forests can probably go away, we won't >>>> be using them. >>>> >>>> The current plan is that jaxp/jaxws changes (new bundles) will go >>>> through the TL forest. >>>> >>>> >>>> -kto >>>> >>>> >>>> >>>> >>>> I'm guilty of also thinking that Jonathan was referring to the jaxws >>>> and jaxp repositories per forest, rather than the specific forests. >>>> On that note, i18n could probably die too because apparently that team >>>> always use the swing forest for commits. >>>> >>>> It would be nice to one day get rid of the jaxp and jaxws trees too. >>>> I don't actually see why they were created as trees to begin with, >>>> given they've always been upstream and not a source of many commits. >>>> The one to actual split up would be jdk, as I can feel Mercurial >>>> struggling with it a bit already on jdk7. ?But I don't know how >>>> feasible that is, if at all. ?Maybe Jigsaw will help there. >>>> >>>> One thing that does worry me -- what happens when the jaxws or jaxp >>>> code needs security updates? >>>> >>>> >>>> >>>> Yes, the need to support security fixes was considered as part of this >>>> new >>>> delivery model. ?Ultimately a revised source bundle with the security >>>> fixes >>>> will need to be produced. ?Until then, the fixes can be represented as >>>> patches which are applied to the sources before the build. ?Kelly can >>>> speak >>>> to the implementation details of the patch mechanism. >>>> >>>> >>>> It's crude, but should serve in an emergency. See the patches/README. >>>> After a bundle is unzipped, all patches are applied, none right now. >>>> >>>> I hope that we can always just get updated bundles. >>>> >>>> Originally, the jaxp and jaxws (and corba) workspaces were created >>>> mainly as a place to move files from (trim) the original "j2se" >>>> workspace, >>>> and we had no idea where we were going with it all, except that we >>>> knew these were out of place in the j2se workspace, which became >>>> the jdk repository. >>>> >>>> The jaxp and jaxws repos could just go away someday, but I'll leave >>>> that for another day. ;^) >>>> >>>> Let's just call it evolution. ;^) >>>> >>>> >>>> >>>> Oh yes, I'm not saying right now -- something for JDK8 perhaps? :) >>>> Certainly, the trivial change Jonathan mentions could be done when >>>> creating the jdk8 forests. >>>> It would be nice to share the common stuff between jaxp and jaxws too, >>>> and I suspect that may be easier if they are in the same toplevel >>>> openjdk repository. >>>> >>>> >>>> >>>> -kto >>>> >>>> >>>> >>>> >>>> -Joe >>>> >>>> >>>> -- >>>> Andrew :-) >>>> >>>> Free Java Software Engineer >>>> Red Hat, Inc. (http://www.redhat.com) >>>> >>>> Support Free Java! >>>> Contribute to GNU Classpath and the OpenJDK >>>> http://www.gnu.org/software/classpath >>>> http://openjdk.java.net >>>> >>>> PGP Key: 94EFD9D8 (http://subkeys.pgp.net) >>>> Fingerprint: F8EF F1EA 401E 2E60 15FA ?7927 142C 2591 94EF D9D8 >>>> >>>> >>>> >>>> I was just testing a webrev for the ALT_DROPS_DIR change on tl and hit >>>> this: >>>> >>>> -jaxp_src-url-bundle: >>>> ? ? [echo] Downloading from >>>> https://jaxp.dev.java.net/files/documents/913/144160/jdk7-jaxp-m5.zip >>>> ? ?[mkdir] Created dir: /mnt/builder/tl/jaxp/drop/bundles >>>> ? ? ?[get] Getting: >>>> https://jaxp.dev.java.net/files/documents/913/144160/jdk7-jaxp-m5.zip >>>> ? ? ?[get] To: /mnt/builder/tl/jaxp/drop/bundles/jdk7-jaxp-m5.zip.temp >>>> ? ? ?[get] Error getting >>>> https://jaxp.dev.java.net/files/documents/913/144160/jdk7-jaxp-m5.zip >>>> to /mnt/builder/tl/jaxp/drop/bundles/jdk7-jaxp-m5.zip.temp >>>> >>>> BUILD FAILED >>>> javax.net.ssl.SSLException: java.lang.RuntimeException: Unexpected >>>> error: java.security.InvalidAlgorithmParameterException: the >>>> trustAnchors parameter must be non-empty >>>> ? ? ? ?at sun.security.ssl.Alerts.getSSLException(Alerts.java:208) >>>> ? ? ? ?at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1627) >>>> ? ? ? ?at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1590) >>>> ? ? ? ?at >>>> sun.security.ssl.SSLSocketImpl.handleException(SSLSocketImpl.java:1573) >>>> ? ? ? ?at >>>> sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1166) >>>> ? ? ? ?at >>>> sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1143) >>>> ? ? ? ?at >>>> sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:423) >>>> ? ? ? ?at >>>> >>>> sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:185) >>>> ? ? ? ?at >>>> >>>> sun.net.www.protocol.https.HttpsURLConnectionImpl.connect(HttpsURLConnectionImpl.java:153) >>>> ? ? ? ?at org.apache.tools.ant.taskdefs.Get.doGet(Get.java:145) >>>> ? ? ? ?at org.apache.tools.ant.taskdefs.Get.execute(Get.java:78) >>>> ? ? ? ?at >>>> org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288) >>>> ? ? ? ?at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source) >>>> ? ? ? ?at >>>> >>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >>>> ? ? ? ?at java.lang.reflect.Method.invoke(Method.java:616) >>>> ? ? ? ?at >>>> >>>> org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106) >>>> ? ? ? ?at org.apache.tools.ant.Task.perform(Task.java:348) >>>> ? ? ? ?at org.apache.tools.ant.Target.execute(Target.java:357) >>>> ? ? ? ?at org.apache.tools.ant.Target.performTasks(Target.java:385) >>>> ? ? ? ?at >>>> org.apache.tools.ant.Project.executeSortedTargets(Project.java:1337) >>>> ? ? ? ?at org.apache.tools.ant.Project.executeTarget(Project.java:1306) >>>> ? ? ? ?at >>>> >>>> org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41) >>>> ? ? ? ?at org.apache.tools.ant.Project.executeTargets(Project.java:1189) >>>> ? ? ? ?at org.apache.tools.ant.Main.runBuild(Main.java:758) >>>> ? ? ? ?at org.apache.tools.ant.Main.startAnt(Main.java:217) >>>> ? ? ? ?at org.apache.tools.ant.launch.Launcher.run(Launcher.java:257) >>>> ? ? ? ?at org.apache.tools.ant.launch.Launcher.main(Launcher.java:104) >>>> >>>> Firstly, I obviously have to wonder why it's still downloading, but >>>> this seems to be caused by the new URL. >>>> >>>> >>>> I'm curious: is there an option to prevent downloading the source bundle? >>>> It seems to me that if you think you've set up the build to not need to >>>> download anything, it would be nice if the build failed if the bits were >>>> not >>>> available, rather than have it try and find the bits. ?Automatic >>>> downloads >>>> sound bad, IMO. >>>> >>>> -- Jon >>>> >>> >>> It would be a nice additional option, I don't think it already exists. >>> ?At present, it happens accidentally in that the JDK crashes >>> instead... :( >>> >>> This is interesting: >>> >>> /mnt/builder/tl/jaxws/build/xml_generated/build-drop-jaxws_src.xml:117: >>> Checksum on file >>> /mnt/builder/tl/jaxws/drop/bundles/jdk7-jaxws-2009_09_28.zip is >>> ? ? ? ? ? ? ?debb949440c5a15ce999cfefbbc56526, not >>> f5010ebf636db9f465a61a7a74944543 >>> >>> Did the jaxws bundle change without being renamed? >> >> I certainly hope not. >> >> These are the md5 sums I have on all the bundles: >> >> bonsai<11> /usr/bin/sum -x md5 ?/java/devtools/share/jdk*drops/*.zip >> 7a50bb540a27cdd0001885630088b758 >> /java/devtools/share/jdk6-drops/jdk6-jaf-2009_10_27.zip >> 0bb03bbd7b1b6d87cc65772c6adb2d6a >> /java/devtools/share/jdk6-drops/jdk6-jaxp-2009_10_27.zip >> 3ea5728706169498b722b898a1008acf >> /java/devtools/share/jdk6-drops/jdk6-jaxws-2009_10_27.zip >> eb8cb7a4a7f14e211fbe2354878a2472 >> /java/devtools/share/jdk7-drops/jdk7-jaf-2009_08_28.zip >> d99f4777bc4c42d7759f7c0fcf87ef5d >> /java/devtools/share/jdk7-drops/jdk7-jaxp-2009_08_28.zip >> 8800970d03bab1fff188dcfafc346f5d >> /java/devtools/share/jdk7-drops/jdk7-jaxp-2009_09_28.zip >> 8b58ce7919cda8e32a9afc5cb4b58bb1 >> /java/devtools/share/jdk7-drops/jdk7-jaxp-m5.zip >> debb949440c5a15ce999cfefbbc56526 >> /java/devtools/share/jdk7-drops/jdk7-jaxws-2009_08_28.zip >> f5010ebf636db9f465a61a7a74944543 >> /java/devtools/share/jdk7-drops/jdk7-jaxws-2009_09_28.zip >> >> -kto >> > > Ok it appears I have 08_28 masquerading as 09_28. ?Thanks. > -- > Andrew :-) > > Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > Support Free Java! > Contribute to GNU Classpath and the OpenJDK > http://www.gnu.org/software/classpath > http://openjdk.java.net > > PGP Key: 94EFD9D8 (http://subkeys.pgp.net) > Fingerprint: F8EF F1EA 401E 2E60 15FA ?7927 142C 2591 94EF D9D8 > Ok here's the webrev for the ALT_DROPS_DIR change against tl: http://cr.openjdk.java.net/~andrew/drops/webrev.02/ Ok to push? Do we have a bug ID for this? Thanks, -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From Jonathan.Gibbons at Sun.COM Wed Oct 28 14:39:22 2009 From: Jonathan.Gibbons at Sun.COM (Jonathan Gibbons) Date: Wed, 28 Oct 2009 14:39:22 -0700 Subject: 6856630: Restructure jaxp/jaxws repository In-Reply-To: <17c6771e0910281429rcd4f529ye4e81ce2f2da25d3@mail.gmail.com> References: <4AB80C37.6000108@sun.com> <17c6771e0910271802n54a67e2cq4d547c592d817e94@mail.gmail.com> <4AE79AF9.5090206@sun.com> <4AE87777.6000001@sun.com> <17c6771e0910281050j4d315cfcm231573f7b284b07f@mail.gmail.com> <17c6771e0910281137k38935208j606eb869345ada59@mail.gmail.com> <4AE89163.3090905@sun.com> <17c6771e0910281214x60d5c44bx33524d7729c1b49f@mail.gmail.com> <4AE89BDE.4010008@sun.com> <17c6771e0910281236q19668173s6d3af7250eec1e16@mail.gmail.com> <17c6771e0910281429rcd4f529ye4e81ce2f2da25d3@mail.gmail.com> Message-ID: <4AE8BA0A.8010601@sun.com> Andrew John Hughes wrote: > 2009/10/28 Andrew John Hughes : > >> 2009/10/28 Kelly O'Hair : >> >>> Andrew John Hughes wrote: >>> >>>> 2009/10/28 Jonathan Gibbons : >>>> >>>>> Andrew John Hughes wrote: >>>>> >>>>> 2009/10/28 Andrew John Hughes : >>>>> >>>>> >>>>> 2009/10/28 Kelly O'Hair : >>>>> >>>>> >>>>> Joseph D. Darcy wrote: >>>>> >>>>> >>>>> Andrew John Hughes wrote: >>>>> >>>>> >>>>> 2009/10/23 Kelly O'Hair : >>>>> >>>>> >>>>> >>>>> Jonathan Gibbons wrote: >>>>> >>>>> >>>>> >>>>> Kelly O'Hair wrote: >>>>> >>>>> >>>>> >>>>> Jonathan Gibbons wrote: >>>>> >>>>> >>>>> >>>>> Kelly O'Hair wrote: >>>>> >>>>> >>>>> >>>>> [big snip] >>>>> >>>>> >>>>> DOH! Sorry... >>>>> >>>>> Yes, these jaxp and jaxws forests can probably go away, we won't >>>>> be using them. >>>>> >>>>> The current plan is that jaxp/jaxws changes (new bundles) will go >>>>> through the TL forest. >>>>> >>>>> >>>>> -kto >>>>> >>>>> >>>>> >>>>> >>>>> I'm guilty of also thinking that Jonathan was referring to the jaxws >>>>> and jaxp repositories per forest, rather than the specific forests. >>>>> On that note, i18n could probably die too because apparently that team >>>>> always use the swing forest for commits. >>>>> >>>>> It would be nice to one day get rid of the jaxp and jaxws trees too. >>>>> I don't actually see why they were created as trees to begin with, >>>>> given they've always been upstream and not a source of many commits. >>>>> The one to actual split up would be jdk, as I can feel Mercurial >>>>> struggling with it a bit already on jdk7. But I don't know how >>>>> feasible that is, if at all. Maybe Jigsaw will help there. >>>>> >>>>> One thing that does worry me -- what happens when the jaxws or jaxp >>>>> code needs security updates? >>>>> >>>>> >>>>> >>>>> Yes, the need to support security fixes was considered as part of this >>>>> new >>>>> delivery model. Ultimately a revised source bundle with the security >>>>> fixes >>>>> will need to be produced. Until then, the fixes can be represented as >>>>> patches which are applied to the sources before the build. Kelly can >>>>> speak >>>>> to the implementation details of the patch mechanism. >>>>> >>>>> >>>>> It's crude, but should serve in an emergency. See the patches/README. >>>>> After a bundle is unzipped, all patches are applied, none right now. >>>>> >>>>> I hope that we can always just get updated bundles. >>>>> >>>>> Originally, the jaxp and jaxws (and corba) workspaces were created >>>>> mainly as a place to move files from (trim) the original "j2se" >>>>> workspace, >>>>> and we had no idea where we were going with it all, except that we >>>>> knew these were out of place in the j2se workspace, which became >>>>> the jdk repository. >>>>> >>>>> The jaxp and jaxws repos could just go away someday, but I'll leave >>>>> that for another day. ;^) >>>>> >>>>> Let's just call it evolution. ;^) >>>>> >>>>> >>>>> >>>>> Oh yes, I'm not saying right now -- something for JDK8 perhaps? :) >>>>> Certainly, the trivial change Jonathan mentions could be done when >>>>> creating the jdk8 forests. >>>>> It would be nice to share the common stuff between jaxp and jaxws too, >>>>> and I suspect that may be easier if they are in the same toplevel >>>>> openjdk repository. >>>>> >>>>> >>>>> >>>>> -kto >>>>> >>>>> >>>>> >>>>> >>>>> -Joe >>>>> >>>>> >>>>> -- >>>>> Andrew :-) >>>>> >>>>> Free Java Software Engineer >>>>> Red Hat, Inc. (http://www.redhat.com) >>>>> >>>>> Support Free Java! >>>>> Contribute to GNU Classpath and the OpenJDK >>>>> http://www.gnu.org/software/classpath >>>>> http://openjdk.java.net >>>>> >>>>> PGP Key: 94EFD9D8 (http://subkeys.pgp.net) >>>>> Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 >>>>> >>>>> >>>>> >>>>> I was just testing a webrev for the ALT_DROPS_DIR change on tl and hit >>>>> this: >>>>> >>>>> -jaxp_src-url-bundle: >>>>> [echo] Downloading from >>>>> https://jaxp.dev.java.net/files/documents/913/144160/jdk7-jaxp-m5.zip >>>>> [mkdir] Created dir: /mnt/builder/tl/jaxp/drop/bundles >>>>> [get] Getting: >>>>> https://jaxp.dev.java.net/files/documents/913/144160/jdk7-jaxp-m5.zip >>>>> [get] To: /mnt/builder/tl/jaxp/drop/bundles/jdk7-jaxp-m5.zip.temp >>>>> [get] Error getting >>>>> https://jaxp.dev.java.net/files/documents/913/144160/jdk7-jaxp-m5.zip >>>>> to /mnt/builder/tl/jaxp/drop/bundles/jdk7-jaxp-m5.zip.temp >>>>> >>>>> BUILD FAILED >>>>> javax.net.ssl.SSLException: java.lang.RuntimeException: Unexpected >>>>> error: java.security.InvalidAlgorithmParameterException: the >>>>> trustAnchors parameter must be non-empty >>>>> at sun.security.ssl.Alerts.getSSLException(Alerts.java:208) >>>>> at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1627) >>>>> at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1590) >>>>> at >>>>> sun.security.ssl.SSLSocketImpl.handleException(SSLSocketImpl.java:1573) >>>>> at >>>>> sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1166) >>>>> at >>>>> sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1143) >>>>> at >>>>> sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:423) >>>>> at >>>>> >>>>> sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:185) >>>>> at >>>>> >>>>> sun.net.www.protocol.https.HttpsURLConnectionImpl.connect(HttpsURLConnectionImpl.java:153) >>>>> at org.apache.tools.ant.taskdefs.Get.doGet(Get.java:145) >>>>> at org.apache.tools.ant.taskdefs.Get.execute(Get.java:78) >>>>> at >>>>> org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288) >>>>> at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source) >>>>> at >>>>> >>>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >>>>> at java.lang.reflect.Method.invoke(Method.java:616) >>>>> at >>>>> >>>>> org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106) >>>>> at org.apache.tools.ant.Task.perform(Task.java:348) >>>>> at org.apache.tools.ant.Target.execute(Target.java:357) >>>>> at org.apache.tools.ant.Target.performTasks(Target.java:385) >>>>> at >>>>> org.apache.tools.ant.Project.executeSortedTargets(Project.java:1337) >>>>> at org.apache.tools.ant.Project.executeTarget(Project.java:1306) >>>>> at >>>>> >>>>> org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41) >>>>> at org.apache.tools.ant.Project.executeTargets(Project.java:1189) >>>>> at org.apache.tools.ant.Main.runBuild(Main.java:758) >>>>> at org.apache.tools.ant.Main.startAnt(Main.java:217) >>>>> at org.apache.tools.ant.launch.Launcher.run(Launcher.java:257) >>>>> at org.apache.tools.ant.launch.Launcher.main(Launcher.java:104) >>>>> >>>>> Firstly, I obviously have to wonder why it's still downloading, but >>>>> this seems to be caused by the new URL. >>>>> >>>>> >>>>> I'm curious: is there an option to prevent downloading the source bundle? >>>>> It seems to me that if you think you've set up the build to not need to >>>>> download anything, it would be nice if the build failed if the bits were >>>>> not >>>>> available, rather than have it try and find the bits. Automatic >>>>> downloads >>>>> sound bad, IMO. >>>>> >>>>> -- Jon >>>>> >>>>> >>>> It would be a nice additional option, I don't think it already exists. >>>> At present, it happens accidentally in that the JDK crashes >>>> instead... :( >>>> >>>> This is interesting: >>>> >>>> /mnt/builder/tl/jaxws/build/xml_generated/build-drop-jaxws_src.xml:117: >>>> Checksum on file >>>> /mnt/builder/tl/jaxws/drop/bundles/jdk7-jaxws-2009_09_28.zip is >>>> debb949440c5a15ce999cfefbbc56526, not >>>> f5010ebf636db9f465a61a7a74944543 >>>> >>>> Did the jaxws bundle change without being renamed? >>>> >>> I certainly hope not. >>> >>> These are the md5 sums I have on all the bundles: >>> >>> bonsai<11> /usr/bin/sum -x md5 /java/devtools/share/jdk*drops/*.zip >>> 7a50bb540a27cdd0001885630088b758 >>> /java/devtools/share/jdk6-drops/jdk6-jaf-2009_10_27.zip >>> 0bb03bbd7b1b6d87cc65772c6adb2d6a >>> /java/devtools/share/jdk6-drops/jdk6-jaxp-2009_10_27.zip >>> 3ea5728706169498b722b898a1008acf >>> /java/devtools/share/jdk6-drops/jdk6-jaxws-2009_10_27.zip >>> eb8cb7a4a7f14e211fbe2354878a2472 >>> /java/devtools/share/jdk7-drops/jdk7-jaf-2009_08_28.zip >>> d99f4777bc4c42d7759f7c0fcf87ef5d >>> /java/devtools/share/jdk7-drops/jdk7-jaxp-2009_08_28.zip >>> 8800970d03bab1fff188dcfafc346f5d >>> /java/devtools/share/jdk7-drops/jdk7-jaxp-2009_09_28.zip >>> 8b58ce7919cda8e32a9afc5cb4b58bb1 >>> /java/devtools/share/jdk7-drops/jdk7-jaxp-m5.zip >>> debb949440c5a15ce999cfefbbc56526 >>> /java/devtools/share/jdk7-drops/jdk7-jaxws-2009_08_28.zip >>> f5010ebf636db9f465a61a7a74944543 >>> /java/devtools/share/jdk7-drops/jdk7-jaxws-2009_09_28.zip >>> >>> -kto >>> >>> >> Ok it appears I have 08_28 masquerading as 09_28. Thanks. >> -- >> Andrew :-) >> >> Free Java Software Engineer >> Red Hat, Inc. (http://www.redhat.com) >> >> Support Free Java! >> Contribute to GNU Classpath and the OpenJDK >> http://www.gnu.org/software/classpath >> http://openjdk.java.net >> >> PGP Key: 94EFD9D8 (http://subkeys.pgp.net) >> Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 >> >> > > Ok here's the webrev for the ALT_DROPS_DIR change against tl: > > http://cr.openjdk.java.net/~andrew/drops/webrev.02/ > > Ok to push? Do we have a bug ID for this? > > Thanks, > Andrew, Some of the comments in the Makefiles need to be updated -- for example, references to devtools in lines 89, 100 -- Jon -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/build-dev/attachments/20091028/ddb52cbf/attachment-0001.html From Jonathan.Gibbons at Sun.COM Wed Oct 28 15:02:06 2009 From: Jonathan.Gibbons at Sun.COM (Jonathan Gibbons) Date: Wed, 28 Oct 2009 15:02:06 -0700 Subject: 6856630: Restructure jaxp/jaxws repository In-Reply-To: <4AE89BDE.4010008@sun.com> References: <4AB80C37.6000108@sun.com> <4AE1D88C.5040408@sun.com> <4AE1DC34.30707@sun.com> <4AE1DF30.2030207@sun.com> <17c6771e0910271802n54a67e2cq4d547c592d817e94@mail.gmail.com> <4AE79AF9.5090206@sun.com> <4AE87777.6000001@sun.com> <17c6771e0910281050j4d315cfcm231573f7b284b07f@mail.gmail.com> <17c6771e0910281137k38935208j606eb869345ada59@mail.gmail.com> <4AE89163.3090905@sun.com> <17c6771e0910281214x60d5c44bx33524d7729c1b49f@mail.gmail.com> <4AE89BDE.4010008@sun.com> Message-ID: <4AE8BF5E.4060406@sun.com> Kelly O'Hair wrote: > [snip] > > These are the md5 sums I have on all the bundles: > > bonsai<11> /usr/bin/sum -x md5 /java/devtools/share/jdk*drops/*.zip > 7a50bb540a27cdd0001885630088b758 > /java/devtools/share/jdk6-drops/jdk6-jaf-2009_10_27.zip > 0bb03bbd7b1b6d87cc65772c6adb2d6a > /java/devtools/share/jdk6-drops/jdk6-jaxp-2009_10_27.zip > 3ea5728706169498b722b898a1008acf > /java/devtools/share/jdk6-drops/jdk6-jaxws-2009_10_27.zip > eb8cb7a4a7f14e211fbe2354878a2472 > /java/devtools/share/jdk7-drops/jdk7-jaf-2009_08_28.zip > d99f4777bc4c42d7759f7c0fcf87ef5d > /java/devtools/share/jdk7-drops/jdk7-jaxp-2009_08_28.zip > 8800970d03bab1fff188dcfafc346f5d > /java/devtools/share/jdk7-drops/jdk7-jaxp-2009_09_28.zip > 8b58ce7919cda8e32a9afc5cb4b58bb1 > /java/devtools/share/jdk7-drops/jdk7-jaxp-m5.zip > debb949440c5a15ce999cfefbbc56526 > /java/devtools/share/jdk7-drops/jdk7-jaxws-2009_08_28.zip > f5010ebf636db9f465a61a7a74944543 > /java/devtools/share/jdk7-drops/jdk7-jaxws-2009_09_28.zip > > -kto Given that the bundles include the jdk name (jdk6, jdk7), is it really necessary to have separate bundle directories (jdk6-drops, jdk7-drops)? It's not a big deal, but on my local cache of these files, I was certainly thinking to merge these directories so that I can have the same value for ALT_DROPS_DIR for both JDK 6 and 7. -- Jon From gnu_andrew at member.fsf.org Wed Oct 28 16:03:10 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Wed, 28 Oct 2009 23:03:10 +0000 Subject: 6856630: Restructure jaxp/jaxws repository In-Reply-To: <4AE8BA0A.8010601@sun.com> References: <4AB80C37.6000108@sun.com> <4AE87777.6000001@sun.com> <17c6771e0910281050j4d315cfcm231573f7b284b07f@mail.gmail.com> <17c6771e0910281137k38935208j606eb869345ada59@mail.gmail.com> <4AE89163.3090905@sun.com> <17c6771e0910281214x60d5c44bx33524d7729c1b49f@mail.gmail.com> <4AE89BDE.4010008@sun.com> <17c6771e0910281236q19668173s6d3af7250eec1e16@mail.gmail.com> <17c6771e0910281429rcd4f529ye4e81ce2f2da25d3@mail.gmail.com> <4AE8BA0A.8010601@sun.com> Message-ID: <17c6771e0910281603n1b6217f1jcf73869b011b749c@mail.gmail.com> 2009/10/28 Jonathan Gibbons : > Andrew John Hughes wrote: > > 2009/10/28 Andrew John Hughes : > > > 2009/10/28 Kelly O'Hair : > > > Andrew John Hughes wrote: > > > 2009/10/28 Jonathan Gibbons : > > > Andrew John Hughes wrote: > > 2009/10/28 Andrew John Hughes : > > > 2009/10/28 Kelly O'Hair : > > > Joseph D. Darcy wrote: > > > Andrew John Hughes wrote: > > > 2009/10/23 Kelly O'Hair : > > > > Jonathan Gibbons wrote: > > > > Kelly O'Hair wrote: > > > > Jonathan Gibbons wrote: > > > > Kelly O'Hair wrote: > > > > [big snip] > > > DOH! ?Sorry... > > Yes, these jaxp and jaxws forests can probably go away, we won't > be using them. > > The current plan is that jaxp/jaxws changes (new bundles) will go > through the TL forest. > > > -kto > > > > > I'm guilty of also thinking that Jonathan was referring to the jaxws > and jaxp repositories per forest, rather than the specific forests. > On that note, i18n could probably die too because apparently that team > always use the swing forest for commits. > > It would be nice to one day get rid of the jaxp and jaxws trees too. > I don't actually see why they were created as trees to begin with, > given they've always been upstream and not a source of many commits. > The one to actual split up would be jdk, as I can feel Mercurial > struggling with it a bit already on jdk7. ?But I don't know how > feasible that is, if at all. ?Maybe Jigsaw will help there. > > One thing that does worry me -- what happens when the jaxws or jaxp > code needs security updates? > > > > Yes, the need to support security fixes was considered as part of this > new > delivery model. ?Ultimately a revised source bundle with the security > fixes > will need to be produced. ?Until then, the fixes can be represented as > patches which are applied to the sources before the build. ?Kelly can > speak > to the implementation details of the patch mechanism. > > > It's crude, but should serve in an emergency. See the patches/README. > After a bundle is unzipped, all patches are applied, none right now. > > I hope that we can always just get updated bundles. > > Originally, the jaxp and jaxws (and corba) workspaces were created > mainly as a place to move files from (trim) the original "j2se" > workspace, > and we had no idea where we were going with it all, except that we > knew these were out of place in the j2se workspace, which became > the jdk repository. > > The jaxp and jaxws repos could just go away someday, but I'll leave > that for another day. ;^) > > Let's just call it evolution. ;^) > > > > Oh yes, I'm not saying right now -- something for JDK8 perhaps? :) > Certainly, the trivial change Jonathan mentions could be done when > creating the jdk8 forests. > It would be nice to share the common stuff between jaxp and jaxws too, > and I suspect that may be easier if they are in the same toplevel > openjdk repository. > > > > -kto > > > > > -Joe > > > -- > Andrew :-) > > Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > Support Free Java! > Contribute to GNU Classpath and the OpenJDK > http://www.gnu.org/software/classpath > http://openjdk.java.net > > PGP Key: 94EFD9D8 (http://subkeys.pgp.net) > Fingerprint: F8EF F1EA 401E 2E60 15FA ?7927 142C 2591 94EF D9D8 > > > > I was just testing a webrev for the ALT_DROPS_DIR change on tl and hit > this: > > -jaxp_src-url-bundle: > ? ? [echo] Downloading from > https://jaxp.dev.java.net/files/documents/913/144160/jdk7-jaxp-m5.zip > ? ?[mkdir] Created dir: /mnt/builder/tl/jaxp/drop/bundles > ? ? ?[get] Getting: > https://jaxp.dev.java.net/files/documents/913/144160/jdk7-jaxp-m5.zip > ? ? ?[get] To: /mnt/builder/tl/jaxp/drop/bundles/jdk7-jaxp-m5.zip.temp > ? ? ?[get] Error getting > https://jaxp.dev.java.net/files/documents/913/144160/jdk7-jaxp-m5.zip > to /mnt/builder/tl/jaxp/drop/bundles/jdk7-jaxp-m5.zip.temp > > BUILD FAILED > javax.net.ssl.SSLException: java.lang.RuntimeException: Unexpected > error: java.security.InvalidAlgorithmParameterException: the > trustAnchors parameter must be non-empty > ? ? ? ?at sun.security.ssl.Alerts.getSSLException(Alerts.java:208) > ? ? ? ?at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1627) > ? ? ? ?at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1590) > ? ? ? ?at > sun.security.ssl.SSLSocketImpl.handleException(SSLSocketImpl.java:1573) > ? ? ? ?at > sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1166) > ? ? ? ?at > sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1143) > ? ? ? ?at > sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:423) > ? ? ? ?at > > sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:185) > ? ? ? ?at > > sun.net.www.protocol.https.HttpsURLConnectionImpl.connect(HttpsURLConnectionImpl.java:153) > ? ? ? ?at org.apache.tools.ant.taskdefs.Get.doGet(Get.java:145) > ? ? ? ?at org.apache.tools.ant.taskdefs.Get.execute(Get.java:78) > ? ? ? ?at > org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288) > ? ? ? ?at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source) > ? ? ? ?at > > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > ? ? ? ?at java.lang.reflect.Method.invoke(Method.java:616) > ? ? ? ?at > > org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106) > ? ? ? ?at org.apache.tools.ant.Task.perform(Task.java:348) > ? ? ? ?at org.apache.tools.ant.Target.execute(Target.java:357) > ? ? ? ?at org.apache.tools.ant.Target.performTasks(Target.java:385) > ? ? ? ?at > org.apache.tools.ant.Project.executeSortedTargets(Project.java:1337) > ? ? ? ?at org.apache.tools.ant.Project.executeTarget(Project.java:1306) > ? ? ? ?at > > org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41) > ? ? ? ?at org.apache.tools.ant.Project.executeTargets(Project.java:1189) > ? ? ? ?at org.apache.tools.ant.Main.runBuild(Main.java:758) > ? ? ? ?at org.apache.tools.ant.Main.startAnt(Main.java:217) > ? ? ? ?at org.apache.tools.ant.launch.Launcher.run(Launcher.java:257) > ? ? ? ?at org.apache.tools.ant.launch.Launcher.main(Launcher.java:104) > > Firstly, I obviously have to wonder why it's still downloading, but > this seems to be caused by the new URL. > > > I'm curious: is there an option to prevent downloading the source bundle? > It seems to me that if you think you've set up the build to not need to > download anything, it would be nice if the build failed if the bits were > not > available, rather than have it try and find the bits. ?Automatic > downloads > sound bad, IMO. > > -- Jon > > > > It would be a nice additional option, I don't think it already exists. > ?At present, it happens accidentally in that the JDK crashes > instead... :( > > This is interesting: > > /mnt/builder/tl/jaxws/build/xml_generated/build-drop-jaxws_src.xml:117: > Checksum on file > /mnt/builder/tl/jaxws/drop/bundles/jdk7-jaxws-2009_09_28.zip is > ? ? ? ? ? ? ?debb949440c5a15ce999cfefbbc56526, not > f5010ebf636db9f465a61a7a74944543 > > Did the jaxws bundle change without being renamed? > > > I certainly hope not. > > These are the md5 sums I have on all the bundles: > > bonsai<11> /usr/bin/sum -x md5 ?/java/devtools/share/jdk*drops/*.zip > 7a50bb540a27cdd0001885630088b758 > /java/devtools/share/jdk6-drops/jdk6-jaf-2009_10_27.zip > 0bb03bbd7b1b6d87cc65772c6adb2d6a > /java/devtools/share/jdk6-drops/jdk6-jaxp-2009_10_27.zip > 3ea5728706169498b722b898a1008acf > /java/devtools/share/jdk6-drops/jdk6-jaxws-2009_10_27.zip > eb8cb7a4a7f14e211fbe2354878a2472 > /java/devtools/share/jdk7-drops/jdk7-jaf-2009_08_28.zip > d99f4777bc4c42d7759f7c0fcf87ef5d > /java/devtools/share/jdk7-drops/jdk7-jaxp-2009_08_28.zip > 8800970d03bab1fff188dcfafc346f5d > /java/devtools/share/jdk7-drops/jdk7-jaxp-2009_09_28.zip > 8b58ce7919cda8e32a9afc5cb4b58bb1 > /java/devtools/share/jdk7-drops/jdk7-jaxp-m5.zip > debb949440c5a15ce999cfefbbc56526 > /java/devtools/share/jdk7-drops/jdk7-jaxws-2009_08_28.zip > f5010ebf636db9f465a61a7a74944543 > /java/devtools/share/jdk7-drops/jdk7-jaxws-2009_09_28.zip > > -kto > > > > Ok it appears I have 08_28 masquerading as 09_28. ?Thanks. > -- > Andrew :-) > > Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > Support Free Java! > Contribute to GNU Classpath and the OpenJDK > http://www.gnu.org/software/classpath > http://openjdk.java.net > > PGP Key: 94EFD9D8 (http://subkeys.pgp.net) > Fingerprint: F8EF F1EA 401E 2E60 15FA ?7927 142C 2591 94EF D9D8 > > > > Ok here's the webrev for the ALT_DROPS_DIR change against tl: > > http://cr.openjdk.java.net/~andrew/drops/webrev.02/ > > Ok to push? Do we have a bug ID for this? > > Thanks, > > > Andrew, > > Some of the comments in the Makefiles need to be updated -- for example, > references to devtools in lines 89, 100 > > -- Jon > Well spotted; revised version here: http://cr.openjdk.java.net/~andrew/drops/webrev.03/ -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From gnu_andrew at member.fsf.org Wed Oct 28 16:04:13 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Wed, 28 Oct 2009 23:04:13 +0000 Subject: 6856630: Restructure jaxp/jaxws repository In-Reply-To: <4AE8BF5E.4060406@sun.com> References: <4AB80C37.6000108@sun.com> <17c6771e0910271802n54a67e2cq4d547c592d817e94@mail.gmail.com> <4AE79AF9.5090206@sun.com> <4AE87777.6000001@sun.com> <17c6771e0910281050j4d315cfcm231573f7b284b07f@mail.gmail.com> <17c6771e0910281137k38935208j606eb869345ada59@mail.gmail.com> <4AE89163.3090905@sun.com> <17c6771e0910281214x60d5c44bx33524d7729c1b49f@mail.gmail.com> <4AE89BDE.4010008@sun.com> <4AE8BF5E.4060406@sun.com> Message-ID: <17c6771e0910281604m4ebae8cw5e91d661005e8167@mail.gmail.com> 2009/10/28 Jonathan Gibbons : > Kelly O'Hair wrote: >> >> [snip] >> >> These are the md5 sums I have on all the bundles: >> >> bonsai<11> /usr/bin/sum -x md5 ?/java/devtools/share/jdk*drops/*.zip >> 7a50bb540a27cdd0001885630088b758 >> /java/devtools/share/jdk6-drops/jdk6-jaf-2009_10_27.zip >> 0bb03bbd7b1b6d87cc65772c6adb2d6a >> /java/devtools/share/jdk6-drops/jdk6-jaxp-2009_10_27.zip >> 3ea5728706169498b722b898a1008acf >> /java/devtools/share/jdk6-drops/jdk6-jaxws-2009_10_27.zip >> eb8cb7a4a7f14e211fbe2354878a2472 >> /java/devtools/share/jdk7-drops/jdk7-jaf-2009_08_28.zip >> d99f4777bc4c42d7759f7c0fcf87ef5d >> /java/devtools/share/jdk7-drops/jdk7-jaxp-2009_08_28.zip >> 8800970d03bab1fff188dcfafc346f5d >> /java/devtools/share/jdk7-drops/jdk7-jaxp-2009_09_28.zip >> 8b58ce7919cda8e32a9afc5cb4b58bb1 >> /java/devtools/share/jdk7-drops/jdk7-jaxp-m5.zip >> debb949440c5a15ce999cfefbbc56526 >> /java/devtools/share/jdk7-drops/jdk7-jaxws-2009_08_28.zip >> f5010ebf636db9f465a61a7a74944543 >> /java/devtools/share/jdk7-drops/jdk7-jaxws-2009_09_28.zip >> >> -kto > > > > Given that the bundles include the jdk name (jdk6, jdk7), is it really > necessary to have separate bundle directories (jdk6-drops, jdk7-drops)? > ?It's not a big deal, but on my local cache of these files, I was certainly > thinking to merge these directories so that I can have the same value for > ALT_DROPS_DIR for both JDK 6 and 7. > > -- Jon > > > Likewise, I wouldn't want to have to alter my build for jdk6. The ALT_DROPS_DIR setting overrides the jdk6-drops part of the path as well so a single drops directory can be used. Probably worth doing this with the default too. -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From kelly.ohair at sun.com Wed Oct 28 16:30:58 2009 From: kelly.ohair at sun.com (kelly.ohair at sun.com) Date: Wed, 28 Oct 2009 23:30:58 +0000 Subject: hg: jdk7/build/jdk: 25 new changesets Message-ID: <20091028233621.60AE441650@hg.openjdk.java.net> Changeset: 3b45b809d8ff Author: darcy Date: 2009-10-09 16:11 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/3b45b809d8ff 6797535: Add shared two argument static equals method to the platform Reviewed-by: sherman ! make/java/java/FILES_java.gmk + src/share/classes/java/util/Objects.java + test/java/util/Objects/BasicObjectsTest.java Changeset: b84f40617f90 Author: alanb Date: 2009-10-09 09:59 +0100 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/b84f40617f90 6889552: Sun provider should not require LDAP CertStore to be present Reviewed-by: vinnie, mullan ! src/share/classes/sun/security/provider/SunEntries.java + src/share/classes/sun/security/provider/certpath/CertStoreHelper.java - src/share/classes/sun/security/provider/certpath/LDAPCertStore.java ! src/share/classes/sun/security/provider/certpath/URICertStore.java + src/share/classes/sun/security/provider/certpath/ldap/LDAPCertStore.java + src/share/classes/sun/security/provider/certpath/ldap/LDAPCertStoreHelper.java Changeset: a7ad133103c6 Author: alanb Date: 2009-10-09 10:06 +0100 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/a7ad133103c6 6888552: Allow JNDI to be used when java.applet is not present Reviewed-by: vinnie ! src/share/classes/com/sun/naming/internal/ResourceManager.java Changeset: f6770138c0fa Author: alanb Date: 2009-10-10 10:14 +0100 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/f6770138c0fa Merge Changeset: 9d240dbadaa3 Author: darcy Date: 2009-10-13 14:08 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/9d240dbadaa3 6648344: (reflect spec) State default of isAccessible for reflective objects Reviewed-by: alanb ! src/share/classes/java/lang/reflect/AccessibleObject.java + test/java/lang/reflect/DefaultAccessibility.java Changeset: 151baf5e19ca Author: darcy Date: 2009-10-13 17:34 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/151baf5e19ca 6349921: (enum) Include links from java.lang.Enum to EnumSet and EnumMap Reviewed-by: martin ! src/share/classes/java/lang/Enum.java Changeset: 5f326176855d Author: mullan Date: 2009-10-14 09:36 -0400 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/5f326176855d 6885667: CertPath/CertPathValidatorTest/bugs/bug6383078 fails on jdk6u18/b02, jdk7/pit/b73 and passes on b72. Summary: Wrap all OCSP exceptions in CertPathValidatorException so that we can fallback to CRLs, if enabled. Reviewed-by: dgu, xuelei ! src/share/classes/sun/security/provider/certpath/OCSP.java ! src/share/classes/sun/security/provider/certpath/OCSPChecker.java Changeset: edeb687e2d9a Author: mullan Date: 2009-10-14 09:47 -0400 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/edeb687e2d9a Merge Changeset: 16b33372af1c Author: mchung Date: 2009-10-14 20:16 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/16b33372af1c 6891701: test/java/lang/management/RuntimeMXBean/GetSystemProperties should restore the system property Summary: Restore the system properties when the test finishes Reviewed-by: jjg ! test/java/lang/management/RuntimeMXBean/GetSystemProperties.java ! test/java/lang/management/RuntimeMXBean/PropertiesTest.java Changeset: 57fe28f3878a Author: michaelm Date: 2009-10-15 12:03 +0100 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/57fe28f3878a 6886436: Lightwight HTTP Container (com.sun.* package) is unstable Reviewed-by: chegar ! src/share/classes/sun/net/httpserver/ExchangeImpl.java ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java + test/com/sun/net/httpserver/bugs/B6886436.java Changeset: 9cf64e7a9978 Author: michaelm Date: 2009-10-15 12:05 +0100 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/9cf64e7a9978 Merge - src/share/classes/sun/security/provider/certpath/LDAPCertStore.java Changeset: f6833a276c1d Author: alanb Date: 2009-10-15 11:54 +0100 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/f6833a276c1d 6883983: JarVerifier dependency on sun.security.pkcs should be removed Reviewed-by: sherman, wetmore ! src/share/classes/java/util/jar/JarVerifier.java Changeset: cb903c9eaebf Author: alanb Date: 2009-10-15 11:55 +0100 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/cb903c9eaebf 6891404: (fs) ACL tests fail with "Invalid argument" on ZFS (sol) Reviewed-by: sherman ! src/solaris/classes/sun/nio/fs/SolarisAclFileAttributeView.java ! test/java/nio/file/attribute/AclFileAttributeView/Basic.java Changeset: 0f92452973eb Author: alanb Date: 2009-10-15 14:02 +0100 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/0f92452973eb Merge Changeset: f85aa3aedf41 Author: darcy Date: 2009-10-15 18:27 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/f85aa3aedf41 4428022: System.out.println(0.001) outputs 0.0010 Reviewed-by: darcy Contributed-by: aph at redhat.com ! src/share/classes/sun/misc/FloatingDecimal.java + test/java/lang/Double/ToString.java Changeset: 16e4bbb7488d Author: mchung Date: 2009-10-15 17:36 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/16e4bbb7488d 6891707: Eliminate the java.io.FilePermission dependency on PolicyFile Summary: Replace call to PolicyFile.canonPath with its own implementation Reviewed-by: alanb, mullan ! src/share/classes/java/io/FilePermission.java ! src/share/classes/sun/security/provider/PolicyFile.java Changeset: f1dab27d668a Author: mchung Date: 2009-10-15 20:18 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/f1dab27d668a Merge Changeset: 368bb282464a Author: tbell Date: 2009-10-15 22:47 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/368bb282464a Merge - src/share/classes/sun/security/provider/certpath/LDAPCertStore.java Changeset: d9f41daf8bcc Author: alanb Date: 2009-10-19 19:58 +0100 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/d9f41daf8bcc 6892710: (file) test/java/nio/file/Path/CheckPermissions.java fails in samevm mode Reviewed-by: ohair ! test/java/nio/file/Files/ContentType.java ! test/java/nio/file/Path/CheckPermissions.java Changeset: 5c6c6627b0b7 Author: alanb Date: 2009-10-19 19:59 +0100 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/5c6c6627b0b7 6892711: (file) test/java/nio/file/Path/CopyAndMove.java fails on Windows 2000 Reviewed-by: ohair ! test/java/nio/file/Path/CopyAndMove.java Changeset: 169ced1d9939 Author: alanb Date: 2009-10-19 20:01 +0100 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/169ced1d9939 6879463: (file) DirectoryStream#iterator's remove method throws wrong exception when stream is closed Reviewed-by: sherman ! src/solaris/classes/sun/nio/fs/UnixDirectoryStream.java ! src/windows/classes/sun/nio/fs/WindowsDirectoryStream.java ! test/java/nio/file/DirectoryStream/Basic.java Changeset: d71241866584 Author: alanb Date: 2009-10-19 20:02 +0100 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/d71241866584 6884480: (file) Path.relativize has typo in parameter description Reviewed-by: chegar ! src/share/classes/java/nio/file/Path.java Changeset: 121284d0489d Author: jjg Date: 2009-10-19 13:43 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/121284d0489d 6889255: javac MethodSymbol throws NPE if ClassReader does not read parameter names correctly Reviewed-by: darcy ! make/common/shared/Defs-java.gmk Changeset: 1602e8848bde Author: darcy Date: 2009-10-19 16:31 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/1602e8848bde 6889858: Add nonNull methods to java.util.Objects Reviewed-by: darcy Contributed-by: jjb at google.com ! src/share/classes/java/util/Objects.java ! test/java/util/Objects/BasicObjectsTest.java Changeset: 009477966682 Author: ohair Date: 2009-10-28 16:26 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/009477966682 Merge - src/share/classes/sun/security/provider/certpath/LDAPCertStore.java From kelly.ohair at sun.com Wed Oct 28 16:36:37 2009 From: kelly.ohair at sun.com (kelly.ohair at sun.com) Date: Wed, 28 Oct 2009 23:36:37 +0000 Subject: hg: jdk7/build/langtools: 7 new changesets Message-ID: <20091028233650.89C2141651@hg.openjdk.java.net> Changeset: e526e39579ae Author: jjg Date: 2009-10-13 14:02 -0700 URL: http://hg.openjdk.java.net/jdk7/build/langtools/rev/e526e39579ae 6887895: CONSTANT_Class_info getBaseName does not handle arrays of primitives correctly Reviewed-by: ksrini ! src/share/classes/com/sun/tools/classfile/ConstantPool.java + test/tools/javap/classfile/T6887895.java Changeset: 8a4543b30586 Author: jjg Date: 2009-10-13 15:26 -0700 URL: http://hg.openjdk.java.net/jdk7/build/langtools/rev/8a4543b30586 6891079: Compiler allows invalid binary literals 0b and oBL Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/parser/Scanner.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties + test/tools/javac/literals/T6891079.java + test/tools/javac/literals/T6891079.out Changeset: 86b773b7cb40 Author: jjg Date: 2009-10-14 15:41 -0700 URL: http://hg.openjdk.java.net/jdk7/build/langtools/rev/86b773b7cb40 6838467: JSR199 FileObjects don't obey general contract of equals. Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/file/BaseFileObject.java ! src/share/classes/com/sun/tools/javac/file/JavacFileManager.java ! src/share/classes/com/sun/tools/javac/file/RegularFileObject.java ! src/share/classes/com/sun/tools/javac/file/SymbolArchive.java ! src/share/classes/com/sun/tools/javac/file/ZipArchive.java ! src/share/classes/com/sun/tools/javac/file/ZipFileIndex.java ! src/share/classes/com/sun/tools/javac/file/ZipFileIndexArchive.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! test/tools/javac/api/6440528/T6440528.java + test/tools/javac/api/T6838467.java Changeset: b8936a7930fe Author: darcy Date: 2009-10-14 18:56 -0700 URL: http://hg.openjdk.java.net/jdk7/build/langtools/rev/b8936a7930fe 6558804: Specification for Elements.getDocComment(Element e) should be clarified Reviewed-by: jjg ! src/share/classes/javax/lang/model/util/Elements.java Changeset: d1e62f78c48b Author: tbell Date: 2009-10-15 22:48 -0700 URL: http://hg.openjdk.java.net/jdk7/build/langtools/rev/d1e62f78c48b Merge Changeset: 6ba399eff2cb Author: jjg Date: 2009-10-16 12:56 -0700 URL: http://hg.openjdk.java.net/jdk7/build/langtools/rev/6ba399eff2cb 6888367: classfile library parses signature attributes incorrectly Reviewed-by: ksrini ! src/share/classes/com/sun/tools/classfile/Signature.java ! src/share/classes/com/sun/tools/classfile/Type.java ! src/share/classes/com/sun/tools/javap/ClassWriter.java ! src/share/classes/com/sun/tools/javap/LocalVariableTypeTableWriter.java + test/tools/javap/classfile/6888367/T6888367.java Changeset: 2485f5641ed0 Author: jjg Date: 2009-10-19 13:38 -0700 URL: http://hg.openjdk.java.net/jdk7/build/langtools/rev/2485f5641ed0 6889255: javac MethodSymbol throws NPE if ClassReader does not read parameter names correctly Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java + test/tools/javac/6889255/T6889255.java From kelly.ohair at sun.com Wed Oct 28 19:43:32 2009 From: kelly.ohair at sun.com (kelly.ohair at sun.com) Date: Thu, 29 Oct 2009 02:43:32 +0000 Subject: hg: jdk7/build: 6865492: /java/devtools/win32/bin/gnumake.exe doesn't work with cygwin Message-ID: <20091029024332.6410E41684@hg.openjdk.java.net> Changeset: 696a6a5030b0 Author: ohair Date: 2009-10-28 13:44 -0700 URL: http://hg.openjdk.java.net/jdk7/build/rev/696a6a5030b0 6865492: /java/devtools/win32/bin/gnumake.exe doesn't work with cygwin Reviewed-by: robilad ! README-builds.html From kelly.ohair at sun.com Wed Oct 28 19:44:21 2009 From: kelly.ohair at sun.com (kelly.ohair at sun.com) Date: Thu, 29 Oct 2009 02:44:21 +0000 Subject: hg: jdk7/build/jdk: 3 new changesets Message-ID: <20091029024500.2598141685@hg.openjdk.java.net> Changeset: 1083413440ee Author: ohair Date: 2009-10-28 12:54 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/1083413440ee 6888701: Change all template java source files to a .java-template file suffix Reviewed-by: jjg, alanb, mr ! make/common/Release.gmk ! make/common/Rules.gmk ! make/java/nio/Makefile ! make/java/nio/genBuffer.sh ! make/java/version/Makefile ! make/netbeans/jconsole/build.properties ! make/netbeans/jconsole/build.xml ! make/sun/jconsole/Makefile ! make/sun/nio/Makefile - src/share/classes/java/nio/ByteBufferAs-X-Buffer.java + src/share/classes/java/nio/ByteBufferAs-X-Buffer.java.template - src/share/classes/java/nio/Direct-X-Buffer-bin.java + src/share/classes/java/nio/Direct-X-Buffer-bin.java.template - src/share/classes/java/nio/Direct-X-Buffer.java + src/share/classes/java/nio/Direct-X-Buffer.java.template - src/share/classes/java/nio/Heap-X-Buffer.java + src/share/classes/java/nio/Heap-X-Buffer.java.template - src/share/classes/java/nio/X-Buffer-bin.java + src/share/classes/java/nio/X-Buffer-bin.java.template - src/share/classes/java/nio/X-Buffer.java + src/share/classes/java/nio/X-Buffer.java.template - src/share/classes/java/nio/charset/Charset-X-Coder.java + src/share/classes/java/nio/charset/Charset-X-Coder.java.template - src/share/classes/sun/misc/Version-template.java + src/share/classes/sun/misc/Version.java.template - src/share/classes/sun/tools/jconsole/Version-template.java + src/share/classes/sun/tools/jconsole/Version.java.template - test/java/nio/Buffer/Basic-X.java + test/java/nio/Buffer/Basic-X.java.template - test/java/nio/Buffer/CopyDirect-X-Memory.java + test/java/nio/Buffer/CopyDirect-X-Memory.java.template ! test/java/nio/Buffer/genBasic.sh ! test/java/nio/Buffer/genCopyDirectMemory.sh Changeset: bf6b160b455d Author: ohair Date: 2009-10-28 13:00 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/bf6b160b455d 6888709: Change use of -DX=\""Y\"" to -DX='"Y"', consistently for all platforms Reviewed-by: jjg, tbell ! make/common/Defs.gmk ! make/common/Program.gmk ! make/java/main/java/Makefile ! make/java/main/javaw/Makefile ! make/javax/sound/Makefile ! make/launchers/Makefile.launcher Changeset: 72a511cf2019 Author: ohair Date: 2009-10-28 16:54 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/72a511cf2019 Merge - src/share/classes/java/nio/ByteBufferAs-X-Buffer.java - src/share/classes/java/nio/Direct-X-Buffer-bin.java - src/share/classes/java/nio/Direct-X-Buffer.java - src/share/classes/java/nio/Heap-X-Buffer.java - src/share/classes/java/nio/X-Buffer-bin.java - src/share/classes/java/nio/X-Buffer.java - src/share/classes/java/nio/charset/Charset-X-Coder.java - src/share/classes/sun/misc/Version-template.java - src/share/classes/sun/tools/jconsole/Version-template.java - test/java/nio/Buffer/Basic-X.java - test/java/nio/Buffer/CopyDirect-X-Memory.java