From mike.duigou at oracle.com Fri Mar 1 00:34:04 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Thu, 28 Feb 2013 16:34:04 -0800 Subject: Review Request: 8004352: build-infra: Limit JOBS on large machines In-Reply-To: <5122177B.2030003@oracle.com> References: <511E24B6.2040309@oracle.com> <97C179D7-3CD4-4213-AA39-A61E735D7136@oracle.com> <51220E27.8090509@oracle.com> <5122177B.2030003@oracle.com> Message-ID: <92916F09-957E-4AEB-9527-95253422F4F2@oracle.com> Looks good to me. Mike On Feb 18 2013, at 03:58 , Erik Joelsson wrote: > New webrev: > > http://cr.openjdk.java.net/~erikj/8004352/webrev.root.02/ > > Moved the cap last. Changed the 1000 to 1100. Also scaling down to 90% is only done when cores is the limiting factor. > > I read your bug and now I understand what you mean about the constants. I agree that would be a good idea. > > /Erik > > On 2013-02-18 12:19, Erik Joelsson wrote: >> >> >> On 2013-02-15 18:12, Mike Duigou wrote: >>> A couple of comments; >>> >>> - Can you reverse steps #2 and #3? Having the hard cap last makes more sense. >> I agree and will do. >>> - In JDK-8007327 I requested some memory size definitions such as MEMORY_SIZE_NORMAL_HEAP for sizing of JVM heaps. The explicit "1000" should probably be replaced with the MEMORY_SIZE_NORMAL_HEAP constant. Elsewhere the value is "1100". >>> >> I can't find any other reference to this constant, but I can certainly change it to 1100. I just wanted something lower than 1024 since the reported amount of memory in a machine is usually somewhat lower than the exact multiple of 2 and the division is rounded down. >>> - The CONCURRENT_BUILD_JOBS is no longer JOBS * 2. Do we think that's right? >> I think it's correct that you can squeeze out a bit more performance from the hotspot (or jdk native) build by using cores * 2 as number of jobs, but any value higher than cores will affect the third bullet point below (don't interfere with my browser experience while I'm building). I also found it weird to have a different setting for hotspot and the jdk native build and thought this a good opportunity to unify the settings. >> >> The problem is that if someone increases JOBS to cores * 2 for maximum speed, there will most likely be problems in the java source generation in the jdk, which is more memory intensive. My assumption is that the speed loss from cores * 2 to cores * 1 is small enough to not matter much. >> >> We could fix this, but I'm not sure it's worth the effort. The user just wants to say something like, "go full speed while I make coffee", "leave some room so my terminal doesn't lock up" or "I'm running 4 builds in parallel, tune it down please". This could be expressed as a percentage, with a suitable default. For each part of the build, where we make a submake call, we can add a call to calculate a suitable value for the -j flag. Input is a factor indicating memory to cpu requirements, the factor from the user (set at configure or at make invocation), the number of cpus (from configure) and the amount of memory (from configure). >> >> /Erik >>> Mike >>> >>> On Feb 15 2013, at 04:06 , Erik Joelsson wrote: >>> >>>> The current default for number of parallel build jobs is just equal to the number of cores in the system. While this works well on many machines, there have been several reports of this not working. I have been trying to come up with a better scheme for the default and the following is something that I think will do. It has been active in the build-infra forest for a while now. >>>> >>>> The complaints that were raised were usually concerning one of the following: >>>> >>>> * A big machine with very many cpus didn't scale well when using all of them, so there is no point in trying to, it just made the build less stable. Suggestion, introduce a hard cap. >>>> * A machine with lots of cpus but not as much memory would run out of memory. Suggestion, limit number of jobs on memory as well as cpus. >>>> * The build eats up all my resources, leaving my browser unusable. Suggestion, don't use everything unless asked for. >>>> >>>> So this is what I ended up with: >>>> 1. Take the min of num_cores and memory_size/1000 >>>> 2. Cap at 16 >>>> 3. If more than 4 cores, shave it to 90% rounded down to leave some room. >>>> >>>> The user can still override this in two ways. Either by using any of the configure arguments: >>>> >>>> --with-num-cores number of cores in the build system, e.g. >>>> --with-num-cores=8 [probed] >>>> --with-memory-size memory (in MB) available in the build system, e.g. >>>> --with-memory-size=1024 [probed] >>>> --with-jobs number of parallel jobs to let make run [calculated >>>> based on cores and memory] >>>> >>>> Or by setting JOBS= on the make command line. >>>> >>>> Also not that this change will set the CONCURRENT_BUILD_JOBS for hotspot to the value of JOBS so that it too will be overridden by the above. >>>> >>>> http://cr.openjdk.java.net/~erikj/8004352/webrev.root.01/ >>>> >>>> /Erik From david.katleman at oracle.com Fri Mar 1 03:31:04 2013 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Fri, 01 Mar 2013 03:31:04 +0000 Subject: hg: jdk8/build/jdk: 8009196: install doesn't define $(AR) as /usr/ccs/bin/ar, results in ar: Command not found Message-ID: <20130301033138.8562A474DE@hg.openjdk.java.net> Changeset: b760d5d4b8d3 Author: katleman Date: 2013-02-28 19:30 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/b760d5d4b8d3 8009196: install doesn't define $(AR) as /usr/ccs/bin/ar, results in ar: Command not found Reviewed-by: tbell ! make/common/shared/Defs-utils.gmk From david.katleman at oracle.com Fri Mar 1 04:39:42 2013 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Fri, 01 Mar 2013 04:39:42 +0000 Subject: hg: jdk8/build: 2 new changesets Message-ID: <20130301043942.DC658474E5@hg.openjdk.java.net> Changeset: 85b5b4cc388c Author: katleman Date: 2013-02-28 10:41 -0800 URL: http://hg.openjdk.java.net/jdk8/build/rev/85b5b4cc388c Added tag jdk8-b79 for changeset 91d35211e744 ! .hgtags Changeset: 0adf9c626bb1 Author: katleman Date: 2013-02-28 20:29 -0800 URL: http://hg.openjdk.java.net/jdk8/build/rev/0adf9c626bb1 Merge From david.katleman at oracle.com Fri Mar 1 04:39:50 2013 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Fri, 01 Mar 2013 04:39:50 +0000 Subject: hg: jdk8/build/corba: Added tag jdk8-b79 for changeset e41fb1aa0329 Message-ID: <20130301043952.6B4AC474E6@hg.openjdk.java.net> Changeset: 5f3d4a6bdd02 Author: katleman Date: 2013-02-28 10:41 -0800 URL: http://hg.openjdk.java.net/jdk8/build/corba/rev/5f3d4a6bdd02 Added tag jdk8-b79 for changeset e41fb1aa0329 ! .hgtags From david.katleman at oracle.com Fri Mar 1 04:40:34 2013 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Fri, 01 Mar 2013 04:40:34 +0000 Subject: hg: jdk8/build/hotspot: Added tag jdk8-b79 for changeset 6691814929b6 Message-ID: <20130301044040.385F0474E9@hg.openjdk.java.net> Changeset: 5d395eb2626f Author: katleman Date: 2013-02-28 10:42 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/5d395eb2626f Added tag jdk8-b79 for changeset 6691814929b6 ! .hgtags From david.katleman at oracle.com Fri Mar 1 04:41:54 2013 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Fri, 01 Mar 2013 04:41:54 +0000 Subject: hg: jdk8/build/jaxp: Added tag jdk8-b79 for changeset 58fa065dd5d6 Message-ID: <20130301044200.3234E474ED@hg.openjdk.java.net> Changeset: 4873a0499bc3 Author: katleman Date: 2013-02-28 10:42 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jaxp/rev/4873a0499bc3 Added tag jdk8-b79 for changeset 58fa065dd5d6 ! .hgtags From david.katleman at oracle.com Fri Mar 1 04:42:05 2013 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Fri, 01 Mar 2013 04:42:05 +0000 Subject: hg: jdk8/build/jaxws: Added tag jdk8-b79 for changeset 70d8658d2a30 Message-ID: <20130301044209.8C793474EF@hg.openjdk.java.net> Changeset: b0224010e2f0 Author: katleman Date: 2013-02-28 10:42 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jaxws/rev/b0224010e2f0 Added tag jdk8-b79 for changeset 70d8658d2a30 ! .hgtags From david.katleman at oracle.com Fri Mar 1 04:42:21 2013 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Fri, 01 Mar 2013 04:42:21 +0000 Subject: hg: jdk8/build/jdk: 2 new changesets Message-ID: <20130301044313.54807474F0@hg.openjdk.java.net> Changeset: d967dd39a5ca Author: katleman Date: 2013-02-28 10:42 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/d967dd39a5ca Added tag jdk8-b79 for changeset c933505d75c2 ! .hgtags Changeset: dfb40f066c6c Author: katleman Date: 2013-02-28 20:30 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/dfb40f066c6c Merge From david.katleman at oracle.com Fri Mar 1 04:44:56 2013 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Fri, 01 Mar 2013 04:44:56 +0000 Subject: hg: jdk8/build/langtools: Added tag jdk8-b79 for changeset 56dfafbb9e1a Message-ID: <20130301044506.4AD15474F2@hg.openjdk.java.net> Changeset: a8227c617684 Author: katleman Date: 2013-02-28 10:43 -0800 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/a8227c617684 Added tag jdk8-b79 for changeset 56dfafbb9e1a ! .hgtags From christian.thalinger at oracle.com Fri Mar 1 05:43:14 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 28 Feb 2013 21:43:14 -0800 Subject: RFR (S): 8006965: test_gamma should run with import JDK In-Reply-To: References: <645283DC-655E-4FA7-A0EA-676D08559F5B@oracle.com> <8CF27CFE-174B-44BA-ABAE-52D3D931DFBF@oracle.com> <512A9A3F.4070402@oracle.com> <6FD71E10-9866-42F5-8201-60FB237AD988@oracle.com> <512C632B.3070206@oracle.com> Message-ID: <1687588F-E191-4ADD-A932-37079E97B2AF@oracle.com> On Feb 26, 2013, at 6:09 PM, Christian Thalinger wrote: > > On Feb 25, 2013, at 11:24 PM, David Holmes wrote: > >> On 26/02/2013 4:42 AM, Christian Thalinger wrote: >>> On Feb 24, 2013, at 2:54 PM, David Holmes wrote: >>>> On 23/02/2013 1:55 PM, Christian Thalinger wrote: >>>>> I talked to a lot of people about this today. What we really want is to not run tests when we build. Mikael and I were looking into how we could do that without gamma and there is a way: >>>>> >>>>> http://cr.openjdk.java.net/~twisti/8006965/ >>>>> >>>>> This would be the first of three fixes: >>>>> >>>>> Fix 1) The patch above removes test_gamma and uses some weirdness in the VM (-Dsun.java.launcher=gamma) to run it with an existing JDK; add test_{product,fastdebug,debug} targets >>>> >>>> This logic is not suitable: >>>> >>>> 541 # Testing the built JVM >>>> 542 ifeq ($(JAVA_HOME),) >>>> 543 RUN_JVM=JAVA_HOME=$(JDK_IMPORT_PATH) $(JDK_IMPORT_PATH)/bin/java -d$(ARCH_DATA_MODEL) -server -XXaltjvm=$(MISC_DIR)/$(VM_FLAVOR) -Dsun.java.launcher=gamma >>>> 544 else >>>> 545 RUN_JVM=$(JAVA_HOME)/bin/java -d$(ARCH_DATA_MODEL) -server -XXaltjvm=$(MISC_DIR)/$(VM_FLAVOR) -Dsun.java.launcher=gamma >>>> 546 endif >>>> >>>> I have JAVA_HOME set in my environment for use by other tools/scripts and it points at JDK7. The existing logic does not use my environments JAVA_HOME setting so neither should the revised logic! >>> >>> That's not entirely correct. test_gamma uses your JAVA_HOME setting: >> >> This is so confusing. Our makefiles are an abomination! > > I couldn't agree more. > >> >> So this all started because the makefile has: >> >> JAVA_HOME=$(ABS_BOOTDIR) >> >> which was flagged as wrong because gamma would run in the boot JDK. But now it seems the make variable JAVA_HOME is irrelevant anyway because the test_gamma script will use the JAVA_HOME environment variable. >> >> So how did the boot JDK come back into this??? >> >>> cthaling at sc14a501:/export/twisti/build/graal/build/linux_amd64_compiler2/product$ export JAVA_HOME=/java/re/jdk/8/latest/binaries/linux-x64 >>> cthaling at sc14a501:/export/twisti/build/graal/build/linux_amd64_compiler2/product$ ./test_gamma >>> Using java runtime at: /java/re/jdk/8/latest/binaries/linux-x64/jre >>> >>> cthaling at sc14a501:/export/twisti/build/graal/build/linux_amd64_compiler2/product$ export JAVA_HOME=/foo >>> cthaling at sc14a501:/export/twisti/build/graal/build/linux_amd64_compiler2/product$ ./test_gamma >>> JAVA_HOME must point to a 64-bit OpenJDK. >>> >>> And here comes this little snippet into play: >>> >>> -MAKE_ARGS += JAVA_HOME=$(ABS_BOOTDIR) >>> +MAKE_ARGS += BOOTDIR=$(ABS_BOOTDIR) >>> >>> Only setting JAVA_HOME to ABS_BOOTDIR make test_gamma work even if you have a JAVA_HOME set. >> >> I still don't get this. What has BOOTDIR got to do with JAVA_HOME? Where is this BOOTDIR value being used? There is no use of it in http://cr.openjdk.java.net/~twisti/8006965/8006965.patch and I don't see it pre-existing ?? > > I talked to John Coomes about that yesterday and we can remove that line. ABS_BOOTDIR is only used by Windows. Btw. I've updated the webrev. I think we can also remove the -server switch from the run command line because we point the VM to the libjvm anyway. How about this change? -- Chris > > -- Chris > >> >> Thanks, >> David >> >>> I have added this logic so that users can control what JDK is used when running the test. In fact they should use ALT_JDK_IMPORT_PATH if they want to control that. >>> >>>> >>>> I also don't see why the above sets JAVA_HOME at #543 - what will read that environment variable? >>> >>> It's the odd logic in os::jvm_path guarded by Arguments::created_by_gamma_launcher(). A clean-up of that logic would be part of Fix 3. >>> >>>> >>>> I still have concerns over what JDK_IMPORT_PATH will point to for different JDK builders. >>> >>> It's either JDK_IMPORT_PATH or JDK_IMAGE_DIR. Since most people don't want to export their libjvm into a JDK we have to use JDK_IMPORT_PATH. We could add some logic that checks if JDK_IMAGE_DIR exists and use that one. >>> >>> -- Chris >>> >>>> >>>> And this addition still makes no sense to me: >>>> >>>> MAKE_ARGS += BOOTDIR=$(ABS_BOOTDIR) >>>> >>>> Why do you need to add BOOTDIR to the MAKE_ARGS? >>>> >>>> David >>>> >>>> >>>>> Fix 2) Remove gamma and all the ugly code that comes with it (copies of the jdk launcher in hotspot and other pieces); make the hotspot script work like the test targets in Fix 1 >>>>> >>>>> Fix 3) Remove the -Dsun.java.launcher=gamma and possibly replace the existing -Dsun.boot.library.path weirdness by explicit command line options like -Xbootlibrarypath:{/p,/a} >>>>> >>>>> -- Chris >>>>> >>>>> On Feb 22, 2013, at 3:21 PM, Christian Thalinger wrote: >>>>> >>>>>> >>>>>> On Feb 22, 2013, at 12:58 AM, Staffan Larsen wrote: >>>>>> >>>>>>> I'm not sure what the correct solution is, but when you do find out, the jdkpath.sh target should also be updated. >>>>>> >>>>>> How many are actually using the hotspot script? Would people be very sentimental if we would remove the gamma launcher altogether? >>>>>> >>>>>> Taking to people here it seems that most are copying their libjvm into a JDK and use java anyway. >>>>>> >>>>>> -- Chris >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> /Staffan >>>>>>> >>>>>>> On 22 feb 2013, at 03:40, Christian Thalinger wrote: >>>>>>> >>>>>>>> http://cr.openjdk.java.net/~twisti/8006965 >>>>>>>> >>>>>>>> 8006965: test_gamma should run with import JDK >>>>>>>> Reviewed-by: >>>>>>>> >>>>>>>> Right now test_gamma runs with the boot JDK which is JDK n-1 (where >>>>>>>> JDK n is the version we are actually compiling for). This setup is >>>>>>>> unsupported and thus should not be done during HotSpot builds. >>>>>>>> >>>>>>>> The fix is to always use JDK_IMPORT_PATH instead of JAVA_HOME when >>>>>>>> running test_gamma. >>>>>>>> >>>>>>>> make/bsd/makefiles/buildtree.make >>>>>>>> make/defs.make >>>>>>>> make/linux/makefiles/buildtree.make >>>>>>>> make/solaris/makefiles/buildtree.make > From david.holmes at oracle.com Fri Mar 1 06:48:02 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 01 Mar 2013 16:48:02 +1000 Subject: Review Request: JDK-8009196 install doesn't define $(AR) as /usr/ccs/bin/ar, results in ar: Command not found In-Reply-To: <512FB319.9000506@oracle.com> References: <512FB319.9000506@oracle.com> Message-ID: <51304F22.2050307@oracle.com> Dave, On 1/03/2013 5:42 AM, David Katleman wrote: > Modification to an earlier fix which broke internal Solaris builds, > because ar could not be found. > > Rather than the hatchet Erik's fix took to the problem, separating the > CROSS_COMPILE_ARCH portion into it's own if, and the second portion into > it's own Solaris only if since the ccs path is valid only on Solaris, > and the original fix was to avoid this whole section for Windows. I don't grok this fix. What Erik added was the "ifndef CONFIGURE_BUILD" around the existing if/else block. That if/else block has existed as part of the old build for a long time. What you have done now would break cross-compiling on Solaris in the old build - we don't do that but that doesn't chang the invalidity of the fix. The whole "ifndef CONFIGURE_BUILD" guard to was to bypass the local tool definitions if configure had already set them, so that Windows sanity passed. The flaw in that fix was that it impacted all platforms, not just Windows, and it changed the "all" target in addition to the sanity one. What you do now is not by-pass the block if configure is used, but simply ensure the block doesn't apply to Windows whether configure was used or not. I would question if this in fact breaks the old build. David > http://cr.openjdk.java.net/~katleman/8009196/webrev.jdk.01/ > > For reference, the original fix > > http://cr.openjdk.java.net/~erikj/8007903/webrev.jdk.01/ > > Thanks > Dave From Alan.Bateman at oracle.com Fri Mar 1 09:49:24 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 01 Mar 2013 09:49:24 +0000 Subject: demos and images In-Reply-To: <38233775-E222-41E4-A306-5BCACDA0B7BA@oracle.COM> References: <38233775-E222-41E4-A306-5BCACDA0B7BA@oracle.COM> Message-ID: <513079A4.8050709@oracle.com> On 27/02/2013 19:44, Mike Duigou wrote: > The demos target is being built as a pre-requisite to building images. This was probably done for compatibility the the old build system. How soon before we can we break this bogusness? > > Mike The demos have traditionally been included in the SDK image (demo directory). Oracle downloads put the demos and sample into a separate download, so maybe that is what you mean? -Alan From Alan.Bateman at oracle.com Fri Mar 1 14:44:09 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 01 Mar 2013 14:44:09 +0000 Subject: Do not let internal JDK zlib symbols leak out of fastdebug libzip.so In-Reply-To: References: <5128AD43.2000809@oracle.com> <51292295.4040802@oracle.com> <512F63AB.2050204@oracle.com> Message-ID: <5130BEB9.7080801@oracle.com> On 28/02/2013 16:11, Martin Buchholz wrote: > > > On Thu, Feb 28, 2013 at 6:03 AM, Alan Bateman > wrote: > > The update to make/java/zip/Makefile looks good to me, we should > have done it a long time ago. I assume you are pushing ahead on > this because you want to push it to jdk7u-dev (as it's not > interesting to jdk8 now because of the new build). > > > Yes I'm hoping you push this fix to jdk7u. > > Also, I'm not sure that the new build system will not try to be > bug-for-bug compatible with the old one and will reintroduce the problem. The old build is on life-support, I don't know how long it will before it will terminally break or be removed. In any case, I wouldn't expect anyone to decide to change it to not use the map files. > The exciting new exception detail change looks okay to me too > although it is hard to read. It wasn't immediately obvious to me > why stddef.h was needed and we'd need to make sure that is okay on > all platforms. > > > It's hard to find something more standard than stddef.h. > It's hard to find something as non-standard as Windows. My point was we just need to double check that this builds okay on Windows, which is does. So I think you are all set on this one. -Alan. From maurizio.cimadamore at oracle.com Fri Mar 1 14:57:20 2013 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 01 Mar 2013 14:57:20 +0000 Subject: build failure in nashorn with sjavac enabled Message-ID: <5130C1D0.8020304@oracle.com> Hi, I was doing experiments with the recently added sjavac flag to enable smart recompilation of JDK classes. I got a failure in Nashorn (I'm building on linux x64, Ubuntu 11.10): ## Starting nashorn Compiling BUILD_NASHORN Compiling 106 files in 7 packages (jdk.internal.dynalink to jdk.nashorn.internal.codegen.types) Compiling 117 files in 7 packages (jdk.nashorn.internal.ir to jdk.nashorn.internal.parser) Compiling 192 files in 14 packages (jdk.nashorn.internal.runtime to netscape.javascript) Compiling BUILD_NASGEN Compiling 19 files in 1 packages Compiling 33 files in 3 packages (commons to signature) Compiling 53 files in 3 packages (tree to util) invalid flag: /home/maurizio/Documents/ws/jdk8/tl/build/linux-x86_64-normal-server-release/nashorn/nasgen_classes invalid flag: /home/maurizio/Documents/ws/jdk8/tl/build/linux-x86_64-normal-server-release/nashorn/nasgen_classes invalid flag: /home/maurizio/Documents/ws/jdk8/tl/build/linux-x86_64-normal-server-release/nashorn/nasgen_classes make[1]: *** [/home/maurizio/Documents/ws/jdk8/tl/build/linux-x86_64-normal-server-release/nashorn/nasgen_classes/javac_state] Error 255 make: *** [nashorn-only] Error 2 Probably just matter of converting the Nashorn build files to be sjavac aware... Maurizio From kelly.ohair at oracle.com Fri Mar 1 16:19:44 2013 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Fri, 1 Mar 2013 08:19:44 -0800 Subject: Do not let internal JDK zlib symbols leak out of fastdebug libzip.so In-Reply-To: <5130BEB9.7080801@oracle.com> References: <5128AD43.2000809@oracle.com> <51292295.4040802@oracle.com> <512F63AB.2050204@oracle.com> <5130BEB9.7080801@oracle.com> Message-ID: <88A911BC-ED7F-47FF-A213-0FDE2F1D14E3@oracle.com> On Mar 1, 2013, at 6:44 AM, Alan Bateman wrote: >> It's hard to find something more standard than stddef.h. >> > It's hard to find something as non-standard as Windows. My point was we just need to double check that this builds okay on Windows, which is does. The only issue I have seen with adding includes, even standard ones like these, is that they tend to drag in so many more hidden include files, and there could be a chance at a compiler error. But that's fairly easy to diagnose, either it builds or it doesn't. What makes it a bit dangerous is that if it creates warning errors that are significant, we probably won't easily see them because we are not using -Werror across the board. :^( Having said that, my job is to be paranoid, and this does border on paranoia, so I say add the stddef.h and damn the torpedos, full steam ahead. -kto From kelly.ohair at oracle.com Fri Mar 1 17:18:14 2013 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Fri, 1 Mar 2013 09:18:14 -0800 Subject: New official README-builds.html Message-ID: Please do not 'reply all', send concerns or issues to just the build-dev or build-infra-dev aliases. The very latest README-builds.html file is: http://hg.openjdk.java.net/jdk8/jdk8/raw-file/tip/README-builds.html This documents the new build makefiles only. As with all documents of this type, it will always be a work in progress. -kto From boaznahum at gmail.com Sat Mar 2 18:00:36 2013 From: boaznahum at gmail.com (Boaz Nahum) Date: Sat, 2 Mar 2013 20:00:36 +0200 Subject: How to create docs in new build system Message-ID: make images doesn't build docs. How can I have docs built ? Thank Boaz From jonathan.gibbons at oracle.com Sat Mar 2 18:13:58 2013 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Sat, 02 Mar 2013 10:13:58 -0800 Subject: How to create docs in new build system In-Reply-To: References: Message-ID: <51324166.8050904@oracle.com> On 03/02/2013 10:00 AM, Boaz Nahum wrote: > make images > > doesn't build docs. > > How can I have docs built ? > > Thank > Boaz make docs -- Jon From mike.duigou at oracle.com Sun Mar 3 00:19:12 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Sat, 2 Mar 2013 16:19:12 -0800 Subject: How to create docs in new build system In-Reply-To: <51324166.8050904@oracle.com> References: <51324166.8050904@oracle.com> Message-ID: <7A4AF96D-5706-496E-9887-A58F8EC6FCA4@oracle.com> I just noticed on Friday that make docs is missing from make help. I will submit an rfe. On 2013-03-02, at 10:13, Jonathan Gibbons wrote: > On 03/02/2013 10:00 AM, Boaz Nahum wrote: >> make images >> >> doesn't build docs. >> >> How can I have docs built ? >> >> Thank >> Boaz > > make docs > > -- Jon From boaznahum at gmail.com Sun Mar 3 16:24:02 2013 From: boaznahum at gmail.com (Boaz Nahum) Date: Sun, 3 Mar 2013 18:24:02 +0200 Subject: Can I control the 'docs' target ? Message-ID: I'm using the new build system. I searched for configuration flags, can't find a way to control the 'docs' generation. What I need is a way to pass '-private Show all classes and members' to 'javadoc' processor. >From the generated docs I assume that the default is *'-public' *? Thanks Boaz From david.holmes at oracle.com Mon Mar 4 04:59:38 2013 From: david.holmes at oracle.com (David Holmes) Date: Mon, 04 Mar 2013 14:59:38 +1000 Subject: Dollar ($) expansion still needs attention In-Reply-To: <5763BF73-F88A-4CB3-843B-8398BAA52DB8@oracle.com> References: <512D73C1.50504@oracle.com> <512DDCDC.7080400@oracle.com> <5763BF73-F88A-4CB3-843B-8398BAA52DB8@oracle.com> Message-ID: <51342A3A.1010400@oracle.com> On 27/02/2013 10:14 PM, Jim Laskey (Oracle) wrote: > I wanted to double check and trace the origins of the MakeBase.gmk patch before I responded. It was part of the original set Erik sent me, but looking thru the other parts of the patch it's not clear why it was necessary. > > http://cr.openjdk.java.net/~erikj/nashorn-build/webrev.01/ So I got to the bottom of this. Basically if a make variable expands to contain a filename for a nested class (ie one with $ in it) then you need to escape the $ so that make doesn't treat it as a meta-character. And because $ is also the shell meta-character you end up needing a double escape of the form \$$$$, depending on how that variables gets used in targets/pre-reqs/recipes. Prior to the nashorn change ListPathsSafely didn't do any $ escaping and any explicit reference to a nested class file, such as: sun/awt/motif/X11GB2312\$$$$Decoder.class in the makefile, had to use the \$$$$. And everything worked fine. What nashorn introduced was .java files with $ in their name: > dir ../nashorn/src/jdk/nashorn/internal/scripts/ total 16 drwxr-xr-x 2 daholme uucp 4096 Feb 26 01:26 . drwxr-xr-x 8 daholme uucp 4096 Feb 26 01:26 .. -rw-r--r-- 1 daholme uucp 2027 Feb 26 01:26 JO$.java -rw-r--r-- 1 daholme uucp 1322 Feb 26 01:26 JS$.java so when ListPathsSafely was used together with a src directory to expand into a set of source files, there was no $ escaping and so the $ got dropped from the name, and so the nashorn build failed. So the escaping was added to ListPathsSafely. But not the full \$$$$ as the need for that depends upon exactly how the make variable is used. For Java compilation commands ListPathSafely only had to do a simpler $ -> $$ escape sequence. But this means that anything explicitly escaped with \$$$$ and passed to ListPathsSafely was now broken as there were too many escapes. This is what broke the profiles builds. So to fix that we had to reduce the number of escapes in the explicitly named files ie: sun/awt/motif/X11GB2312\$$Decoder.class so that after processing by ListPathsSafely it was back to the full \$$$$ form. That would have been the end of it, except, as I pointed out, not all uses of nested class file names get passed through ListFilesSafely. Those that do not still need the \$$$$ escape, while those that do need only \$$. Hence we have the problem that when writing the name of such a file you have to know how it is going to be used - which is not a very maintainable solution. I propose that we regress the change to ListpathsSafely so that it doesn't do the $ escape, and instead we either: a) rename the nashorn .java files with $ in their name; or else b) add the $ escape at a different point in the src list expansion so that it only affects src list expansion Pragmatically I prefer (a) because having $ in filenames is really a PITA when it is both the make meta-character and the shell meta-character. It's too late for .class file names but if we can avoid adding it to .java file names then we will simplify our lives. :) Otherwise (b) should be done somewhere in the bowels of JavaCompilation.gmk, probably by adjusting $1_ALL_SRCS. David ----- > -- Jim > > > > > On 2013-02-27, at 6:15 AM, Alan Bateman wrote: > >> On 27/02/2013 02:47, David Holmes wrote: >>> : >>> >>> So the same file names are listed once with \$$ and once with \$$$$, and they both have to be that way to work! >>> >>> This is untenable. There should only be one way to write the name of a nested class file inside the makefile. >>> >>> FYI in Profiles.gmk when expanding foo/*.class I already had to do a similar substitution as is now in ListPathsSafely: >>> >>> # Function to expand foo/*.class into the set of classes >>> # NOTE: Classfiles with $ in their name are problematic as that is the >>> # meta-character for both make and the shell! Hence the \$$$$ substitution. >>> # But note that if you echo these values they will NOT display as expected. >>> class_list = $(patsubst $(JDK_OUTPUTDIR)/classes/%,%,\ >>> $(foreach i,$(1), $(subst $$,\$$$$, $(wildcard $(JDK_OUTPUTDIR)/classes/$i)))) >>> >>> >>> So I'd like to understand why the nashorn change was made so that we can determine how to get back to only having one way to specify file names containing $ >> I completely agree, it's very difficult to maintain. Also the two patches yesterday were just to get the build working again (Erik is out this week so it wasn't possible to establish why MakeBase.gmk was changed, also I cannot find the review thread to know if it came up during the review). >> >> -Alan > From oehrstroem at gmail.com Mon Mar 4 06:06:06 2013 From: oehrstroem at gmail.com (=?ISO-8859-1?Q?Fredrik_=D6hrstr=F6m?=) Date: Mon, 4 Mar 2013 07:06:06 +0100 Subject: build failure in nashorn with sjavac enabled In-Reply-To: <5130C1D0.8020304@oracle.com> References: <5130C1D0.8020304@oracle.com> Message-ID: Minor glitch in sjavac, it only understands -classpath not -cp. (To be fixed soon.) Temporary fix in nashorn/makefiles/BuildNashorn.gmk change -cp to -classpath in the BUILD_NASGEN setup macro call. //Fredrik 2013/3/1 Maurizio Cimadamore : > Hi, > I was doing experiments with the recently added sjavac flag to enable smart > recompilation of JDK classes. I got a failure in Nashorn (I'm building on > linux x64, Ubuntu 11.10): > > ## Starting nashorn > Compiling BUILD_NASHORN > Compiling 106 files in 7 packages (jdk.internal.dynalink to > jdk.nashorn.internal.codegen.types) > Compiling 117 files in 7 packages (jdk.nashorn.internal.ir to > jdk.nashorn.internal.parser) > Compiling 192 files in 14 packages (jdk.nashorn.internal.runtime to > netscape.javascript) > Compiling BUILD_NASGEN > Compiling 19 files in 1 packages > Compiling 33 files in 3 packages (commons to signature) > Compiling 53 files in 3 packages (tree to util) > invalid flag: > /home/maurizio/Documents/ws/jdk8/tl/build/linux-x86_64-normal-server-release/nashorn/nasgen_classes > invalid flag: > /home/maurizio/Documents/ws/jdk8/tl/build/linux-x86_64-normal-server-release/nashorn/nasgen_classes > invalid flag: > /home/maurizio/Documents/ws/jdk8/tl/build/linux-x86_64-normal-server-release/nashorn/nasgen_classes > make[1]: *** > [/home/maurizio/Documents/ws/jdk8/tl/build/linux-x86_64-normal-server-release/nashorn/nasgen_classes/javac_state] > Error 255 > make: *** [nashorn-only] Error 2 > > Probably just matter of converting the Nashorn build files to be sjavac > aware... > > Maurizio > From erik.joelsson at oracle.com Mon Mar 4 10:26:03 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 04 Mar 2013 11:26:03 +0100 Subject: Testing OpenJDK under Windows 7 64, problem with Makefile In-Reply-To: References: Message-ID: <513476BB.3040704@oracle.com> I'm assuming this is concerning jdk7 (and the old build system) so moving to the build-dev list. This is a known issue in the cygwin version of make. It can be addressed by building it yourself from source, enabling the feature to accept ':' in paths. See the build readme for more details. http://hg.openjdk.java.net/jdk7/build/raw-file/tip/README-builds.html#gmake (In the new build system in jdk8, this is solved differently and should not be an issue.) /Erik On 2013-02-27 13:05, Daniel L?pez wrote: > Hi there, > I've been redirected here from the Adopt OpenJDK programme, as the > investigation while trying to "adopt" the OpenJDK build using Windows has > led me to some issues involving the build scripts. > Back to the point, I was able to successfully build the OpenJDK following > the instructions from the programme, but when it was time to verify the > build, the make did not succeed. After some research, I found out that one > of the issues is that, under Cygwin, the JDK does not like being passed the > Unix equivalent paths, so you need the DOS adapted ones, but the Makefile > is unable to work with the DOS adapted ones (due to the presence of ':' in > the paths that is interpreted as path separators). The Makefile is > transforming that paths and use them in several places (using cygpath -m -s > ) but then it fails with a "multiple targets" error due to ':' being used > in some paths. > > The solution I found was to convert the paths that are used internally > inside the Makefile using 'cygpath -u' and use the DOS paths when they are > passed to call the jtreg tool (a Java call). It surely needs some testing > and MK might have a similar problem (I have not tested it, I don't have it > installed) but just I wanted to let you know about the issue, in case > someone else has the same troubles. > > How would you like to proceed with it? Google did not produce any bug > report that covered that and I'm quite new to the Adop OpenJDK programme > and the whole OpenJDK contribution (the documentation is not too clear as > it assumes a bug is already created and the bugDatabase page is a WIP). > > Cheers! > D. > > To follow the whole discussion, the topic at the Adopt OpenJDK google group > should be here: > https://groups.google.com/forum/?hl=es&fromgroups=#!topic/adopt-openjdk/qRdMlWFgrhc From erik.joelsson at oracle.com Mon Mar 4 10:31:30 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 04 Mar 2013 11:31:30 +0100 Subject: Customizing CFLAGS_JDKLIB etc? In-Reply-To: <512AA1C5.5090701@oracle.com> References: <51289B06.2080900@oracle.com> <512AA1C5.5090701@oracle.com> Message-ID: <51347802.4080509@oracle.com> On 2013-02-25 00:27, David Holmes wrote: > On 23/02/2013 8:33 PM, David Holmes wrote: >> What's the right way to customize these flags? > > --with-extra-cflags > > For some reason I thought the above was only for legacy hotspot stuff. > > I don't know but I suspect that we still need to define it. I'm not sure of the usecases here. Suggestions are welcome. /Erik From erik.joelsson at oracle.com Mon Mar 4 11:12:33 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 04 Mar 2013 12:12:33 +0100 Subject: Suggestion: "make help" should print list of configurations In-Reply-To: <54B7901A-A75F-45E9-BA5C-B2E9FAC9C68E@oracle.com> References: <54B7901A-A75F-45E9-BA5C-B2E9FAC9C68E@oracle.com> Message-ID: <513481A1.5060600@oracle.com> Created bug 8009371 for this. /Erik On 2013-02-24 16:08, Mike Duigou wrote: > Perfect timing on asking this question Martin. I have been wondering about exactly the same question myself for IDE and external tooling support. To make parsing easier I would prefer if the target which displayed information about the configurations was relatively unadorned. > > Mike > > On Feb 23 2013, at 09:29 , Martin Buchholz wrote: > >> I'm having fun with the shiny new build system. >> It took me a while to discover that "make help" was exceptionally helpful. >> >> However, I was interested in passing a configuration to CONF= and was >> annoyed there was no clue what to provide. (I wasn't even sure exactly >> what a "configuration" was) >> >> After some trial and error, I discovered that >> >> make CONF=bogus >> >> would actually give me that precious list of supported configurations. >> It would be nice if "make help" always printed that list, even though by >> default it contains only one entry. From erik.joelsson at oracle.com Mon Mar 4 11:20:44 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 04 Mar 2013 12:20:44 +0100 Subject: 8008977: profiles build broken by Nashorn build changes In-Reply-To: <512D1B0E.3000309@oracle.com> References: <512CBD17.8090808@oracle.com> <512D1B0E.3000309@oracle.com> Message-ID: <5134838C.9070702@oracle.com> The change in ListPathsSafely was needed because in nashorn, there are java files with $ in the class name (not inner classes!). Thinking of it now, I can imagine my change there causing problems for other uses of the macro. Hopefully it will all be better with fewer $$ in the makefiles in the long run though. /Erik On 2013-02-26 21:29, David Holmes wrote: > Alan, > > Thanks for diving onto this. I can't say I understand what changed in > detail yet but I know that there are places where I had to jump > through hoops to deal with $ in class names appropriately. I would not > be surprised if there is further breakage if somehow this expansion > mechanism has changed. > > David > > On 26/02/2013 11:48 PM, Alan Bateman wrote: >> >> The build changes for Nashorn were pushed to jdk8/tl yesterday and one >> of the casualties is the profiles build. >> >> My reading of the make file changes is that ListPathsSafely_If (defined >> in MakeBase.gmk) has changed the expansion so that secondary expansion >> is no longer required. Erik is away this week but I assume this was >> intentional. >> >> Attached is the diffs that I propose to push to jdk8/tl today to get >> profiles building again, assuming I get a reviewer. >> >> -Alan >> >> >> diff --git a/makefiles/profile-rtjar-includes.txt >> b/makefiles/profile-rtjar-includes.txt >> --- a/makefiles/profile-rtjar-includes.txt >> +++ b/makefiles/profile-rtjar-includes.txt >> @@ -349,6 +349,7 @@ >> com/sun/rowset/providers \ >> com/sun/script/javascript \ >> com/sun/script/util \ >> + com/sun/security/auth \ >> com/sun/security/auth/callback \ >> com/sun/security/auth/login \ >> com/sun/security/auth/module \ >> @@ -448,8 +449,7 @@ >> sun/tracing \ >> sun/tracing/dtrace >> >> -PROFILE_3_RTJAR_INCLUDE_TYPES := \ >> - com/sun/security/auth/*.class >> +PROFILE_3_RTJAR_INCLUDE_TYPES := >> >> PROFILE_3_RTJAR_EXCLUDE_TYPES := \ >> javax/management/remote/rmi/_RMIConnectionImpl_Tie.class \ >> @@ -457,10 +457,10 @@ >> javax/management/remote/rmi/_RMIServerImpl_Tie.class \ >> javax/management/remote/rmi/_RMIServer_Stub.class \ >> com/sun/security/auth/callback/DialogCallbackHandler.class \ >> - com/sun/security/auth/callback/DialogCallbackHandler\$$$$1.class \ >> - com/sun/security/auth/callback/DialogCallbackHandler\$$$$2.class \ >> - >> com/sun/security/auth/callback/DialogCallbackHandler\$$$$Action.class \ >> - >> com/sun/security/auth/callback/DialogCallbackHandler\$$$$ConfirmationInfo.class >> >> >> + com/sun/security/auth/callback/DialogCallbackHandler\$$1.class \ >> + com/sun/security/auth/callback/DialogCallbackHandler\$$2.class \ >> + >> com/sun/security/auth/callback/DialogCallbackHandler\$$Action.class \ >> + >> com/sun/security/auth/callback/DialogCallbackHandler\$$ConfirmationInfo.class >> >> >> >> PROFILE_3_INCLUDE_METAINF_SERVICES := \ >> META-INF/services/javax.script.ScriptEngineFactory From Alan.Bateman at oracle.com Mon Mar 4 12:01:27 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 04 Mar 2013 12:01:27 +0000 Subject: 8008977: profiles build broken by Nashorn build changes In-Reply-To: <5134838C.9070702@oracle.com> References: <512CBD17.8090808@oracle.com> <512D1B0E.3000309@oracle.com> <5134838C.9070702@oracle.com> Message-ID: <51348D17.30103@oracle.com> On 04/03/2013 11:20, Erik Joelsson wrote: > The change in ListPathsSafely was needed because in nashorn, there are > java files with $ in the class name (not inner classes!). Thinking of > it now, I can imagine my change there causing problems for other uses > of the macro. Hopefully it will all be better with fewer $$ in the > makefiles in the long run though. > > /Erik Will there be inconsistency now and depending on usage, some rules will use \$$ and some \$$$$ ? David Holmes has started another thread on this topic. -Alan From erik.joelsson at oracle.com Mon Mar 4 12:34:13 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 04 Mar 2013 13:34:13 +0100 Subject: Can I control the 'docs' target ? In-Reply-To: References: Message-ID: <513494C5.4030603@oracle.com> A simple way to do this is currently missing. A workaround would be to edit build//spec.gmk and add it to NEW_JAVADOC if you want it temporarily. /Erik On 2013-03-03 17:24, Boaz Nahum wrote: > I'm using the new build system. > > I searched for configuration flags, can't find a way to control the 'docs' > generation. > What I need is a way to pass '-private Show all classes > and members' to 'javadoc' processor. > > > From the generated docs I assume that the default is *'-public' *? > > Thanks > Boaz From erik.joelsson at oracle.com Mon Mar 4 12:42:27 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 04 Mar 2013 13:42:27 +0100 Subject: Dollar ($) expansion still needs attention In-Reply-To: <51342A3A.1010400@oracle.com> References: <512D73C1.50504@oracle.com> <512DDCDC.7080400@oracle.com> <5763BF73-F88A-4CB3-843B-8398BAA52DB8@oracle.com> <51342A3A.1010400@oracle.com> Message-ID: <513496B3.7020201@oracle.com> This certainly needs to be looked at. Thanks for bringing it up. Your assessment of the situation looks correct to me. /Erik On 2013-03-04 05:59, David Holmes wrote: > On 27/02/2013 10:14 PM, Jim Laskey (Oracle) wrote: >> I wanted to double check and trace the origins of the MakeBase.gmk >> patch before I responded. It was part of the original set Erik sent >> me, but looking thru the other parts of the patch it's not clear why >> it was necessary. >> >> http://cr.openjdk.java.net/~erikj/nashorn-build/webrev.01/ > > So I got to the bottom of this. Basically if a make variable expands > to contain a filename for a nested class (ie one with $ in it) then > you need to escape the $ so that make doesn't treat it as a > meta-character. And because $ is also the shell meta-character you end > up needing a double escape of the form \$$$$, depending on how that > variables gets used in targets/pre-reqs/recipes. > > Prior to the nashorn change ListPathsSafely didn't do any $ escaping > and any explicit reference to a nested class file, such as: > > sun/awt/motif/X11GB2312\$$$$Decoder.class > > in the makefile, had to use the \$$$$. And everything worked fine. > > What nashorn introduced was .java files with $ in their name: > > > dir ../nashorn/src/jdk/nashorn/internal/scripts/ > total 16 > drwxr-xr-x 2 daholme uucp 4096 Feb 26 01:26 . > drwxr-xr-x 8 daholme uucp 4096 Feb 26 01:26 .. > -rw-r--r-- 1 daholme uucp 2027 Feb 26 01:26 JO$.java > -rw-r--r-- 1 daholme uucp 1322 Feb 26 01:26 JS$.java > > so when ListPathsSafely was used together with a src directory to > expand into a set of source files, there was no $ escaping and so the > $ got dropped from the name, and so the nashorn build failed. > > So the escaping was added to ListPathsSafely. But not the full \$$$$ > as the need for that depends upon exactly how the make variable is > used. For Java compilation commands ListPathSafely only had to do a > simpler $ -> $$ escape sequence. > > But this means that anything explicitly escaped with \$$$$ and passed > to ListPathsSafely was now broken as there were too many escapes. This > is what broke the profiles builds. So to fix that we had to reduce the > number of escapes in the explicitly named files ie: > > sun/awt/motif/X11GB2312\$$Decoder.class > > so that after processing by ListPathsSafely it was back to the full > \$$$$ form. > > That would have been the end of it, except, as I pointed out, not all > uses of nested class file names get passed through ListFilesSafely. > Those that do not still need the \$$$$ escape, while those that do > need only \$$. Hence we have the problem that when writing the name of > such a file you have to know how it is going to be used - which is not > a very maintainable solution. > > I propose that we regress the change to ListpathsSafely so that it > doesn't do the $ escape, and instead we either: > > a) rename the nashorn .java files with $ in their name; or else > b) add the $ escape at a different point in the src list expansion so > that it only affects src list expansion > > Pragmatically I prefer (a) because having $ in filenames is really a > PITA when it is both the make meta-character and the shell > meta-character. It's too late for .class file names but if we can > avoid adding it to .java file names then we will simplify our lives. :) > > Otherwise (b) should be done somewhere in the bowels of > JavaCompilation.gmk, probably by adjusting $1_ALL_SRCS. > > > David > ----- > > > > >> -- Jim >> >> >> >> >> On 2013-02-27, at 6:15 AM, Alan Bateman wrote: >> >>> On 27/02/2013 02:47, David Holmes wrote: >>>> : >>>> >>>> So the same file names are listed once with \$$ and once with >>>> \$$$$, and they both have to be that way to work! >>>> >>>> This is untenable. There should only be one way to write the name >>>> of a nested class file inside the makefile. >>>> >>>> FYI in Profiles.gmk when expanding foo/*.class I already had to do >>>> a similar substitution as is now in ListPathsSafely: >>>> >>>> # Function to expand foo/*.class into the set of classes >>>> # NOTE: Classfiles with $ in their name are problematic as that is the >>>> # meta-character for both make and the shell! Hence the \$$$$ >>>> substitution. >>>> # But note that if you echo these values they will NOT display as >>>> expected. >>>> class_list = $(patsubst $(JDK_OUTPUTDIR)/classes/%,%,\ >>>> $(foreach i,$(1), $(subst $$,\$$$$, $(wildcard >>>> $(JDK_OUTPUTDIR)/classes/$i)))) >>>> >>>> >>>> So I'd like to understand why the nashorn change was made so that >>>> we can determine how to get back to only having one way to specify >>>> file names containing $ >>> I completely agree, it's very difficult to maintain. Also the two >>> patches yesterday were just to get the build working again (Erik is >>> out this week so it wasn't possible to establish why MakeBase.gmk >>> was changed, also I cannot find the review thread to know if it came >>> up during the review). >>> >>> -Alan >> From boaznahum at gmail.com Mon Mar 4 15:03:07 2013 From: boaznahum at gmail.com (Boaz Nahum) Date: Mon, 4 Mar 2013 17:03:07 +0200 Subject: Javadoc errors when adding -private Message-ID: I'm not sure if this belongs to *build-dev* or *compiler-dev*, so please forgive me. I'm building lambda/lambda I modified spec.gmk to include private and protected elements in docs: *NEW_JAVADOC = $(BOOTSTRAP_JAVAC_ARGS) com.sun.tools.javadoc.Main -private* No *make docs * Generate errors of this kind: c:\jdk8build\LL2\jdk\src\share\classes\java\util\ResourceBundle.java:471: error: missing method body, or declare abstract new PrivilegedAction() { ^ The relevant code is: private static class RBClassLoader extends ClassLoader { private static final RBClassLoader INSTANCE = AccessController.doPrivileged( new PrivilegedAction() { public RBClassLoader run() { return new RBClassLoader(); } }); private static final ClassLoader loader = ClassLoader.getSystemClassLoader(); Thanks Boaz From kelly.ohair at oracle.com Mon Mar 4 15:54:23 2013 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Mon, 4 Mar 2013 07:54:23 -0800 Subject: 8008977: profiles build broken by Nashorn build changes In-Reply-To: <5134838C.9070702@oracle.com> References: <512CBD17.8090808@oracle.com> <512D1B0E.3000309@oracle.com> <5134838C.9070702@oracle.com> Message-ID: <0AD855CC-CA24-4F77-BA20-520177F533FD@oracle.com> It seems to me that using $ in class names when they are NOT Inner Classes is a huge mistake. Mark my words, this will come back to haunt us, multiple times, I guarantee it. -kto On Mar 4, 2013, at 3:20 AM, Erik Joelsson wrote: > The change in ListPathsSafely was needed because in nashorn, there are java files with $ in the class name (not inner classes!). Thinking of it now, I can imagine my change there causing problems for other uses of the macro. Hopefully it will all be better with fewer $$ in the makefiles in the long run though. > > /Erik > > On 2013-02-26 21:29, David Holmes wrote: >> Alan, >> >> Thanks for diving onto this. I can't say I understand what changed in detail yet but I know that there are places where I had to jump through hoops to deal with $ in class names appropriately. I would not be surprised if there is further breakage if somehow this expansion mechanism has changed. >> >> David >> >> On 26/02/2013 11:48 PM, Alan Bateman wrote: >>> >>> The build changes for Nashorn were pushed to jdk8/tl yesterday and one >>> of the casualties is the profiles build. >>> >>> My reading of the make file changes is that ListPathsSafely_If (defined >>> in MakeBase.gmk) has changed the expansion so that secondary expansion >>> is no longer required. Erik is away this week but I assume this was >>> intentional. >>> >>> Attached is the diffs that I propose to push to jdk8/tl today to get >>> profiles building again, assuming I get a reviewer. >>> >>> -Alan >>> >>> >>> diff --git a/makefiles/profile-rtjar-includes.txt >>> b/makefiles/profile-rtjar-includes.txt >>> --- a/makefiles/profile-rtjar-includes.txt >>> +++ b/makefiles/profile-rtjar-includes.txt >>> @@ -349,6 +349,7 @@ >>> com/sun/rowset/providers \ >>> com/sun/script/javascript \ >>> com/sun/script/util \ >>> + com/sun/security/auth \ >>> com/sun/security/auth/callback \ >>> com/sun/security/auth/login \ >>> com/sun/security/auth/module \ >>> @@ -448,8 +449,7 @@ >>> sun/tracing \ >>> sun/tracing/dtrace >>> >>> -PROFILE_3_RTJAR_INCLUDE_TYPES := \ >>> - com/sun/security/auth/*.class >>> +PROFILE_3_RTJAR_INCLUDE_TYPES := >>> >>> PROFILE_3_RTJAR_EXCLUDE_TYPES := \ >>> javax/management/remote/rmi/_RMIConnectionImpl_Tie.class \ >>> @@ -457,10 +457,10 @@ >>> javax/management/remote/rmi/_RMIServerImpl_Tie.class \ >>> javax/management/remote/rmi/_RMIServer_Stub.class \ >>> com/sun/security/auth/callback/DialogCallbackHandler.class \ >>> - com/sun/security/auth/callback/DialogCallbackHandler\$$$$1.class \ >>> - com/sun/security/auth/callback/DialogCallbackHandler\$$$$2.class \ >>> - >>> com/sun/security/auth/callback/DialogCallbackHandler\$$$$Action.class \ >>> - >>> com/sun/security/auth/callback/DialogCallbackHandler\$$$$ConfirmationInfo.class >>> >>> + com/sun/security/auth/callback/DialogCallbackHandler\$$1.class \ >>> + com/sun/security/auth/callback/DialogCallbackHandler\$$2.class \ >>> + com/sun/security/auth/callback/DialogCallbackHandler\$$Action.class \ >>> + >>> com/sun/security/auth/callback/DialogCallbackHandler\$$ConfirmationInfo.class >>> >>> >>> PROFILE_3_INCLUDE_METAINF_SERVICES := \ >>> META-INF/services/javax.script.ScriptEngineFactory From jonathan.gibbons at oracle.com Mon Mar 4 16:16:31 2013 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 04 Mar 2013 08:16:31 -0800 Subject: Javadoc errors when adding -private In-Reply-To: References: Message-ID: <5134C8DF.3020507@oracle.com> On 03/04/2013 07:03 AM, Boaz Nahum wrote: > I'm not sure if this belongs to /*build-dev*/ or /*compiler-dev*/, so > please forgive me. javadoc-dev :-) -- Jon From erik.joelsson at oracle.com Mon Mar 4 16:52:08 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 04 Mar 2013 17:52:08 +0100 Subject: Review Request: 8009393: Supply correct AR to install build from InstallWrapper.gmk Message-ID: <5134D138.5070306@oracle.com> Open part of this review. In JDK-8009196, a quick fix for letting the install repo find the correct AR was submitted. A better solution is possible, reverting that fix and instead supplying AR on the make command line from InstallWrapper.gmk, as is the pattern for other such variables. This webrev just reverts the change made in 8009196. http://cr.openjdk.java.net/~erikj/8009393/webrev.jdk.01/ /Erik From james.laskey at oracle.com Mon Mar 4 10:34:18 2013 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Mon, 4 Mar 2013 06:34:18 -0400 Subject: Dollar ($) expansion still needs attention In-Reply-To: <51342A3A.1010400@oracle.com> References: <512D73C1.50504@oracle.com> <512DDCDC.7080400@oracle.com> <5763BF73-F88A-4CB3-843B-8398BAA52DB8@oracle.com> <51342A3A.1010400@oracle.com> Message-ID: <84FA84D4-03BB-4731-B45E-D5930449061F@oracle.com> Nashorn uses this mark to identify generated files. Erik may have assumed other languages might do the same and was planning ahead. If I had known I would have changed the marker. In Nashorn's case, since $ only affects class names, a) should be an easy change. Sent from my iPhone 4 On 2013-03-04, at 12:59 AM, David Holmes wrote: > On 27/02/2013 10:14 PM, Jim Laskey (Oracle) wrote: >> I wanted to double check and trace the origins of the MakeBase.gmk patch before I responded. It was part of the original set Erik sent me, but looking thru the other parts of the patch it's not clear why it was necessary. >> >> http://cr.openjdk.java.net/~erikj/nashorn-build/webrev.01/ > > So I got to the bottom of this. Basically if a make variable expands to contain a filename for a nested class (ie one with $ in it) then you need to escape the $ so that make doesn't treat it as a meta-character. And because $ is also the shell meta-character you end up needing a double escape of the form \$$$$, depending on how that variables gets used in targets/pre-reqs/recipes. > > Prior to the nashorn change ListPathsSafely didn't do any $ escaping and any explicit reference to a nested class file, such as: > > sun/awt/motif/X11GB2312\$$$$Decoder.class > > in the makefile, had to use the \$$$$. And everything worked fine. > > What nashorn introduced was .java files with $ in their name: > > > dir ../nashorn/src/jdk/nashorn/internal/scripts/ > total 16 > drwxr-xr-x 2 daholme uucp 4096 Feb 26 01:26 . > drwxr-xr-x 8 daholme uucp 4096 Feb 26 01:26 .. > -rw-r--r-- 1 daholme uucp 2027 Feb 26 01:26 JO$.java > -rw-r--r-- 1 daholme uucp 1322 Feb 26 01:26 JS$.java > > so when ListPathsSafely was used together with a src directory to expand into a set of source files, there was no $ escaping and so the $ got dropped from the name, and so the nashorn build failed. > > So the escaping was added to ListPathsSafely. But not the full \$$$$ as the need for that depends upon exactly how the make variable is used. For Java compilation commands ListPathSafely only had to do a simpler $ -> $$ escape sequence. > > But this means that anything explicitly escaped with \$$$$ and passed to ListPathsSafely was now broken as there were too many escapes. This is what broke the profiles builds. So to fix that we had to reduce the number of escapes in the explicitly named files ie: > > sun/awt/motif/X11GB2312\$$Decoder.class > > so that after processing by ListPathsSafely it was back to the full \$$$$ form. > > That would have been the end of it, except, as I pointed out, not all uses of nested class file names get passed through ListFilesSafely. Those that do not still need the \$$$$ escape, while those that do need only \$$. Hence we have the problem that when writing the name of such a file you have to know how it is going to be used - which is not a very maintainable solution. > > I propose that we regress the change to ListpathsSafely so that it doesn't do the $ escape, and instead we either: > > a) rename the nashorn .java files with $ in their name; or else > b) add the $ escape at a different point in the src list expansion so that it only affects src list expansion > > Pragmatically I prefer (a) because having $ in filenames is really a PITA when it is both the make meta-character and the shell meta-character. It's too late for .class file names but if we can avoid adding it to .java file names then we will simplify our lives. :) > > Otherwise (b) should be done somewhere in the bowels of JavaCompilation.gmk, probably by adjusting $1_ALL_SRCS. > > > David > ----- > > > > >> -- Jim >> >> >> >> >> On 2013-02-27, at 6:15 AM, Alan Bateman wrote: >> >>> On 27/02/2013 02:47, David Holmes wrote: >>>> : >>>> >>>> So the same file names are listed once with \$$ and once with \$$$$, and they both have to be that way to work! >>>> >>>> This is untenable. There should only be one way to write the name of a nested class file inside the makefile. >>>> >>>> FYI in Profiles.gmk when expanding foo/*.class I already had to do a similar substitution as is now in ListPathsSafely: >>>> >>>> # Function to expand foo/*.class into the set of classes >>>> # NOTE: Classfiles with $ in their name are problematic as that is the >>>> # meta-character for both make and the shell! Hence the \$$$$ substitution. >>>> # But note that if you echo these values they will NOT display as expected. >>>> class_list = $(patsubst $(JDK_OUTPUTDIR)/classes/%,%,\ >>>> $(foreach i,$(1), $(subst $$,\$$$$, $(wildcard $(JDK_OUTPUTDIR)/classes/$i)))) >>>> >>>> >>>> So I'd like to understand why the nashorn change was made so that we can determine how to get back to only having one way to specify file names containing $ >>> I completely agree, it's very difficult to maintain. Also the two patches yesterday were just to get the build working again (Erik is out this week so it wasn't possible to establish why MakeBase.gmk was changed, also I cannot find the review thread to know if it came up during the review). >>> >>> -Alan >> From d.lopez.j at gmail.com Mon Mar 4 10:50:01 2013 From: d.lopez.j at gmail.com (=?ISO-8859-1?Q?Daniel_L=F3pez?=) Date: Mon, 4 Mar 2013 11:50:01 +0100 Subject: Testing OpenJDK under Windows 7 64, problem with Makefile In-Reply-To: <513476BB.3040704@oracle.com> References: <513476BB.3040704@oracle.com> Message-ID: This happens trying to test Java 8 following the instructions described in http://java.net/projects/adoptopenjdk/pages/BuildWindows that I thought were related to the new system and then trying to test the installation using the instructions provided here http://java.net/projects/adoptopenjdk/pages/InstallJtreg. Is this the old system of testing the jdk? The building itself succeeds, it's the test Makefile that gives me troubles (OpenJDK/jdk8_tl/jdk/test) to be precise. Nevertheless, I'll try to build the make from the sources and see if that also fixes it. Thanks, D. 2013/3/4 Erik Joelsson > I'm assuming this is concerning jdk7 (and the old build system) so moving > to the build-dev list. This is a known issue in the cygwin version of make. > It can be addressed by building it yourself from source, enabling the > feature to accept ':' in paths. See the build readme for more details. > > http://hg.openjdk.java.net/**jdk7/build/raw-file/tip/** > README-builds.html#gmake > > (In the new build system in jdk8, this is solved differently and should > not be an issue.) > > /Erik > > > On 2013-02-27 13:05, Daniel L?pez wrote: > >> Hi there, >> I've been redirected here from the Adopt OpenJDK programme, as the >> investigation while trying to "adopt" the OpenJDK build using Windows has >> led me to some issues involving the build scripts. >> Back to the point, I was able to successfully build the OpenJDK following >> the instructions from the programme, but when it was time to verify the >> build, the make did not succeed. After some research, I found out that one >> of the issues is that, under Cygwin, the JDK does not like being passed >> the >> Unix equivalent paths, so you need the DOS adapted ones, but the Makefile >> is unable to work with the DOS adapted ones (due to the presence of ':' in >> the paths that is interpreted as path separators). The Makefile is >> transforming that paths and use them in several places (using cygpath -m >> -s >> ) but then it fails with a "multiple targets" error due to ':' being used >> in some paths. >> >> The solution I found was to convert the paths that are used internally >> inside the Makefile using 'cygpath -u' and use the DOS paths when they are >> passed to call the jtreg tool (a Java call). It surely needs some testing >> and MK might have a similar problem (I have not tested it, I don't have it >> installed) but just I wanted to let you know about the issue, in case >> someone else has the same troubles. >> >> How would you like to proceed with it? Google did not produce any bug >> report that covered that and I'm quite new to the Adop OpenJDK programme >> and the whole OpenJDK contribution (the documentation is not too clear as >> it assumes a bug is already created and the bugDatabase page is a WIP). >> >> Cheers! >> D. >> >> To follow the whole discussion, the topic at the Adopt OpenJDK google >> group >> should be here: >> https://groups.google.com/**forum/?hl=es&fromgroups=#!** >> topic/adopt-openjdk/**qRdMlWFgrhc >> > From fweimer at redhat.com Mon Mar 4 11:02:00 2013 From: fweimer at redhat.com (Florian Weimer) Date: Mon, 04 Mar 2013 12:02:00 +0100 Subject: Do not let internal JDK zlib symbols leak out of fastdebug libzip.so In-Reply-To: References: Message-ID: <51347F28.6050407@redhat.com> On 02/22/2013 11:03 PM, Martin Buchholz wrote: > I've finally figured out why fastdebug jdk occasionally gives InternalError > in the zip code. In the distant past, I also saw this with product builds. Triggering conditions involved a JNI DSO calling dlopen(RTLD_GLOBAL) on another DSO which eventually triggered loading the system zlib. This might still be relevant on stock OpenJDK 7. IcedTea avoids this by linking against system zlib. -- Florian Weimer / Red Hat Product Security Team From d.lopez.j at gmail.com Mon Mar 4 11:15:38 2013 From: d.lopez.j at gmail.com (=?ISO-8859-1?Q?Daniel_L=F3pez?=) Date: Mon, 4 Mar 2013 12:15:38 +0100 Subject: Testing OpenJDK under Windows 7 64, problem with Makefile In-Reply-To: References: <513476BB.3040704@oracle.com> Message-ID: I just tried downloading and building myself make 3.80 (as Mozilla guys suggest) or the newest 3.82 and none of them is able to run the Makefile unmodified :(. S! D. 2013/3/4 Daniel L?pez > This happens trying to test Java 8 following the instructions described in > http://java.net/projects/adoptopenjdk/pages/BuildWindows that I thought > were related to the new system and then trying to test the installation > using the instructions provided here > http://java.net/projects/adoptopenjdk/pages/InstallJtreg. > > Is this the old system of testing the jdk? The building itself succeeds, > it's the test Makefile that gives me troubles (OpenJDK/jdk8_tl/jdk/test) to > be precise. > Nevertheless, I'll try to build the make from the sources and see if that > also fixes it. > > Thanks, > D. > > > 2013/3/4 Erik Joelsson > >> I'm assuming this is concerning jdk7 (and the old build system) so moving >> to the build-dev list. This is a known issue in the cygwin version of make. >> It can be addressed by building it yourself from source, enabling the >> feature to accept ':' in paths. See the build readme for more details. >> >> http://hg.openjdk.java.net/**jdk7/build/raw-file/tip/** >> README-builds.html#gmake >> >> (In the new build system in jdk8, this is solved differently and should >> not be an issue.) >> >> /Erik >> >> >> On 2013-02-27 13:05, Daniel L?pez wrote: >> >>> Hi there, >>> I've been redirected here from the Adopt OpenJDK programme, as the >>> investigation while trying to "adopt" the OpenJDK build using Windows has >>> led me to some issues involving the build scripts. >>> Back to the point, I was able to successfully build the OpenJDK following >>> the instructions from the programme, but when it was time to verify the >>> build, the make did not succeed. After some research, I found out that >>> one >>> of the issues is that, under Cygwin, the JDK does not like being passed >>> the >>> Unix equivalent paths, so you need the DOS adapted ones, but the Makefile >>> is unable to work with the DOS adapted ones (due to the presence of ':' >>> in >>> the paths that is interpreted as path separators). The Makefile is >>> transforming that paths and use them in several places (using cygpath -m >>> -s >>> ) but then it fails with a "multiple targets" error due to ':' being used >>> in some paths. >>> >>> The solution I found was to convert the paths that are used internally >>> inside the Makefile using 'cygpath -u' and use the DOS paths when they >>> are >>> passed to call the jtreg tool (a Java call). It surely needs some testing >>> and MK might have a similar problem (I have not tested it, I don't have >>> it >>> installed) but just I wanted to let you know about the issue, in case >>> someone else has the same troubles. >>> >>> How would you like to proceed with it? Google did not produce any bug >>> report that covered that and I'm quite new to the Adop OpenJDK programme >>> and the whole OpenJDK contribution (the documentation is not too clear as >>> it assumes a bug is already created and the bugDatabase page is a WIP). >>> >>> Cheers! >>> D. >>> >>> To follow the whole discussion, the topic at the Adopt OpenJDK google >>> group >>> should be here: >>> https://groups.google.com/**forum/?hl=es&fromgroups=#!** >>> topic/adopt-openjdk/**qRdMlWFgrhc >>> >> > From James.Laskey at oracle.com Mon Mar 4 15:58:33 2013 From: James.Laskey at oracle.com (Jim Laskey (Oracle)) Date: Mon, 4 Mar 2013 11:58:33 -0400 Subject: 8008977: profiles build broken by Nashorn build changes In-Reply-To: <0AD855CC-CA24-4F77-BA20-520177F533FD@oracle.com> References: <512CBD17.8090808@oracle.com> <512D1B0E.3000309@oracle.com> <5134838C.9070702@oracle.com> <0AD855CC-CA24-4F77-BA20-520177F533FD@oracle.com> Message-ID: <8D4DD173-88AB-413B-9DD5-71ACB8107D6B@oracle.com> I have a change set making its way to tl that removes this requirement. -- Jim On 2013-03-04, at 11:54 AM, Kelly O'Hair wrote: > It seems to me that using $ in class names when they are NOT Inner Classes is a huge mistake. > > Mark my words, this will come back to haunt us, multiple times, I guarantee it. > > -kto > > On Mar 4, 2013, at 3:20 AM, Erik Joelsson wrote: > >> The change in ListPathsSafely was needed because in nashorn, there are java files with $ in the class name (not inner classes!). Thinking of it now, I can imagine my change there causing problems for other uses of the macro. Hopefully it will all be better with fewer $$ in the makefiles in the long run though. >> >> /Erik >> >> On 2013-02-26 21:29, David Holmes wrote: >>> Alan, >>> >>> Thanks for diving onto this. I can't say I understand what changed in detail yet but I know that there are places where I had to jump through hoops to deal with $ in class names appropriately. I would not be surprised if there is further breakage if somehow this expansion mechanism has changed. >>> >>> David >>> >>> On 26/02/2013 11:48 PM, Alan Bateman wrote: >>>> >>>> The build changes for Nashorn were pushed to jdk8/tl yesterday and one >>>> of the casualties is the profiles build. >>>> >>>> My reading of the make file changes is that ListPathsSafely_If (defined >>>> in MakeBase.gmk) has changed the expansion so that secondary expansion >>>> is no longer required. Erik is away this week but I assume this was >>>> intentional. >>>> >>>> Attached is the diffs that I propose to push to jdk8/tl today to get >>>> profiles building again, assuming I get a reviewer. >>>> >>>> -Alan >>>> >>>> >>>> diff --git a/makefiles/profile-rtjar-includes.txt >>>> b/makefiles/profile-rtjar-includes.txt >>>> --- a/makefiles/profile-rtjar-includes.txt >>>> +++ b/makefiles/profile-rtjar-includes.txt >>>> @@ -349,6 +349,7 @@ >>>> com/sun/rowset/providers \ >>>> com/sun/script/javascript \ >>>> com/sun/script/util \ >>>> + com/sun/security/auth \ >>>> com/sun/security/auth/callback \ >>>> com/sun/security/auth/login \ >>>> com/sun/security/auth/module \ >>>> @@ -448,8 +449,7 @@ >>>> sun/tracing \ >>>> sun/tracing/dtrace >>>> >>>> -PROFILE_3_RTJAR_INCLUDE_TYPES := \ >>>> - com/sun/security/auth/*.class >>>> +PROFILE_3_RTJAR_INCLUDE_TYPES := >>>> >>>> PROFILE_3_RTJAR_EXCLUDE_TYPES := \ >>>> javax/management/remote/rmi/_RMIConnectionImpl_Tie.class \ >>>> @@ -457,10 +457,10 @@ >>>> javax/management/remote/rmi/_RMIServerImpl_Tie.class \ >>>> javax/management/remote/rmi/_RMIServer_Stub.class \ >>>> com/sun/security/auth/callback/DialogCallbackHandler.class \ >>>> - com/sun/security/auth/callback/DialogCallbackHandler\$$$$1.class \ >>>> - com/sun/security/auth/callback/DialogCallbackHandler\$$$$2.class \ >>>> - >>>> com/sun/security/auth/callback/DialogCallbackHandler\$$$$Action.class \ >>>> - >>>> com/sun/security/auth/callback/DialogCallbackHandler\$$$$ConfirmationInfo.class >>>> >>>> + com/sun/security/auth/callback/DialogCallbackHandler\$$1.class \ >>>> + com/sun/security/auth/callback/DialogCallbackHandler\$$2.class \ >>>> + com/sun/security/auth/callback/DialogCallbackHandler\$$Action.class \ >>>> + >>>> com/sun/security/auth/callback/DialogCallbackHandler\$$ConfirmationInfo.class >>>> >>>> >>>> PROFILE_3_INCLUDE_METAINF_SERVICES := \ >>>> META-INF/services/javax.script.ScriptEngineFactory > From james.laskey at oracle.com Mon Mar 4 17:05:47 2013 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Mon, 4 Mar 2013 13:05:47 -0400 Subject: 8008977: profiles build broken by Nashorn build changes In-Reply-To: <8D4DD173-88AB-413B-9DD5-71ACB8107D6B@oracle.com> References: <512CBD17.8090808@oracle.com> <512D1B0E.3000309@oracle.com> <5134838C.9070702@oracle.com> <0AD855CC-CA24-4F77-BA20-520177F533FD@oracle.com> <8D4DD173-88AB-413B-9DD5-71ACB8107D6B@oracle.com> Message-ID: Erik, The changes to remove $ from the class file name (Nashorn) are in tl. https://jbs.oracle.com/bugs/browse/JDK-8009379 HG Updates added a comment - 2013-03-04 12:54 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/fe5211fc3114 User: sundar Date: 2013-03-04 16:49:50 +0000 -- Jim On 2013-03-04, at 11:58 AM, Jim Laskey (Oracle) wrote: > I have a change set making its way to tl that removes this requirement. > > -- Jim > > > > On 2013-03-04, at 11:54 AM, Kelly O'Hair wrote: > >> It seems to me that using $ in class names when they are NOT Inner Classes is a huge mistake. >> >> Mark my words, this will come back to haunt us, multiple times, I guarantee it. >> >> -kto >> >> On Mar 4, 2013, at 3:20 AM, Erik Joelsson wrote: >> >>> The change in ListPathsSafely was needed because in nashorn, there are java files with $ in the class name (not inner classes!). Thinking of it now, I can imagine my change there causing problems for other uses of the macro. Hopefully it will all be better with fewer $$ in the makefiles in the long run though. >>> >>> /Erik >>> >>> On 2013-02-26 21:29, David Holmes wrote: >>>> Alan, >>>> >>>> Thanks for diving onto this. I can't say I understand what changed in detail yet but I know that there are places where I had to jump through hoops to deal with $ in class names appropriately. I would not be surprised if there is further breakage if somehow this expansion mechanism has changed. >>>> >>>> David >>>> >>>> On 26/02/2013 11:48 PM, Alan Bateman wrote: >>>>> >>>>> The build changes for Nashorn were pushed to jdk8/tl yesterday and one >>>>> of the casualties is the profiles build. >>>>> >>>>> My reading of the make file changes is that ListPathsSafely_If (defined >>>>> in MakeBase.gmk) has changed the expansion so that secondary expansion >>>>> is no longer required. Erik is away this week but I assume this was >>>>> intentional. >>>>> >>>>> Attached is the diffs that I propose to push to jdk8/tl today to get >>>>> profiles building again, assuming I get a reviewer. >>>>> >>>>> -Alan >>>>> >>>>> >>>>> diff --git a/makefiles/profile-rtjar-includes.txt >>>>> b/makefiles/profile-rtjar-includes.txt >>>>> --- a/makefiles/profile-rtjar-includes.txt >>>>> +++ b/makefiles/profile-rtjar-includes.txt >>>>> @@ -349,6 +349,7 @@ >>>>> com/sun/rowset/providers \ >>>>> com/sun/script/javascript \ >>>>> com/sun/script/util \ >>>>> + com/sun/security/auth \ >>>>> com/sun/security/auth/callback \ >>>>> com/sun/security/auth/login \ >>>>> com/sun/security/auth/module \ >>>>> @@ -448,8 +449,7 @@ >>>>> sun/tracing \ >>>>> sun/tracing/dtrace >>>>> >>>>> -PROFILE_3_RTJAR_INCLUDE_TYPES := \ >>>>> - com/sun/security/auth/*.class >>>>> +PROFILE_3_RTJAR_INCLUDE_TYPES := >>>>> >>>>> PROFILE_3_RTJAR_EXCLUDE_TYPES := \ >>>>> javax/management/remote/rmi/_RMIConnectionImpl_Tie.class \ >>>>> @@ -457,10 +457,10 @@ >>>>> javax/management/remote/rmi/_RMIServerImpl_Tie.class \ >>>>> javax/management/remote/rmi/_RMIServer_Stub.class \ >>>>> com/sun/security/auth/callback/DialogCallbackHandler.class \ >>>>> - com/sun/security/auth/callback/DialogCallbackHandler\$$$$1.class \ >>>>> - com/sun/security/auth/callback/DialogCallbackHandler\$$$$2.class \ >>>>> - >>>>> com/sun/security/auth/callback/DialogCallbackHandler\$$$$Action.class \ >>>>> - >>>>> com/sun/security/auth/callback/DialogCallbackHandler\$$$$ConfirmationInfo.class >>>>> >>>>> + com/sun/security/auth/callback/DialogCallbackHandler\$$1.class \ >>>>> + com/sun/security/auth/callback/DialogCallbackHandler\$$2.class \ >>>>> + com/sun/security/auth/callback/DialogCallbackHandler\$$Action.class \ >>>>> + >>>>> com/sun/security/auth/callback/DialogCallbackHandler\$$ConfirmationInfo.class >>>>> >>>>> >>>>> PROFILE_3_INCLUDE_METAINF_SERVICES := \ >>>>> META-INF/services/javax.script.ScriptEngineFactory >> > From kelly.ohair at oracle.com Mon Mar 4 18:58:45 2013 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Mon, 4 Mar 2013 10:58:45 -0800 Subject: Testing OpenJDK under Windows 7 64, problem with Makefile In-Reply-To: References: <513476BB.3040704@oracle.com> Message-ID: GNU make 3.81 NOT 3.80, but 3.82 should work too. And I have no idea who wrote up the instructions at: http://java.net/projects/adoptopenjdk/pages/BuildWindows http://java.net/projects/adoptopenjdk/pages/InstallJtreg. The instructions we support are at: http://hg.openjdk.java.net/jdk8/build/raw-file/tip/README-builds.html and if there are mistakes in that page, issues can be filed, and anyone is welcome to fix it. -kto On Mar 4, 2013, at 3:15 AM, Daniel L?pez wrote: > I just tried downloading and building myself make 3.80 (as Mozilla guys > suggest) or the newest 3.82 and none of them is able to run the Makefile > unmodified :(. > > S! > D. > > 2013/3/4 Daniel L?pez > >> This happens trying to test Java 8 following the instructions described in >> http://java.net/projects/adoptopenjdk/pages/BuildWindows that I thought >> were related to the new system and then trying to test the installation >> using the instructions provided here >> http://java.net/projects/adoptopenjdk/pages/InstallJtreg. >> >> Is this the old system of testing the jdk? The building itself succeeds, >> it's the test Makefile that gives me troubles (OpenJDK/jdk8_tl/jdk/test) to >> be precise. >> Nevertheless, I'll try to build the make from the sources and see if that >> also fixes it. >> >> Thanks, >> D. >> >> >> 2013/3/4 Erik Joelsson >> >>> I'm assuming this is concerning jdk7 (and the old build system) so moving >>> to the build-dev list. This is a known issue in the cygwin version of make. >>> It can be addressed by building it yourself from source, enabling the >>> feature to accept ':' in paths. See the build readme for more details. >>> >>> http://hg.openjdk.java.net/**jdk7/build/raw-file/tip/** >>> README-builds.html#gmake >>> >>> (In the new build system in jdk8, this is solved differently and should >>> not be an issue.) >>> >>> /Erik >>> >>> >>> On 2013-02-27 13:05, Daniel L?pez wrote: >>> >>>> Hi there, >>>> I've been redirected here from the Adopt OpenJDK programme, as the >>>> investigation while trying to "adopt" the OpenJDK build using Windows has >>>> led me to some issues involving the build scripts. >>>> Back to the point, I was able to successfully build the OpenJDK following >>>> the instructions from the programme, but when it was time to verify the >>>> build, the make did not succeed. After some research, I found out that >>>> one >>>> of the issues is that, under Cygwin, the JDK does not like being passed >>>> the >>>> Unix equivalent paths, so you need the DOS adapted ones, but the Makefile >>>> is unable to work with the DOS adapted ones (due to the presence of ':' >>>> in >>>> the paths that is interpreted as path separators). The Makefile is >>>> transforming that paths and use them in several places (using cygpath -m >>>> -s >>>> ) but then it fails with a "multiple targets" error due to ':' being used >>>> in some paths. >>>> >>>> The solution I found was to convert the paths that are used internally >>>> inside the Makefile using 'cygpath -u' and use the DOS paths when they >>>> are >>>> passed to call the jtreg tool (a Java call). It surely needs some testing >>>> and MK might have a similar problem (I have not tested it, I don't have >>>> it >>>> installed) but just I wanted to let you know about the issue, in case >>>> someone else has the same troubles. >>>> >>>> How would you like to proceed with it? Google did not produce any bug >>>> report that covered that and I'm quite new to the Adop OpenJDK programme >>>> and the whole OpenJDK contribution (the documentation is not too clear as >>>> it assumes a bug is already created and the bugDatabase page is a WIP). >>>> >>>> Cheers! >>>> D. >>>> >>>> To follow the whole discussion, the topic at the Adopt OpenJDK google >>>> group >>>> should be here: >>>> https://groups.google.com/**forum/?hl=es&fromgroups=#!** >>>> topic/adopt-openjdk/**qRdMlWFgrhc >>>> >>> >> From erik.joelsson at oracle.com Mon Mar 4 20:25:46 2013 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Mon, 04 Mar 2013 20:25:46 +0000 Subject: hg: jdk8/build: 8004352: build-infra: Limit JOBS on large machines Message-ID: <20130304202546.7D31D4781D@hg.openjdk.java.net> Changeset: 907a926d3c96 Author: erikj Date: 2013-03-04 16:45 +0100 URL: http://hg.openjdk.java.net/jdk8/build/rev/907a926d3c96 8004352: build-infra: Limit JOBS on large machines Reviewed-by: mduigou ! common/autoconf/build-performance.m4 ! common/autoconf/configure.ac ! common/autoconf/generated-configure.sh ! common/autoconf/help.m4 ! common/autoconf/hotspot-spec.gmk.in ! common/autoconf/spec.gmk.in ! common/makefiles/JavaCompilation.gmk ! common/makefiles/Main.gmk From martinrb at google.com Mon Mar 4 22:36:56 2013 From: martinrb at google.com (Martin Buchholz) Date: Mon, 4 Mar 2013 14:36:56 -0800 Subject: Do not let internal JDK zlib symbols leak out of fastdebug libzip.so In-Reply-To: <51347F28.6050407@redhat.com> References: <51347F28.6050407@redhat.com> Message-ID: On Mon, Mar 4, 2013 at 3:02 AM, Florian Weimer wrote: > On 02/22/2013 11:03 PM, Martin Buchholz wrote: > > I've finally figured out why fastdebug jdk occasionally gives >> InternalError >> in the zip code. >> > > In the distant past, I also saw this with product builds. Triggering > conditions involved a JNI DSO calling dlopen(RTLD_GLOBAL) on another DSO > which eventually triggered loading the system zlib. This might still be > relevant on stock OpenJDK 7. > > IcedTea avoids this by linking against system zlib. It's certainly risky to have two separate system libraries in the same process using the same symbols. You are then very dependent on carefully using the linker (or utilties like objcopy) to produce "symbol jails" where one set of symbols cannot affect the other. Which is not consistent with traditional linker culture where there is a single global symbol namespace. From martinrb at google.com Mon Mar 4 22:55:51 2013 From: martinrb at google.com (Martin Buchholz) Date: Mon, 4 Mar 2013 14:55:51 -0800 Subject: New build system problems In-Reply-To: <513486CE.40405@oracle.com> References: <5129CD25.2000003@oracle.com> <513486CE.40405@oracle.com> Message-ID: On Mon, Mar 4, 2013 at 3:34 AM, Erik Joelsson wrote: > ** > Thanks for the suggestion Martin! > > I created 8009376 for this and will try to get it done. > There's already a bug for this: 8006988 : build-infra: Configure fails if 'cl' is in path on linux I've refreshed my patch to implement the consensus. http://cr.openjdk.java.net/~martin/webrevs/openjdk8/COMPILER_CHECK_LIST/ From david.holmes at oracle.com Tue Mar 5 02:25:59 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 05 Mar 2013 12:25:59 +1000 Subject: 8008977: profiles build broken by Nashorn build changes In-Reply-To: References: <512CBD17.8090808@oracle.com> <512D1B0E.3000309@oracle.com> <5134838C.9070702@oracle.com> <0AD855CC-CA24-4F77-BA20-520177F533FD@oracle.com> <8D4DD173-88AB-413B-9DD5-71ACB8107D6B@oracle.com> Message-ID: <513557B7.9030809@oracle.com> On 5/03/2013 3:05 AM, Jim Laskey (Oracle) wrote: > Erik, > > The changes to remove $ from the class file name (Nashorn) are in tl. Thanks Jim. We'll need a new bug filed to revert the original $$ change and the subsequent \$$$$ -> \$$ changes. I can probably do that in conjunction with some other cleanups in the profile-include lists. David ----- > https://jbs.oracle.com/bugs/browse/JDK-8009379 > > HG Updates added a comment - 2013-03-04 12:54 > URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/fe5211fc3114 > User: sundar > Date: 2013-03-04 16:49:50 +0000 > > -- Jim > > > > On 2013-03-04, at 11:58 AM, Jim Laskey (Oracle) wrote: > >> I have a change set making its way to tl that removes this requirement. >> >> -- Jim >> >> >> >> On 2013-03-04, at 11:54 AM, Kelly O'Hair wrote: >> >>> It seems to me that using $ in class names when they are NOT Inner Classes is a huge mistake. >>> >>> Mark my words, this will come back to haunt us, multiple times, I guarantee it. >>> >>> -kto >>> >>> On Mar 4, 2013, at 3:20 AM, Erik Joelsson wrote: >>> >>>> The change in ListPathsSafely was needed because in nashorn, there are java files with $ in the class name (not inner classes!). Thinking of it now, I can imagine my change there causing problems for other uses of the macro. Hopefully it will all be better with fewer $$ in the makefiles in the long run though. >>>> >>>> /Erik >>>> >>>> On 2013-02-26 21:29, David Holmes wrote: >>>>> Alan, >>>>> >>>>> Thanks for diving onto this. I can't say I understand what changed in detail yet but I know that there are places where I had to jump through hoops to deal with $ in class names appropriately. I would not be surprised if there is further breakage if somehow this expansion mechanism has changed. >>>>> >>>>> David >>>>> >>>>> On 26/02/2013 11:48 PM, Alan Bateman wrote: >>>>>> >>>>>> The build changes for Nashorn were pushed to jdk8/tl yesterday and one >>>>>> of the casualties is the profiles build. >>>>>> >>>>>> My reading of the make file changes is that ListPathsSafely_If (defined >>>>>> in MakeBase.gmk) has changed the expansion so that secondary expansion >>>>>> is no longer required. Erik is away this week but I assume this was >>>>>> intentional. >>>>>> >>>>>> Attached is the diffs that I propose to push to jdk8/tl today to get >>>>>> profiles building again, assuming I get a reviewer. >>>>>> >>>>>> -Alan >>>>>> >>>>>> >>>>>> diff --git a/makefiles/profile-rtjar-includes.txt >>>>>> b/makefiles/profile-rtjar-includes.txt >>>>>> --- a/makefiles/profile-rtjar-includes.txt >>>>>> +++ b/makefiles/profile-rtjar-includes.txt >>>>>> @@ -349,6 +349,7 @@ >>>>>> com/sun/rowset/providers \ >>>>>> com/sun/script/javascript \ >>>>>> com/sun/script/util \ >>>>>> + com/sun/security/auth \ >>>>>> com/sun/security/auth/callback \ >>>>>> com/sun/security/auth/login \ >>>>>> com/sun/security/auth/module \ >>>>>> @@ -448,8 +449,7 @@ >>>>>> sun/tracing \ >>>>>> sun/tracing/dtrace >>>>>> >>>>>> -PROFILE_3_RTJAR_INCLUDE_TYPES := \ >>>>>> - com/sun/security/auth/*.class >>>>>> +PROFILE_3_RTJAR_INCLUDE_TYPES := >>>>>> >>>>>> PROFILE_3_RTJAR_EXCLUDE_TYPES := \ >>>>>> javax/management/remote/rmi/_RMIConnectionImpl_Tie.class \ >>>>>> @@ -457,10 +457,10 @@ >>>>>> javax/management/remote/rmi/_RMIServerImpl_Tie.class \ >>>>>> javax/management/remote/rmi/_RMIServer_Stub.class \ >>>>>> com/sun/security/auth/callback/DialogCallbackHandler.class \ >>>>>> - com/sun/security/auth/callback/DialogCallbackHandler\$$$$1.class \ >>>>>> - com/sun/security/auth/callback/DialogCallbackHandler\$$$$2.class \ >>>>>> - >>>>>> com/sun/security/auth/callback/DialogCallbackHandler\$$$$Action.class \ >>>>>> - >>>>>> com/sun/security/auth/callback/DialogCallbackHandler\$$$$ConfirmationInfo.class >>>>>> >>>>>> + com/sun/security/auth/callback/DialogCallbackHandler\$$1.class \ >>>>>> + com/sun/security/auth/callback/DialogCallbackHandler\$$2.class \ >>>>>> + com/sun/security/auth/callback/DialogCallbackHandler\$$Action.class \ >>>>>> + >>>>>> com/sun/security/auth/callback/DialogCallbackHandler\$$ConfirmationInfo.class >>>>>> >>>>>> >>>>>> PROFILE_3_INCLUDE_METAINF_SERVICES := \ >>>>>> META-INF/services/javax.script.ScriptEngineFactory >>> >> > From david.holmes at oracle.com Tue Mar 5 02:30:59 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 05 Mar 2013 12:30:59 +1000 Subject: Review Request: 8009393: Supply correct AR to install build from InstallWrapper.gmk In-Reply-To: <5134D138.5070306@oracle.com> References: <5134D138.5070306@oracle.com> Message-ID: <513558E3.5050901@oracle.com> Looks good to me. Thank Erik. David On 5/03/2013 2:52 AM, Erik Joelsson wrote: > Open part of this review. > > In JDK-8009196, a quick fix for letting the install repo find the > correct AR was submitted. A better solution is possible, reverting that > fix and instead supplying AR on the make command line from > InstallWrapper.gmk, as is the pattern for other such variables. This > webrev just reverts the change made in 8009196. > > http://cr.openjdk.java.net/~erikj/8009393/webrev.jdk.01/ > > /Erik From erik.joelsson at oracle.com Tue Mar 5 07:46:55 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 05 Mar 2013 08:46:55 +0100 Subject: 8008977: profiles build broken by Nashorn build changes In-Reply-To: <513557B7.9030809@oracle.com> References: <512CBD17.8090808@oracle.com> <512D1B0E.3000309@oracle.com> <5134838C.9070702@oracle.com> <0AD855CC-CA24-4F77-BA20-520177F533FD@oracle.com> <8D4DD173-88AB-413B-9DD5-71ACB8107D6B@oracle.com> <513557B7.9030809@oracle.com> Message-ID: <5135A2EF.4040807@oracle.com> On 2013-03-05 03:25, David Holmes wrote: > On 5/03/2013 3:05 AM, Jim Laskey (Oracle) wrote: >> Erik, >> >> The changes to remove $ from the class file name (Nashorn) are in tl. > > Thanks Jim. > > We'll need a new bug filed to revert the original $$ change and the > subsequent \$$$$ -> \$$ changes. I can probably do that in conjunction > with some other cleanups in the profile-include lists. > Good to see this getting resolved. Tell me if you need any help with it. /Erik > David > ----- > >> https://jbs.oracle.com/bugs/browse/JDK-8009379 >> >> HG Updates added a comment - 2013-03-04 12:54 >> URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/fe5211fc3114 >> User: sundar >> Date: 2013-03-04 16:49:50 +0000 >> >> -- Jim >> >> >> >> On 2013-03-04, at 11:58 AM, Jim Laskey (Oracle) >> wrote: >> >>> I have a change set making its way to tl that removes this requirement. >>> >>> -- Jim >>> >>> >>> >>> On 2013-03-04, at 11:54 AM, Kelly O'Hair >>> wrote: >>> >>>> It seems to me that using $ in class names when they are NOT Inner >>>> Classes is a huge mistake. >>>> >>>> Mark my words, this will come back to haunt us, multiple times, I >>>> guarantee it. >>>> >>>> -kto >>>> >>>> On Mar 4, 2013, at 3:20 AM, Erik Joelsson wrote: >>>> >>>>> The change in ListPathsSafely was needed because in nashorn, there >>>>> are java files with $ in the class name (not inner classes!). >>>>> Thinking of it now, I can imagine my change there causing problems >>>>> for other uses of the macro. Hopefully it will all be better with >>>>> fewer $$ in the makefiles in the long run though. >>>>> >>>>> /Erik >>>>> >>>>> On 2013-02-26 21:29, David Holmes wrote: >>>>>> Alan, >>>>>> >>>>>> Thanks for diving onto this. I can't say I understand what >>>>>> changed in detail yet but I know that there are places where I >>>>>> had to jump through hoops to deal with $ in class names >>>>>> appropriately. I would not be surprised if there is further >>>>>> breakage if somehow this expansion mechanism has changed. >>>>>> >>>>>> David >>>>>> >>>>>> On 26/02/2013 11:48 PM, Alan Bateman wrote: >>>>>>> >>>>>>> The build changes for Nashorn were pushed to jdk8/tl yesterday >>>>>>> and one >>>>>>> of the casualties is the profiles build. >>>>>>> >>>>>>> My reading of the make file changes is that ListPathsSafely_If >>>>>>> (defined >>>>>>> in MakeBase.gmk) has changed the expansion so that secondary >>>>>>> expansion >>>>>>> is no longer required. Erik is away this week but I assume this was >>>>>>> intentional. >>>>>>> >>>>>>> Attached is the diffs that I propose to push to jdk8/tl today to >>>>>>> get >>>>>>> profiles building again, assuming I get a reviewer. >>>>>>> >>>>>>> -Alan >>>>>>> >>>>>>> >>>>>>> diff --git a/makefiles/profile-rtjar-includes.txt >>>>>>> b/makefiles/profile-rtjar-includes.txt >>>>>>> --- a/makefiles/profile-rtjar-includes.txt >>>>>>> +++ b/makefiles/profile-rtjar-includes.txt >>>>>>> @@ -349,6 +349,7 @@ >>>>>>> com/sun/rowset/providers \ >>>>>>> com/sun/script/javascript \ >>>>>>> com/sun/script/util \ >>>>>>> + com/sun/security/auth \ >>>>>>> com/sun/security/auth/callback \ >>>>>>> com/sun/security/auth/login \ >>>>>>> com/sun/security/auth/module \ >>>>>>> @@ -448,8 +449,7 @@ >>>>>>> sun/tracing \ >>>>>>> sun/tracing/dtrace >>>>>>> >>>>>>> -PROFILE_3_RTJAR_INCLUDE_TYPES := \ >>>>>>> - com/sun/security/auth/*.class >>>>>>> +PROFILE_3_RTJAR_INCLUDE_TYPES := >>>>>>> >>>>>>> PROFILE_3_RTJAR_EXCLUDE_TYPES := \ >>>>>>> javax/management/remote/rmi/_RMIConnectionImpl_Tie.class \ >>>>>>> @@ -457,10 +457,10 @@ >>>>>>> javax/management/remote/rmi/_RMIServerImpl_Tie.class \ >>>>>>> javax/management/remote/rmi/_RMIServer_Stub.class \ >>>>>>> com/sun/security/auth/callback/DialogCallbackHandler.class \ >>>>>>> - >>>>>>> com/sun/security/auth/callback/DialogCallbackHandler\$$$$1.class \ >>>>>>> - >>>>>>> com/sun/security/auth/callback/DialogCallbackHandler\$$$$2.class \ >>>>>>> - >>>>>>> com/sun/security/auth/callback/DialogCallbackHandler\$$$$Action.class >>>>>>> \ >>>>>>> - >>>>>>> com/sun/security/auth/callback/DialogCallbackHandler\$$$$ConfirmationInfo.class >>>>>>> >>>>>>> >>>>>>> + >>>>>>> com/sun/security/auth/callback/DialogCallbackHandler\$$1.class \ >>>>>>> + >>>>>>> com/sun/security/auth/callback/DialogCallbackHandler\$$2.class \ >>>>>>> + >>>>>>> com/sun/security/auth/callback/DialogCallbackHandler\$$Action.class >>>>>>> \ >>>>>>> + >>>>>>> com/sun/security/auth/callback/DialogCallbackHandler\$$ConfirmationInfo.class >>>>>>> >>>>>>> >>>>>>> >>>>>>> PROFILE_3_INCLUDE_METAINF_SERVICES := \ >>>>>>> META-INF/services/javax.script.ScriptEngineFactory >>>> >>> >> From david.holmes at oracle.com Tue Mar 5 07:51:14 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 05 Mar 2013 17:51:14 +1000 Subject: 8008977: profiles build broken by Nashorn build changes In-Reply-To: <5135A2EF.4040807@oracle.com> References: <512CBD17.8090808@oracle.com> <512D1B0E.3000309@oracle.com> <5134838C.9070702@oracle.com> <0AD855CC-CA24-4F77-BA20-520177F533FD@oracle.com> <8D4DD173-88AB-413B-9DD5-71ACB8107D6B@oracle.com> <513557B7.9030809@oracle.com> <5135A2EF.4040807@oracle.com> Message-ID: <5135A3F2.5020406@oracle.com> On 5/03/2013 5:46 PM, Erik Joelsson wrote: > > > On 2013-03-05 03:25, David Holmes wrote: >> On 5/03/2013 3:05 AM, Jim Laskey (Oracle) wrote: >>> Erik, >>> >>> The changes to remove $ from the class file name (Nashorn) are in tl. >> >> Thanks Jim. >> >> We'll need a new bug filed to revert the original $$ change and the >> subsequent \$$$$ -> \$$ changes. I can probably do that in conjunction >> with some other cleanups in the profile-include lists. >> > Good to see this getting resolved. Tell me if you need any help with it. All in hand - thanks Erik. JDK-8009428: Revert changes to $ substitution performed as part of nashorn integration David ----- > /Erik >> David >> ----- >> >>> https://jbs.oracle.com/bugs/browse/JDK-8009379 >>> >>> HG Updates added a comment - 2013-03-04 12:54 >>> URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/fe5211fc3114 >>> User: sundar >>> Date: 2013-03-04 16:49:50 +0000 >>> >>> -- Jim >>> >>> >>> >>> On 2013-03-04, at 11:58 AM, Jim Laskey (Oracle) >>> wrote: >>> >>>> I have a change set making its way to tl that removes this requirement. >>>> >>>> -- Jim >>>> >>>> >>>> >>>> On 2013-03-04, at 11:54 AM, Kelly O'Hair >>>> wrote: >>>> >>>>> It seems to me that using $ in class names when they are NOT Inner >>>>> Classes is a huge mistake. >>>>> >>>>> Mark my words, this will come back to haunt us, multiple times, I >>>>> guarantee it. >>>>> >>>>> -kto >>>>> >>>>> On Mar 4, 2013, at 3:20 AM, Erik Joelsson wrote: >>>>> >>>>>> The change in ListPathsSafely was needed because in nashorn, there >>>>>> are java files with $ in the class name (not inner classes!). >>>>>> Thinking of it now, I can imagine my change there causing problems >>>>>> for other uses of the macro. Hopefully it will all be better with >>>>>> fewer $$ in the makefiles in the long run though. >>>>>> >>>>>> /Erik >>>>>> >>>>>> On 2013-02-26 21:29, David Holmes wrote: >>>>>>> Alan, >>>>>>> >>>>>>> Thanks for diving onto this. I can't say I understand what >>>>>>> changed in detail yet but I know that there are places where I >>>>>>> had to jump through hoops to deal with $ in class names >>>>>>> appropriately. I would not be surprised if there is further >>>>>>> breakage if somehow this expansion mechanism has changed. >>>>>>> >>>>>>> David >>>>>>> >>>>>>> On 26/02/2013 11:48 PM, Alan Bateman wrote: >>>>>>>> >>>>>>>> The build changes for Nashorn were pushed to jdk8/tl yesterday >>>>>>>> and one >>>>>>>> of the casualties is the profiles build. >>>>>>>> >>>>>>>> My reading of the make file changes is that ListPathsSafely_If >>>>>>>> (defined >>>>>>>> in MakeBase.gmk) has changed the expansion so that secondary >>>>>>>> expansion >>>>>>>> is no longer required. Erik is away this week but I assume this was >>>>>>>> intentional. >>>>>>>> >>>>>>>> Attached is the diffs that I propose to push to jdk8/tl today to >>>>>>>> get >>>>>>>> profiles building again, assuming I get a reviewer. >>>>>>>> >>>>>>>> -Alan >>>>>>>> >>>>>>>> >>>>>>>> diff --git a/makefiles/profile-rtjar-includes.txt >>>>>>>> b/makefiles/profile-rtjar-includes.txt >>>>>>>> --- a/makefiles/profile-rtjar-includes.txt >>>>>>>> +++ b/makefiles/profile-rtjar-includes.txt >>>>>>>> @@ -349,6 +349,7 @@ >>>>>>>> com/sun/rowset/providers \ >>>>>>>> com/sun/script/javascript \ >>>>>>>> com/sun/script/util \ >>>>>>>> + com/sun/security/auth \ >>>>>>>> com/sun/security/auth/callback \ >>>>>>>> com/sun/security/auth/login \ >>>>>>>> com/sun/security/auth/module \ >>>>>>>> @@ -448,8 +449,7 @@ >>>>>>>> sun/tracing \ >>>>>>>> sun/tracing/dtrace >>>>>>>> >>>>>>>> -PROFILE_3_RTJAR_INCLUDE_TYPES := \ >>>>>>>> - com/sun/security/auth/*.class >>>>>>>> +PROFILE_3_RTJAR_INCLUDE_TYPES := >>>>>>>> >>>>>>>> PROFILE_3_RTJAR_EXCLUDE_TYPES := \ >>>>>>>> javax/management/remote/rmi/_RMIConnectionImpl_Tie.class \ >>>>>>>> @@ -457,10 +457,10 @@ >>>>>>>> javax/management/remote/rmi/_RMIServerImpl_Tie.class \ >>>>>>>> javax/management/remote/rmi/_RMIServer_Stub.class \ >>>>>>>> com/sun/security/auth/callback/DialogCallbackHandler.class \ >>>>>>>> - >>>>>>>> com/sun/security/auth/callback/DialogCallbackHandler\$$$$1.class \ >>>>>>>> - >>>>>>>> com/sun/security/auth/callback/DialogCallbackHandler\$$$$2.class \ >>>>>>>> - >>>>>>>> com/sun/security/auth/callback/DialogCallbackHandler\$$$$Action.class >>>>>>>> \ >>>>>>>> - >>>>>>>> com/sun/security/auth/callback/DialogCallbackHandler\$$$$ConfirmationInfo.class >>>>>>>> >>>>>>>> >>>>>>>> + com/sun/security/auth/callback/DialogCallbackHandler\$$1.class \ >>>>>>>> + com/sun/security/auth/callback/DialogCallbackHandler\$$2.class \ >>>>>>>> + >>>>>>>> com/sun/security/auth/callback/DialogCallbackHandler\$$Action.class >>>>>>>> \ >>>>>>>> + >>>>>>>> com/sun/security/auth/callback/DialogCallbackHandler\$$ConfirmationInfo.class >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> PROFILE_3_INCLUDE_METAINF_SERVICES := \ >>>>>>>> META-INF/services/javax.script.ScriptEngineFactory >>>>> >>>> >>> From david.holmes at oracle.com Tue Mar 5 07:52:56 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 05 Mar 2013 17:52:56 +1000 Subject: Dollar ($) expansion still needs attention In-Reply-To: <51342A3A.1010400@oracle.com> References: <512D73C1.50504@oracle.com> <512DDCDC.7080400@oracle.com> <5763BF73-F88A-4CB3-843B-8398BAA52DB8@oracle.com> <51342A3A.1010400@oracle.com> Message-ID: <5135A458.6000709@oracle.com> Just to close off this thread. The nashorn code was changed to not use $ in .java file names. So we can revert the \$$$$ changes: JDK-8009428: Revert changes to $ substitution performed as part of nashorn integration David On 4/03/2013 2:59 PM, David Holmes wrote: > On 27/02/2013 10:14 PM, Jim Laskey (Oracle) wrote: >> I wanted to double check and trace the origins of the MakeBase.gmk >> patch before I responded. It was part of the original set Erik sent >> me, but looking thru the other parts of the patch it's not clear why >> it was necessary. >> >> http://cr.openjdk.java.net/~erikj/nashorn-build/webrev.01/ > > So I got to the bottom of this. Basically if a make variable expands to > contain a filename for a nested class (ie one with $ in it) then you > need to escape the $ so that make doesn't treat it as a meta-character. > And because $ is also the shell meta-character you end up needing a > double escape of the form \$$$$, depending on how that variables gets > used in targets/pre-reqs/recipes. > > Prior to the nashorn change ListPathsSafely didn't do any $ escaping and > any explicit reference to a nested class file, such as: > > sun/awt/motif/X11GB2312\$$$$Decoder.class > > in the makefile, had to use the \$$$$. And everything worked fine. > > What nashorn introduced was .java files with $ in their name: > > > dir ../nashorn/src/jdk/nashorn/internal/scripts/ > total 16 > drwxr-xr-x 2 daholme uucp 4096 Feb 26 01:26 . > drwxr-xr-x 8 daholme uucp 4096 Feb 26 01:26 .. > -rw-r--r-- 1 daholme uucp 2027 Feb 26 01:26 JO$.java > -rw-r--r-- 1 daholme uucp 1322 Feb 26 01:26 JS$.java > > so when ListPathsSafely was used together with a src directory to expand > into a set of source files, there was no $ escaping and so the $ got > dropped from the name, and so the nashorn build failed. > > So the escaping was added to ListPathsSafely. But not the full \$$$$ as > the need for that depends upon exactly how the make variable is used. > For Java compilation commands ListPathSafely only had to do a simpler $ > -> $$ escape sequence. > > But this means that anything explicitly escaped with \$$$$ and passed to > ListPathsSafely was now broken as there were too many escapes. This is > what broke the profiles builds. So to fix that we had to reduce the > number of escapes in the explicitly named files ie: > > sun/awt/motif/X11GB2312\$$Decoder.class > > so that after processing by ListPathsSafely it was back to the full > \$$$$ form. > > That would have been the end of it, except, as I pointed out, not all > uses of nested class file names get passed through ListFilesSafely. > Those that do not still need the \$$$$ escape, while those that do need > only \$$. Hence we have the problem that when writing the name of such a > file you have to know how it is going to be used - which is not a very > maintainable solution. > > I propose that we regress the change to ListpathsSafely so that it > doesn't do the $ escape, and instead we either: > > a) rename the nashorn .java files with $ in their name; or else > b) add the $ escape at a different point in the src list expansion so > that it only affects src list expansion > > Pragmatically I prefer (a) because having $ in filenames is really a > PITA when it is both the make meta-character and the shell > meta-character. It's too late for .class file names but if we can avoid > adding it to .java file names then we will simplify our lives. :) > > Otherwise (b) should be done somewhere in the bowels of > JavaCompilation.gmk, probably by adjusting $1_ALL_SRCS. > > > David > ----- > > > > >> -- Jim >> >> >> >> >> On 2013-02-27, at 6:15 AM, Alan Bateman wrote: >> >>> On 27/02/2013 02:47, David Holmes wrote: >>>> : >>>> >>>> So the same file names are listed once with \$$ and once with \$$$$, >>>> and they both have to be that way to work! >>>> >>>> This is untenable. There should only be one way to write the name of >>>> a nested class file inside the makefile. >>>> >>>> FYI in Profiles.gmk when expanding foo/*.class I already had to do a >>>> similar substitution as is now in ListPathsSafely: >>>> >>>> # Function to expand foo/*.class into the set of classes >>>> # NOTE: Classfiles with $ in their name are problematic as that is the >>>> # meta-character for both make and the shell! Hence the \$$$$ >>>> substitution. >>>> # But note that if you echo these values they will NOT display as >>>> expected. >>>> class_list = $(patsubst $(JDK_OUTPUTDIR)/classes/%,%,\ >>>> $(foreach i,$(1), $(subst $$,\$$$$, $(wildcard >>>> $(JDK_OUTPUTDIR)/classes/$i)))) >>>> >>>> >>>> So I'd like to understand why the nashorn change was made so that we >>>> can determine how to get back to only having one way to specify file >>>> names containing $ >>> I completely agree, it's very difficult to maintain. Also the two >>> patches yesterday were just to get the build working again (Erik is >>> out this week so it wasn't possible to establish why MakeBase.gmk was >>> changed, also I cannot find the review thread to know if it came up >>> during the review). >>> >>> -Alan >> From erik.joelsson at oracle.com Tue Mar 5 14:01:21 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 05 Mar 2013 15:01:21 +0100 Subject: Review Request: 8008073: build-infra: Need --with-dxsdk option? And awt/sound -I option additions? Message-ID: <5135FAB1.9000605@oracle.com> This patch adds support for compiling and linking against a specific dxsdk to the new build. This was omitted by mistake during the conversion from the old build. This patch adds three new configure parameters: --with-dxsdk --with-dxsdk-lib --with-dxsdk-include The latter two are constructed from the first if not supplied. If --with-dxsdk is not given, the environment variable DXSDK_DIR is checked (which is set by the sdk installation). The include dir is added to the compiler flags for jsoundds, awt and jawt. The lib dir is added to all jdk link flags. This mimics the old build as far as I can tell. Note that I could only find actual linking to dxsdk libraries for jsoundds. http://cr.openjdk.java.net/~erikj/8008073/webrev.root.01/ http://cr.openjdk.java.net/~erikj/8008073/webrev.jdk.01/ /Erik From erik.joelsson at oracle.com Tue Mar 5 15:14:09 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 05 Mar 2013 16:14:09 +0100 Subject: Review Request: 8006828: "SKIP_BOOT_CYCLE=false" must work in new building infrastructure In-Reply-To: <5124DBC4.5050906@oracle.com> References: <5124DBC4.5050906@oracle.com> Message-ID: <51360BC1.8060505@oracle.com> On 2013-02-20 15:20, Erik Joelsson wrote: > Adding check for SKIP_BOOT_CYCLE=false in Jprt.gmk which adds the > target bootcycle-images. Also fixing an issue with bootcycle-images > target that prevented them from creating images. > > http://cr.openjdk.java.net/~erikj/8006828/webrev.root.01/ > http://cr.openjdk.java.net/~erikj/8006828/webrev.root.02/ Discovered some more problems with the bootcycle-images target that needed to be fixed. A full bootcycle build is still not possible due to errors like this: /localhome/mercurial/closed-jdk8-build/jdk/make/tools/src/build/tools/javazic/GenDoc.java:123: error: cannot f ind symbol String zonefile = ZoneInfoFile.getFileName(zonename) + ".html"; /Erik From tim.bell at oracle.com Tue Mar 5 15:27:12 2013 From: tim.bell at oracle.com (Tim Bell) Date: Tue, 05 Mar 2013 07:27:12 -0800 Subject: Review Request: 8008073: build-infra: Need --with-dxsdk option? And awt/sound -I option additions? In-Reply-To: <5135FAB1.9000605@oracle.com> References: <5135FAB1.9000605@oracle.com> Message-ID: <51360ED0.2000806@oracle.com> Erik: Looks good. Tim > This patch adds support for compiling and linking against a specific > dxsdk to the new build. This was omitted by mistake during the > conversion from the old build. > > This patch adds three new configure parameters: > > --with-dxsdk > --with-dxsdk-lib > --with-dxsdk-include > > The latter two are constructed from the first if not supplied. If > --with-dxsdk is not given, the environment variable DXSDK_DIR is > checked (which is set by the sdk installation). > > The include dir is added to the compiler flags for jsoundds, awt and > jawt. The lib dir is added to all jdk link flags. This mimics the old > build as far as I can tell. Note that I could only find actual linking > to dxsdk libraries for jsoundds. > > http://cr.openjdk.java.net/~erikj/8008073/webrev.root.01/ > http://cr.openjdk.java.net/~erikj/8008073/webrev.jdk.01/ > > /Erik > From Alan.Bateman at oracle.com Tue Mar 5 15:30:31 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 05 Mar 2013 15:30:31 +0000 Subject: Review Request: 8006828: "SKIP_BOOT_CYCLE=false" must work in new building infrastructure In-Reply-To: <51360BC1.8060505@oracle.com> References: <5124DBC4.5050906@oracle.com> <51360BC1.8060505@oracle.com> Message-ID: <51360F97.5060400@oracle.com> On 05/03/2013 15:14, Erik Joelsson wrote: > : > > Discovered some more problems with the bootcycle-images target that > needed to be fixed. A full bootcycle build is still not possible due > to errors like this: > > /localhome/mercurial/closed-jdk8-build/jdk/make/tools/src/build/tools/javazic/GenDoc.java:123: > error: cannot f > ind symbol > String zonefile = ZoneInfoFile.getFileName(zonename) + > ".html"; This has been fix in jdk8/tl, it just hasn't got to master yet: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/43726ed11fb3 -Alan. From Alan.Bateman at oracle.com Tue Mar 5 15:34:05 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 05 Mar 2013 15:34:05 +0000 Subject: --with-zlib=system supposed to work? Message-ID: <5136106D.8070400@oracle.com> I've been meaning to ask this for a while but is --with-zlib=system supposed to work? With the old build then there is a build variable to use the system zlib but it only worked (to my knowledge) when doing dynamic linking of C++ runtime. Attached is what I get currently and maybe we have to look at the pack200 code to resolve this but I was just curious if this configure optional has been used successfully or not. I tried it with --with-stdc++lib=dynamic too. -Alan. /u/alanb/ws/tl/build/linux-x86_64-normal-server-release/jdk/objs/unpackexe/zip.o: In function `jar::deflate_bytes(bytes&, bytes&)': zip.cpp:(.text+0x71a): undefined reference to `deflateInit2_' zip.cpp:(.text+0x7b6): undefined reference to `deflate' zip.cpp:(.text+0x7d0): undefined reference to `deflateEnd' zip.cpp:(.text+0x7e4): undefined reference to `deflateEnd' zip.cpp:(.text+0x7f6): undefined reference to `deflate' /u/alanb/ws/tl/build/linux-x86_64-normal-server-release/jdk/objs/unpackexe/zip.o: In function `jar::addJarEntry(char const*, bool, int, bytes&, bytes&)': zip.cpp:(.text+0x84e): undefined reference to `crc32' zip.cpp:(.text+0x910): undefined reference to `crc32' zip.cpp:(.text+0x926): undefined reference to `crc32' /u/alanb/ws/tl/build/linux-x86_64-normal-server-release/jdk/objs/unpackexe/zip.o: In function `gunzip::free()': zip.cpp:(.text+0xa17): undefined reference to `inflateEnd' /u/alanb/ws/tl/build/linux-x86_64-normal-server-release/jdk/objs/unpackexe/zip.o: In function `read_input_via_gzip(unpacker*, void*, long, long)': zip.cpp:(.text+0xa96): undefined reference to `inflate' zip.cpp:(.text+0xb0a): undefined reference to `inflate' /u/alanb/ws/tl/build/linux-x86_64-normal-server-release/jdk/objs/unpackexe/zip.o: In function `gunzip::start(int)': zip.cpp:(.text+0xd03): undefined reference to `inflateInit2_' collect2: ld returned 1 exit status make[2]: *** [/u/alanb/ws/tl/build/linux-x86_64-normal-server-release/jdk/objs/unpackexe/unpack200] Error 1 make[1]: *** [launchers-only] Error 2 make: *** [jdk-only] Error 2 From erik.joelsson at oracle.com Tue Mar 5 16:07:56 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 05 Mar 2013 17:07:56 +0100 Subject: --with-zlib=system supposed to work? In-Reply-To: <5136106D.8070400@oracle.com> References: <5136106D.8070400@oracle.com> Message-ID: <5136185C.4020309@oracle.com> I just tried it on my machine (Ubuntu 10.10) and it works. I can imagine it being sensitive to the exact version of zlib on the system though. Doing this, my resulting libzip.so is linked against the system libz: $ ldd images/j2sdk-image/jre/lib/amd64/libzip.so libz.so.1 => /lib/libz.so.1 (0x00007f7477b4a000) (cutting out the other libs) /Erik On 2013-03-05 16:34, Alan Bateman wrote: > > I've been meaning to ask this for a while but is --with-zlib=system > supposed to work? > > With the old build then there is a build variable to use the system > zlib but it only worked (to my knowledge) when doing dynamic linking > of C++ runtime. > > Attached is what I get currently and maybe we have to look at the > pack200 code to resolve this but I was just curious if this configure > optional has been used successfully or not. I tried it with > --with-stdc++lib=dynamic too. > > -Alan. > > > /u/alanb/ws/tl/build/linux-x86_64-normal-server-release/jdk/objs/unpackexe/zip.o: > In function `jar::deflate_bytes(bytes&, bytes&)': > zip.cpp:(.text+0x71a): undefined reference to `deflateInit2_' > zip.cpp:(.text+0x7b6): undefined reference to `deflate' > zip.cpp:(.text+0x7d0): undefined reference to `deflateEnd' > zip.cpp:(.text+0x7e4): undefined reference to `deflateEnd' > zip.cpp:(.text+0x7f6): undefined reference to `deflate' > /u/alanb/ws/tl/build/linux-x86_64-normal-server-release/jdk/objs/unpackexe/zip.o: > In function `jar::addJarEntry(char const*, bool, int, bytes&, bytes&)': > zip.cpp:(.text+0x84e): undefined reference to `crc32' > zip.cpp:(.text+0x910): undefined reference to `crc32' > zip.cpp:(.text+0x926): undefined reference to `crc32' > /u/alanb/ws/tl/build/linux-x86_64-normal-server-release/jdk/objs/unpackexe/zip.o: > In function `gunzip::free()': > zip.cpp:(.text+0xa17): undefined reference to `inflateEnd' > /u/alanb/ws/tl/build/linux-x86_64-normal-server-release/jdk/objs/unpackexe/zip.o: > In function `read_input_via_gzip(unpacker*, void*, long, long)': > zip.cpp:(.text+0xa96): undefined reference to `inflate' > zip.cpp:(.text+0xb0a): undefined reference to `inflate' > /u/alanb/ws/tl/build/linux-x86_64-normal-server-release/jdk/objs/unpackexe/zip.o: > In function `gunzip::start(int)': > zip.cpp:(.text+0xd03): undefined reference to `inflateInit2_' > collect2: ld returned 1 exit status > make[2]: *** > [/u/alanb/ws/tl/build/linux-x86_64-normal-server-release/jdk/objs/unpackexe/unpack200] > Error 1 > make[1]: *** [launchers-only] Error 2 > make: *** [jdk-only] Error 2 From martinrb at google.com Tue Mar 5 21:19:57 2013 From: martinrb at google.com (Martin Buchholz) Date: Tue, 5 Mar 2013 13:19:57 -0800 Subject: New build system problems In-Reply-To: <5135A29F.3000804@oracle.com> References: <5129CD25.2000003@oracle.com> <513486CE.40405@oracle.com> <5135A29F.3000804@oracle.com> Message-ID: Thanks. Pushed to /hg/jdk8/tl. (only tested on Linux) On Mon, Mar 4, 2013 at 11:45 PM, Erik Joelsson wrote: > ** > On 2013-03-04 23:55, Martin Buchholz wrote: > > > > On Mon, Mar 4, 2013 at 3:34 AM, Erik Joelsson wrote: > >> Thanks for the suggestion Martin! >> >> I created 8009376 for this and will try to get it done. >> > > There's already a bug for this: > > 8006988 : build-infra: Configure fails if 'cl' is in path on linux > > Oop, thanks! > > I've refreshed my patch to implement the consensus. > http://cr.openjdk.java.net/~martin/webrevs/openjdk8/COMPILER_CHECK_LIST/ > > And thanks again. I think this looks good. > > /Erik > From david.holmes at oracle.com Tue Mar 5 21:44:12 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 06 Mar 2013 07:44:12 +1000 Subject: New build system problems In-Reply-To: References: <5129CD25.2000003@oracle.com> <513486CE.40405@oracle.com> <5135A29F.3000804@oracle.com> Message-ID: <5136672C.8080102@oracle.com> Martin, Erik, On 6/03/2013 7:19 AM, Martin Buchholz wrote: > Thanks. > Pushed to /hg/jdk8/tl. There has to be a corresponding push of the update to closed generated-configure.sh. This will now break all non OPENJDK builds. David > (only tested on Linux) > > On Mon, Mar 4, 2013 at 11:45 PM, Erik Joelsson wrote: > >> ** >> On 2013-03-04 23:55, Martin Buchholz wrote: >> >> >> >> On Mon, Mar 4, 2013 at 3:34 AM, Erik Joelsson wrote: >> >>> Thanks for the suggestion Martin! >>> >>> I created 8009376 for this and will try to get it done. >>> >> >> There's already a bug for this: >> >> 8006988 : build-infra: Configure fails if 'cl' is in path on linux >> >> Oop, thanks! >> >> I've refreshed my patch to implement the consensus. >> http://cr.openjdk.java.net/~martin/webrevs/openjdk8/COMPILER_CHECK_LIST/ >> >> And thanks again. I think this looks good. >> >> /Erik >> From david.holmes at oracle.com Tue Mar 5 21:53:30 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 06 Mar 2013 07:53:30 +1000 Subject: New build system problems In-Reply-To: References: <5129CD25.2000003@oracle.com> <513486CE.40405@oracle.com> <5135A29F.3000804@oracle.com> Message-ID: <5136695A.2030808@oracle.com> Martin, A couple of points of order here On 6/03/2013 7:19 AM, Martin Buchholz wrote: > Thanks. > Pushed to /hg/jdk8/tl. You needed to have a jdk8 Reviewer listed for this change. Erik is a Committer not Reviewer. > (only tested on Linux) I sincerely hope Erik tested on Windows, BSD and Solaris before this was pushed! David ----- > On Mon, Mar 4, 2013 at 11:45 PM, Erik Joelsson wrote: > >> ** >> On 2013-03-04 23:55, Martin Buchholz wrote: >> >> >> >> On Mon, Mar 4, 2013 at 3:34 AM, Erik Joelsson wrote: >> >>> Thanks for the suggestion Martin! >>> >>> I created 8009376 for this and will try to get it done. >>> >> >> There's already a bug for this: >> >> 8006988 : build-infra: Configure fails if 'cl' is in path on linux >> >> Oop, thanks! >> >> I've refreshed my patch to implement the consensus. >> http://cr.openjdk.java.net/~martin/webrevs/openjdk8/COMPILER_CHECK_LIST/ >> >> And thanks again. I think this looks good. >> >> /Erik >> From martinrb at google.com Tue Mar 5 22:20:55 2013 From: martinrb at google.com (Martin Buchholz) Date: Tue, 5 Mar 2013 14:20:55 -0800 Subject: New build system problems In-Reply-To: <5136672C.8080102@oracle.com> References: <5129CD25.2000003@oracle.com> <513486CE.40405@oracle.com> <5135A29F.3000804@oracle.com> <5136672C.8080102@oracle.com> Message-ID: Oh dear. Please add in a fixup change if required. On Tue, Mar 5, 2013 at 1:44 PM, David Holmes wrote: > Martin, Erik, > > On 6/03/2013 7:19 AM, Martin Buchholz wrote: > >> Thanks. >> Pushed to /hg/jdk8/tl. >> > > There has to be a corresponding push of the update to closed > generated-configure.sh. This will now break all non OPENJDK builds. > > David > > (only tested on Linux) >> >> On Mon, Mar 4, 2013 at 11:45 PM, Erik Joelsson >> **wrote: >> >> ** >>> >>> On 2013-03-04 23:55, Martin Buchholz wrote: >>> >>> >>> >>> On Mon, Mar 4, 2013 at 3:34 AM, Erik Joelsson >>> **wrote: >>> >>> Thanks for the suggestion Martin! >>>> >>>> I created 8009376 for this and will try to get it done. >>>> >>>> >>> There's already a bug for this: >>> >>> 8006988 : build-infra: Configure fails if 'cl' is in path on linux >>> >>> Oop, thanks! >>> >>> I've refreshed my patch to implement the consensus. >>> http://cr.openjdk.java.net/~**martin/webrevs/openjdk8/** >>> COMPILER_CHECK_LIST/ >>> >>> And thanks again. I think this looks good. >>> >>> /Erik >>> >>> From martinrb at google.com Tue Mar 5 22:24:03 2013 From: martinrb at google.com (Martin Buchholz) Date: Tue, 5 Mar 2013 14:24:03 -0800 Subject: New build system problems In-Reply-To: <5136695A.2030808@oracle.com> References: <5129CD25.2000003@oracle.com> <513486CE.40405@oracle.com> <5135A29F.3000804@oracle.com> <5136695A.2030808@oracle.com> Message-ID: On Tue, Mar 5, 2013 at 1:53 PM, David Holmes wrote: > > You needed to have a jdk8 Reviewer listed for this change. Erik is a > Committer not Reviewer. > > That's not obvious. Isn't it jcheck's job to make sure any required approvals are in? I should have included more eyeball names on the Reviewed-by: line anyways. > (only tested on Linux) >> > > I sincerely hope Erik tested on Windows, BSD and Solaris before this was > pushed! > This kind of change is very hard for folks outside of Oracle to test, without jprt access. On the other hand, any breakage is easy to detect and fix. Let's not be too afraid to make changes! From david.holmes at oracle.com Tue Mar 5 22:36:04 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 06 Mar 2013 08:36:04 +1000 Subject: New build system problems In-Reply-To: References: <5129CD25.2000003@oracle.com> <513486CE.40405@oracle.com> <5135A29F.3000804@oracle.com> <5136695A.2030808@oracle.com> Message-ID: <51367354.2060705@oracle.com> On 6/03/2013 8:24 AM, Martin Buchholz wrote: > On Tue, Mar 5, 2013 at 1:53 PM, David Holmes > wrote: > > You needed to have a jdk8 Reviewer listed for this change. Erik is a > Committer not Reviewer. > > That's not obvious. Isn't it jcheck's job to make sure any required > approvals are in? It should be but obviously it does not do that check. That said you are an OpenJDK Reviewer and you should be familiar with the OpenJDK rules. > I should have included more eyeball names on the Reviewed-by: line anyways. Yes - mine would have fulfilled the requirement. ;-) > (only tested on Linux) > > I sincerely hope Erik tested on Windows, BSD and Solaris before this > was pushed! > > This kind of change is very hard for folks outside of Oracle to test, > without jprt access. On the other hand, any breakage is easy to detect > and fix. Let's not be too afraid to make changes! Sorry but that is completely unacceptable. If you are providing changes that obviously impact multiple platforms (ie there are platform specific changes) then they _must_ be tested on all platforms. If the external author/committer can not do that then they must work with someone in Oracle who can assist with JPRT runs etc. David From martinrb at google.com Tue Mar 5 23:17:03 2013 From: martinrb at google.com (Martin Buchholz) Date: Tue, 5 Mar 2013 15:17:03 -0800 Subject: New build system problems In-Reply-To: <51367354.2060705@oracle.com> References: <5129CD25.2000003@oracle.com> <513486CE.40405@oracle.com> <5135A29F.3000804@oracle.com> <5136695A.2030808@oracle.com> <51367354.2060705@oracle.com> Message-ID: On Tue, Mar 5, 2013 at 2:36 PM, David Holmes wrote: > > Sorry but that is completely unacceptable. If you are providing changes > that obviously impact multiple platforms (ie there are platform specific > changes) then they _must_ be tested on all platforms. If the external > author/committer can not do that then they must work with someone in Oracle > who can assist with JPRT runs etc. There's always a tradeoff between agility and not breaking other folks. IMO the right approach is to improve processes so that bad commits don't cause other developers to lose time. Once upon a time, I was actually the tl gatekeeper and I implemented such a system. Today, I see there's a tl-gate, but there's close to zero testing between submission to tl-gate and "promotion" to tl-proper. In the system I implemented, there was a full build/test cycle in between. From david.holmes at oracle.com Tue Mar 5 23:30:34 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 06 Mar 2013 09:30:34 +1000 Subject: New build system problems In-Reply-To: References: <5129CD25.2000003@oracle.com> <513486CE.40405@oracle.com> <5135A29F.3000804@oracle.com> <5136695A.2030808@oracle.com> <51367354.2060705@oracle.com> Message-ID: <5136801A.1050907@oracle.com> On 6/03/2013 9:17 AM, Martin Buchholz wrote: > > > On Tue, Mar 5, 2013 at 2:36 PM, David Holmes > wrote: > > > Sorry but that is completely unacceptable. If you are providing > changes that obviously impact multiple platforms (ie there are > platform specific changes) then they _must_ be tested on all > platforms. If the external author/committer can not do that then > they must work with someone in Oracle who can assist with JPRT runs etc. > > > There's always a tradeoff between agility and not breaking other folks. And in this kind of case the right tradeoff is to not break things. You simply can't push a change and not have tested a build! > IMO the right approach is to improve processes so that bad commits don't > cause other developers to lose time. Once upon a time, I was actually > the tl gatekeeper and I implemented such a system. Today, I see there's > a tl-gate, but there's close to zero testing between submission to > tl-gate and "promotion" to tl-proper. In the system I implemented, > there was a full build/test cycle in between. The processes should be there to catch mistakes, not to encourage lack of upfront testing. If the "gate" provided such functionality it would be like submitting each change via JPRT. While a nice idea it is completely impractical given the resources it would require. David From martinrb at google.com Tue Mar 5 23:44:33 2013 From: martinrb at google.com (Martin Buchholz) Date: Tue, 5 Mar 2013 15:44:33 -0800 Subject: New build system problems In-Reply-To: <5136801A.1050907@oracle.com> References: <5129CD25.2000003@oracle.com> <513486CE.40405@oracle.com> <5135A29F.3000804@oracle.com> <5136695A.2030808@oracle.com> <51367354.2060705@oracle.com> <5136801A.1050907@oracle.com> Message-ID: On Tue, Mar 5, 2013 at 3:30 PM, David Holmes wrote: > On 6/03/2013 9:17 AM, Martin Buchholz wrote: > >> >> IMO the right approach is to improve processes so that bad commits don't >> cause other developers to lose time. Once upon a time, I was actually >> the tl gatekeeper and I implemented such a system. Today, I see there's >> a tl-gate, but there's close to zero testing between submission to >> tl-gate and "promotion" to tl-proper. In the system I implemented, >> there was a full build/test cycle in between. >> > > The processes should be there to catch mistakes, not to encourage lack of > upfront testing. > > I disagree. The submitter should be responsible for the "right" amount of upfront testing. > If the "gate" provided such functionality it would be like submitting each > change via JPRT. While a nice idea it is completely impractical given the > resources it would require. But ... I actually implemented such a system for tl, back in 2005! The current state is a regression. Martin From david.holmes at oracle.com Wed Mar 6 00:36:23 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 06 Mar 2013 10:36:23 +1000 Subject: New build system problems In-Reply-To: References: <5129CD25.2000003@oracle.com> <513486CE.40405@oracle.com> <5135A29F.3000804@oracle.com> <5136695A.2030808@oracle.com> <51367354.2060705@oracle.com> <5136801A.1050907@oracle.com> Message-ID: <51368F87.3010501@oracle.com> On 6/03/2013 9:44 AM, Martin Buchholz wrote: > On Tue, Mar 5, 2013 at 3:30 PM, David Holmes wrote: > >> On 6/03/2013 9:17 AM, Martin Buchholz wrote: >> >>> >>> IMO the right approach is to improve processes so that bad commits don't >>> cause other developers to lose time. Once upon a time, I was actually >>> the tl gatekeeper and I implemented such a system. Today, I see there's >>> a tl-gate, but there's close to zero testing between submission to >>> tl-gate and "promotion" to tl-proper. In the system I implemented, >>> there was a full build/test cycle in between. >>> >> >> The processes should be there to catch mistakes, not to encourage lack of >> upfront testing. >> >> > I disagree. The submitter should be responsible for the "right" amount of > upfront testing. Now you are confusing me :) You disagree but say the responsibility is on the submitter. Well I certainly agree with that! Our difference is the notion of "right". I maintain that for a change to the build instructions of a given platform, then a test build on that platform is the absolute minimum upfront testing that must be done. > >> If the "gate" provided such functionality it would be like submitting each >> change via JPRT. While a nice idea it is completely impractical given the >> resources it would require. > > > But ... I actually implemented such a system for tl, back in 2005! I can't really comment on that. I don't recall ever encountering your system and I don't know what builds or tests it did, nor what happened to it. David ----- > The current state is a regression. > > Martin > From martinrb at google.com Wed Mar 6 00:52:30 2013 From: martinrb at google.com (Martin Buchholz) Date: Tue, 5 Mar 2013 16:52:30 -0800 Subject: New build system problems In-Reply-To: <51368F87.3010501@oracle.com> References: <5129CD25.2000003@oracle.com> <513486CE.40405@oracle.com> <5135A29F.3000804@oracle.com> <5136695A.2030808@oracle.com> <51367354.2060705@oracle.com> <5136801A.1050907@oracle.com> <51368F87.3010501@oracle.com> Message-ID: On Tue, Mar 5, 2013 at 4:36 PM, David Holmes wrote: > >>> I disagree. The submitter should be responsible for the "right" amount >> of >> upfront testing. >> > > Now you are confusing me :) You disagree but say the responsibility is on > the submitter. Well I certainly agree with that! Our difference is the > notion of "right". I maintain that for a change to the build instructions > of a given platform, then a test build on that platform is the absolute > minimum upfront testing that must be done. > > The responsibility is on the submitter to be "responsible". But there's a limit to the certainty of correctness you can expect from the submitter. The integration process (including gatekeepers) needs to help out as well. If: - erroneous commits only cause lost work for the submitter and the gatekeeper - erroneous commits can be trivially rolled back - testing is highly automated then we can have a more productive and pleasant developer experience for everyone. From david.holmes at oracle.com Wed Mar 6 01:00:15 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 06 Mar 2013 11:00:15 +1000 Subject: New build system problems In-Reply-To: References: <5129CD25.2000003@oracle.com> <513486CE.40405@oracle.com> <5135A29F.3000804@oracle.com> <5136695A.2030808@oracle.com> <51367354.2060705@oracle.com> <5136801A.1050907@oracle.com> <51368F87.3010501@oracle.com> Message-ID: <5136951F.20401@oracle.com> On 6/03/2013 10:52 AM, Martin Buchholz wrote: > On Tue, Mar 5, 2013 at 4:36 PM, David Holmes > wrote: > > > I disagree. The submitter should be responsible for the "right" > amount of > upfront testing. > > > Now you are confusing me :) You disagree but say the responsibility > is on the submitter. Well I certainly agree with that! Our > difference is the notion of "right". I maintain that for a change to > the build instructions of a given platform, then a test build on > that platform is the absolute minimum upfront testing that must be done. > > > The responsibility is on the submitter to be "responsible". But there's > a limit to the certainty of correctness you can expect from the > submitter. The integration process (including gatekeepers) needs to > help out as well. > If: > - erroneous commits only cause lost work for the submitter and the > gatekeeper > - erroneous commits can be trivially rolled back > - testing is highly automated > then we can have a more productive and pleasant developer experience for > everyone. None of these premises hold with the current system. You can lament or debate that all you like but the facts remain. So in the current system it is not acceptable, in my opinion, to push a change that includes build instructions for platform X without a build of platform X having been tested. So if a submitter can't do that test themselves then they need to collaborate with someone who can. David From david.holmes at oracle.com Wed Mar 6 03:39:39 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 06 Mar 2013 13:39:39 +1000 Subject: Request for review: 8009529: Fix for 8006988 missed closed configure changes Message-ID: <5136BA7B.3000709@oracle.com> We need to regenerate the open and closed configure scripts in the tl forest. The open change is trivial as it just updates the timestamp: > hg diff diff -r c4901c0e0579 common/autoconf/generated-configure.sh --- a/common/autoconf/generated-configure.sh +++ b/common/autoconf/generated-configure.sh @@ -3725,7 +3725,7 @@ #CUSTOM_AUTOCONF_INCLUDE # Do not change or remove the following line, it is needed for consistency checks: -DATE_WHEN_GENERATED=1362517596 +DATE_WHEN_GENERATED=1362540061 ############################################################################### # I need a nocturnal Reviewer please :) Thanks, David From mark.reinhold at oracle.com Wed Mar 6 03:42:50 2013 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 05 Mar 2013 19:42:50 -0800 Subject: Request for review: 8009529: Fix for 8006988 missed closed configure changes In-Reply-To: <5136BA7B.3000709@oracle.com> References: <5136BA7B.3000709@oracle.com> Message-ID: <20130305194250.443822@eggemoggin.niobe.net> 2013/3/5 11:39 -0800, david.holmes at oracle.com: > We need to regenerate the open and closed configure scripts in the tl > forest. > > The open change is trivial as it just updates the timestamp: > >> hg diff > diff -r c4901c0e0579 common/autoconf/generated-configure.sh > --- a/common/autoconf/generated-configure.sh > +++ b/common/autoconf/generated-configure.sh > @@ -3725,7 +3725,7 @@ > #CUSTOM_AUTOCONF_INCLUDE > > # Do not change or remove the following line, it is needed for > consistency checks: > -DATE_WHEN_GENERATED=1362517596 > +DATE_WHEN_GENERATED=1362540061 > > > ############################################################################### > # > > I need a nocturnal Reviewer please :) Looks good to me. (Sigh, we really need to fix this very brittle system ...) - Mark From martijnverburg at gmail.com Wed Mar 6 09:11:06 2013 From: martijnverburg at gmail.com (Martijn Verburg) Date: Wed, 6 Mar 2013 09:11:06 +0000 Subject: New build system problems In-Reply-To: <5136951F.20401@oracle.com> References: <5129CD25.2000003@oracle.com> <513486CE.40405@oracle.com> <5135A29F.3000804@oracle.com> <5136695A.2030808@oracle.com> <51367354.2060705@oracle.com> <5136801A.1050907@oracle.com> <51368F87.3010501@oracle.com> <5136951F.20401@oracle.com> Message-ID: Hey All, As an aside to this - we're looking to build a distributed build farm that will enable folks to test changes on at least the common platforms. If you want to help out (especially if you have Build/Jenkins/CI/Git/Mercurial expertise) then please drop me a note off-list. Cheers, Martijn On 6 March 2013 01:00, David Holmes wrote: > On 6/03/2013 10:52 AM, Martin Buchholz wrote: > >> On Tue, Mar 5, 2013 at 4:36 PM, David Holmes > >> wrote: >> >> >> I disagree. The submitter should be responsible for the "right" >> amount of >> upfront testing. >> >> >> Now you are confusing me :) You disagree but say the responsibility >> is on the submitter. Well I certainly agree with that! Our >> difference is the notion of "right". I maintain that for a change to >> the build instructions of a given platform, then a test build on >> that platform is the absolute minimum upfront testing that must be >> done. >> >> >> The responsibility is on the submitter to be "responsible". But there's >> a limit to the certainty of correctness you can expect from the >> submitter. The integration process (including gatekeepers) needs to >> help out as well. >> If: >> - erroneous commits only cause lost work for the submitter and the >> gatekeeper >> - erroneous commits can be trivially rolled back >> - testing is highly automated >> then we can have a more productive and pleasant developer experience for >> everyone. >> > > None of these premises hold with the current system. You can lament or > debate that all you like but the facts remain. So in the current system it > is not acceptable, in my opinion, to push a change that includes build > instructions for platform X without a build of platform X having been > tested. So if a submitter can't do that test themselves then they need to > collaborate with someone who can. > > David > > > From jonathan.gibbons at oracle.com Wed Mar 6 17:31:40 2013 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 06 Mar 2013 09:31:40 -0800 Subject: New build system problems In-Reply-To: References: <5129CD25.2000003@oracle.com> <513486CE.40405@oracle.com> <5135A29F.3000804@oracle.com> <5136695A.2030808@oracle.com> <51367354.2060705@oracle.com> <5136801A.1050907@oracle.com> <51368F87.3010501@oracle.com> <5136951F.20401@oracle.com> Message-ID: <51377D7C.5010306@oracle.com> As I see it, a "build and test system" has 3 significant components. 1. "build" -- thanks to the build-infra team, we've made great progress in this area to modernize and streamline the build process.(OK, there are still some warts that need to be addressed, like closed configure files.) 2. "test" -- the main problem here is having a robust and reliable set of tests that can be run after each build. As you can see here[1], we are not there yet. A number of people in the core-libs team and more have been working on this issue, but there's still more work to do. 3. "system" -- the good news here is that there are better options for an off-the-shelf starting point that there were when systems like "otto" and JPRT were designed. -- Jon [1] http://download.java.net/jdk8/testresults/archive-index.html On 03/06/2013 01:11 AM, Martijn Verburg wrote: > Hey All, > > As an aside to this - we're looking to build a distributed build farm that > will enable folks to test changes on at least the common platforms. If you > want to help out (especially if you have Build/Jenkins/CI/Git/Mercurial > expertise) then please drop me a note off-list. > > Cheers, > Martijn > > > On 6 March 2013 01:00, David Holmes wrote: > >> On 6/03/2013 10:52 AM, Martin Buchholz wrote: >> >>> On Tue, Mar 5, 2013 at 4:36 PM, David Holmes >> >> wrote: >>> >>> >>> I disagree. The submitter should be responsible for the "right" >>> amount of >>> upfront testing. >>> >>> >>> Now you are confusing me :) You disagree but say the responsibility >>> is on the submitter. Well I certainly agree with that! Our >>> difference is the notion of "right". I maintain that for a change to >>> the build instructions of a given platform, then a test build on >>> that platform is the absolute minimum upfront testing that must be >>> done. >>> >>> >>> The responsibility is on the submitter to be "responsible". But there's >>> a limit to the certainty of correctness you can expect from the >>> submitter. The integration process (including gatekeepers) needs to >>> help out as well. >>> If: >>> - erroneous commits only cause lost work for the submitter and the >>> gatekeeper >>> - erroneous commits can be trivially rolled back >>> - testing is highly automated >>> then we can have a more productive and pleasant developer experience for >>> everyone. >>> >> None of these premises hold with the current system. You can lament or >> debate that all you like but the facts remain. So in the current system it >> is not acceptable, in my opinion, to push a change that includes build >> instructions for platform X without a build of platform X having been >> tested. So if a submitter can't do that test themselves then they need to >> collaborate with someone who can. >> >> David >> >> >> From david.katleman at oracle.com Wed Mar 6 22:21:26 2013 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Wed, 06 Mar 2013 22:21:26 +0000 Subject: hg: jdk8/build/hotspot: 29 new changesets Message-ID: <20130306222240.AE9C647A0E@hg.openjdk.java.net> Changeset: be1fbee20765 Author: amurillo Date: 2013-02-22 10:12 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/be1fbee20765 8008692: new hotspot build - hs25-b21 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 1b0dc9f87e75 Author: mgerdin Date: 2013-02-19 18:45 +0100 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/1b0dc9f87e75 8006753: fix failed for JDK-8002415 White box testing API for HotSpot Summary: Modify WhiteBoxAPI to use interface classes from test/testlibrary instead, add ClassFileInstaller to resolve the boot class path issue Reviewed-by: ctornqvi, dsamersoff, coleenp, kvn ! make/Makefile ! make/bsd/makefiles/defs.make ! make/bsd/makefiles/vm.make - make/bsd/makefiles/wb.make ! make/linux/makefiles/defs.make ! make/linux/makefiles/vm.make - make/linux/makefiles/wb.make ! make/solaris/makefiles/defs.make ! make/solaris/makefiles/vm.make - make/solaris/makefiles/wb.make ! make/windows/makefiles/debug.make ! make/windows/makefiles/defs.make ! make/windows/makefiles/fastdebug.make ! make/windows/makefiles/product.make - make/windows/makefiles/wb.make - src/share/tools/whitebox/sun/hotspot/WhiteBox.java - src/share/tools/whitebox/sun/hotspot/parser/DiagnosticCommand.java ! src/share/vm/runtime/arguments.cpp ! test/compiler/whitebox/DeoptimizeAllTest.java ! test/compiler/whitebox/DeoptimizeMethodTest.java ! test/compiler/whitebox/IsMethodCompilableTest.java ! test/compiler/whitebox/MakeMethodNotCompilableTest.java ! test/compiler/whitebox/SetDontInlineMethodTest.java ! test/runtime/NMT/AllocTestType.java ! test/runtime/NMT/PrintNMTStatistics.java ! test/runtime/NMT/SummarySanityCheck.java ! test/sanity/WBApi.java ! test/serviceability/ParserTest.java + test/testlibrary/ClassFileInstaller.java + test/testlibrary/whitebox/sun/hotspot/WhiteBox.java + test/testlibrary/whitebox/sun/hotspot/parser/DiagnosticCommand.java Changeset: 4c1d8002ffb1 Author: hseigel Date: 2013-02-20 07:16 -0500 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/4c1d8002ffb1 8004495: [parfait] False positive Buffer overflow in hotspot/src/os/linux/vm/os_linux.cpp Summary: Delete the questionable source code because it is for no-longer supported versions of Linux. Reviewed-by: mikael, coleenp ! src/os/linux/vm/os_linux.cpp Changeset: b861c8af2510 Author: hseigel Date: 2013-02-20 07:42 -0500 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/b861c8af2510 Merge - make/bsd/makefiles/wb.make - make/linux/makefiles/wb.make - make/solaris/makefiles/wb.make - make/windows/makefiles/wb.make - src/share/tools/whitebox/sun/hotspot/WhiteBox.java - src/share/tools/whitebox/sun/hotspot/parser/DiagnosticCommand.java Changeset: b6d5b3e50379 Author: dcubed Date: 2013-02-20 19:36 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/b6d5b3e50379 6799919: Recursive calls to report_vm_out_of_memory are handled incorrectly Summary: report_vm_out_of_memory() should allow VMError.report_and_die() to handle multiple out of native memory errors. Reviewed-by: dcubed, dholmes, coleenp, acorn Contributed-by: ron.durbin at oracle.com ! src/share/vm/utilities/debug.cpp Changeset: fc64254f5579 Author: zgu Date: 2013-02-21 07:50 -0500 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/fc64254f5579 8008071: Crashed in promote_malloc_records() with Kitchensink after 19 days Summary: Added NULL pointer check for arena size record Reviewed-by: sspitsyn, dholmes ! src/share/vm/services/memSnapshot.cpp Changeset: 5ed317b25e23 Author: sla Date: 2013-02-22 10:03 +0100 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/5ed317b25e23 7165259: Remove BugSpot Reviewed-by: coleenp, mgronlun ! agent/make/Makefile - agent/make/bugspot.bat ! agent/make/marks_notes.html ! agent/src/os/win32/windbg/sawindbg.cpp - agent/src/share/classes/sun/jvm/hotspot/asm/amd64/AMD64FloatRegister.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/BugSpot.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/BugSpotAgent.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/JavaLineNumberInfo.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/Main.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/PCFinder.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/PackageScanner.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/RegisterPanel.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/StackTraceEntry.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/StackTracePanel.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/ThreadListPanel.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/VariablePanel.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/AddressTreeNodeAdapter.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/DoubleTreeNodeAdapter.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/EnumTreeNodeAdapter.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/FieldTreeNodeAdapter.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/FloatTreeNodeAdapter.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/LongTreeNodeAdapter.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/ObjectTreeNodeAdapter.java - agent/src/share/classes/sun/jvm/hotspot/livejvm/BreakpointEvent.java - agent/src/share/classes/sun/jvm/hotspot/livejvm/CIntegerAccessor.java - agent/src/share/classes/sun/jvm/hotspot/livejvm/CStringAccessor.java - agent/src/share/classes/sun/jvm/hotspot/livejvm/Event.java - agent/src/share/classes/sun/jvm/hotspot/livejvm/ExceptionEvent.java - agent/src/share/classes/sun/jvm/hotspot/livejvm/JNIHandleAccessor.java - agent/src/share/classes/sun/jvm/hotspot/livejvm/ServiceabilityAgentJVMDIModule.java ! agent/src/share/classes/sun/jvm/hotspot/tools/PMap.java ! agent/src/share/classes/sun/jvm/hotspot/tools/PStack.java ! agent/src/share/classes/sun/jvm/hotspot/tools/Tool.java ! agent/src/share/classes/sun/jvm/hotspot/ui/SAPanel.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/soql/sa.js - agent/src/share/native/jvmdi/sa.cpp - agent/src/share/native/jvmdi/sa.dsp - agent/src/share/native/jvmdi/sa.dsw - agent/src/share/native/jvmdi/sa.hpp ! make/sa.files Changeset: f16e75e0cf11 Author: coleenp Date: 2013-02-22 08:36 -0500 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/f16e75e0cf11 8000797: NPG: is_pseudo_string_at() doesn't work Summary: Zero Symbol* for constant pool strings to indicate pseudo_strings (objects that aren't strings). Clean up JVM_CONSTANT_Object and unused flags. Reviewed-by: sspitsyn, jrose ! agent/src/share/classes/sun/jvm/hotspot/oops/ConstantPool.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/ClassConstants.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/ConstantTag.java ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/interpreter/bytecodeTracer.cpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/interpreter/rewriter.cpp ! src/share/vm/oops/constantPool.cpp ! src/share/vm/oops/constantPool.hpp ! src/share/vm/oops/generateOopMap.cpp ! src/share/vm/utilities/constantTag.cpp ! src/share/vm/utilities/constantTag.hpp Changeset: 94478a033036 Author: sspitsyn Date: 2013-02-22 10:16 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/94478a033036 Merge - agent/make/bugspot.bat - agent/src/share/classes/sun/jvm/hotspot/asm/amd64/AMD64FloatRegister.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/BugSpot.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/BugSpotAgent.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/JavaLineNumberInfo.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/Main.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/PCFinder.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/PackageScanner.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/RegisterPanel.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/StackTraceEntry.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/StackTracePanel.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/ThreadListPanel.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/VariablePanel.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/AddressTreeNodeAdapter.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/DoubleTreeNodeAdapter.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/EnumTreeNodeAdapter.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/FieldTreeNodeAdapter.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/FloatTreeNodeAdapter.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/LongTreeNodeAdapter.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/ObjectTreeNodeAdapter.java - agent/src/share/classes/sun/jvm/hotspot/livejvm/BreakpointEvent.java - agent/src/share/classes/sun/jvm/hotspot/livejvm/CIntegerAccessor.java - agent/src/share/classes/sun/jvm/hotspot/livejvm/CStringAccessor.java - agent/src/share/classes/sun/jvm/hotspot/livejvm/Event.java - agent/src/share/classes/sun/jvm/hotspot/livejvm/ExceptionEvent.java - agent/src/share/classes/sun/jvm/hotspot/livejvm/JNIHandleAccessor.java - agent/src/share/classes/sun/jvm/hotspot/livejvm/ServiceabilityAgentJVMDIModule.java - agent/src/share/native/jvmdi/sa.cpp - agent/src/share/native/jvmdi/sa.dsp - agent/src/share/native/jvmdi/sa.dsw - agent/src/share/native/jvmdi/sa.hpp - make/bsd/makefiles/wb.make - make/linux/makefiles/wb.make - make/solaris/makefiles/wb.make - make/windows/makefiles/wb.make - src/share/tools/whitebox/sun/hotspot/WhiteBox.java - src/share/tools/whitebox/sun/hotspot/parser/DiagnosticCommand.java ! src/share/vm/runtime/arguments.cpp Changeset: ec2eddfed950 Author: rbackman Date: 2013-02-26 14:09 +0100 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/ec2eddfed950 8008340: [sampling] assert(upper->pc_offset() >= pc_offset) failed: sanity Reviewed-by: kvn, sla ! src/cpu/sparc/vm/frame_sparc.cpp ! src/cpu/x86/vm/frame_x86.cpp Changeset: 77f9b6d0126e Author: sspitsyn Date: 2013-02-27 12:20 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/77f9b6d0126e Merge - agent/make/bugspot.bat - agent/src/share/classes/sun/jvm/hotspot/asm/amd64/AMD64FloatRegister.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/BugSpot.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/BugSpotAgent.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/JavaLineNumberInfo.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/Main.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/PCFinder.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/PackageScanner.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/RegisterPanel.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/StackTraceEntry.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/StackTracePanel.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/ThreadListPanel.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/VariablePanel.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/AddressTreeNodeAdapter.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/DoubleTreeNodeAdapter.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/EnumTreeNodeAdapter.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/FieldTreeNodeAdapter.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/FloatTreeNodeAdapter.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/LongTreeNodeAdapter.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/ObjectTreeNodeAdapter.java - agent/src/share/classes/sun/jvm/hotspot/livejvm/BreakpointEvent.java - agent/src/share/classes/sun/jvm/hotspot/livejvm/CIntegerAccessor.java - agent/src/share/classes/sun/jvm/hotspot/livejvm/CStringAccessor.java - agent/src/share/classes/sun/jvm/hotspot/livejvm/Event.java - agent/src/share/classes/sun/jvm/hotspot/livejvm/ExceptionEvent.java - agent/src/share/classes/sun/jvm/hotspot/livejvm/JNIHandleAccessor.java - agent/src/share/classes/sun/jvm/hotspot/livejvm/ServiceabilityAgentJVMDIModule.java - agent/src/share/native/jvmdi/sa.cpp - agent/src/share/native/jvmdi/sa.dsp - agent/src/share/native/jvmdi/sa.dsw - agent/src/share/native/jvmdi/sa.hpp - make/bsd/makefiles/wb.make - make/linux/makefiles/wb.make - make/solaris/makefiles/wb.make - make/windows/makefiles/wb.make - src/share/tools/whitebox/sun/hotspot/WhiteBox.java - src/share/tools/whitebox/sun/hotspot/parser/DiagnosticCommand.java Changeset: 0598674c0056 Author: jwilhelm Date: 2013-02-21 11:16 +0100 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/0598674c0056 8008314: Unimplemented() Atomic::load breaks the applications Summary: jlong atomics isn't fully implemented om all 32-bit platforms so we try to avoid it. In this case the atomic add wasn't needed. Reviewed-by: dholmes, dlong ! src/share/vm/runtime/atomic.hpp ! src/share/vm/utilities/ostream.cpp ! src/share/vm/utilities/ostream.hpp Changeset: 96c885895d22 Author: johnc Date: 2013-02-22 11:01 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/96c885895d22 8007221: G1: concurrent phase durations do not state the time units ("secs") Summary: Add timer units to concurrent marking phases where the units were missing. Reviewed-by: jmasa, ysr ! src/share/vm/gc_implementation/g1/concurrentMarkThread.cpp Changeset: 9a8ee5301f33 Author: brutisso Date: 2013-02-26 11:52 +0100 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/9a8ee5301f33 Merge Changeset: f1fb03a251e9 Author: poonam Date: 2013-02-21 23:58 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/f1fb03a251e9 8008546: Wrong G1ConfidencePercent results in GUARANTEE(VARIANCE() > -1.0) FAILED Reviewed-by: brutisso, johnc Contributed-by: vladimir.kempik at oracle.com ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp Changeset: fd32b88a87e9 Author: poonam Date: 2013-02-23 17:40 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/fd32b88a87e9 Merge Changeset: 9289a00709b5 Author: poonam Date: 2013-02-26 08:58 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/9289a00709b5 Merge Changeset: b685ca4f4fb9 Author: ehelin Date: 2013-02-20 16:41 +0100 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/b685ca4f4fb9 8008536: Add HotSpot support for printing class loader statistics for JMap Reviewed-by: sla, brutisso + agent/src/share/classes/sun/jvm/hotspot/tools/ClassLoaderStats.java ! agent/src/share/classes/sun/jvm/hotspot/tools/JMap.java - agent/src/share/classes/sun/jvm/hotspot/tools/PermStat.java Changeset: 3d3379aab292 Author: ehelin Date: 2013-02-26 22:31 +0100 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/3d3379aab292 Merge - agent/src/share/classes/sun/jvm/hotspot/tools/PermStat.java Changeset: 9a094d29af19 Author: ehelin Date: 2013-02-06 07:48 +0100 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/9a094d29af19 8004924: NPG: jmap -heap output should contain ClassMetaspaceSize value Reviewed-by: stefank, mgerdin ! agent/src/share/classes/sun/jvm/hotspot/tools/HeapSummary.java + test/gc/metaspace/ClassMetaspaceSizeInJmapHeap.java Changeset: b5e03c8ead49 Author: brutisso Date: 2013-02-28 09:01 +0100 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/b5e03c8ead49 Merge - agent/src/share/classes/sun/jvm/hotspot/tools/PermStat.java Changeset: 6931f425c517 Author: roland Date: 2013-02-25 14:13 +0100 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/6931f425c517 8007294: ReduceFieldZeroing doesn't check for dependent load and can lead to incorrect execution Summary: InitializeNode::can_capture_store() must check that the captured store doesn't overwrite a memory location that is loaded before the store. Reviewed-by: kvn ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/memnode.hpp ! src/share/vm/opto/node.cpp ! src/share/vm/opto/phaseX.cpp + test/compiler/8007294/Test8007294.java Changeset: 706c919d3b56 Author: roland Date: 2013-02-26 12:18 +0100 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/706c919d3b56 8007722: C2: "assert(tp->base() != Type::AnyPtr) failed: not a bare pointer" at machnode.cpp:376 Summary: GetAndSetP's MachNode should capture bottom type. Reviewed-by: kvn ! src/share/vm/adlc/formssel.cpp + test/compiler/8007722/Test8007722.java Changeset: a00ed9736260 Author: drchase Date: 2013-02-26 15:38 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/a00ed9736260 8007776: Test6852078.java timeouts Summary: if more than 100 seconds and more than 100 iterations have both passed, then exit is allowed. Reviewed-by: kvn ! test/compiler/6852078/Test6852078.java Changeset: 133bf557ef77 Author: iignatyev Date: 2013-02-27 05:58 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/133bf557ef77 8007439: C2: adding successful message of inlining Reviewed-by: kvn, vlivanov ! src/share/vm/opto/bytecodeInfo.cpp ! src/share/vm/opto/parse.hpp Changeset: b02157cd249f Author: vlivanov Date: 2013-02-27 08:03 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/b02157cd249f Merge Changeset: 338da89b2592 Author: vlivanov Date: 2013-02-28 15:31 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/338da89b2592 Merge Changeset: df5396524152 Author: amurillo Date: 2013-03-01 04:45 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/df5396524152 Merge - agent/make/bugspot.bat - agent/src/share/classes/sun/jvm/hotspot/asm/amd64/AMD64FloatRegister.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/BugSpot.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/BugSpotAgent.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/JavaLineNumberInfo.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/Main.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/PCFinder.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/PackageScanner.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/RegisterPanel.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/StackTraceEntry.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/StackTracePanel.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/ThreadListPanel.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/VariablePanel.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/AddressTreeNodeAdapter.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/DoubleTreeNodeAdapter.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/EnumTreeNodeAdapter.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/FieldTreeNodeAdapter.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/FloatTreeNodeAdapter.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/LongTreeNodeAdapter.java - agent/src/share/classes/sun/jvm/hotspot/bugspot/tree/ObjectTreeNodeAdapter.java - agent/src/share/classes/sun/jvm/hotspot/livejvm/BreakpointEvent.java - agent/src/share/classes/sun/jvm/hotspot/livejvm/CIntegerAccessor.java - agent/src/share/classes/sun/jvm/hotspot/livejvm/CStringAccessor.java - agent/src/share/classes/sun/jvm/hotspot/livejvm/Event.java - agent/src/share/classes/sun/jvm/hotspot/livejvm/ExceptionEvent.java - agent/src/share/classes/sun/jvm/hotspot/livejvm/JNIHandleAccessor.java - agent/src/share/classes/sun/jvm/hotspot/livejvm/ServiceabilityAgentJVMDIModule.java - agent/src/share/classes/sun/jvm/hotspot/tools/PermStat.java - agent/src/share/native/jvmdi/sa.cpp - agent/src/share/native/jvmdi/sa.dsp - agent/src/share/native/jvmdi/sa.dsw - agent/src/share/native/jvmdi/sa.hpp - make/bsd/makefiles/wb.make - make/linux/makefiles/wb.make - make/solaris/makefiles/wb.make - make/windows/makefiles/wb.make - src/share/tools/whitebox/sun/hotspot/WhiteBox.java - src/share/tools/whitebox/sun/hotspot/parser/DiagnosticCommand.java Changeset: 4a198b201f3c Author: amurillo Date: 2013-03-01 04:45 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/4a198b201f3c Added tag hs25-b21 for changeset df5396524152 ! .hgtags From mike.duigou at oracle.com Wed Mar 6 22:36:35 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Wed, 6 Mar 2013 14:36:35 -0800 Subject: New official README-builds.html In-Reply-To: References: Message-ID: <2F5A90AE-9BBC-462D-B267-13EF8A101AB7@oracle.com> The testing section could be made simpler: JT_HOME=/path/to/jtreg make test The test suite can be specified with the TEST environment variable: JT_HOME=/path/to/jtreg make test TEST=jdk_util The default is TEST=jdk_core which runs a wide selection of tests. Multiple tests can be specified. JT_HOME=/path/to/jtreg make test TEST="jdk_security1 jdk_security2 jdk_security3" The brave and foolhardy can add "CONCURRENCY" to run tests concurrently. JT_HOME=/path/to/jtreg make test TEST="CONCURRENCY=12 jdk_security1 jdk_security2 jdk_security3" I have an RFE (JDK-8007129) to add a configure option for locating JTREG which would allow omission of the JT_HOME definition. HTH, Mike On Mar 1 2013, at 09:18 , Kelly O'Hair wrote: > > Please do not 'reply all', send concerns or issues to just the build-dev or build-infra-dev aliases. > > The very latest README-builds.html file is: > http://hg.openjdk.java.net/jdk8/jdk8/raw-file/tip/README-builds.html > > This documents the new build makefiles only. > As with all documents of this type, it will always be a work in progress. > > -kto > From weijun.wang at oracle.com Thu Mar 7 02:07:04 2013 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 07 Mar 2013 10:07:04 +0800 Subject: Update Re: new infra? Fwd: Re: Request to build security jars In-Reply-To: <5137F3E8.6060209@oracle.com> References: <513541AE.3080003@oracle.com> <51362ACD.9060807@oracle.com> <5137B20C.6080204@oracle.com> <5137E5C5.7080804@oracle.com> <5137F175.10001@oracle.com> <5137F3E8.6060209@oracle.com> Message-ID: <5137F648.9040002@oracle.com> [ Copying security-dev and build-dev ] I've filed one at https://jbs.oracle.com/bugs/browse/JDK-8009604 and please review the fix at http://cr.openjdk.java.net/~weijun/8009604/webrev.00/ Noreg-build. Thanks Max On 3/7/13 9:56 AM, Xuelei Fan wrote: > On 3/7/2013 9:46 AM, Weijun Wang wrote: >> This class does not exist anymore after >> >> 8006182: cleanup to use java.util.Base64 in java security component, >> providers, and regression tests >> >> It was inside JarSigner.java. >> >> The references to it in jdk/make/common/Releases.gmk should be removed. >> >> I'll file a bug and fix it. Or, if you are urgent, you can fix it in >> master with Dave. >> > Not a urgent to me as the jars has been signed. Please file a bug. > > Xuelei > >> -Max >> >> On 3/7/13 8:56 AM, Xuelei Fan wrote: >>> Max, do you know where comes the >>> sun/security/tools/jarsigner/JarBASE64Encoder.class? It looks weird to >>> me, I cannot find the java file in the repository. >>> >>> On 3/7/2013 5:15 AM, David Katleman wrote: >>>> Xuelei, >>>> >>>> Update on where we're at. >>>> >>>> I've made a bit of progress working around JDK-8009517 (Werror), >>>> ultimately updating 5 Makefiles to get past new warnings >>>> >>>> At this point I'm stuck on this error, can't find JarBASE64Encoder.class >>>> >>>> http://rehudson.us.oracle.com:8080/hudson/view/JDK8/view/Nightly/view/tl/job/jdk8_tl-2-build-solaris-sparc-product/415/console >>>> >>>>> META-INF/services/com.sun.jdi.connect.Connector >>>>> META-INF/services/com.sun.jdi.connect.spi.TransportService >>>>> sun/tools/asm sun/tools/jar sun/tools/java sun/tools/javac >>>>> sun/tools/jcmd sun/tools/jps sun/tools/jstat sun/tools/jstatd >>>>> sun/tools/native2ascii sun/tools/serialver sun/tools/tree >>>>> sun/tools/util sun/security/tools/jarsigner/JarBASE64Encoder.class >>>>> sun/security/tools/jarsigner/Main.class >>>>> sun/security/tools/jarsigner/JarSignerParameters.class >>>>> sun/security/tools/jarsigner/Resources.class >>>>> sun/security/tools/jarsigner/Resources_ja.class >>>>> sun/security/tools/jarsigner/Resources_zh_CN.class >>>>> sun/security/tools/jarsigner/SignatureFile\$Block.class >>>>> sun/security/tools/jarsigner/SignatureFile.class >>>>> sun/security/tools/jarsigner/TimestampedSigner.class sun/rmi/rmic >>>>> sun/applet sun/jvmstat com/sun/javadoc com/sun/jdi com/sun/jarsigner >>>>> com/sun/source com/sun/tools/classfile com/sun/tools/doclets >>>>> com/sun/tools/doclint com/sun/tools/example/debug/expr >>>>> com/sun/tools/example/debug/t >>>>> ty com/sun/tools/extcheck com/sun/tools/hat com/sun/tools/javac >>>>> com/sun/tools/javadoc com/sun/tools/javah com/sun/tools/javap >>>>> com/sun/tools/jdeps com/sun/tools/corba com/sun/tools/internal/xjc >>>>> com/sun/tools/internal/ws >>>>> META-INF/services/com.sun.tools.internal.ws.wscompile.Plugin >>>>> META-INF/services/com.sun.tools.internal.xjc.Plugin >>>>> com/sun/istack/internal/tools com/sun/tools/internal/jxc/ap >>>>> com/sun/tools/internal/ws/wscompile/plugin/at_generated >>>>> com/sun/codemodel com/sun/tools/internal/jxc >>>>> com/sun/xml/internal/rngom com/sun/xml/internal/xsom >>>>> org/relaxng/datatype com/sun/xml/internal/dtdparser >>>>> com/sun/tools/jdi com/sun/tools/script/shell >>>>> META-INF/services/com.sun.tools.attach.spi.AttachProvider >>>>> com/sun/tools/attach sun/tools/attach sun/tools/jstack >>>>> sun/tools/jinfo sun/tools/jmap -J-XX:-PrintVMOptions >>>>> -J-XX:+UnlockDiagnosticVMOptions -J-XX:-LogVMOutput -J-client >>>>> -J-Xmx512m -J-Xms512m -J-XX:PermSize=32m -J-XX:MaxPermSize=160m >>>>> sun/security/tools/jarsigner/JarBASE64Encoder.class : no such file >>>>> or directory >>>>> gnumake[2]: *** [initial-image-jdk] Error 1 >>>>> gnumake[2]: Leaving directory >>>>> `/export/HUDSON/workspace/jdk8_tl-2-build-solaris-sparc-product/jdk8_tl/jdk/make' >>>>> >>>>> gnumake[1]: *** [jdk-build] Error 2 >>>>> gnumake[1]: Leaving directory >>>>> `/export/HUDSON/workspace/jdk8_tl-2-build-solaris-sparc-product/jdk8_tl' >>>>> >>>>> gnumake: *** [build_product_image] Error 2 >>>>> gmkexitcode=2 >>>>> + [ 2 -ne 0 ] >>>>> + errorExit gnumake failed, return code 2 >>>>> + echo ERROR: gnumake failed, return code 2 >>>>> ERROR: gnumake failed, return code 2 >>>>> + exit 3 >>>> >>>> Is this related to your changes for JDK-7030966? >>>> >>>> hg.openjdk.java.net/jdk8/tl/jdk/rev/def2e05299b7 >>>> >>> Yes. >>> >>>> Even though the build didn't complete, the security jars we need are >>>> built at this point, but are they complete? >>>> Is more added to them after the above portion of the build? >>>> >>> I think they should be complete. While testing, I used to do a partial >>> build to generate the unsigned jars in the directory of >>> make/javax/crypto. etc., and then sign them at the same directories. We >>> should not add more to the jars in other make files. >>> >>> Xuelei >>> >>>> >>>> Thanks >>>> Dave >>>> >>>> >>>> On 3/5/2013 9:26 AM, David Katleman wrote: >>>>> Brad, >>>>> >>>>> I'm about to generate signed jars for Xuelei >>>>>> I integrated the feature of JEP 115/JDK-7030966 into JDK 8 workspace, >>>>>> need to build the security jars, sunpkcs11.jar, jce.jar and >>>>>> sunjce_provider.jar. >>>>> >>>>> Has build problem been resolved with new infra yet? I don't recall >>>>> seeing anything beyond this mention 6 weeks ago. >>>>> >>>>> Is there a tracking CR? >>>>> >>>>>> On 1/20/2013 1:43 PM, Brad Wetmore wrote: >>>>>>> What I *THOUGHT* was originally said was that the JCE build >>>>>>> environment would not be changing significantly, and the build team >>>>>>> would work with us to create the JCE makefiles before moving JCE >>>>>>> builds to the new system. What was done was the intermediate build >>>>>>> steps were done now. Just the images builds supposedly have the same >>>>>>> content. All the conversations were done in the build-dev alias (no >>>>>>> mention on security-dev). I haven't been following build-dev >>>>>>> closely, so I'm a behind the curve here. >>>>>>> >>>>>>> After Kelly's presentation, I ran a build against the jdk8/build >>>>>>> workspace last week, and noted several problems that affect JCE >>>>>>> builds. Raw classes are put into classes subdirectory and are not >>>>>>> removed, and the images build target is required to copy prebuilt >>>>>>> signed jars. I didn't look at the final rt.jar to see if duplicate >>>>>>> classes exist. (that is, in both rt.jar/jce.jar) I did confirm that >>>>>>> at least the JCE tests do pass using the images build. >>>>>>> >>>>>>> I've barely had time to finish the SecureRandom work and AEAD >>>>>>> review, and just got hit with an urgent task. I'm planning to build >>>>>>> with NEWBUILD=false to at least get my changes in. For the required >>>>>>> JCE binary build, David is going to build TL nightly with the false >>>>>>> also so I can do my signed jars putback. When we get this done, >>>>>>> we'll look into adjusting/verifying the new build environment for >>>>>>> JCE. >>>>> >>>>> Thanks >>>>> Dave >>>>> >>>>> >>>>> -------- Original Message -------- >>>>> Subject: Re: Request to build security jars >>>>> Date: Mon, 04 Mar 2013 16:51:58 -0800 >>>>> From: David Katleman >>>>> Organization: Oracle Corporation >>>>> To: Xuelei Fan >>>>> CC: Tristan Yan , "christine.lu at oracle.com" >>>>> , "vita-re_us_grp at oracle.com" >>>>> >>>>> >>>>> >>>>> >>>>> On 3/4/2013 4:37 PM, Xuelei Fan wrote: >>>>>> Did the jar get signed? Where can I get them? >>>>> >>>>> jdk8-tl builds were turned off over the weekend, from what I can tell, >>>>> to give priority to the ER that was being worked. >>>>> >>>>> jdk8-tl nightly should start shortly (5pm), and I'll be able to sign >>>>> the jars after the build completes >>>>> >>>>>> Tonight is better to me. I am afraid the nightly testing tonight and >>>>>> weekend may get some failures if I cannot integrate the jars in time. >>>>> >>>>> Testing shouldn't have been a problem over the weekend since the >>>>> jdk8-tl >>>>> builds weren't running. >>>>> >>>>> Thanks >>>>> Dave >>>>> >>>>> On 3/2/2013 9:08 AM, Xuelei Fan wrote: >>>>>>> On Mar 2, 2013, at 0:51, "David Katleman (Oracle)" >>>>>>> > wrote: >>>>>>> >>>>>>>> Xuelei, >>>>>>>> >>>>>>>> Happened to be online doing the weekly status. >>>>>>>> >>>>>>>> Your integration was into jdk8-tl, which is correct, but it occurred >>>>>>>> this morning, well after last night's TL nightly had started. >>>>>>>> >>>>>>>> Tonight's tl nightly will build the jars you need, and then we'll >>>>>>>> sign >>>>>>>> them and send them back to you. Do you need them tonight or will >>>>>>>> first thing Monday AM work as well? >>>>>>>> >>>>>>> Tonight is better to me. I am afraid the nightly testing tonight and >>>>>>> weekend may get some failures if I cannot integrate the jars in time. >>>>>>> >>>>>>> Thanks, >>>>>>> Xuelei >>>>>>> >>>>>>>> Thanks >>>>>>>> Dave >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 3/1/2013 3:14 AM, Tristan Yan wrote: >>>>>>>>> We do, jdk8 build happens every day. >>>>>>>>> >>>>>>>>> On Mar 1, 2013, at 7:13 PM, Xuelei Fan wrote: >>>>>>>>> >>>>>>>>>> On 3/1/2013 7:09 PM, Tristan Yan wrote: >>>>>>>>>>> We have the regular nightly base jdk8 build, which build >>>>>>>>>>> result is >>>>>>>>>>> in http://rehudson.us.oracle.com/nightlyws/jdk8/latest/, but >>>>>>>>>>> it starts >>>>>>>>>>> at 0:0 every day, you probably miss today's build. >>>>>>>>>> It's intended to miss today's build, as we need the new jars >>>>>>>>>> built by >>>>>>>>>> the RE team. >>>>>>>>>> >>>>>>>>>> Do you have regular nightly at Friday night and weekend? >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Xuelei >>>>>>>>>> >>>>>>>>>>> On Mar 1, 2013, at 6:59 PM, Xuelei Fan wrote: >>>>>>>>>>> >>>>>>>>>>>> On 3/1/2013 6:54 PM, Xuelei Fan wrote: >>>>>>>>>>>>> Hi Christine, >>>>>>>>>>>>> >>>>>>>>>>>>> Can you help to build the jars? I cannot wait for next Monday, >>>>>>>>>>>> Dave is out of office, and will be back next Monday. >>>>>>>>>>>> >>>>>>>>>>>>> otherwise, we may run into test failures in the nightly >>>>>>>>>>>>> testing. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Xuelei >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -------- Original Message -------- >>>>>>>>>>>>> Subject: Request to build security jars >>>>>>>>>>>>> Date: Fri, 01 Mar 2013 18:41:54 +0800 >>>>>>>>>>>>> From: Xuelei Fan >>>>>>>>>>>> > >>>>>>>>>>>>> To: David Katleman >>>>>>>>>>>> >>>>>>>>>>>>> > >>>>>>>>>>>>> >>>>>>>>>>>>> Hi Dave, >>>>>>>>>>>>> >>>>>>>>>>>>> I integrated the feature of JEP 115/JDK-7030966 into JDK 8 >>>>>>>>>>>>> workspace, >>>>>>>>>>>>> need to build the security jars, sunpkcs11.jar, jce.jar and >>>>>>>>>>>>> sunjce_provider.jar. >>>>>>>>>>>>> >>>>>>>>>>>>> changeset: >>>>>>>>>>>>> http://hg.openjdk.java.net/jdk8/tl/jdk/rev/def2e05299b7 >>>>>>>>>>>>> workspace: http://hg.openjdk.java.net/jdk8/tl/jdk >>>>>>>>>>>>> >>>>>>>>>>>>> Please let me know when the jars available. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Xuelei >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>> >>>>> >>>>> >>>> >>> > From xuelei.fan at oracle.com Thu Mar 7 02:29:59 2013 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 07 Mar 2013 10:29:59 +0800 Subject: Update Re: new infra? Fwd: Re: Request to build security jars In-Reply-To: <5137F648.9040002@oracle.com> References: <513541AE.3080003@oracle.com> <51362ACD.9060807@oracle.com> <5137B20C.6080204@oracle.com> <5137E5C5.7080804@oracle.com> <5137F175.10001@oracle.com> <5137F3E8.6060209@oracle.com> <5137F648.9040002@oracle.com> Message-ID: <5137FBA7.60208@oracle.com> Looks fine to me. Thanks, Xuelei On 3/7/2013 10:07 AM, Weijun Wang wrote: > [ Copying security-dev and build-dev ] > > JDK-8009604 > > and please review the fix at > > http://cr.openjdk.java.net/~weijun/8009604/webrev.00/ > > Noreg-build. > > Thanks > Max > From weijun.wang at oracle.com Thu Mar 7 02:33:00 2013 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 07 Mar 2013 10:33:00 +0800 Subject: code review request: 8009604, old make images failed: JarBASE64Encoder class not found In-Reply-To: <5137F648.9040002@oracle.com> References: <5137F648.9040002@oracle.com> Message-ID: <5137FC5C.6040001@oracle.com> Please review the fix at http://cr.openjdk.java.net/~weijun/8009604/webrev.00/ The class was defined in jarsigner/Main.java and was removed in JDK-8006182, but it's still mentioned in jdk/make/common/Releases.gmk. Noreg-build. Thanks Max From martinrb at google.com Thu Mar 7 02:57:57 2013 From: martinrb at google.com (Martin Buchholz) Date: Wed, 6 Mar 2013 18:57:57 -0800 Subject: Do not let internal JDK zlib symbols leak out of fastdebug libzip.so In-Reply-To: References: <5128AD43.2000809@oracle.com> <51292295.4040802@oracle.com> <512F63AB.2050204@oracle.com> Message-ID: Pushed to jdk8/tl/jdk. I recommend this be backported to jdk7u. From bradford.wetmore at oracle.com Thu Mar 7 03:32:02 2013 From: bradford.wetmore at oracle.com (Brad Wetmore) Date: Wed, 06 Mar 2013 19:32:02 -0800 Subject: code review request: 8009604, old make images failed: JarBASE64Encoder class not found In-Reply-To: <5137FC5C.6040001@oracle.com> References: <5137F648.9040002@oracle.com> <5137FC5C.6040001@oracle.com> Message-ID: <51380A32.5010501@oracle.com> Looks good. brad On 3/6/2013 6:33 PM, Weijun Wang wrote: > Please review the fix at > > http://cr.openjdk.java.net/~weijun/8009604/webrev.00/ > > The class was defined in jarsigner/Main.java and was removed in > JDK-8006182, but it's still mentioned in jdk/make/common/Releases.gmk. > > Noreg-build. > > Thanks > Max From tim.bell at oracle.com Thu Mar 7 03:36:20 2013 From: tim.bell at oracle.com (Tim Bell) Date: Wed, 06 Mar 2013 19:36:20 -0800 Subject: Update Re: new infra? Fwd: Re: Request to build security jars In-Reply-To: <5137FBA7.60208@oracle.com> References: <513541AE.3080003@oracle.com> <51362ACD.9060807@oracle.com> <5137B20C.6080204@oracle.com> <5137E5C5.7080804@oracle.com> <5137F175.10001@oracle.com> <5137F3E8.6060209@oracle.com> <5137F648.9040002@oracle.com> <5137FBA7.60208@oracle.com> Message-ID: <51380B34.8070802@oracle.com> Looks good to me as well. Tim On 03/06/13 18:29, Xuelei Fan wrote: > Looks fine to me. > > Thanks, > Xuelei > > On 3/7/2013 10:07 AM, Weijun Wang wrote: >> [ Copying security-dev and build-dev ] >> >> JDK-8009604 >> >> and please review the fix at >> >> http://cr.openjdk.java.net/~weijun/8009604/webrev.00/ >> >> Noreg-build. >> >> Thanks >> Max >> From erik.joelsson at oracle.com Thu Mar 7 08:46:52 2013 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Thu, 07 Mar 2013 08:46:52 +0000 Subject: hg: jdk8/build: 8008073: build-infra: Need --with-dxsdk option? And awt/sound -I option additions? Message-ID: <20130307084652.BCC6647DCA@hg.openjdk.java.net> Changeset: 52741ab7c601 Author: erikj Date: 2013-03-06 10:50 +0100 URL: http://hg.openjdk.java.net/jdk8/build/rev/52741ab7c601 8008073: build-infra: Need --with-dxsdk option? And awt/sound -I option additions? Reviewed-by: tbell ! common/autoconf/generated-configure.sh ! common/autoconf/spec.gmk.in ! common/autoconf/toolchain.m4 ! common/autoconf/toolchain_windows.m4 From erik.joelsson at oracle.com Thu Mar 7 08:47:04 2013 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Thu, 07 Mar 2013 08:47:04 +0000 Subject: hg: jdk8/build/jdk: 8008073: build-infra: Need --with-dxsdk option? And awt/sound -I option additions? Message-ID: <20130307084716.F2A9347DCD@hg.openjdk.java.net> Changeset: aee1c6c52b68 Author: erikj Date: 2013-03-06 16:15 +0100 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/aee1c6c52b68 8008073: build-infra: Need --with-dxsdk option? And awt/sound -I option additions? Reviewed-by: tbell ! makefiles/CompileNativeLibraries.gmk From bharadwaj.yadavalli at oracle.com Thu Mar 7 17:32:50 2013 From: bharadwaj.yadavalli at oracle.com (Bharadwaj Yadavalli) Date: Thu, 07 Mar 2013 12:32:50 -0500 Subject: configure using --disable-zip-debug-info Message-ID: <5138CF42.1040102@oracle.com> I pulled down jdk/tl tree and configured it using the following command line: sh configure --with-debug-level=slowdebug --with-boot-jdk=/path/to/installed/jdk7 --disable-zip-debug-info and built by running make all I get the following build error Ignoring (other) javax.xml.ws.wsaddressing.package-info : ClassSymbol Creating images/lib/ct.sym gmake[2]: *** No rule to make target `/path/to/jdk8/workspace/build/linux-x86_64-normal-server-slowdebug/images/_strip_jre/bin/jarsigner.debuginfo.stripped', needed by `jre-image'. Stop. gmake[2]: *** Waiting for unfinished jobs.... gmake[1]: *** [images] Error 2 make: *** [images-only] Error 2 The build does not have any problems if I do not specify --disable-zip-debug-info Do I need to specify some other option along with --disable-zip-debug-info? Thanks for your help, Bharadwaj From david.holmes at oracle.com Fri Mar 8 00:54:19 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 08 Mar 2013 10:54:19 +1000 Subject: configure using --disable-zip-debug-info In-Reply-To: <5138CF42.1040102@oracle.com> References: <5138CF42.1040102@oracle.com> Message-ID: <513936BB.2070404@oracle.com> I think this is a bug in Images.gmk: ifneq ($(OPENJDK_TARGET_OS),windows) ALL_BIN_LIST := $(filter-out %.debuginfo %.diz, $(ALL_BIN_LIST)) else You can only have a single wildcard in a pattern so I don't think that expands the way the author intended. Can you try editing jdk/makefiles/Images.gmk and changing the above to: ifneq ($(OPENJDK_TARGET_OS),windows) ALL_BIN_LIST := $(filter-out %.debuginfo, $(ALL_BIN_LIST)) ALL_BIN_LIST := $(filter-out %.diz, $(ALL_BIN_LIST)) else Thanks, David On 8/03/2013 3:32 AM, Bharadwaj Yadavalli wrote: > I pulled down jdk/tl tree and configured it using the following command > line: > > sh configure --with-debug-level=slowdebug > --with-boot-jdk=/path/to/installed/jdk7 --disable-zip-debug-info > > and built by running > > make all > > I get the following build error > > Ignoring (other) javax.xml.ws.wsaddressing.package-info : > ClassSymbol > Creating images/lib/ct.sym > gmake[2]: *** No rule to make target > `/path/to/jdk8/workspace/build/linux-x86_64-normal-server-slowdebug/images/_strip_jre/bin/jarsigner.debuginfo.stripped', > needed by `jre-image'. Stop. > gmake[2]: *** Waiting for unfinished jobs.... > gmake[1]: *** [images] Error 2 > make: *** [images-only] Error 2 > > The build does not have any problems if I do not specify > --disable-zip-debug-info > > Do I need to specify some other option along with --disable-zip-debug-info? > > Thanks for your help, > > Bharadwaj > From david.holmes at oracle.com Fri Mar 8 01:48:35 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 08 Mar 2013 11:48:35 +1000 Subject: RFR: 8009428 and 8009429 - Profile related fixes and clean ups Message-ID: <51394373.4040404@oracle.com> Not sure which is best list for this given Alan will likely be the only reviewer anyway :) Webrevs under: http://cr.openjdk.java.net/~dholmes/8009428_8009429/ Two related sets of fixes here: JDK-8009428: Revert changes to $ substitution performed as part of nashorn integration This removes the special $ handling in ListPathSafely in MakeBase.gmk; and reverts the change in file names in CreateJars.gmk so that \$$ is restored to \$$$$ --- JDK-8009429 Miscellaneous profiles cleanup Miscellaneous cleanups to the Profiles.gmk file and the include lists: - ensure all lists are expanded in case they contain wildcards Previously I only expanded lists I knew to be (or have been non-empty). - use wildcards to list related classes Avoid listing explicit classes, particularly if nested classes are involved. - remove redundant subpackage entries if all subpackages are in the same profile The original list was generated from a list of all packages and subpackages and contained a lot of redundancy. If profile_1 for example contains java/lang then it implicitly contains java/lang/ref, java/lang/reflect etc, and doesn't need them listed. If a particular subpackage is not part of profile_1, say java/lang/special is in the full JRE only, then we need only list java/lang/special as an included package for the full JRE. All included packages for the full JRE and higher numbered profiles become excluded packages for the lower numbered profiles hence profile_1 would be "everything in java/lang except java/lang/special". (Things are a little more complicated when the subpackage exists in the lower numbered profiles. In that case the higher-level has to list out the included subpackages explicitly together with included classes.) - rename things so that the full JRE is not referred to as "PROFILE_4" The Full JRE is not a compact profile. While we logically treated it as a fourth profile for build purposes this is potentially confusing and so we no longer do that. A JRE may be a full JRE or it may be a Compact Profile JRE. Plus in CreateJars.gmk: - cleanup the de-beaning actions Now we've got a better understanding of the way $ gets processed I figured out how to express this the "natural" way. --- Thanks, David From omajid at redhat.com Fri Mar 8 02:59:55 2013 From: omajid at redhat.com (Omair Majid) Date: Thu, 07 Mar 2013 21:59:55 -0500 Subject: Allow using a system-installed giflib Message-ID: <5139542B.5080100@redhat.com> Hi, I have a webrev at: http://cr.openjdk.java.net/~omajid/webrevs/system-giflib/00/ It introduces a configure option --with-giflib that (similar to the existing --with-zlib) allows specifying whether the build should use the system installed giflib or the one bundled with OpenJDK. I have not tested it extensively yet (just verified that it builds fine with both configurations), but I will do that over the coming days if the patch looks (somewhat) acceptable for OpenJDK8. Thanks, Omair -- PGP Key: 66484681 (http://pgp.mit.edu/) Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 From david.holmes at oracle.com Fri Mar 8 05:06:15 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 08 Mar 2013 15:06:15 +1000 Subject: How to override which autoconf is used? Message-ID: <513971C7.6090707@oracle.com> My build machine has autoconf 2.68 in /usr/bin but others use 2.67. This means we keep getting differences in generated-configure.sh that are not related to actual changes. So I put the 2.67 version of autoconf first in my path: > which autoconf /home/dholmes/bin/autoconf > autoconf -V autoconf (GNU Autoconf) 2.67 but when I run autogen.sh (which simply calls "autoconf") the resulting file has: #! /bin/sh # Guess values for system-dependent variables and create Makefiles. # Generated by GNU Autoconf 2.68 for OpenJDK jdk8. ??? How can I use 2.67 without having to actually downgrade it on a shared build machine ? :( I've even tried copying autom4te to ~/bin and hacking the scripts directly. But I still get autoconf 2.68 ??? Makes no sense. Thanks, David From Alan.Bateman at oracle.com Fri Mar 8 09:19:01 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 08 Mar 2013 09:19:01 +0000 Subject: RFR: 8009428 and 8009429 - Profile related fixes and clean ups In-Reply-To: <51394373.4040404@oracle.com> References: <51394373.4040404@oracle.com> Message-ID: <5139AD05.1060208@oracle.com> On 08/03/2013 01:48, David Holmes wrote: > Not sure which is best list for this given Alan will likely be the > only reviewer anyway :) > > Webrevs under: > > http://cr.openjdk.java.net/~dholmes/8009428_8009429/ As further background to others, the reverting of the $ substitution became possible when Nashorn removed $ from its generated classes [1]. I've looked through the changes and they look really good to me. Putting $< in single quotes to avoid shell expansion is the solution that I could not find when adding the de-beaning recipes a few months ago. It's great to see PROFILE_4 renamed to FULL_JRE and is also great to remove the redundant sub-packages from the include lists. For profiles-rtjar-includes then I think it makes it much more readable and maintainable. Two minor inconsistencies: the sub-packages of javax.naming are listed and com/sun/jndi/ has a trailing slash. One probable side effect of removing the redundant sub-packages will be the javadoc. The one case to date where we didn't list sub-packages is java.time (because there are still changes going on there) and that the result is that the sub-packages of java.time don't show up in the profiles view. I created 8008367 a few weeks for that and I suspect that once these changes are pushed that the profiles view will be very incomplete. I don't think this should be a reason to hold off your changes as the profiles view isn't right now anyway. Hopefully Bhavesh will get to this soon. I think Erik should review this too as it's important that the build changes in jdk8/tl will merge easily with changes going into jdk8/build. -Alan. [1] http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/fe5211fc3114 From erik.joelsson at oracle.com Fri Mar 8 11:12:23 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 08 Mar 2013 12:12:23 +0100 Subject: Allow using a system-installed giflib In-Reply-To: <5139542B.5080100@redhat.com> References: <5139542B.5080100@redhat.com> Message-ID: <5139C797.6090009@oracle.com> On 2013-03-08 03:59, Omair Majid wrote: > Hi, > > I have a webrev at: > http://cr.openjdk.java.net/~omajid/webrevs/system-giflib/00/ > > It introduces a configure option --with-giflib that (similar to the > existing --with-zlib) allows specifying whether the build should use the > system installed giflib or the one bundled with OpenJDK. > > I have not tested it extensively yet (just verified that it builds fine > with both configurations), but I will do that over the coming days if > the patch looks (somewhat) acceptable for OpenJDK8. > Looks good from the build group. (You still need a jdk8 reviewer to approve too) /Erik From erik.joelsson at oracle.com Fri Mar 8 11:15:45 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 08 Mar 2013 12:15:45 +0100 Subject: How to override which autoconf is used? In-Reply-To: <513971C7.6090707@oracle.com> References: <513971C7.6090707@oracle.com> Message-ID: <5139C861.80100@oracle.com> Could it be that bash is somehow resetting your path when you launch it? /Erik On 2013-03-08 06:06, David Holmes wrote: > My build machine has autoconf 2.68 in /usr/bin but others use 2.67. > This means we keep getting differences in generated-configure.sh that > are not related to actual changes. > > So I put the 2.67 version of autoconf first in my path: > > > which autoconf > /home/dholmes/bin/autoconf > > autoconf -V > autoconf (GNU Autoconf) 2.67 > > but when I run autogen.sh (which simply calls "autoconf") the > resulting file has: > > #! /bin/sh > # Guess values for system-dependent variables and create Makefiles. > # Generated by GNU Autoconf 2.68 for OpenJDK jdk8. > > ??? > > How can I use 2.67 without having to actually downgrade it on a shared > build machine ? :( > > I've even tried copying autom4te to ~/bin and hacking the scripts > directly. But I still get autoconf 2.68 ??? Makes no sense. > > Thanks, > David > From erik.joelsson at oracle.com Fri Mar 8 11:25:33 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 08 Mar 2013 12:25:33 +0100 Subject: RFR: 8009428 and 8009429 - Profile related fixes and clean ups In-Reply-To: <5139AD05.1060208@oracle.com> References: <51394373.4040404@oracle.com> <5139AD05.1060208@oracle.com> Message-ID: <5139CAAD.5070401@oracle.com> On 2013-03-08 10:19, Alan Bateman wrote: > On 08/03/2013 01:48, David Holmes wrote: >> Not sure which is best list for this given Alan will likely be the >> only reviewer anyway :) >> >> Webrevs under: >> >> http://cr.openjdk.java.net/~dholmes/8009428_8009429/ > As further background to others, the reverting of the $ substitution > became possible when Nashorn removed $ from its generated classes [1]. > > I've looked through the changes and they look really good to me. > Putting $< in single quotes to avoid shell expansion is the solution > that I could not find when adding the de-beaning recipes a few months > ago. It's great to see PROFILE_4 renamed to FULL_JRE and is also great > to remove the redundant sub-packages from the include lists. For > profiles-rtjar-includes then I think it makes it much more readable > and maintainable. Two minor inconsistencies: the sub-packages of > javax.naming are listed and com/sun/jndi/ has a trailing slash. > > One probable side effect of removing the redundant sub-packages will > be the javadoc. The one case to date where we didn't list sub-packages > is java.time (because there are still changes going on there) and that > the result is that the sub-packages of java.time don't show up in the > profiles view. I created 8008367 a few weeks for that and I suspect > that once these changes are pushed that the profiles view will be very > incomplete. I don't think this should be a reason to hold off your > changes as the profiles view isn't right now anyway. Hopefully Bhavesh > will get to this soon. > > I think Erik should review this too as it's important that the build > changes in jdk8/tl will merge easily with changes going into jdk8/build. > > -Alan. > > [1] http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/fe5211fc3114 Looks good to me and thanks again for cleaning up that $ business. I do not think this will conflict with anything coming from jdk8/build. /Erik From david.holmes at oracle.com Fri Mar 8 11:28:09 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 08 Mar 2013 21:28:09 +1000 Subject: RFR: 8009428 and 8009429 - Profile related fixes and clean ups In-Reply-To: <5139AD05.1060208@oracle.com> References: <51394373.4040404@oracle.com> <5139AD05.1060208@oracle.com> Message-ID: <5139CB49.5000601@oracle.com> On 8/03/2013 7:19 PM, Alan Bateman wrote: > On 08/03/2013 01:48, David Holmes wrote: >> Not sure which is best list for this given Alan will likely be the >> only reviewer anyway :) >> >> Webrevs under: >> >> http://cr.openjdk.java.net/~dholmes/8009428_8009429/ > As further background to others, the reverting of the $ substitution > became possible when Nashorn removed $ from its generated classes [1]. > > I've looked through the changes and they look really good to me. Putting > $< in single quotes to avoid shell expansion is the solution that I > could not find when adding the de-beaning recipes a few months ago. It's > great to see PROFILE_4 renamed to FULL_JRE and is also great to remove > the redundant sub-packages from the include lists. For > profiles-rtjar-includes then I think it makes it much more readable and > maintainable. Two minor inconsistencies: the sub-packages of > javax.naming are listed and com/sun/jndi/ has a trailing slash. Fixed - well spotted! > One probable side effect of removing the redundant sub-packages will be > the javadoc. The one case to date where we didn't list sub-packages is > java.time (because there are still changes going on there) and that the > result is that the sub-packages of java.time don't show up in the > profiles view. I created 8008367 a few weeks for that and I suspect that > once these changes are pushed that the profiles view will be very > incomplete. I don't think this should be a reason to hold off your > changes as the profiles view isn't right now anyway. Hopefully Bhavesh > will get to this soon. Now I'm a little concerned. I had not considered whether javac/javadoc considered these to be complete lists. They have to know how to combine the includes at a low-level with the excludes of a higher-level - and potentially vice-versa. > I think Erik should review this too as it's important that the build > changes in jdk8/tl will merge easily with changes going into jdk8/build. OK. Thanks, David > -Alan. > > [1] http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/fe5211fc3114 From david.holmes at oracle.com Fri Mar 8 11:34:32 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 08 Mar 2013 21:34:32 +1000 Subject: How to override which autoconf is used? In-Reply-To: <5139C861.80100@oracle.com> References: <513971C7.6090707@oracle.com> <5139C861.80100@oracle.com> Message-ID: <5139CCC8.3080301@oracle.com> On 8/03/2013 9:15 PM, Erik Joelsson wrote: > Could it be that bash is somehow resetting your path when you launch it? I can't see how. Yet I've annotated my copy and it is not being executed. ??? Totally baffled. And rather peeved. This is a big waste of time. Thanks, David > /Erik > > On 2013-03-08 06:06, David Holmes wrote: >> My build machine has autoconf 2.68 in /usr/bin but others use 2.67. >> This means we keep getting differences in generated-configure.sh that >> are not related to actual changes. >> >> So I put the 2.67 version of autoconf first in my path: >> >> > which autoconf >> /home/dholmes/bin/autoconf >> > autoconf -V >> autoconf (GNU Autoconf) 2.67 >> >> but when I run autogen.sh (which simply calls "autoconf") the >> resulting file has: >> >> #! /bin/sh >> # Guess values for system-dependent variables and create Makefiles. >> # Generated by GNU Autoconf 2.68 for OpenJDK jdk8. >> >> ??? >> >> How can I use 2.67 without having to actually downgrade it on a shared >> build machine ? :( >> >> I've even tried copying autom4te to ~/bin and hacking the scripts >> directly. But I still get autoconf 2.68 ??? Makes no sense. >> >> Thanks, >> David >> From david.holmes at oracle.com Fri Mar 8 11:34:57 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 08 Mar 2013 21:34:57 +1000 Subject: RFR: 8009428 and 8009429 - Profile related fixes and clean ups In-Reply-To: <5139CAAD.5070401@oracle.com> References: <51394373.4040404@oracle.com> <5139AD05.1060208@oracle.com> <5139CAAD.5070401@oracle.com> Message-ID: <5139CCE1.8050904@oracle.com> Thanks Erik! David On 8/03/2013 9:25 PM, Erik Joelsson wrote: > > > On 2013-03-08 10:19, Alan Bateman wrote: >> On 08/03/2013 01:48, David Holmes wrote: >>> Not sure which is best list for this given Alan will likely be the >>> only reviewer anyway :) >>> >>> Webrevs under: >>> >>> http://cr.openjdk.java.net/~dholmes/8009428_8009429/ >> As further background to others, the reverting of the $ substitution >> became possible when Nashorn removed $ from its generated classes [1]. >> >> I've looked through the changes and they look really good to me. >> Putting $< in single quotes to avoid shell expansion is the solution >> that I could not find when adding the de-beaning recipes a few months >> ago. It's great to see PROFILE_4 renamed to FULL_JRE and is also great >> to remove the redundant sub-packages from the include lists. For >> profiles-rtjar-includes then I think it makes it much more readable >> and maintainable. Two minor inconsistencies: the sub-packages of >> javax.naming are listed and com/sun/jndi/ has a trailing slash. >> >> One probable side effect of removing the redundant sub-packages will >> be the javadoc. The one case to date where we didn't list sub-packages >> is java.time (because there are still changes going on there) and that >> the result is that the sub-packages of java.time don't show up in the >> profiles view. I created 8008367 a few weeks for that and I suspect >> that once these changes are pushed that the profiles view will be very >> incomplete. I don't think this should be a reason to hold off your >> changes as the profiles view isn't right now anyway. Hopefully Bhavesh >> will get to this soon. >> >> I think Erik should review this too as it's important that the build >> changes in jdk8/tl will merge easily with changes going into jdk8/build. >> >> -Alan. >> >> [1] http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/fe5211fc3114 > > Looks good to me and thanks again for cleaning up that $ business. I do > not think this will conflict with anything coming from jdk8/build. > > /Erik From Alan.Bateman at oracle.com Fri Mar 8 12:00:49 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 08 Mar 2013 12:00:49 +0000 Subject: RFR: 8009428 and 8009429 - Profile related fixes and clean ups In-Reply-To: <5139CB49.5000601@oracle.com> References: <51394373.4040404@oracle.com> <5139AD05.1060208@oracle.com> <5139CB49.5000601@oracle.com> Message-ID: <5139D2F1.7070108@oracle.com> On 08/03/2013 11:28, David Holmes wrote: > > Now I'm a little concerned. I had not considered whether javac/javadoc > considered these to be complete lists. They have to know how to > combine the includes at a low-level with the excludes of a > higher-level - and potentially vice-versa. I think javac should be okay, and you can easily test this by trying to compile with "javac -profile compact ..." on a test that references types in one of these sub-packages. There are tests in the langtools repo for this too and it would be good to check ProfileOptionTest to see if need more sub-tests to cover a few sample types from these sub-packages. So I think the issue will be just the docs build and you can quickly check that too. To date we've only seen it with java.time because that was the one case where only the top-most API package was listed. I'm pretty sure the issue is in the standard doclet, in which case I think pushing your changes are okay. The only complication is that there is another issue with the generated docs and that is default view is the Profiles view so it is very confusing until you hit the "All Packages" link. -Alan From chris.hegarty at oracle.com Fri Mar 8 13:24:16 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 08 Mar 2013 13:24:16 +0000 Subject: RFR 8009517: Disable fatal compiler warning in the old build Message-ID: <5139E680.6000606@oracle.com> Since the new build does not enable -Werror when compiling any java code, and disables quite a few lint options, new changes my inadvertently introduce warnings without even realizing. This can cause problems when building with the old build as many areas do compile with -Werror set. Since the old build is on life support, probably best to just completely disable -Werror, so anyone still needing to use it can. diff -r 48b7295f02f8 make/common/shared/Defs-java.gmk --- a/make/common/shared/Defs-java.gmk Thu Mar 07 10:07:13 2013 +0000 +++ b/make/common/shared/Defs-java.gmk Thu Mar 07 11:10:37 2013 +0000 @@ -122,9 +122,10 @@ ifeq ($(JAVAC_MAX_WARNINGS), true) ifeq ($(JAVAC_MAX_WARNINGS), true) JAVAC_LINT_OPTIONS += -Xlint:all endif -ifeq ($(JAVAC_WARNINGS_FATAL), true) - JAVACFLAGS += -Werror -endif +# Disable fatal warnings, 8009517 +#ifeq ($(JAVAC_WARNINGS_FATAL), true) +# JAVACFLAGS += -Werror +#endif # TODO: Workaround for CR 7063027. Remove -path eventually. JAVAC_LINT_OPTIONS += -Xlint:-path -Chris. From Alan.Bateman at oracle.com Fri Mar 8 15:31:17 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 08 Mar 2013 15:31:17 +0000 Subject: RFR 8009517: Disable fatal compiler warning in the old build In-Reply-To: <5139E680.6000606@oracle.com> References: <5139E680.6000606@oracle.com> Message-ID: <513A0445.4060502@oracle.com> On 08/03/2013 13:24, Chris Hegarty wrote: > Since the new build does not enable -Werror when compiling any java > code, and disables quite a few lint options, new changes my > inadvertently introduce warnings without even realizing. This can > cause problems when building with the old build as many areas do > compile with -Werror set. Since the old build is on life support, > probably best to just completely disable -Werror, so anyone still > needing to use it can. > > diff -r 48b7295f02f8 make/common/shared/Defs-java.gmk > --- a/make/common/shared/Defs-java.gmk Thu Mar 07 10:07:13 2013 +0000 > +++ b/make/common/shared/Defs-java.gmk Thu Mar 07 11:10:37 2013 +0000 > @@ -122,9 +122,10 @@ ifeq ($(JAVAC_MAX_WARNINGS), true) > ifeq ($(JAVAC_MAX_WARNINGS), true) > JAVAC_LINT_OPTIONS += -Xlint:all > endif > -ifeq ($(JAVAC_WARNINGS_FATAL), true) > - JAVACFLAGS += -Werror > -endif > +# Disable fatal warnings, 8009517 > +#ifeq ($(JAVAC_WARNINGS_FATAL), true) > +# JAVACFLAGS += -Werror > +#endif > > # TODO: Workaround for CR 7063027. Remove -path eventually. > JAVAC_LINT_OPTIONS += -Xlint:-path > > -Chris. This seems the most sensible thing to me as it is impossible to keep the old build warning working when warnings aren't fatal in the new build. -Alan. From mike.duigou at oracle.com Fri Mar 8 15:49:58 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Fri, 8 Mar 2013 07:49:58 -0800 Subject: RFR 8009517: Disable fatal compiler warning in the old build In-Reply-To: <5139E680.6000606@oracle.com> References: <5139E680.6000606@oracle.com> Message-ID: Looks fine to me. Do we have an issue open for restoring warnings to the new build? Mike On Mar 8 2013, at 05:24 , Chris Hegarty wrote: > Since the new build does not enable -Werror when compiling any java code, and disables quite a few lint options, new changes my inadvertently introduce warnings without even realizing. This can cause problems when building with the old build as many areas do compile with -Werror set. Since the old build is on life support, probably best to just completely disable -Werror, so anyone still needing to use it can. > > diff -r 48b7295f02f8 make/common/shared/Defs-java.gmk > --- a/make/common/shared/Defs-java.gmk Thu Mar 07 10:07:13 2013 +0000 > +++ b/make/common/shared/Defs-java.gmk Thu Mar 07 11:10:37 2013 +0000 > @@ -122,9 +122,10 @@ ifeq ($(JAVAC_MAX_WARNINGS), true) > ifeq ($(JAVAC_MAX_WARNINGS), true) > JAVAC_LINT_OPTIONS += -Xlint:all > endif > -ifeq ($(JAVAC_WARNINGS_FATAL), true) > - JAVACFLAGS += -Werror > -endif > +# Disable fatal warnings, 8009517 > +#ifeq ($(JAVAC_WARNINGS_FATAL), true) > +# JAVACFLAGS += -Werror > +#endif > > # TODO: Workaround for CR 7063027. Remove -path eventually. > JAVAC_LINT_OPTIONS += -Xlint:-path > > -Chris. From chris.hegarty at oracle.com Fri Mar 8 15:58:14 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 08 Mar 2013 15:58:14 +0000 Subject: RFR 8009517: Disable fatal compiler warning in the old build In-Reply-To: References: <5139E680.6000606@oracle.com> Message-ID: <513A0A96.7080508@oracle.com> On 08/03/2013 15:49, Mike Duigou wrote: > Looks fine to me. Thanks Mike. > Do we have an issue open for restoring warnings to the new build? Not yet, that I am aware of. We really need the ability to set lint options per package/subpackage. -Chris. > > Mike > > On Mar 8 2013, at 05:24 , Chris Hegarty wrote: > >> Since the new build does not enable -Werror when compiling any java code, and disables quite a few lint options, new changes my inadvertently introduce warnings without even realizing. This can cause problems when building with the old build as many areas do compile with -Werror set. Since the old build is on life support, probably best to just completely disable -Werror, so anyone still needing to use it can. >> >> diff -r 48b7295f02f8 make/common/shared/Defs-java.gmk >> --- a/make/common/shared/Defs-java.gmk Thu Mar 07 10:07:13 2013 +0000 >> +++ b/make/common/shared/Defs-java.gmk Thu Mar 07 11:10:37 2013 +0000 >> @@ -122,9 +122,10 @@ ifeq ($(JAVAC_MAX_WARNINGS), true) >> ifeq ($(JAVAC_MAX_WARNINGS), true) >> JAVAC_LINT_OPTIONS += -Xlint:all >> endif >> -ifeq ($(JAVAC_WARNINGS_FATAL), true) >> - JAVACFLAGS += -Werror >> -endif >> +# Disable fatal warnings, 8009517 >> +#ifeq ($(JAVAC_WARNINGS_FATAL), true) >> +# JAVACFLAGS += -Werror >> +#endif >> >> # TODO: Workaround for CR 7063027. Remove -path eventually. >> JAVAC_LINT_OPTIONS += -Xlint:-path >> >> -Chris. > From Alan.Bateman at oracle.com Fri Mar 8 15:56:37 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 08 Mar 2013 15:56:37 +0000 Subject: RFR 8009517: Disable fatal compiler warning in the old build In-Reply-To: References: <5139E680.6000606@oracle.com> Message-ID: <513A0A35.40809@oracle.com> On 08/03/2013 15:49, Mike Duigou wrote: > Looks fine to me. Do we have an issue open for restoring warnings to the new build? > > Mike > I don't know if there is an issue for that yet but as the new build compiles thousands of classes in a single compilation unit then it means we will need to make significant inroads on the warnings before more can be enabled. The approach with the old build was by area and good progress had been made but with the new build, then it may have to be by warning type as all areas are compiled together. -Alan. From mike.duigou at oracle.com Fri Mar 8 16:09:51 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Fri, 8 Mar 2013 08:09:51 -0800 Subject: RFR 8009517: Disable fatal compiler warning in the old build In-Reply-To: <513A0A35.40809@oracle.com> References: <5139E680.6000606@oracle.com> <513A0A35.40809@oracle.com> Message-ID: <431B8999-D7AE-42B4-B8F5-734AB8577906@oracle.com> On Mar 8 2013, at 07:56 , Alan Bateman wrote: > On 08/03/2013 15:49, Mike Duigou wrote: >> Looks fine to me. Do we have an issue open for restoring warnings to the new build? >> >> Mike >> > I don't know if there is an issue for that yet but as the new build compiles thousands of classes in a single compilation unit then it means we will need to make significant inroads on the warnings before more can be enabled. The approach with the old build was by area and good progress had been made but with the new build, then it may have to be by warning type as all areas are compiled together. Understood. Perhaps we can at least use JDK_FILTER incrementally. Do we have a way to override the warnings used by the makefile? Any thoughts towards perhaps disabling -Werror but enabling all of the warnings? Mike From Alan.Bateman at oracle.com Fri Mar 8 16:40:01 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 08 Mar 2013 16:40:01 +0000 Subject: RFR 8009517: Disable fatal compiler warning in the old build In-Reply-To: <431B8999-D7AE-42B4-B8F5-734AB8577906@oracle.com> References: <5139E680.6000606@oracle.com> <513A0A35.40809@oracle.com> <431B8999-D7AE-42B4-B8F5-734AB8577906@oracle.com> Message-ID: <513A1461.4090402@oracle.com> On 08/03/2013 16:09, Mike Duigou wrote: > : > Understood. Perhaps we can at least use JDK_FILTER incrementally. Do we have a way to override the warnings used by the makefile? I haven't tried it but Erik suggested in a reply to Dan a few months ago, that is should be possible: http://mail.openjdk.java.net/pipermail/build-dev/2012-December/007427.html > > Any thoughts towards perhaps disabling -Werror but enabling all of the warnings? I think it would just annoy people and make it impossible to see the errors. We'll need to continue to make progress on the warnings and I think can only enable them when they are down to a manageable number, ideally 0. Stuart lead the last few campaigns and may have ideas or plans. -Alan From jonathan.gibbons at oracle.com Fri Mar 8 16:40:24 2013 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 08 Mar 2013 08:40:24 -0800 Subject: RFR 8009517: Disable fatal compiler warning in the old build In-Reply-To: <431B8999-D7AE-42B4-B8F5-734AB8577906@oracle.com> References: <5139E680.6000606@oracle.com> <513A0A35.40809@oracle.com> <431B8999-D7AE-42B4-B8F5-734AB8577906@oracle.com> Message-ID: <513A1478.7070809@oracle.com> On 03/08/2013 08:09 AM, Mike Duigou wrote: > On Mar 8 2013, at 07:56 , Alan Bateman wrote: > >> On 08/03/2013 15:49, Mike Duigou wrote: >>> Looks fine to me. Do we have an issue open for restoring warnings to the new build? >>> >>> Mike >>> >> I don't know if there is an issue for that yet but as the new build compiles thousands of classes in a single compilation unit then it means we will need to make significant inroads on the warnings before more can be enabled. The approach with the old build was by area and good progress had been made but with the new build, then it may have to be by warning type as all areas are compiled together. > Understood. Perhaps we can at least use JDK_FILTER incrementally. Do we have a way to override the warnings used by the makefile? > > Any thoughts towards perhaps disabling -Werror but enabling all of the warnings? > > Mike > A different and maybe more effective way of tracking this (for now) would be to generate a separate report on a regular basis that details the number of different types of warnings in each package. The technology to do that is easy; the hard part is getting people to monitor the results and fixup the issues. That being said, it should be relatively uncontroversial to totally eliminate some types of warnings, like cast warnings, and enable those warnings in the build with -Werror. -- Jon From dan.xu at oracle.com Fri Mar 8 17:20:05 2013 From: dan.xu at oracle.com (Dan Xu) Date: Fri, 08 Mar 2013 09:20:05 -0800 Subject: RFR 8009517: Disable fatal compiler warning in the old build In-Reply-To: <513A1478.7070809@oracle.com> References: <5139E680.6000606@oracle.com> <513A0A35.40809@oracle.com> <431B8999-D7AE-42B4-B8F5-734AB8577906@oracle.com> <513A1478.7070809@oracle.com> Message-ID: <513A1DC5.8000001@oracle.com> On 03/08/2013 08:40 AM, Jonathan Gibbons wrote: > On 03/08/2013 08:09 AM, Mike Duigou wrote: >> On Mar 8 2013, at 07:56 , Alan Bateman wrote: >> >>> On 08/03/2013 15:49, Mike Duigou wrote: >>>> Looks fine to me. Do we have an issue open for restoring warnings >>>> to the new build? >>>> >>>> Mike >>>> >>> I don't know if there is an issue for that yet but as the new build >>> compiles thousands of classes in a single compilation unit then it >>> means we will need to make significant inroads on the warnings >>> before more can be enabled. The approach with the old build was by >>> area and good progress had been made but with the new build, then it >>> may have to be by warning type as all areas are compiled together. >> Understood. Perhaps we can at least use JDK_FILTER incrementally. Do >> we have a way to override the warnings used by the makefile? >> >> Any thoughts towards perhaps disabling -Werror but enabling all of >> the warnings? >> >> Mike >> > > A different and maybe more effective way of tracking this (for now) > would be to generate a separate report on a regular basis that details > the number of different types of warnings in each package. The > technology to do that is easy; the hard part is getting people to > monitor the results and fixup the issues. > > That being said, it should be relatively uncontroversial to totally > eliminate some types of warnings, like cast warnings, and enable those > warnings in the build with -Werror. > > -- Jon Kurchi and I are working on this as our side project. We have modified your java program to analyse the build logs generated by the new build. I am thinking to generate some trend reports after running the build regularly and collecting some log data. -Dan From philip.race at oracle.com Fri Mar 8 17:26:07 2013 From: philip.race at oracle.com (Phil Race) Date: Fri, 08 Mar 2013 09:26:07 -0800 Subject: Allow using a system-installed giflib In-Reply-To: <5139C797.6090009@oracle.com> References: <5139542B.5080100@redhat.com> <5139C797.6090009@oracle.com> Message-ID: <513A1F2F.3080300@oracle.com> If I understand correctly, this removes the directory containing the JDK's copy of giflib sources from the set of locations to be compiled etc, and replaces it with just a link line pointer to use "libgif" which is then expected to be on the default linker path, ie in /usr/lib. I think this is fine except I would guard USE_EXTERNAL_LIBGIF with an expectation that this is at least "not" windows, since I'm pretty sure that option would always be a mistake there. > 502 USE_EXTERNAL_LIBJPEG=true This appears to have been a bug in the old autoconf.m4, yes ? -phil. PS I count as a JDK 8 reviewer .. On 3/8/2013 3:12 AM, Erik Joelsson wrote: > On 2013-03-08 03:59, Omair Majid wrote: >> Hi, >> >> I have a webrev at: >> http://cr.openjdk.java.net/~omajid/webrevs/system-giflib/00/ >> >> It introduces a configure option --with-giflib that (similar to the >> existing --with-zlib) allows specifying whether the build should use the >> system installed giflib or the one bundled with OpenJDK. >> >> I have not tested it extensively yet (just verified that it builds fine >> with both configurations), but I will do that over the coming days if >> the patch looks (somewhat) acceptable for OpenJDK8. >> > Looks good from the build group. (You still need a jdk8 reviewer to > approve too) > > /Erik From bradford.wetmore at oracle.com Sat Mar 9 00:25:56 2013 From: bradford.wetmore at oracle.com (Brad Wetmore) Date: Fri, 08 Mar 2013 16:25:56 -0800 Subject: RFR 8009517: Disable fatal compiler warning in the old build In-Reply-To: <513A0A96.7080508@oracle.com> References: <5139E680.6000606@oracle.com> <513A0A96.7080508@oracle.com> Message-ID: <513A8194.9040002@oracle.com> I responded in another thread (wasn't aware of this one, sorry), there is an alternate to completely disabling -Werror. On 3/8/2013 7:58 AM, Chris Hegarty wrote: > On 08/03/2013 15:49, Mike Duigou wrote: >> Looks fine to me. > > Thanks Mike. > > > Do we have an issue open for restoring warnings to the new build? > > Not yet, that I am aware of. We really need the ability to set lint > options per package/subpackage. That would be nice. I agree about warning creeping problems. This is a temporary solution, we should soon be fixing the underlying hashcode/equals problems...but... 1. javac tightened hashcode/equals checks 2. new: -Werror is off in the new builds. (i.e. not failing on any lint warnings) 3. old: -Werror is on for the old builds (i.e. is failing for any lint warnings) The proposal is to turn off all errors in the old builds (remove -Werror), essentially making 3 like the 2. Warn but not fatal. We spent a lot of time cleaning up many directories, seems a shame to start allowing non-fatal warnings to come back into previously clean code because people aren't taking the time to fix new warnings as they are introduced. My suggestion was to turn off just the one warning type in 3 *in the old code only* so we can at least continue to build the old without completely disabling -Werror. The new builds will still warn, but the old builds will still fail for all but these override problems. Yes, you lose the warnings in the old, but seems better than completely shutting off erroring. (Ideally it would be nice to warn but not fail on just this one lint option, but don't see how that's possible.) Brad > -Chris. > >> >> Mike >> >> On Mar 8 2013, at 05:24 , Chris Hegarty wrote: >> >>> Since the new build does not enable -Werror when compiling any java >>> code, and disables quite a few lint options, new changes my >>> inadvertently introduce warnings without even realizing. This can >>> cause problems when building with the old build as many areas do >>> compile with -Werror set. Since the old build is on life support, >>> probably best to just completely disable -Werror, so anyone still >>> needing to use it can. >>> >>> diff -r 48b7295f02f8 make/common/shared/Defs-java.gmk >>> --- a/make/common/shared/Defs-java.gmk Thu Mar 07 10:07:13 2013 +0000 >>> +++ b/make/common/shared/Defs-java.gmk Thu Mar 07 11:10:37 2013 +0000 >>> @@ -122,9 +122,10 @@ ifeq ($(JAVAC_MAX_WARNINGS), true) >>> ifeq ($(JAVAC_MAX_WARNINGS), true) >>> JAVAC_LINT_OPTIONS += -Xlint:all >>> endif >>> -ifeq ($(JAVAC_WARNINGS_FATAL), true) >>> - JAVACFLAGS += -Werror >>> -endif >>> +# Disable fatal warnings, 8009517 >>> +#ifeq ($(JAVAC_WARNINGS_FATAL), true) >>> +# JAVACFLAGS += -Werror >>> +#endif >>> >>> # TODO: Workaround for CR 7063027. Remove -path eventually. >>> JAVAC_LINT_OPTIONS += -Xlint:-path >>> >>> -Chris. >> From omajid at redhat.com Sat Mar 9 00:42:33 2013 From: omajid at redhat.com (Omair Majid) Date: Fri, 08 Mar 2013 19:42:33 -0500 Subject: Allow using a system-installed giflib In-Reply-To: <513A1F2F.3080300@oracle.com> References: <5139542B.5080100@redhat.com> <5139C797.6090009@oracle.com> <513A1F2F.3080300@oracle.com> Message-ID: <513A8579.5020707@redhat.com> On 03/08/2013 12:26 PM, Phil Race wrote: > If I understand correctly, this removes the directory containing > the JDK's copy of giflib sources from the set of locations to be > compiled etc, and replaces it with just a link line pointer to use > "libgif" which is then expected to be on the default linker path, > ie in /usr/lib. Yes, that was what I intended. The JDK's copy of giflib is still compiled if --with-giflib=system is used. > I think this is fine except I would guard USE_EXTERNAL_LIBGIF > with an expectation that this is at least "not" windows, since > I'm pretty sure that option would always be a mistake there. I will post an updated patch soon with this fixed. >> 502 USE_EXTERNAL_LIBJPEG=true > > This appears to have been a bug in the old autoconf.m4, yes ? Yes, it's definitely a (harmless?) bug. The old file looks like this: 485 ################################################################## 486 # 487 # Check for the jpeg library 488 # 489 490 USE_EXTERNAL_LIBJPEG=true 491 AC_CHECK_LIB(jpeg, main, [], 492 [ USE_EXTERNAL_LIBJPEG=false 493 AC_MSG_NOTICE([ .. snipped ... ]) 494 ]) 495 AC_SUBST(USE_EXTERNAL_LIBJPEG) 496 497 ################################################################## 498 # 499 # Check for the gif library 500 # 501 502 USE_EXTERNAL_LIBJPEG=true 503 AC_CHECK_LIB(gif, main, [], 504 [ USE_EXTERNAL_LIBGIF=false 505 AC_MSG_NOTICE([ .. snipped ...]) 506 ]) 507 AC_SUBST(USE_EXTERNAL_LIBGIF) So ${USE_EXTERNAL_LIBJPEG} is "true" and ${USE_EXTERNAL_LIBGIF} is either "" or "false". Neither of these are used in CompileNativeLibraries.gmk, however. > PS I count as a JDK 8 reviewer .. Thanks for the review. Could I get a bug id, please? Thanks, Omair -- PGP Key: 66484681 (http://pgp.mit.edu/) Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 From chris.hegarty at oracle.com Sat Mar 9 08:11:39 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Sat, 09 Mar 2013 08:11:39 +0000 Subject: RFR 8009517: Disable fatal compiler warning in the old build In-Reply-To: <513A8194.9040002@oracle.com> References: <5139E680.6000606@oracle.com> <513A0A96.7080508@oracle.com> <513A8194.9040002@oracle.com> Message-ID: <513AEEBB.2080900@oracle.com> > I agree about warning creeping problems. This is a temporary solution, > we should soon be fixing the underlying hashcode/equals problems...but... Your temporary solution, -overrides, is just that. It will enable the old build to complete today, but it could fail at any point in the future, as the code changes. For example, java.net is currently warning free, in the old it compiles with fatal warnings enabled. Lets say, in a moment of madness, I add a dependency from java.net.Socket to say java.awt.RenderingHints.Key ( or any class that produces warnings when compiled. I run the new build, all is fine. Push the changes. Now someone else sync's up, but need to build using the old build. If the new dependent class is not already compiled before java.net.Socket gets compiled, it will be compiled implicitly. It's warnings will cause the compile to fail, and the old build will fail. Or much simpler, anyone could write sloppy code with warnings, the new build will suppress them, and they won't notice. Push this code, and the old build will fail if is explicitly, or implicitly, compiles this code with -Werror enabled. > We > spent a lot of time cleaning up many directories, seems a shame to start > allowing non-fatal warnings to come back into previously clean code > because people aren't taking the time to fix new warnings as they are > introduced. I personally spent several weeks over the past number of years fixing warnings and reviewing warning cleanup webrevs from others. I took much pride in keeping certain areas warnings free. It is with great regret that I propose to disable fatal warnings in the old build, but I felt this the best/safest option. I heard much annoyance and frustration from others about hitting seemingly random errors with the old build recently. This is the only sure way to avoid that. > The new builds will still warn, but the > old builds will still fail for all but these override problems. Yes, > you lose the warnings in the old, but seems better than completely > shutting off erroring. I'm ok with that, if others are. To clarify, I think you are suggesting that we keep the old build as it, with -overrides, and use it periodically as a way of tracking new warnings being introduced into areas that were warning free. That is, if the old build fails because of a fatal warning, so be it. File a bug and fix the source code. Then the old build will work again. This means that at any point in time the old build cannot be guaranteed to be buildable. Everyone seems to agree, a solution needs to be found to allow us to keep certain areas warning free. This issue is too important, and too much time was spent, to allow it to regress to the state it was in a few years ago. -Chris. > > (Ideally it would be nice to warn but not fail on just this one lint > option, but don't see how that's possible.) > > Brad > > > > > >> -Chris. >> >>> >>> Mike >>> >>> On Mar 8 2013, at 05:24 , Chris Hegarty wrote: >>> >>>> Since the new build does not enable -Werror when compiling any java >>>> code, and disables quite a few lint options, new changes my >>>> inadvertently introduce warnings without even realizing. This can >>>> cause problems when building with the old build as many areas do >>>> compile with -Werror set. Since the old build is on life support, >>>> probably best to just completely disable -Werror, so anyone still >>>> needing to use it can. >>>> >>>> diff -r 48b7295f02f8 make/common/shared/Defs-java.gmk >>>> --- a/make/common/shared/Defs-java.gmk Thu Mar 07 10:07:13 2013 +0000 >>>> +++ b/make/common/shared/Defs-java.gmk Thu Mar 07 11:10:37 2013 +0000 >>>> @@ -122,9 +122,10 @@ ifeq ($(JAVAC_MAX_WARNINGS), true) >>>> ifeq ($(JAVAC_MAX_WARNINGS), true) >>>> JAVAC_LINT_OPTIONS += -Xlint:all >>>> endif >>>> -ifeq ($(JAVAC_WARNINGS_FATAL), true) >>>> - JAVACFLAGS += -Werror >>>> -endif >>>> +# Disable fatal warnings, 8009517 >>>> +#ifeq ($(JAVAC_WARNINGS_FATAL), true) >>>> +# JAVACFLAGS += -Werror >>>> +#endif >>>> >>>> # TODO: Workaround for CR 7063027. Remove -path eventually. >>>> JAVAC_LINT_OPTIONS += -Xlint:-path >>>> >>>> -Chris. >>> From jonathan.gibbons at oracle.com Sat Mar 9 19:01:36 2013 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Sat, 09 Mar 2013 11:01:36 -0800 Subject: RFR 8009517: Disable fatal compiler warning in the old build In-Reply-To: <513AEEBB.2080900@oracle.com> References: <5139E680.6000606@oracle.com> <513A0A96.7080508@oracle.com> <513A8194.9040002@oracle.com> <513AEEBB.2080900@oracle.com> Message-ID: <513B8710.8020102@oracle.com> On 03/09/2013 12:11 AM, Chris Hegarty wrote: > > Everyone seems to agree, a solution needs to be found to allow us to > keep certain areas warning free. This issue is too important, and too > much time was spent, to allow it to regress to the state it was in a > few years ago. It is true that selective use of -Werror does not play well with the new build and the desire to compile as much as possible at any time, possibly using sjavac. I have previously reported on a utility I've written in the past to analyze java code and report on the different types of warnings found in different packages. I'm sure we could take something like that utility and improve it to the point where it can give errors when entries in the matrix which should be empty are not. This utility could be run as a "test" meaning it needn't break the build but the info is available for those that want to run it. -- Jon From chris.hegarty at oracle.com Sat Mar 9 19:53:48 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Sat, 9 Mar 2013 19:53:48 +0000 Subject: RFR 8009517: Disable fatal compiler warning in the old build In-Reply-To: <513B8710.8020102@oracle.com> References: <5139E680.6000606@oracle.com> <513A0A96.7080508@oracle.com> <513A8194.9040002@oracle.com> <513AEEBB.2080900@oracle.com> <513B8710.8020102@oracle.com> Message-ID: On 9 Mar 2013, at 19:01, Jonathan Gibbons wrote: > On 03/09/2013 12:11 AM, Chris Hegarty wrote: >> >> Everyone seems to agree, a solution needs to be found to allow us to keep certain areas warning free. This issue is too important, and too much time was spent, to allow it to regress to the state it was in a few years ago. > > It is true that selective use of -Werror does not play well with the new build and the desire to compile as much as possible at any time, possibly using sjavac. > > I have previously reported on a utility I've written in the past to analyze java code and report on the different types of warnings found in different packages. I'm sure we could take something like that utility and improve it to the point where it can give errors when entries in the matrix which should be empty are not. > > This utility could be run as a "test" meaning it needn't break the build but the info is available for those that want to run it. Sounds interesting Jon, and certainly worth exploring. Another idea, is to enable all lint options and -Werror ;-) If the SuppressWarnings annotation was allowable on the PACKAGE Target :-^ It may be reasonable to add to the packages where applicable. -Chris. > > -- Jon From david.holmes at oracle.com Mon Mar 11 01:24:39 2013 From: david.holmes at oracle.com (David Holmes) Date: Mon, 11 Mar 2013 11:24:39 +1000 Subject: RFR: 8009428 and 8009429 - Profile related fixes and clean ups In-Reply-To: <5139CB49.5000601@oracle.com> References: <51394373.4040404@oracle.com> <5139AD05.1060208@oracle.com> <5139CB49.5000601@oracle.com> Message-ID: <513D3257.2030801@oracle.com> I had overlooked the need to update the ct.sym creation tool to recognize the new syntax in the profile spec file. That process also uncovered a few bugs in the listing that needed correcting. The javadoc generation of compact profile information is not quite right, but that will be handled in a seperate bug. Updated webrevs at: http://cr.openjdk.java.net/~dholmes/8009428_8009429.v2/ --- http://cr.openjdk.java.net/~dholmes/8009428_8009429.v2/webrev.root/ No change from v1. Simply reverses the Nashorn change to $ processing. --- http://cr.openjdk.java.net/~dholmes/8009428_8009429.v2/webrev.langtools/ Updated the logic to look for FULL_JRE instead of PROFILE_4. And as a result of that needed to make the logic explicitly aware that there are 3 compact profiles plus the full JRE. --- http://cr.openjdk.java.net/~dholmes/8009428_8009429.v2/webrev.jdk/ Changes from v1: - I stopped trying to use a new wildcard syntax for included/excluded types. The only options are *.class else a full type name with $ replaced by $$. (The wildcard support would need more extensive changes to the ct.sym tool and for 4 classes it isn't worth it). - Types explicitly excluded from one profile must be explicitly included in a higher one (or the full JRE). (This happened to work by accident because we were dealing with compact3 and a full JRE). - The package sun/beans no longer exists - Fixed up include packages to capture new types ie jdk instead of jdk/internal so that we include the jdk.Supported annotation class - Removed additional redundant sub-packages Thanks for the follow up reviews. Erik's review stands as no further changes made to the actual build logic. David ----- On 8/03/2013 9:28 PM, David Holmes wrote: > On 8/03/2013 7:19 PM, Alan Bateman wrote: >> On 08/03/2013 01:48, David Holmes wrote: >>> Not sure which is best list for this given Alan will likely be the >>> only reviewer anyway :) >>> >>> Webrevs under: >>> >>> http://cr.openjdk.java.net/~dholmes/8009428_8009429/ >> As further background to others, the reverting of the $ substitution >> became possible when Nashorn removed $ from its generated classes [1]. >> >> I've looked through the changes and they look really good to me. Putting >> $< in single quotes to avoid shell expansion is the solution that I >> could not find when adding the de-beaning recipes a few months ago. It's >> great to see PROFILE_4 renamed to FULL_JRE and is also great to remove >> the redundant sub-packages from the include lists. For >> profiles-rtjar-includes then I think it makes it much more readable and >> maintainable. Two minor inconsistencies: the sub-packages of >> javax.naming are listed and com/sun/jndi/ has a trailing slash. > > Fixed - well spotted! > >> One probable side effect of removing the redundant sub-packages will be >> the javadoc. The one case to date where we didn't list sub-packages is >> java.time (because there are still changes going on there) and that the >> result is that the sub-packages of java.time don't show up in the >> profiles view. I created 8008367 a few weeks for that and I suspect that >> once these changes are pushed that the profiles view will be very >> incomplete. I don't think this should be a reason to hold off your >> changes as the profiles view isn't right now anyway. Hopefully Bhavesh >> will get to this soon. > > Now I'm a little concerned. I had not considered whether javac/javadoc > considered these to be complete lists. They have to know how to combine > the includes at a low-level with the excludes of a higher-level - and > potentially vice-versa. > >> I think Erik should review this too as it's important that the build >> changes in jdk8/tl will merge easily with changes going into jdk8/build. > > OK. > > Thanks, > David > >> -Alan. >> >> [1] http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/fe5211fc3114 From Alan.Bateman at oracle.com Mon Mar 11 08:54:41 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 11 Mar 2013 08:54:41 +0000 Subject: RFR: 8009428 and 8009429 - Profile related fixes and clean ups In-Reply-To: <513D3257.2030801@oracle.com> References: <51394373.4040404@oracle.com> <5139AD05.1060208@oracle.com> <5139CB49.5000601@oracle.com> <513D3257.2030801@oracle.com> Message-ID: <513D9BD1.6060807@oracle.com> On 11/03/2013 01:24, David Holmes wrote: > I had overlooked the need to update the ct.sym creation tool to > recognize the new syntax in the profile spec file. That process also > uncovered a few bugs in the listing that needed correcting. > > The javadoc generation of compact profile information is not quite > right, but that will be handled in a seperate bug. > > Updated webrevs at: > > http://cr.openjdk.java.net/~dholmes/8009428_8009429.v2/ The changes to the top-level and jdk repo look good to me. As per my original comments, I'm happy to see profile-rtjar-includes.txt changed to be much easier to maintain. The assumption that jdk.** is in compact1 is okay for now but I'm sure that will need to be changed when that namespace is used more. For the intro comment in profile-rtjar-includes.txt then it might be useful to beef up the comment to explain what happens when an API package does not match one of the rules, ie: does it go into compact1, only the full JRE, or none. Also make it explicit that the form DialogCallbackHandler*.class should not be used. I suggest this for the benefit of someone needing to tweak this in the future. I have played with com.sun.tools.javac.sym.Profiles and so the changes to MakefileProfiles look okay to me but Jon should really be the reviewer for this. One thing about maxProfiles is that it should match Profile.values.length maybe maxProfiles should not be hardcoded to 4. Another thing is whether to add a test or beef up an existing test (ProfileOptionTest.java in particular). -Alan. From erik.joelsson at oracle.com Mon Mar 11 09:30:54 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 11 Mar 2013 10:30:54 +0100 Subject: RFR 8009517: Disable fatal compiler warning in the old build In-Reply-To: <513A0A35.40809@oracle.com> References: <5139E680.6000606@oracle.com> <513A0A35.40809@oracle.com> Message-ID: <513DA44E.9000504@oracle.com> I have a suggestion for how to at least partly enable -Werror in the new build. The penalty is slightly longer compile time, but the difference should be negligible. We split the big java compilation in jdk in two. The first pass with -Werror and all warnings turned on, the second without. We make a list of packages that are passing -Werror and use as include list for the first and exclude list for the second. As you make more packages warning free, we add them to the list. This solution is not as fine grained as a per package configured set of warning flags, but it's much better than we have today. /Erik On 2013-03-08 16:56, Alan Bateman wrote: > On 08/03/2013 15:49, Mike Duigou wrote: >> Looks fine to me. Do we have an issue open for restoring warnings to >> the new build? >> >> Mike >> > I don't know if there is an issue for that yet but as the new build > compiles thousands of classes in a single compilation unit then it > means we will need to make significant inroads on the warnings before > more can be enabled. The approach with the old build was by area and > good progress had been made but with the new build, then it may have > to be by warning type as all areas are compiled together. > > -Alan. > From erik.joelsson at oracle.com Mon Mar 11 14:20:08 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 11 Mar 2013 15:20:08 +0100 Subject: RFR 8009517: Disable fatal compiler warning in the old build In-Reply-To: <513DA44E.9000504@oracle.com> References: <5139E680.6000606@oracle.com> <513A0A35.40809@oracle.com> <513DA44E.9000504@oracle.com> Message-ID: <513DE818.1000803@oracle.com> I tried implementing a PoC for this. Without sjavac, it works, except that the first pass must be run without -Werror and the second with. Since we use -implicit:none, this is fine. With sjavac I had to let it compile the full set of classes first and then run a second time (into a different output directory) with just the warning free set of packages. The overhead on my machine was 5 seconds for the second pass. This solution also works without sjavac, but then the overhead is 37 seconds on my machine. Now the question is, do we want to pursue this or not? /Erik On 2013-03-11 10:30, Erik Joelsson wrote: > I have a suggestion for how to at least partly enable -Werror in the > new build. The penalty is slightly longer compile time, but the > difference should be negligible. > > We split the big java compilation in jdk in two. The first pass with > -Werror and all warnings turned on, the second without. We make a list > of packages that are passing -Werror and use as include list for the > first and exclude list for the second. As you make more packages > warning free, we add them to the list. > > This solution is not as fine grained as a per package configured set > of warning flags, but it's much better than we have today. > > /Erik > > On 2013-03-08 16:56, Alan Bateman wrote: >> On 08/03/2013 15:49, Mike Duigou wrote: >>> Looks fine to me. Do we have an issue open for restoring warnings to >>> the new build? >>> >>> Mike >>> >> I don't know if there is an issue for that yet but as the new build >> compiles thousands of classes in a single compilation unit then it >> means we will need to make significant inroads on the warnings before >> more can be enabled. The approach with the old build was by area and >> good progress had been made but with the new build, then it may have >> to be by warning type as all areas are compiled together. >> >> -Alan. >> From chris.hegarty at oracle.com Mon Mar 11 15:00:46 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 11 Mar 2013 15:00:46 +0000 Subject: RFR 8009517: Disable fatal compiler warning in the old build In-Reply-To: <513DE818.1000803@oracle.com> References: <5139E680.6000606@oracle.com> <513A0A35.40809@oracle.com> <513DA44E.9000504@oracle.com> <513DE818.1000803@oracle.com> Message-ID: <513DF19E.9040107@oracle.com> Thank you for trying this Erik. I did think of this "workaround" myself, but felt if might not be acceptable due to the performance penalty. But this information is great to have. I wonder if we should try to get all alternatives/proposals on the table, then make a decision. I know of two other possibilities. 1) Leave things are they are, and use another tool to investigate warnings. From Jon. 2) Explore supporting Package level SuppressWarnings. Then apply to the relevant packages, and enable -Werror in the build. Others? -Chris. On 11/03/2013 14:20, Erik Joelsson wrote: > I tried implementing a PoC for this. Without sjavac, it works, except > that the first pass must be run without -Werror and the second with. > Since we use -implicit:none, this is fine. > > With sjavac I had to let it compile the full set of classes first and > then run a second time (into a different output directory) with just the > warning free set of packages. The overhead on my machine was 5 seconds > for the second pass. This solution also works without sjavac, but then > the overhead is 37 seconds on my machine. > > Now the question is, do we want to pursue this or not? > > /Erik > > On 2013-03-11 10:30, Erik Joelsson wrote: >> I have a suggestion for how to at least partly enable -Werror in the >> new build. The penalty is slightly longer compile time, but the >> difference should be negligible. >> >> We split the big java compilation in jdk in two. The first pass with >> -Werror and all warnings turned on, the second without. We make a list >> of packages that are passing -Werror and use as include list for the >> first and exclude list for the second. As you make more packages >> warning free, we add them to the list. >> >> This solution is not as fine grained as a per package configured set >> of warning flags, but it's much better than we have today. >> >> /Erik >> >> On 2013-03-08 16:56, Alan Bateman wrote: >>> On 08/03/2013 15:49, Mike Duigou wrote: >>>> Looks fine to me. Do we have an issue open for restoring warnings to >>>> the new build? >>>> >>>> Mike >>>> >>> I don't know if there is an issue for that yet but as the new build >>> compiles thousands of classes in a single compilation unit then it >>> means we will need to make significant inroads on the warnings before >>> more can be enabled. The approach with the old build was by area and >>> good progress had been made but with the new build, then it may have >>> to be by warning type as all areas are compiled together. >>> >>> -Alan. >>> From james.laskey at oracle.com Mon Mar 11 18:33:29 2013 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Mon, 11 Mar 2013 15:33:29 -0300 Subject: sjavac Message-ID: <4D80390B-083F-473B-AF92-17567FEDF2ED@oracle.com> The Nashorn team is wondering about the status of sjavac and the builds. Note: https://jbs.oracle.com/bugs/browse/JDK-8009788 . There are two occurances of "-cp" which should be convered to "-classpath" in makefiles/BuildNashorn.gmk . Cheers, -- Jim From jonathan.gibbons at oracle.com Mon Mar 11 19:30:54 2013 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 11 Mar 2013 12:30:54 -0700 Subject: sjavac In-Reply-To: <4D80390B-083F-473B-AF92-17567FEDF2ED@oracle.com> References: <4D80390B-083F-473B-AF92-17567FEDF2ED@oracle.com> Message-ID: <513E30EE.90603@oracle.com> On 03/11/2013 11:33 AM, Jim Laskey (Oracle) wrote: > The Nashorn team is wondering about the status of sjavac and the builds. Note: https://jbs.oracle.com/bugs/browse/JDK-8009788 . There are two occurances of "-cp" which should be convered to "-classpath" in makefiles/BuildNashorn.gmk . > > Cheers, > > -- Jim > I will also patch sjavac to accept -cp. -- Jon From martinrb at google.com Mon Mar 11 19:39:05 2013 From: martinrb at google.com (Martin Buchholz) Date: Mon, 11 Mar 2013 12:39:05 -0700 Subject: sjavac In-Reply-To: <513E30EE.90603@oracle.com> References: <4D80390B-083F-473B-AF92-17567FEDF2ED@oracle.com> <513E30EE.90603@oracle.com> Message-ID: While you're there, consider checking/modfying all of the jdk tools to accept either both or neither of "-cp" and "-classpath". javap is the command I'm thinking of. From jonathan.gibbons at oracle.com Mon Mar 11 19:41:10 2013 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 11 Mar 2013 12:41:10 -0700 Subject: sjavac In-Reply-To: References: <4D80390B-083F-473B-AF92-17567FEDF2ED@oracle.com> <513E30EE.90603@oracle.com> Message-ID: <513E3356.70801@oracle.com> On 03/11/2013 12:39 PM, Martin Buchholz wrote: > > While you're there, consider checking/modfying all of the jdk tools to > accept either both or neither of "-cp" and "-classpath". javap is the > command I'm thinking of. Noted. -- Jon From david.katleman at oracle.com Mon Mar 11 21:59:27 2013 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Mon, 11 Mar 2013 21:59:27 +0000 Subject: hg: jdk8/build: 2 new changesets Message-ID: <20130311215927.D4C5E4807D@hg.openjdk.java.net> Changeset: cd7f2c7e2a0e Author: katleman Date: 2013-03-07 11:17 -0800 URL: http://hg.openjdk.java.net/jdk8/build/rev/cd7f2c7e2a0e Added tag jdk8-b80 for changeset 907a926d3c96 ! .hgtags Changeset: 235854886494 Author: katleman Date: 2013-03-11 13:41 -0700 URL: http://hg.openjdk.java.net/jdk8/build/rev/235854886494 Merge From david.katleman at oracle.com Mon Mar 11 21:59:31 2013 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Mon, 11 Mar 2013 21:59:31 +0000 Subject: hg: jdk8/build/corba: Added tag jdk8-b80 for changeset 5f3d4a6bdd02 Message-ID: <20130311215933.B9D284807E@hg.openjdk.java.net> Changeset: 2a00aeeb466b Author: katleman Date: 2013-03-07 11:17 -0800 URL: http://hg.openjdk.java.net/jdk8/build/corba/rev/2a00aeeb466b Added tag jdk8-b80 for changeset 5f3d4a6bdd02 ! .hgtags From david.katleman at oracle.com Mon Mar 11 22:01:20 2013 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Mon, 11 Mar 2013 22:01:20 +0000 Subject: hg: jdk8/build/hotspot: Added tag jdk8-b80 for changeset 4a198b201f3c Message-ID: <20130311220131.4B9AA4807F@hg.openjdk.java.net> Changeset: fbda7e1dee9a Author: katleman Date: 2013-03-07 11:17 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/fbda7e1dee9a Added tag jdk8-b80 for changeset 4a198b201f3c ! .hgtags From david.katleman at oracle.com Mon Mar 11 22:02:59 2013 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Mon, 11 Mar 2013 22:02:59 +0000 Subject: hg: jdk8/build/jaxp: Added tag jdk8-b80 for changeset 4873a0499bc3 Message-ID: <20130311220307.3575748080@hg.openjdk.java.net> Changeset: ef3495555a4c Author: katleman Date: 2013-03-07 11:17 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jaxp/rev/ef3495555a4c Added tag jdk8-b80 for changeset 4873a0499bc3 ! .hgtags From david.katleman at oracle.com Mon Mar 11 22:03:16 2013 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Mon, 11 Mar 2013 22:03:16 +0000 Subject: hg: jdk8/build/jaxws: Added tag jdk8-b80 for changeset b0224010e2f0 Message-ID: <20130311220322.D032D48081@hg.openjdk.java.net> Changeset: c88bb21560cc Author: katleman Date: 2013-03-07 11:17 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jaxws/rev/c88bb21560cc Added tag jdk8-b80 for changeset b0224010e2f0 ! .hgtags From david.katleman at oracle.com Mon Mar 11 22:03:34 2013 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Mon, 11 Mar 2013 22:03:34 +0000 Subject: hg: jdk8/build/jdk: 2 new changesets Message-ID: <20130311220447.7CD5948082@hg.openjdk.java.net> Changeset: d60a95b95f01 Author: katleman Date: 2013-03-07 11:17 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/d60a95b95f01 Added tag jdk8-b80 for changeset dfb40f066c6c ! .hgtags Changeset: da8edcfc19af Author: katleman Date: 2013-03-11 13:42 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/da8edcfc19af Merge From david.katleman at oracle.com Mon Mar 11 22:06:12 2013 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Mon, 11 Mar 2013 22:06:12 +0000 Subject: hg: jdk8/build/langtools: Added tag jdk8-b80 for changeset a8227c617684 Message-ID: <20130311220618.9813948083@hg.openjdk.java.net> Changeset: ed69d087fdfd Author: katleman Date: 2013-03-07 11:18 -0800 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/ed69d087fdfd Added tag jdk8-b80 for changeset a8227c617684 ! .hgtags From jonathan.gibbons at oracle.com Tue Mar 12 02:09:08 2013 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 11 Mar 2013 19:09:08 -0700 Subject: sjavac In-Reply-To: <4D80390B-083F-473B-AF92-17567FEDF2ED@oracle.com> References: <4D80390B-083F-473B-AF92-17567FEDF2ED@oracle.com> Message-ID: <513E8E44.4060306@oracle.com> On 03/11/2013 11:33 AM, Jim Laskey (Oracle) wrote: > The Nashorn team is wondering about the status of sjavac and the builds. Note: https://jbs.oracle.com/bugs/browse/JDK-8009788 . There are two occurances of "-cp" which should be convered to "-classpath" in makefiles/BuildNashorn.gmk . > > Cheers, > > -- Jim > sjavac has been updated (in tl/langtools) to accept -cp as well as -classpath -- Jon From tim.bell at oracle.com Tue Mar 12 03:02:23 2013 From: tim.bell at oracle.com (Tim Bell) Date: Mon, 11 Mar 2013 20:02:23 -0700 Subject: sjavac In-Reply-To: <513E8E44.4060306@oracle.com> References: <4D80390B-083F-473B-AF92-17567FEDF2ED@oracle.com> <513E8E44.4060306@oracle.com> Message-ID: <513E9ABF.9050406@oracle.com> Hi Jon: > On 03/11/2013 11:33 AM, Jim Laskey (Oracle) wrote: >> The Nashorn team is wondering about the status of sjavac and the >> builds. Note: https://jbs.oracle.com/bugs/browse/JDK-8009788 . >> There are two occurances of "-cp" which should be convered to >> "-classpath" in makefiles/BuildNashorn.gmk . >> >> Cheers, >> >> -- Jim >> > > sjavac has been updated (in tl/langtools) to accept -cp as well as > -classpath Thanks very much! Tim From david.holmes at oracle.com Tue Mar 12 07:10:59 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 12 Mar 2013 17:10:59 +1000 Subject: RFR: 8009428 and 8009429 - Profile related fixes and clean ups In-Reply-To: <513D9BD1.6060807@oracle.com> References: <51394373.4040404@oracle.com> <5139AD05.1060208@oracle.com> <5139CB49.5000601@oracle.com> <513D3257.2030801@oracle.com> <513D9BD1.6060807@oracle.com> Message-ID: <513ED503.6040000@oracle.com> Hi Alan, On 11/03/2013 6:54 PM, Alan Bateman wrote: > On 11/03/2013 01:24, David Holmes wrote: >> I had overlooked the need to update the ct.sym creation tool to >> recognize the new syntax in the profile spec file. That process also >> uncovered a few bugs in the listing that needed correcting. >> >> The javadoc generation of compact profile information is not quite >> right, but that will be handled in a seperate bug. >> >> Updated webrevs at: >> >> http://cr.openjdk.java.net/~dholmes/8009428_8009429.v2/ > The changes to the top-level and jdk repo look good to me. As per my > original comments, I'm happy to see profile-rtjar-includes.txt changed > to be much easier to maintain. The assumption that jdk.** is in compact1 > is okay for now but I'm sure that will need to be changed when that > namespace is used more. Yes we will change this as we need to, once other packages come into play. > For the intro comment in profile-rtjar-includes.txt then it might be > useful to beef up the comment to explain what happens when an API > package does not match one of the rules, ie: does it go into compact1, > only the full JRE, or none. Also make it explicit that the form > DialogCallbackHandler*.class should not be used. I suggest this for the > benefit of someone needing to tweak this in the future. I have updated the webrev with additional commentary. > I have played with com.sun.tools.javac.sym.Profiles and so the changes > to MakefileProfiles look okay to me but Jon should really be the > reviewer for this. One thing about maxProfiles is that it should match > Profile.values.length maybe maxProfiles should not be hardcoded to 4. Sorry but what is Profiles.values.length? Previously we inferred the number of profiles from the fact that we failed to find PROFILE_n for some value n. That can't work (easily) now hence the hard limit. > Another thing is whether to add a test or beef up an existing test > (ProfileOptionTest.java in particular). What exactly is it that you would like to test for? Thanks, David > -Alan. From erik.joelsson at oracle.com Tue Mar 12 08:39:51 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 12 Mar 2013 09:39:51 +0100 Subject: RFR: 8009695: embedded/GP/RI: This intermittent error happens too often, makes the build unstable, and waste machine resources. Message-ID: <513EE9D7.2020306@oracle.com> Profiles builds are being plagued by intermittent failures due to exceptions in the meta-index builder, looking like this: Creating rt.jar profile_1 Compressed=false Creating resources.jar Updating rt.jar profile_1 Removed method addPropertyChangeListener(java.beans.PropertyChangeListener) from java/util/jar/Pack200$Packer Removed method removePropertyChangeListener(java.beans.PropertyChangeListener) from java/util/jar/Pack200$Packer Removed method addPropertyChangeListener(java.beans.PropertyChangeListener) from java/util/jar/Pack200$Unpacker Removed method removePropertyChangeListener(java.beans.PropertyChangeListener) from java/util/jar/Pack200$Unpacker Exception in thread "main" java.util.zip.ZipException: error in opening zip file at java.util.zip.ZipFile.open(Native Method) at java.util.zip.ZipFile.(ZipFile.java:214) at java.util.zip.ZipFile.(ZipFile.java:144) at java.util.jar.JarFile.(JarFile.java:152) at java.util.jar.JarFile.(JarFile.java:89) at build.tools.buildmetaindex.JarMetaIndex.(BuildMetaIndex.java:186) at build.tools.buildmetaindex.BuildMetaIndex.main(BuildMetaIndex.java:96) I believe I have found the cause for it. Near the bottom of Images.gmk: ifneq ($(PROFILE),) # Files in lib$(PROFILE) are excluded from the generic copying routines so # we have to add them back in here $(foreach f,$(CUSTOM_PROFILE_JARS),\ $(eval $(call AddFileToCopy,$(IMAGES_OUTPUTDIR)/lib$(PROFILE),$(JRE_IMAGE_DIR)/lib,$f,JRE_LIB_TARGETS))) The above happens after the rules for building meta-indexes are declared: $(JRE_IMAGE_DIR)/lib/meta-index: $(JRE_LIB_TARGETS) $(ECHO) $(LOG_INFO) Generating $(patsubst $(OUTPUT_ROOT)/%,%,$@) $(CD) $(@D) && $(TOOL_BUILDMETAINDEX) -o meta-index `$(LS) *.jar | $(SED) 's/JObjC\.jar//g'` This means that the variable JRE_LIB_TARGETS does not contain the jars that are copied from lib$(PROFILE) and the meta-index files are not declared dependent on those jars, which creates the race causing intermittent failures. It also explains why this only happens when building profiles and not images. Webrev moving the foreach loop to the lib section, above the meta-index rules declarations: http://cr.openjdk.java.net/~erikj/8009695/webrev.jdk.01/ /Erik From david.holmes at oracle.com Tue Mar 12 09:42:47 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 12 Mar 2013 19:42:47 +1000 Subject: RFR: 8009695: embedded/GP/RI: This intermittent error happens too often, makes the build unstable, and waste machine resources. In-Reply-To: <513EE9D7.2020306@oracle.com> References: <513EE9D7.2020306@oracle.com> Message-ID: <513EF897.70409@oracle.com> Great find Erik - thanks! Looks good to me. David On 12/03/2013 6:39 PM, Erik Joelsson wrote: > Profiles builds are being plagued by intermittent failures due to > exceptions in the meta-index builder, looking like this: > > Creating rt.jar profile_1 Compressed=false > Creating resources.jar > Updating rt.jar profile_1 > Removed method > addPropertyChangeListener(java.beans.PropertyChangeListener) from > java/util/jar/Pack200$Packer > Removed method > removePropertyChangeListener(java.beans.PropertyChangeListener) from > java/util/jar/Pack200$Packer > Removed method > addPropertyChangeListener(java.beans.PropertyChangeListener) from > java/util/jar/Pack200$Unpacker > Removed method > removePropertyChangeListener(java.beans.PropertyChangeListener) from > java/util/jar/Pack200$Unpacker > Exception in thread "main" java.util.zip.ZipException: error in opening > zip file > at java.util.zip.ZipFile.open(Native Method) > at java.util.zip.ZipFile.(ZipFile.java:214) > at java.util.zip.ZipFile.(ZipFile.java:144) > at java.util.jar.JarFile.(JarFile.java:152) > at java.util.jar.JarFile.(JarFile.java:89) > at > build.tools.buildmetaindex.JarMetaIndex.(BuildMetaIndex.java:186) > at > build.tools.buildmetaindex.BuildMetaIndex.main(BuildMetaIndex.java:96) > > > I believe I have found the cause for it. Near the bottom of Images.gmk: > > ifneq ($(PROFILE),) > # Files in lib$(PROFILE) are excluded from the generic copying routines so > # we have to add them back in here > $(foreach f,$(CUSTOM_PROFILE_JARS),\ > $(eval $(call > AddFileToCopy,$(IMAGES_OUTPUTDIR)/lib$(PROFILE),$(JRE_IMAGE_DIR)/lib,$f,JRE_LIB_TARGETS))) > > > The above happens after the rules for building meta-indexes are declared: > > $(JRE_IMAGE_DIR)/lib/meta-index: $(JRE_LIB_TARGETS) > $(ECHO) $(LOG_INFO) Generating $(patsubst $(OUTPUT_ROOT)/%,%,$@) > $(CD) $(@D) && $(TOOL_BUILDMETAINDEX) -o meta-index `$(LS) > *.jar | $(SED) 's/JObjC\.jar//g'` > > This means that the variable JRE_LIB_TARGETS does not contain the jars > that are copied from lib$(PROFILE) and the meta-index files are not > declared dependent on those jars, which creates the race causing > intermittent failures. It also explains why this only happens when > building profiles and not images. > > Webrev moving the foreach loop to the lib section, above the meta-index > rules declarations: > > http://cr.openjdk.java.net/~erikj/8009695/webrev.jdk.01/ > > /Erik From Alan.Bateman at oracle.com Tue Mar 12 10:05:01 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 12 Mar 2013 10:05:01 +0000 Subject: RFR: 8009428 and 8009429 - Profile related fixes and clean ups In-Reply-To: <513ED503.6040000@oracle.com> References: <51394373.4040404@oracle.com> <5139AD05.1060208@oracle.com> <5139CB49.5000601@oracle.com> <513D3257.2030801@oracle.com> <513D9BD1.6060807@oracle.com> <513ED503.6040000@oracle.com> Message-ID: <513EFDCD.4040309@oracle.com> On 12/03/2013 07:10, David Holmes wrote: > : > >> For the intro comment in profile-rtjar-includes.txt then it might be >> useful to beef up the comment to explain what happens when an API >> package does not match one of the rules, ie: does it go into compact1, >> only the full JRE, or none. Also make it explicit that the form >> DialogCallbackHandler*.class should not be used. I suggest this for the >> benefit of someone needing to tweak this in the future. > > I have updated the webrev with additional commentary. Thanks, that will be very useful to future maintainers. > >> I have played with com.sun.tools.javac.sym.Profiles and so the changes >> to MakefileProfiles look okay to me but Jon should really be the >> reviewer for this. One thing about maxProfiles is that it should match >> Profile.values.length maybe maxProfiles should not be hardcoded to 4. > > Sorry but what is Profiles.values.length? Previously we inferred the > number of profiles from the fact that we failed to find PROFILE_n for > some value n. That can't work (easily) now hence the hard limit. I meant com.sun.tools.javac.jvm.Profile, it's an enum of the profiles so it means that the knowledge about 3 + full JRE is now in two places. > >> Another thing is whether to add a test or beef up an existing test >> (ProfileOptionTest.java in particular). > > What exactly is it that you would like to test for? I think the test should include a few cases to cover a few selected types in sub-packages to make sure they are in the right profile. -Alan. From mikhail.cherkasov at oracle.com Tue Mar 12 10:29:27 2013 From: mikhail.cherkasov at oracle.com (mikhail cherkasov) Date: Tue, 12 Mar 2013 14:29:27 +0400 Subject: Solaris jdk8 build failed due missed dependency: freetype2 Message-ID: <513F0387.1020804@oracle.com> Hello all, Could you please advise where I can get freetype2 for Solaris? I'm looking for binaries for amd64/i386, I've tried to build it, but faced with the following error: gmake: *** [/export/home/Users/jpse/tools/freetype-2.4.11/objs/libfreetype.la] Error 1 I'll be glad for advice how to fix freetype2 build too. I have no idea where to get libfreetype.la. Also I want to mention that I use Solaris 10, *not* OpenSolaris. Thanks, Mikhail. From tim.bell at oracle.com Tue Mar 12 14:13:32 2013 From: tim.bell at oracle.com (Tim Bell) Date: Tue, 12 Mar 2013 07:13:32 -0700 Subject: RFR: 8009695: embedded/GP/RI: This intermittent error happens too often, makes the build unstable, and waste machine resources. In-Reply-To: <513EF897.70409@oracle.com> References: <513EE9D7.2020306@oracle.com> <513EF897.70409@oracle.com> Message-ID: <513F380C.9050305@oracle.com> Hi Erik Looks good to me as well. Tim On 03/12/13 02:42, David Holmes wrote: > Great find Erik - thanks! > > Looks good to me. > > David > > On 12/03/2013 6:39 PM, Erik Joelsson wrote: >> Profiles builds are being plagued by intermittent failures due to >> exceptions in the meta-index builder, looking like this: >> >> Creating rt.jar profile_1 Compressed=false >> Creating resources.jar >> Updating rt.jar profile_1 >> Removed method >> addPropertyChangeListener(java.beans.PropertyChangeListener) from >> java/util/jar/Pack200$Packer >> Removed method >> removePropertyChangeListener(java.beans.PropertyChangeListener) from >> java/util/jar/Pack200$Packer >> Removed method >> addPropertyChangeListener(java.beans.PropertyChangeListener) from >> java/util/jar/Pack200$Unpacker >> Removed method >> removePropertyChangeListener(java.beans.PropertyChangeListener) from >> java/util/jar/Pack200$Unpacker >> Exception in thread "main" java.util.zip.ZipException: error in opening >> zip file >> at java.util.zip.ZipFile.open(Native Method) >> at java.util.zip.ZipFile.(ZipFile.java:214) >> at java.util.zip.ZipFile.(ZipFile.java:144) >> at java.util.jar.JarFile.(JarFile.java:152) >> at java.util.jar.JarFile.(JarFile.java:89) >> at >> build.tools.buildmetaindex.JarMetaIndex.(BuildMetaIndex.java:186) >> at >> build.tools.buildmetaindex.BuildMetaIndex.main(BuildMetaIndex.java:96) >> >> >> I believe I have found the cause for it. Near the bottom of Images.gmk: >> >> ifneq ($(PROFILE),) >> # Files in lib$(PROFILE) are excluded from the generic copying >> routines so >> # we have to add them back in here >> $(foreach f,$(CUSTOM_PROFILE_JARS),\ >> $(eval $(call >> AddFileToCopy,$(IMAGES_OUTPUTDIR)/lib$(PROFILE),$(JRE_IMAGE_DIR)/lib,$f,JRE_LIB_TARGETS))) >> >> >> >> The above happens after the rules for building meta-indexes are >> declared: >> >> $(JRE_IMAGE_DIR)/lib/meta-index: $(JRE_LIB_TARGETS) >> $(ECHO) $(LOG_INFO) Generating $(patsubst >> $(OUTPUT_ROOT)/%,%,$@) >> $(CD) $(@D) && $(TOOL_BUILDMETAINDEX) -o meta-index `$(LS) >> *.jar | $(SED) 's/JObjC\.jar//g'` >> >> This means that the variable JRE_LIB_TARGETS does not contain the jars >> that are copied from lib$(PROFILE) and the meta-index files are not >> declared dependent on those jars, which creates the race causing >> intermittent failures. It also explains why this only happens when >> building profiles and not images. >> >> Webrev moving the foreach loop to the lib section, above the meta-index >> rules declarations: >> >> http://cr.openjdk.java.net/~erikj/8009695/webrev.jdk.01/ >> >> /Erik From philip.race at oracle.com Tue Mar 12 16:17:31 2013 From: philip.race at oracle.com (Phil Race) Date: Tue, 12 Mar 2013 09:17:31 -0700 Subject: Solaris jdk8 build failed due missed dependency: freetype2 In-Reply-To: <513F0387.1020804@oracle.com> References: <513F0387.1020804@oracle.com> Message-ID: <513F551B.9050701@oracle.com> Do you have the SUNWfreetype2 package installed ? -phil. On 3/12/2013 3:29 AM, mikhail cherkasov wrote: > Hello all, > > Could you please advise where I can get freetype2 for Solaris? > I'm looking for binaries for amd64/i386, I've tried to build it, but > faced with the following error: > > gmake: *** > [/export/home/Users/jpse/tools/freetype-2.4.11/objs/libfreetype.la] > Error 1 > > I'll be glad for advice how to fix freetype2 build too. I have no idea > where to get libfreetype.la. > > Also I want to mention that I use Solaris 10, *not* OpenSolaris. > > Thanks, > Mikhail. From Alan.Bateman at oracle.com Tue Mar 12 17:23:26 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 12 Mar 2013 17:23:26 +0000 Subject: RFR: 8009695: embedded/GP/RI: This intermittent error happens too often, makes the build unstable, and waste machine resources. In-Reply-To: <513EE9D7.2020306@oracle.com> References: <513EE9D7.2020306@oracle.com> Message-ID: <513F648E.8000104@oracle.com> On 12/03/2013 08:39, Erik Joelsson wrote: > Profiles builds are being plagued by intermittent failures due to > exceptions in the meta-index builder, looking like this: It's great to fine this. The change looks good to me too . -Alan From jonathan.gibbons at oracle.com Tue Mar 12 19:48:08 2013 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 12 Mar 2013 12:48:08 -0700 Subject: sjavac In-Reply-To: References: <4D80390B-083F-473B-AF92-17567FEDF2ED@oracle.com> <513E30EE.90603@oracle.com> Message-ID: <513F8678.3010400@oracle.com> On 03/11/2013 12:39 PM, Martin Buchholz wrote: > > While you're there, consider checking/modfying all of the jdk tools to > accept either both or neither of "-cp" and "-classpath". javap is the > command I'm thinking of. Issue JDK-8009924. -- Jon From erik.joelsson at oracle.com Tue Mar 12 21:44:41 2013 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Tue, 12 Mar 2013 21:44:41 +0000 Subject: hg: jdk8/build/jdk: 8009695: embedded/GP/RI: This intermittent error happens too often, makes the build unstable, and waste machine Message-ID: <20130312214526.2D7E7480C1@hg.openjdk.java.net> Changeset: bc0ca8bc4637 Author: erikj Date: 2013-03-12 15:17 +0100 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/bc0ca8bc4637 8009695: embedded/GP/RI: This intermittent error happens too often, makes the build unstable, and waste machine Reviewed-by: dholmes, tbell ! make/common/shared/Defs-utils.gmk ! makefiles/Images.gmk From tim.bell at oracle.com Tue Mar 12 21:54:28 2013 From: tim.bell at oracle.com (Tim Bell) Date: Tue, 12 Mar 2013 14:54:28 -0700 Subject: RFR: JDK-8009819 build-infra: RE jdk8 build forest fails for windows since addition of --with-dxsdk Message-ID: <513FA414.3010400@oracle.com> Please review this change, which provides a fallback to the traditional location for the DXSDK if it is not specified on the configure line. We don't like doing this, but in this case I will give in. It seems many of the legacy build systems we use internally do not have the environment variable defined. Bug report (not visible externally yet... should be soon): http://bugs.sun.com/view_bug.do?bug_id=8009819 JDK-8009819 build-infra: RE jdk8 build forest fails for windows since addition of --with-dxsdk Webrev: http://cr.openjdk.java.net/~tbell/8009819/webrev.00/ This is related to the fix for 8008073, which is still in the build forest. http://bugs.sun.com/view_bug.do?bug_id=8008073 Thank you- Tim From tim.bell at oracle.com Tue Mar 12 22:05:29 2013 From: tim.bell at oracle.com (Tim Bell) Date: Tue, 12 Mar 2013 15:05:29 -0700 Subject: RFR: JDK-8009819 build-infra: RE jdk8 build forest fails for windows since addition of --with-dxsdk In-Reply-To: <513FA414.3010400@oracle.com> References: <513FA414.3010400@oracle.com> Message-ID: <513FA6A9.5090800@oracle.com> On 03/12/13 14:54, Tim Bell wrote: > Please review this change, which provides a fallback to the > traditional location for the DXSDK if it is not specified on the > configure line. We don't like doing this, but in this case I will > give in. It seems many of the legacy build systems we use internally > do not have the environment variable defined. > > Bug report (not visible externally yet... should be soon): > > http://bugs.sun.com/view_bug.do?bug_id=8009819 > > JDK-8009819 > build-infra: RE jdk8 build forest fails for windows since addition of > --with-dxsdk > > Webrev: > > http://cr.openjdk.java.net/~tbell/8009819/webrev.00/ For some reason, this webrev did not find any changes. While I debug webrev :-/ ... here is the change. There are also the corresponding mechanical changes to common/autoconf/generated-configure.sh and the closed generated-configure.sh: % hg diff common/autoconf/toolchain_windows.m4 diff --git a/common/autoconf/toolchain_windows.m4 b/common/autoconf/toolchain_windows.m4 --- a/common/autoconf/toolchain_windows.m4 +++ b/common/autoconf/toolchain_windows.m4 @@ -280,6 +280,8 @@ AC_DEFUN([TOOLCHAIN_SETUP_DXSDK], dxsdk_path="$with_dxsdk" elif test "x$DXSDK_DIR" != x; then dxsdk_path="$DXSDK_DIR" + elif test -d "C:/DXSDK"; then + dxsdk_path="C:/DXSDK" else AC_MSG_ERROR([Could not find the DirectX SDK]) fi > > > This is related to the fix for 8008073, which is still in the build > forest. > > http://bugs.sun.com/view_bug.do?bug_id=8008073 > > Thank you- > > Tim > From tim.bell at oracle.com Tue Mar 12 23:31:42 2013 From: tim.bell at oracle.com (Tim Bell) Date: Tue, 12 Mar 2013 16:31:42 -0700 Subject: RFR: JDK-8009819 build-infra: RE jdk8 build forest fails for windows since addition of --with-dxsdk In-Reply-To: <513FA6A9.5090800@oracle.com> References: <513FA414.3010400@oracle.com> <513FA6A9.5090800@oracle.com> Message-ID: <513FBADE.3050405@oracle.com> On 03/12/13 15:05, Tim Bell wrote: > On 03/12/13 14:54, Tim Bell wrote: >> Please review this change, which provides a fallback to the >> traditional location for the DXSDK if it is not specified on the >> configure line. We don't like doing this, but in this case I will >> give in. It seems many of the legacy build systems we use internally >> do not have the environment variable defined. >> >> Bug report (not visible externally yet... should be soon): >> >> http://bugs.sun.com/view_bug.do?bug_id=8009819 >> >> JDK-8009819 >> build-infra: RE jdk8 build forest fails for windows since addition of >> --with-dxsdk >> >> Webrev: >> >> http://cr.openjdk.java.net/~tbell/8009819/webrev.00/ > > For some reason, this webrev did not find any changes. While I debug > webrev :-/ ... It was a case of a newer hg versus the older forest extension. Here is a corrected webrev: http://cr.openjdk.java.net/~tbell/8009819/webrev.01/ Sorry for the extra emails. Tim From david.katleman at oracle.com Wed Mar 13 02:31:31 2013 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Wed, 13 Mar 2013 02:31:31 +0000 Subject: hg: jdk8/build/jdk: 2 new changesets Message-ID: <20130313023205.A22BC480D2@hg.openjdk.java.net> Changeset: 758db1c4c65c Author: ehelin Date: 2013-03-04 15:40 +0100 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/758db1c4c65c 8009384: Temporarily disable jstat tests to ease complicated push Reviewed-by: mchung ! test/ProblemList.txt Changeset: c0f8022eba53 Author: katleman Date: 2013-03-12 19:19 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/c0f8022eba53 Merge From david.katleman at oracle.com Wed Mar 13 02:28:27 2013 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Wed, 13 Mar 2013 02:28:27 +0000 Subject: hg: jdk8/build/hotspot: 34 new changesets Message-ID: <20130313022950.727BC480D1@hg.openjdk.java.net> Changeset: 7f482030ff64 Author: amurillo Date: 2013-03-01 04:58 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/7f482030ff64 8009226: new hotspot build - hs25-b22 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 1f9994892f89 Author: stefank Date: 2013-02-21 17:22 +0100 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/1f9994892f89 8008549: NPG: SystemDictionary::find(...) unnecessarily keeps class loaders alive Summary: SystemDictionary::find(...) should not create and register ClassLoaderData objects for class loaders. Reviewed-by: coleenp, acorn Contributed-by: Stefan Karlsson , Erik Helin ! src/share/vm/classfile/classLoaderData.hpp ! src/share/vm/classfile/classLoaderData.inline.hpp ! src/share/vm/classfile/dictionary.cpp ! src/share/vm/classfile/systemDictionary.cpp Changeset: 3c9db54c2660 Author: mikael Date: 2013-02-26 08:54 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/3c9db54c2660 8008081: Print outs do not have matching arguments Summary: Corrected formatted prints to have matching arguments, removed dead print_frame_layout function Reviewed-by: sla, dholmes ! src/share/vm/c1/c1_FrameMap.cpp ! src/share/vm/c1/c1_FrameMap.hpp ! src/share/vm/gc_implementation/parNew/parCardTableModRefBS.cpp ! src/share/vm/memory/cardTableModRefBS.cpp ! src/share/vm/memory/cardTableRS.cpp ! src/share/vm/prims/jvmtiEnter.xsl ! src/share/vm/services/memReporter.cpp ! src/share/vm/utilities/numberSeq.cpp Changeset: 05f2fc6b4ea7 Author: dholmes Date: 2013-02-27 04:58 -0500 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/05f2fc6b4ea7 Merge Changeset: 96bd4772ec62 Author: kevinw Date: 2013-02-27 14:02 +0000 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/96bd4772ec62 8008807: SA: jstack crash when target has mismatched bitness (Linux) Reviewed-by: rbackman, sla, poonam ! agent/src/os/linux/LinuxDebuggerLocal.c Changeset: 698b615a1cde Author: kevinw Date: 2013-02-27 16:40 +0000 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/698b615a1cde Merge Changeset: 651919d134f7 Author: kevinw Date: 2013-02-27 22:40 +0000 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/651919d134f7 7178741: SA: jstack -m produce UnalignedAddressException in output (Linux) Reviewed-by: poonam, sla ! agent/src/share/classes/sun/jvm/hotspot/debugger/linux/amd64/LinuxAMD64CFrame.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/linux/x86/LinuxX86CFrame.java Changeset: 5ee250974db9 Author: dcubed Date: 2013-02-27 15:00 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/5ee250974db9 8007476: assert(the_owner != NULL) failed: Did not find owning Java thread for lock word address Summary: Make deadlock detection a little more robust in the case of being unable to find the JavaThread associated with an object lock. Reviewed-by: sla, acorn ! src/share/vm/prims/jvmtiEnvBase.cpp ! src/share/vm/runtime/synchronizer.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/services/threadService.cpp Changeset: a140cd925462 Author: dcubed Date: 2013-02-28 05:55 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/a140cd925462 Merge Changeset: 63e54c37ac64 Author: simonis Date: 2013-02-27 09:40 +0100 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/63e54c37ac64 8008959: Fix non-PCH build on Linux, Windows and MacOS X Summary: Fix the build without precompiled headers by either including the missing ".inline.hpp" files into the appropriate files or by turning inline-functions declared in header files into ordinary functions in ".cpp" files. Reviewed-by: coleenp, stefank, dholmes ! src/os/bsd/vm/os_bsd.cpp ! src/os/bsd/vm/os_bsd.hpp ! src/os/bsd/vm/os_bsd.inline.hpp ! src/os/linux/vm/os_linux.cpp ! src/os/linux/vm/os_linux.hpp ! src/os/linux/vm/os_linux.inline.hpp ! src/os/solaris/vm/os_solaris.inline.hpp ! src/os/windows/vm/decoder_windows.cpp ! src/os/windows/vm/os_windows.inline.hpp ! src/os_cpu/bsd_x86/vm/atomic_bsd_x86.inline.hpp ! src/os_cpu/bsd_x86/vm/orderAccess_bsd_x86.inline.hpp ! src/os_cpu/bsd_zero/vm/atomic_bsd_zero.inline.hpp ! src/os_cpu/linux_sparc/vm/atomic_linux_sparc.inline.hpp ! src/os_cpu/linux_x86/vm/atomic_linux_x86.inline.hpp ! src/os_cpu/linux_x86/vm/orderAccess_linux_x86.inline.hpp ! src/os_cpu/linux_zero/vm/atomic_linux_zero.inline.hpp ! src/os_cpu/solaris_sparc/vm/atomic_solaris_sparc.inline.hpp ! src/os_cpu/solaris_sparc/vm/orderAccess_solaris_sparc.inline.hpp ! src/os_cpu/solaris_x86/vm/atomic_solaris_x86.inline.hpp ! src/os_cpu/solaris_x86/vm/orderAccess_solaris_x86.inline.hpp ! src/os_cpu/windows_x86/vm/atomic_windows_x86.inline.hpp ! src/os_cpu/windows_x86/vm/orderAccess_windows_x86.inline.hpp ! src/share/vm/memory/allocation.inline.hpp ! src/share/vm/oops/symbol.cpp ! src/share/vm/oops/symbol.hpp Changeset: a506ac816f14 Author: coleenp Date: 2013-02-27 07:35 -0500 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/a506ac816f14 Merge Changeset: 143973ced9ab Author: coleenp Date: 2013-02-28 18:37 -0500 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/143973ced9ab Merge Changeset: 3e83d69c19db Author: dcubed Date: 2013-03-01 15:59 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/3e83d69c19db Merge Changeset: a252e688abcf Author: jmasa Date: 2013-02-01 17:02 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/a252e688abcf 7189971: Implement CMSWaitDuration for non-incremental mode of CMS Reviewed-by: jmasa, johnc, ysr Contributed-by: michal at frajt.eu ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepThread.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepThread.hpp ! src/share/vm/runtime/globals.hpp Changeset: 0624b9d81255 Author: ehelin Date: 2013-03-04 13:01 +0100 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/0624b9d81255 8004172: Update jstat counter names to reflect metaspace changes Reviewed-by: stefank, jmasa ! src/share/vm/memory/metaspaceCounters.cpp ! src/share/vm/memory/metaspaceCounters.hpp Changeset: 27714220e50e Author: johnc Date: 2013-03-04 12:42 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/27714220e50e 8007036: G1: Too many old regions added to last mixed GC Summary: Stop adding old regions to collection set when the remaining reclaimable bytes reaches, or goes below, G1HeapWastePercent. Changes were also reviewed by Vitaly Davidovich . Reviewed-by: brutisso ! src/share/vm/gc_implementation/g1/collectionSetChooser.cpp ! src/share/vm/gc_implementation/g1/collectionSetChooser.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp Changeset: d778bb46a9a5 Author: erikj Date: 2013-03-04 22:39 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/d778bb46a9a5 8008451: Make mac builds on 10.8 work on 10.7 Reviewed-by: jcoomes, ohair ! make/bsd/makefiles/gcc.make Changeset: c71e15057f1d Author: stefank Date: 2013-03-07 14:29 +0100 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/c71e15057f1d Merge Changeset: 7369298bec7e Author: collins Date: 2013-02-27 20:36 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/7369298bec7e 7115383: TEST_BUG: some jtreg tests fail because they explicitly specify -server option Summary: Small changes to hotspot tests to remove "-server" and replace with ${TESTVMOPTS} Reviewed-by: kvn ! test/compiler/6431242/Test.java ! test/compiler/6589834/Test_ia32.java ! test/compiler/6636138/Test1.java ! test/compiler/6636138/Test2.java ! test/compiler/6795161/Test.java ! test/compiler/6946040/TestCharShortByteSwap.java ! test/compiler/7068051/Test7068051.sh ! test/compiler/8000805/Test8000805.java Changeset: 5cf033ff06c4 Author: bpittore Date: 2013-03-01 14:06 -0500 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/5cf033ff06c4 Merge Changeset: af5ac43f06e9 Author: jprovino Date: 2013-03-07 10:46 -0500 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/af5ac43f06e9 Merge Changeset: 0b8f9c8d2617 Author: jiangli Date: 2013-03-07 10:39 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/0b8f9c8d2617 Merge Changeset: 40b7c6b800ab Author: morris Date: 2013-03-01 14:26 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/40b7c6b800ab 8008327: [parfait] Unitialized variable in hotspot/agent/src/os/bsd/MacosxDebuggerLocal.m Summary: Fix unitialized variable and return value. Reviewed-by: kvn ! agent/src/os/bsd/MacosxDebuggerLocal.m Changeset: bf06968a8a00 Author: morris Date: 2013-03-04 13:15 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/bf06968a8a00 8008559: [parfait] Path through non-void function '_ZN2os15thread_cpu_timeEP6Thread' returns an undefined value Summary: safety checks for non-Apple thread time functions Reviewed-by: kvn ! src/os/bsd/vm/os_bsd.cpp Changeset: c40fbf634c90 Author: morris Date: 2013-03-05 04:24 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/c40fbf634c90 8008574: [parfait] Null pointer deference in hotspot/src/share/vm/runtime/frame.cpp Summary: fix null pointer Reviewed-by: kvn ! src/share/vm/runtime/frame.cpp Changeset: 571076d3c79d Author: shade Date: 2013-03-05 04:24 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/571076d3c79d 8009120: Fuzz instruction scheduling in HotSpot compilers Reviewed-by: kvn, vlivanov ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/gcm.cpp ! src/share/vm/opto/lcm.cpp Changeset: 4f553e24b3b5 Author: vlivanov Date: 2013-03-05 08:17 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/4f553e24b3b5 Merge Changeset: 872b3feace55 Author: morris Date: 2013-03-05 18:03 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/872b3feace55 8008750: [partfait] Null pointer deference in hotspot/src/share/vm/oops/instanceKlass.hpp Summary: fix null pointer Reviewed-by: kvn, coleenp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp Changeset: 8651f608fea4 Author: roland Date: 2013-03-06 10:28 +0100 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/8651f608fea4 8009460: C2compiler crash in machnode::in_regmask(unsigned int) Summary: 7121140 may not correctly break the Allocate -> MemBarStoreStore link Reviewed-by: kvn ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/macro.cpp Changeset: ff55877839bc Author: kvn Date: 2013-03-06 12:25 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/ff55877839bc 8009472: Print additional information for 8004640 failure Summary: dump nodes and types in 8004640 case. Reviewed-by: roland ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/memnode.cpp Changeset: bdb602473679 Author: morris Date: 2013-03-07 14:46 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/bdb602473679 Merge ! src/os/bsd/vm/os_bsd.cpp Changeset: b5bd25d55994 Author: morris Date: 2013-03-07 18:03 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/b5bd25d55994 Merge Changeset: dd6350b4abc4 Author: amurillo Date: 2013-03-08 08:10 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/dd6350b4abc4 Merge Changeset: 65b797426a3b Author: amurillo Date: 2013-03-08 08:10 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/65b797426a3b Added tag hs25-b22 for changeset dd6350b4abc4 ! .hgtags From tim.bell at oracle.com Wed Mar 13 06:01:40 2013 From: tim.bell at oracle.com (tim.bell at oracle.com) Date: Wed, 13 Mar 2013 06:01:40 +0000 Subject: hg: jdk8/build: 8009819: build-infra: RE jdk8 build forest fails for windows since addition of --with-dxsdk Message-ID: <20130313060141.4BC0B480D9@hg.openjdk.java.net> Changeset: 145dbc56f931 Author: tbell Date: 2013-03-12 22:08 -0700 URL: http://hg.openjdk.java.net/jdk8/build/rev/145dbc56f931 8009819: build-infra: RE jdk8 build forest fails for windows since addition of --with-dxsdk Reviewed-by: katleman ! common/autoconf/generated-configure.sh ! common/autoconf/toolchain_windows.m4 From erik.joelsson at oracle.com Wed Mar 13 07:57:49 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 13 Mar 2013 08:57:49 +0100 Subject: RFR: JDK-8009819 build-infra: RE jdk8 build forest fails for windows since addition of --with-dxsdk In-Reply-To: <513FBADE.3050405@oracle.com> References: <513FA414.3010400@oracle.com> <513FA6A9.5090800@oracle.com> <513FBADE.3050405@oracle.com> Message-ID: <5140317D.60307@oracle.com> Looks good, Tim. /Erik On 2013-03-13 00:31, Tim Bell wrote: > On 03/12/13 15:05, Tim Bell wrote: >> On 03/12/13 14:54, Tim Bell wrote: >>> Please review this change, which provides a fallback to the >>> traditional location for the DXSDK if it is not specified on the >>> configure line. We don't like doing this, but in this case I will >>> give in. It seems many of the legacy build systems we use internally >>> do not have the environment variable defined. >>> >>> Bug report (not visible externally yet... should be soon): >>> >>> http://bugs.sun.com/view_bug.do?bug_id=8009819 >>> >>> JDK-8009819 >>> build-infra: RE jdk8 build forest fails for windows since addition >>> of --with-dxsdk >>> >>> Webrev: >>> >>> http://cr.openjdk.java.net/~tbell/8009819/webrev.00/ >> >> For some reason, this webrev did not find any changes. While I debug >> webrev :-/ ... > > It was a case of a newer hg versus the older forest extension. Here > is a corrected webrev: > > http://cr.openjdk.java.net/~tbell/8009819/webrev.01/ > > Sorry for the extra emails. > > Tim > From david.holmes at oracle.com Wed Mar 13 09:40:53 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 13 Mar 2013 19:40:53 +1000 Subject: RFR: JDK-8009819 build-infra: RE jdk8 build forest fails for windows since addition of --with-dxsdk In-Reply-To: <513FBADE.3050405@oracle.com> References: <513FA414.3010400@oracle.com> <513FA6A9.5090800@oracle.com> <513FBADE.3050405@oracle.com> Message-ID: <514049A5.8000602@oracle.com> Looks okay to me. David On 13/03/2013 9:31 AM, Tim Bell wrote: > On 03/12/13 15:05, Tim Bell wrote: >> On 03/12/13 14:54, Tim Bell wrote: >>> Please review this change, which provides a fallback to the >>> traditional location for the DXSDK if it is not specified on the >>> configure line. We don't like doing this, but in this case I will >>> give in. It seems many of the legacy build systems we use internally >>> do not have the environment variable defined. >>> >>> Bug report (not visible externally yet... should be soon): >>> >>> http://bugs.sun.com/view_bug.do?bug_id=8009819 >>> >>> JDK-8009819 >>> build-infra: RE jdk8 build forest fails for windows since addition of >>> --with-dxsdk >>> >>> Webrev: >>> >>> http://cr.openjdk.java.net/~tbell/8009819/webrev.00/ >> >> For some reason, this webrev did not find any changes. While I debug >> webrev :-/ ... > > It was a case of a newer hg versus the older forest extension. Here is > a corrected webrev: > > http://cr.openjdk.java.net/~tbell/8009819/webrev.01/ > > Sorry for the extra emails. > > Tim > From gnu.andrew at redhat.com Wed Mar 13 09:08:23 2013 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 13 Mar 2013 05:08:23 -0400 (EDT) Subject: Allow using a system-installed giflib In-Reply-To: <5139542B.5080100@redhat.com> Message-ID: <107580076.17765929.1363165703471.JavaMail.root@redhat.com> ----- Original Message ----- > Hi, > > I have a webrev at: > http://cr.openjdk.java.net/~omajid/webrevs/system-giflib/00/ > > It introduces a configure option --with-giflib that (similar to the > existing --with-zlib) allows specifying whether the build should use > the > system installed giflib or the one bundled with OpenJDK. > > I have not tested it extensively yet (just verified that it builds > fine > with both configurations), but I will do that over the coming days if > the patch looks (somewhat) acceptable for OpenJDK8. > > Thanks, > Omair > -- > PGP Key: 66484681 (http://pgp.mit.edu/) > Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 > Given this is essentially a binary option (system giflib or bundled giflib), why is AC_ARG_ENABLE not being used instead of AC_ARG_WITH? It would simplify the logic here and is what we use in the equivalent IcedTea check which has been in production use for almost two years. This code also checks for the giflib library even if "bundled" has been selected. This is the existing IcedTea check: AC_MSG_CHECKING([whether to use the system giflib install]) AC_ARG_ENABLE([system-gif], [AS_HELP_STRING(--enable-system-gif,use the system giflib [[default=yes]])], [ ENABLE_SYSTEM_GIF="${enableval}" ], [ ENABLE_SYSTEM_GIF="yes" ]) AC_MSG_RESULT(${ENABLE_SYSTEM_GIF}) if test x"${ENABLE_SYSTEM_GIF}" = "xyes"; then dnl Check for GIF headers and libraries. AC_CHECK_LIB([gif], [main], , [AC_MSG_ERROR([Could not find GIF library; install GIF or build with --disable-system-gif to use the in-tree copy.])]\ ) AC_CHECK_HEADER([gif_lib.h], , [AC_MSG_ERROR([Could not find GIF header; install GIF or build with --disable-system-gif to use the in-tree copy.])]) GIF_LIBS="-lgif" AC_SUBST(GIF_LIBS) fi A few simple changes to this (making the default no, setting USE_EXTERNAL_GIFLIB instead of GIF_LIBS) would make this equivalent to what you have, yet retain the advantage that this code has been well tested over the last two years. Was there a reason to change main to DGifGetCode? It seems a better choice, assuming that symbol is available in all versions, but I'm just wondering if a problem with using main was exposed. -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From gnu.andrew at redhat.com Wed Mar 13 12:18:27 2013 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 13 Mar 2013 08:18:27 -0400 (EDT) Subject: Code Review Request: Simple new build system fix In-Reply-To: <1487841229.17867859.1363176720175.JavaMail.root@redhat.com> Message-ID: <1867795841.17870711.1363177107530.JavaMail.root@redhat.com> I've finally found time to look at the new build system (well, there seems to no longer be any choice ;) and so thought I start out with a simple fix. http://cr.openjdk.java.net/~andrew/build/zip_debug_info/webrev.01/ At the moment, if disable-zip-debug-info is not specified, the configure output is: checking if we should zip debug-info files... with no result as $enable_zip_debug_info is unset. This simple patch makes the option use the more standard AC_ARG_ENABLE form used elsewhere and will print the default ('yes') when the option is unspecified: checking if we should zip debug-info files... yes What actually took longer than the fix was updating the generated files. We seem to have already settled on autoconf 2.67 for generating the configure script, so my initial attempt threw up a huge number of changes as the system install is 2.69. I was able to get it down to something closer to what is expected by installing a local copy of 2.67 but it's still not perfect. I don't know why. I've never been a fan of including generated files for this reason. So this script also updates autogen.sh to see if there is an autoconf-2.67 available and use that in preference to autoconf if it is. I also added a little debug output so we can see which autoconf is being used in autogen.sh. If this is ok, can you please allocate it a bug ID and let me know which tree to commit it to. Thanks, -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From david.holmes at oracle.com Wed Mar 13 12:58:55 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 13 Mar 2013 22:58:55 +1000 Subject: Code Review Request: Simple new build system fix In-Reply-To: <1867795841.17870711.1363177107530.JavaMail.root@redhat.com> References: <1867795841.17870711.1363177107530.JavaMail.root@redhat.com> Message-ID: <5140780F.3050503@oracle.com> Andrew, FWIW we are not tied to autoconf 2.67. There have already been a number of pushes using 2.68 and now 2.69 is also showing up. David On 13/03/2013 10:18 PM, Andrew Hughes wrote: > I've finally found time to look at the new build system (well, there seems to no longer be any choice ;) > and so thought I start out with a simple fix. > > http://cr.openjdk.java.net/~andrew/build/zip_debug_info/webrev.01/ > > At the moment, if disable-zip-debug-info is not specified, the configure output is: > > checking if we should zip debug-info files... > > with no result as $enable_zip_debug_info is unset. > > This simple patch makes the option use the more standard AC_ARG_ENABLE form used elsewhere and will > print the default ('yes') when the option is unspecified: > > checking if we should zip debug-info files... yes > > What actually took longer than the fix was updating the generated files. We seem to have already settled > on autoconf 2.67 for generating the configure script, so my initial attempt threw up a huge number of changes > as the system install is 2.69. I was able to get it down to something closer to what is expected by installing > a local copy of 2.67 but it's still not perfect. I don't know why. I've never been a fan of including generated > files for this reason. > > So this script also updates autogen.sh to see if there is an autoconf-2.67 available and use that in preference > to autoconf if it is. I also added a little debug output so we can see which autoconf is being used in autogen.sh. > > If this is ok, can you please allocate it a bug ID and let me know which tree to commit it to. > > Thanks, > From erik.joelsson at oracle.com Wed Mar 13 13:37:32 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 13 Mar 2013 14:37:32 +0100 Subject: Code Review Request: Simple new build system fix In-Reply-To: <1867795841.17870711.1363177107530.JavaMail.root@redhat.com> References: <1867795841.17870711.1363177107530.JavaMail.root@redhat.com> Message-ID: <5140811C.4060703@oracle.com> Hello, I created a bug for you: 8009988: build-infra: Fix configure output for zip debuginfo check As David says, we haven't decided on 2.67, but I would guess that a majority of the commits have been with that version. This change is a first step towards enforcing a specific version and I'm ok with that. The actual fix looks good to. You will still need a JDK reviewer to ok it. Also, please notify me when you push this so that the closed version of the configure script may also be regenerated. /Erik On 2013-03-13 13:18, Andrew Hughes wrote: > I've finally found time to look at the new build system (well, there seems to no longer be any choice ;) > and so thought I start out with a simple fix. > > http://cr.openjdk.java.net/~andrew/build/zip_debug_info/webrev.01/ > > At the moment, if disable-zip-debug-info is not specified, the configure output is: > > checking if we should zip debug-info files... > > with no result as $enable_zip_debug_info is unset. > > This simple patch makes the option use the more standard AC_ARG_ENABLE form used elsewhere and will > print the default ('yes') when the option is unspecified: > > checking if we should zip debug-info files... yes > > What actually took longer than the fix was updating the generated files. We seem to have already settled > on autoconf 2.67 for generating the configure script, so my initial attempt threw up a huge number of changes > as the system install is 2.69. I was able to get it down to something closer to what is expected by installing > a local copy of 2.67 but it's still not perfect. I don't know why. I've never been a fan of including generated > files for this reason. > > So this script also updates autogen.sh to see if there is an autoconf-2.67 available and use that in preference > to autoconf if it is. I also added a little debug output so we can see which autoconf is being used in autogen.sh. > > If this is ok, can you please allocate it a bug ID and let me know which tree to commit it to. > > Thanks, From gnu.andrew at redhat.com Wed Mar 13 13:58:21 2013 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 13 Mar 2013 09:58:21 -0400 (EDT) Subject: Code Review Request: Simple new build system fix In-Reply-To: <5140780F.3050503@oracle.com> Message-ID: <385440755.17944109.1363183101615.JavaMail.root@redhat.com> ----- Original Message ----- > Andrew, > > FWIW we are not tied to autoconf 2.67. There have already been a > number > of pushes using 2.68 and now 2.69 is also showing up. > Yes, Omair was kind enough to point me to this changeset which indeed uses 2.68: http://hg.openjdk.java.net/jdk8/build/rev/145dbc56f931 It would be nice to settle on one version though, if the generated file is going to be checked into the repository, otherwise everyone who has a different version installed is going to make lots of spurious changes to that file which obscure the real change. FWIW, gcc also includes the configure file in its Subversion repository and a specific version is used to update it. > David > > On 13/03/2013 10:18 PM, Andrew Hughes wrote: > > I've finally found time to look at the new build system (well, > > there seems to no longer be any choice ;) > > and so thought I start out with a simple fix. > > > > http://cr.openjdk.java.net/~andrew/build/zip_debug_info/webrev.01/ > > > > At the moment, if disable-zip-debug-info is not specified, the > > configure output is: > > > > checking if we should zip debug-info files... > > > > with no result as $enable_zip_debug_info is unset. > > > > This simple patch makes the option use the more standard > > AC_ARG_ENABLE form used elsewhere and will > > print the default ('yes') when the option is unspecified: > > > > checking if we should zip debug-info files... yes > > > > What actually took longer than the fix was updating the generated > > files. We seem to have already settled > > on autoconf 2.67 for generating the configure script, so my initial > > attempt threw up a huge number of changes > > as the system install is 2.69. I was able to get it down to > > something closer to what is expected by installing > > a local copy of 2.67 but it's still not perfect. I don't know why. > > I've never been a fan of including generated > > files for this reason. > > > > So this script also updates autogen.sh to see if there is an > > autoconf-2.67 available and use that in preference > > to autoconf if it is. I also added a little debug output so we can > > see which autoconf is being used in autogen.sh. > > > > If this is ok, can you please allocate it a bug ID and let me know > > which tree to commit it to. > > > > Thanks, > > > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From gnu.andrew at redhat.com Wed Mar 13 14:01:54 2013 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 13 Mar 2013 10:01:54 -0400 (EDT) Subject: Code Review Request: Simple new build system fix In-Reply-To: <5140811C.4060703@oracle.com> Message-ID: <1703838243.17946965.1363183314051.JavaMail.root@redhat.com> ----- Original Message ----- > Hello, > > I created a bug for you: > > 8009988: build-infra: Fix configure output for zip debuginfo check > > As David says, we haven't decided on 2.67, but I would guess that a > majority of the commits have been with that version. This change is a > first step towards enforcing a specific version and I'm ok with that. Yes, I've been out of the loop a bit on this new build system. When I saw the huge diff my first attempt generated, I just assumed I should be using the same version that had been used previously. > The actual fix looks good to. You will still need a JDK reviewer to > ok > it. Also, please notify me when you push this so that the closed > version > of the configure script may also be regenerated. > Ok, no problem. I await a review from someone like David or Kelly. Is there a preferred tree to push to? I spotted this when just trying to build so it's against jdk8 at the moment (which I obviously can't push to). Perhaps build? > /Erik > > On 2013-03-13 13:18, Andrew Hughes wrote: > > I've finally found time to look at the new build system (well, > > there seems to no longer be any choice ;) > > and so thought I start out with a simple fix. > > > > http://cr.openjdk.java.net/~andrew/build/zip_debug_info/webrev.01/ > > > > At the moment, if disable-zip-debug-info is not specified, the > > configure output is: > > > > checking if we should zip debug-info files... > > > > with no result as $enable_zip_debug_info is unset. > > > > This simple patch makes the option use the more standard > > AC_ARG_ENABLE form used elsewhere and will > > print the default ('yes') when the option is unspecified: > > > > checking if we should zip debug-info files... yes > > > > What actually took longer than the fix was updating the generated > > files. We seem to have already settled > > on autoconf 2.67 for generating the configure script, so my initial > > attempt threw up a huge number of changes > > as the system install is 2.69. I was able to get it down to > > something closer to what is expected by installing > > a local copy of 2.67 but it's still not perfect. I don't know why. > > I've never been a fan of including generated > > files for this reason. > > > > So this script also updates autogen.sh to see if there is an > > autoconf-2.67 available and use that in preference > > to autoconf if it is. I also added a little debug output so we can > > see which autoconf is being used in autogen.sh. > > > > If this is ok, can you please allocate it a bug ID and let me know > > which tree to commit it to. > > > > Thanks, > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From erik.joelsson at oracle.com Wed Mar 13 14:09:52 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 13 Mar 2013 15:09:52 +0100 Subject: Code Review Request: Simple new build system fix In-Reply-To: <1703838243.17946965.1363183314051.JavaMail.root@redhat.com> References: <1703838243.17946965.1363183314051.JavaMail.root@redhat.com> Message-ID: <514088B0.3080702@oracle.com> On 2013-03-13 15:01, Andrew Hughes wrote: > ----- Original Message ----- >> Hello, >> >> I created a bug for you: >> >> 8009988: build-infra: Fix configure output for zip debuginfo check >> >> As David says, we haven't decided on 2.67, but I would guess that a >> majority of the commits have been with that version. This change is a >> first step towards enforcing a specific version and I'm ok with that. > Yes, I've been out of the loop a bit on this new build system. > When I saw the huge diff my first attempt generated, I just assumed > I should be using the same version that had been used previously. > >> The actual fix looks good to. You will still need a JDK reviewer to >> ok >> it. Also, please notify me when you push this so that the closed >> version >> of the configure script may also be regenerated. >> > Ok, no problem. I await a review from someone like David or Kelly. > > Is there a preferred tree to push to? I spotted this when just trying > to build so it's against jdk8 at the moment (which I obviously can't push > to). Perhaps build? > Please use jdk8/build. /Erik >> /Erik >> >> On 2013-03-13 13:18, Andrew Hughes wrote: >>> I've finally found time to look at the new build system (well, >>> there seems to no longer be any choice ;) >>> and so thought I start out with a simple fix. >>> >>> http://cr.openjdk.java.net/~andrew/build/zip_debug_info/webrev.01/ >>> >>> At the moment, if disable-zip-debug-info is not specified, the >>> configure output is: >>> >>> checking if we should zip debug-info files... >>> >>> with no result as $enable_zip_debug_info is unset. >>> >>> This simple patch makes the option use the more standard >>> AC_ARG_ENABLE form used elsewhere and will >>> print the default ('yes') when the option is unspecified: >>> >>> checking if we should zip debug-info files... yes >>> >>> What actually took longer than the fix was updating the generated >>> files. We seem to have already settled >>> on autoconf 2.67 for generating the configure script, so my initial >>> attempt threw up a huge number of changes >>> as the system install is 2.69. I was able to get it down to >>> something closer to what is expected by installing >>> a local copy of 2.67 but it's still not perfect. I don't know why. >>> I've never been a fan of including generated >>> files for this reason. >>> >>> So this script also updates autogen.sh to see if there is an >>> autoconf-2.67 available and use that in preference >>> to autoconf if it is. I also added a little debug output so we can >>> see which autoconf is being used in autogen.sh. >>> >>> If this is ok, can you please allocate it a bug ID and let me know >>> which tree to commit it to. >>> >>> Thanks, From gnu.andrew at redhat.com Wed Mar 13 16:16:06 2013 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 13 Mar 2013 12:16:06 -0400 (EDT) Subject: Feedback on the New Build System In-Reply-To: <1461183806.18058801.1363190525156.JavaMail.root@redhat.com> Message-ID: <62528518.18066096.1363191366939.JavaMail.root@redhat.com> I've just got my first build out of the new system using the main jdk8/jdk8 tree (b80) and so thought it was worth giving some feedback on the problems encountered and issues with the end result: 1. It took some time to work out how to get back to the usual 'noisy' build as the default seems to subdue all the useful output. VERBOSE=true broke the build when it tried to use 'true' as a Makefile target. It turns out the solution is the rather non-obvious VERBOSE= . Could we not have this documented somewhere and perhaps have verbosity as a configure option? After grepping around, it's not very obvious to me where it gets set. 2. One of the javac calls in the jdk tree fails with: /home/andrew/projects/openjdk/upstream/jdk8/jdk/src/share/classes/javax/swing/JSpinner.java:43: error: package sun.util.locale.provider does not exist /home/andrew/projects/openjdk/upstream/jdk8/jdk/src/share/classes/javax/swing/JSpinner.java:44: error: package sun.util.locale.provider does not exist /home/andrew/projects/openjdk/upstream/jdk8/jdk/src/share/classes/javax/swing/JSpinner.java:45: error: package sun.util.locale.provider does not exist This package is in the jdk8 tree but not in the build JDK (7). Oddly, the build continues despite this error and the final rt.jar does include JSpinner. 3. -Werror is set for the SCTP native code causing the build to fail: Lots of stuff like: /home/andrew/projects/openjdk/upstream/jdk8/jdk/src/solaris/native/sun/nio/ch/sctp/SctpChannelImpl.c:88:24: error: unused parameter 'klass' [-Werror=unused-parameter] as -Werror is passed and -Wno-unused doesn't seem to turn these off. SCTP_WERROR= worked around it (perhaps this should at least be WARNINGS_ARE_ERRORS to match HotSpot?) Do we have a preferred way to fix these errors? I know about __unused__ but I believe this is GCC-specific and I wouldn't want to break the build on other platforms (Solaris, MacOS X, BSD). 4. It's odd that the default 'make' no longer means 'make all' and 'make' on its own doesn't produce a JDK image to use. This will be confusing for newcomers who miss that important 'all' word or people like me who go by the usual presumption that the default argument to make is 'all', but appears to have been subverted here. 5. The final image produces: openjdk version "1.8.0-internal" from -version. I can't remember whether or not the internal was there before and we suppressed it in IcedTea, but we've definitely always had 'java version' and not having this will break numerous applications (possibly including the JDK build, as I know at least the old one used to check the version). Hope this helps. I'm happy to produce patches for some of these issues, but wanted to discuss the best way forward first. Thanks, -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From omajid at redhat.com Wed Mar 13 17:39:22 2013 From: omajid at redhat.com (Omair Majid) Date: Wed, 13 Mar 2013 13:39:22 -0400 Subject: Feedback on the New Build System In-Reply-To: <62528518.18066096.1363191366939.JavaMail.root@redhat.com> References: <62528518.18066096.1363191366939.JavaMail.root@redhat.com> Message-ID: <5140B9CA.2030407@redhat.com> On 03/13/2013 12:16 PM, Andrew Hughes wrote: > 1. It took some time to work out how to get back to the usual 'noisy' build as the > default seems to subdue all the useful output. VERBOSE=true broke the build when > it tried to use 'true' as a Makefile target. It turns out the solution is the rather > non-obvious VERBOSE= . Could we not have this documented somewhere and perhaps have > verbosity as a configure option? After grepping around, it's not very obvious to me > where it gets set. I ran into this problem as well. I asked on #openjdk and Mike Duigou pointed me to "LOG=trace", which is documented in the build README FAQ [1], although a little hard to find. Cheers, Omair [1] http://hg.openjdk.java.net/jdk8/jdk8/raw-file/tip/README-builds.html#faq -- PGP Key: 66484681 (http://pgp.mit.edu/) Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 From gnu.andrew at redhat.com Wed Mar 13 18:35:09 2013 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 13 Mar 2013 14:35:09 -0400 (EDT) Subject: Feedback on the New Build System In-Reply-To: <5140B9CA.2030407@redhat.com> Message-ID: <1566907415.18160057.1363199709926.JavaMail.root@redhat.com> ----- Original Message ----- > On 03/13/2013 12:16 PM, Andrew Hughes wrote: > > 1. It took some time to work out how to get back to the usual > > 'noisy' build as the > > default seems to subdue all the useful output. VERBOSE=true broke > > the build when > > it tried to use 'true' as a Makefile target. It turns out the > > solution is the rather > > non-obvious VERBOSE= . Could we not have this documented somewhere > > and perhaps have > > verbosity as a configure option? After grepping around, it's not > > very obvious to me > > where it gets set. > > I ran into this problem as well. I asked on #openjdk and Mike Duigou > pointed me to "LOG=trace", which is documented in the build README > FAQ > [1], although a little hard to find. > Thanks! Ah, I read that document and even that FAQ, but completely missed that as I was looking for something relating to verbosity, not logging which implies (at least to me) that a log will be stored on disk. I still think it should be a configure option, which is the first place I looked. It seems there's still a need to make some options available via configure which are currently only available to make. > Cheers, > Omair > > [1] > http://hg.openjdk.java.net/jdk8/jdk8/raw-file/tip/README-builds.html#faq > > -- > PGP Key: 66484681 (http://pgp.mit.edu/) > Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From dalibor.topic at oracle.com Wed Mar 13 19:06:14 2013 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Wed, 13 Mar 2013 20:06:14 +0100 Subject: Feedback on the New Build System In-Reply-To: <1566907415.18160057.1363199709926.JavaMail.root@redhat.com> References: <1566907415.18160057.1363199709926.JavaMail.root@redhat.com> Message-ID: <5140CE26.3080809@oracle.com> On 3/13/13 7:35 PM, Andrew Hughes wrote: > I still think it should be a configure option, which is the first place I looked. You'd usually use it if something interesting happens, like a build failure, and it's a you're 'not sure how it could have come to this' situation, so in that case, having to re-run configure, and potentially the whole build again seems like a worse option then just adding a variable to the make run as you need it (or not). cheers, dalibor topic -- Oracle Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 Oracle Java Platform Group ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Gesch?ftsf?hrer: J?rgen Kunz Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher Green Oracle Oracle is committed to developing practices and products that help protect the environment From mike.duigou at oracle.com Wed Mar 13 19:18:23 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Wed, 13 Mar 2013 12:18:23 -0700 Subject: Feedback on the New Build System In-Reply-To: <5140CE26.3080809@oracle.com> References: <1566907415.18160057.1363199709926.JavaMail.root@redhat.com> <5140CE26.3080809@oracle.com> Message-ID: <7DE54217-7121-4626-8D39-86FDD8B7578A@oracle.com> I generally agree that logging is something I want to tune dynamically. Logging is one of the few things I prefer as an environment variable. As a compromise though perhaps a configure option to adjust the default logging level might work. Still overridable via LOG but with a configurable default. The help documentation could/should also be improved to document "Environment variables which can effect configuration" and "Environment variables which can effect build". These do need to be described separately even if there are some which apply to both. Mike On Mar 13 2013, at 12:06 , Dalibor Topic wrote: > On 3/13/13 7:35 PM, Andrew Hughes wrote: >> I still think it should be a configure option, which is the first place I looked. > > You'd usually use it if something interesting happens, like a build failure, and > it's a you're 'not sure how it could have come to this' situation, so in that case, > having to re-run configure, and potentially the whole build again seems like a worse > option then just adding a variable to the make run as you need it (or not). > > cheers, > dalibor topic > > -- > Oracle > Dalibor Topic | Principal Product Manager > Phone: +494089091214 | Mobile: +491737185961 > Oracle Java Platform Group > > ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg > > ORACLE Deutschland B.V. & Co. KG > Hauptverwaltung: Riesstr. 25, D-80992 M?nchen > Registergericht: Amtsgericht M?nchen, HRA 95603 > Gesch?ftsf?hrer: J?rgen Kunz > > Komplement?rin: ORACLE Deutschland Verwaltung B.V. > Hertogswetering 163/167, 3543 AS Utrecht, Niederlande > Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 > Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher > > Green Oracle Oracle is committed to developing practices and products that help protect the environment From mike.duigou at oracle.com Wed Mar 13 19:22:29 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Wed, 13 Mar 2013 12:22:29 -0700 Subject: Feedback on the New Build System In-Reply-To: <7DE54217-7121-4626-8D39-86FDD8B7578A@oracle.com> References: <1566907415.18160057.1363199709926.JavaMail.root@redhat.com> <5140CE26.3080809@oracle.com> <7DE54217-7121-4626-8D39-86FDD8B7578A@oracle.com> Message-ID: <1F95BB4A-936C-413F-850F-4FB06EEEADAB@oracle.com> Ugh. effect -> affect. An unforgivable mistake. Mike On Mar 13 2013, at 12:18 , Mike Duigou wrote: > I generally agree that logging is something I want to tune dynamically. Logging is one of the few things I prefer as an environment variable. > > As a compromise though perhaps a configure option to adjust the default logging level might work. Still overridable via LOG but with a configurable default. > > The help documentation could/should also be improved to document "Environment variables which can effect configuration" and "Environment variables which can effect build". These do need to be described separately even if there are some which apply to both. > > Mike > > > On Mar 13 2013, at 12:06 , Dalibor Topic wrote: > >> On 3/13/13 7:35 PM, Andrew Hughes wrote: >>> I still think it should be a configure option, which is the first place I looked. >> >> You'd usually use it if something interesting happens, like a build failure, and >> it's a you're 'not sure how it could have come to this' situation, so in that case, >> having to re-run configure, and potentially the whole build again seems like a worse >> option then just adding a variable to the make run as you need it (or not). >> >> cheers, >> dalibor topic >> >> -- >> Oracle >> Dalibor Topic | Principal Product Manager >> Phone: +494089091214 | Mobile: +491737185961 >> Oracle Java Platform Group >> >> ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg >> >> ORACLE Deutschland B.V. & Co. KG >> Hauptverwaltung: Riesstr. 25, D-80992 M?nchen >> Registergericht: Amtsgericht M?nchen, HRA 95603 >> Gesch?ftsf?hrer: J?rgen Kunz >> >> Komplement?rin: ORACLE Deutschland Verwaltung B.V. >> Hertogswetering 163/167, 3543 AS Utrecht, Niederlande >> Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 >> Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher >> >> Green Oracle Oracle is committed to developing practices and products that help protect the environment > From gnu.andrew at redhat.com Wed Mar 13 19:11:59 2013 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 13 Mar 2013 15:11:59 -0400 (EDT) Subject: Feedback on the New Build System In-Reply-To: <5140CE26.3080809@oracle.com> Message-ID: <751822536.18180781.1363201919264.JavaMail.root@redhat.com> ----- Original Message ----- > On 3/13/13 7:35 PM, Andrew Hughes wrote: > > I still think it should be a configure option, which is the first > > place I looked. > > You'd usually use it if something interesting happens, like a build > failure, and > it's a you're 'not sure how it could have come to this' situation, so > in that case, > having to re-run configure, and potentially the whole build again > seems like a worse > option then just adding a variable to the make run as you need it (or > not). > I wasn't suggesting that we replace one with the other, just that configure could be used to pass a setting through to make if requested. It also then means that all the options are documented in one place (./configure --help) rather than some being there, some only in the build README, some not at all, etc. I prefer to run with it always enabled and it worries me that this is no longer the default. It's very easy to suppress information when you don't want it, but it's impossible to produce it if it never existed in the first place. The very people who most need verbose output, when things go wrong, are going to be newbies who won't be aware of this option. Also, failures may be sporadic and not reproducible when you run make again and many of our builds run on remote build systems where it's not a simple case of 'just running make again' to get the output with verbosity. > cheers, > dalibor topic > > -- > Oracle > Dalibor Topic | Principal Product Manager > Phone: +494089091214 | Mobile: +491737185961 > > Oracle Java Platform Group > > ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg > > ORACLE Deutschland B.V. & Co. KG > Hauptverwaltung: Riesstr. 25, D-80992 M?nchen > Registergericht: Amtsgericht M?nchen, HRA 95603 > Gesch?ftsf?hrer: J?rgen Kunz > > Komplement?rin: ORACLE Deutschland Verwaltung B.V. > Hertogswetering 163/167, 3543 AS Utrecht, Niederlande > Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 > Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher > > Green Oracle Oracle is committed > to developing practices and products that help protect the > environment > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From omajid at redhat.com Wed Mar 13 20:09:23 2013 From: omajid at redhat.com (Omair Majid) Date: Wed, 13 Mar 2013 16:09:23 -0400 Subject: Allow configure to detect if EC implementation is present Message-ID: <5140DCF3.8020808@redhat.com> Hi, jdk/makefiles/CompileNativeLibraries.gmk has a little note: TODO Set DISABLE_INTREE_EC in configure if src/share/native/sun/security/ec/impl is not present The webrev at http://cr.openjdk.java.net/~omajid/webrevs/intree-ec/00/ implements this. Does this look okay for jdk8/build ? Can I get a bug id? Thanks, Omair -- PGP Key: 66484681 (http://pgp.mit.edu/) Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 From gnu.andrew at redhat.com Wed Mar 13 20:34:01 2013 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 13 Mar 2013 16:34:01 -0400 (EDT) Subject: Allow configure to detect if EC implementation is present In-Reply-To: <5140DCF3.8020808@redhat.com> Message-ID: <1481407924.18210579.1363206841281.JavaMail.root@redhat.com> ----- Original Message ----- > Hi, > > jdk/makefiles/CompileNativeLibraries.gmk has a little note: > > TODO Set DISABLE_INTREE_EC in configure if > src/share/native/sun/security/ec/impl is not present > > The webrev at > http://cr.openjdk.java.net/~omajid/webrevs/intree-ec/00/ > implements this. Does this look okay for jdk8/build ? Can I get a bug > id? > This looks okay to me. So I can review it... But I can't give you a bug ID :-( > Thanks, > Omair > > -- > PGP Key: 66484681 (http://pgp.mit.edu/) > Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From david.holmes at oracle.com Wed Mar 13 22:13:08 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 14 Mar 2013 08:13:08 +1000 Subject: Code Review Request: Simple new build system fix In-Reply-To: <385440755.17944109.1363183101615.JavaMail.root@redhat.com> References: <385440755.17944109.1363183101615.JavaMail.root@redhat.com> Message-ID: <5140F9F4.7050502@oracle.com> On 13/03/2013 11:58 PM, Andrew Hughes wrote: > ----- Original Message ----- >> Andrew, >> >> FWIW we are not tied to autoconf 2.67. There have already been a >> number >> of pushes using 2.68 and now 2.69 is also showing up. >> > > Yes, Omair was kind enough to point me to this changeset which indeed > uses 2.68: > > http://hg.openjdk.java.net/jdk8/build/rev/145dbc56f931 > > It would be nice to settle on one version though, if the generated file is > going to be checked into the repository, otherwise everyone who has a different > version installed is going to make lots of spurious changes to that file which > obscure the real change. FWIW I rarely pay any attention to the actual generated-configure.sh in doing a review. I only look at the changes to the m4 files etc. There's just too much noise. Any cross-platform build issues will be readily detected, and it's not likely the issues would be recognizable from the source code. Fixing on one version is a problem when so many different machines can be involved in doing the builds. I have 2.68, no matter how I tried I couldn't get it to use the 2.67 that I had installed privately/locally - so I gave up. David ----- > FWIW, gcc also includes the configure file in its Subversion repository and a specific > version is used to update it. > >> David >> >> On 13/03/2013 10:18 PM, Andrew Hughes wrote: >>> I've finally found time to look at the new build system (well, >>> there seems to no longer be any choice ;) >>> and so thought I start out with a simple fix. >>> >>> http://cr.openjdk.java.net/~andrew/build/zip_debug_info/webrev.01/ >>> >>> At the moment, if disable-zip-debug-info is not specified, the >>> configure output is: >>> >>> checking if we should zip debug-info files... >>> >>> with no result as $enable_zip_debug_info is unset. >>> >>> This simple patch makes the option use the more standard >>> AC_ARG_ENABLE form used elsewhere and will >>> print the default ('yes') when the option is unspecified: >>> >>> checking if we should zip debug-info files... yes >>> >>> What actually took longer than the fix was updating the generated >>> files. We seem to have already settled >>> on autoconf 2.67 for generating the configure script, so my initial >>> attempt threw up a huge number of changes >>> as the system install is 2.69. I was able to get it down to >>> something closer to what is expected by installing >>> a local copy of 2.67 but it's still not perfect. I don't know why. >>> I've never been a fan of including generated >>> files for this reason. >>> >>> So this script also updates autogen.sh to see if there is an >>> autoconf-2.67 available and use that in preference >>> to autoconf if it is. I also added a little debug output so we can >>> see which autoconf is being used in autogen.sh. >>> >>> If this is ok, can you please allocate it a bug ID and let me know >>> which tree to commit it to. >>> >>> Thanks, >>> >> > From christian.thalinger at oracle.com Wed Mar 13 23:44:29 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 13 Mar 2013 16:44:29 -0700 Subject: RFR (S): 8006965: test_gamma should run with import JDK In-Reply-To: References: <645283DC-655E-4FA7-A0EA-676D08559F5B@oracle.com> <8CF27CFE-174B-44BA-ABAE-52D3D931DFBF@oracle.com> <512A9A3F.4070402@oracle.com> <6FD71E10-9866-42F5-8201-60FB237AD988@oracle.com> <512C632B.3070206@oracle.com> Message-ID: On Feb 26, 2013, at 6:09 PM, Christian Thalinger wrote: > > On Feb 25, 2013, at 11:24 PM, David Holmes wrote: > >> On 26/02/2013 4:42 AM, Christian Thalinger wrote: >>> On Feb 24, 2013, at 2:54 PM, David Holmes wrote: >>>> On 23/02/2013 1:55 PM, Christian Thalinger wrote: >>>>> I talked to a lot of people about this today. What we really want is to not run tests when we build. Mikael and I were looking into how we could do that without gamma and there is a way: >>>>> >>>>> http://cr.openjdk.java.net/~twisti/8006965/ >>>>> >>>>> This would be the first of three fixes: >>>>> >>>>> Fix 1) The patch above removes test_gamma and uses some weirdness in the VM (-Dsun.java.launcher=gamma) to run it with an existing JDK; add test_{product,fastdebug,debug} targets >>>> >>>> This logic is not suitable: >>>> >>>> 541 # Testing the built JVM >>>> 542 ifeq ($(JAVA_HOME),) >>>> 543 RUN_JVM=JAVA_HOME=$(JDK_IMPORT_PATH) $(JDK_IMPORT_PATH)/bin/java -d$(ARCH_DATA_MODEL) -server -XXaltjvm=$(MISC_DIR)/$(VM_FLAVOR) -Dsun.java.launcher=gamma >>>> 544 else >>>> 545 RUN_JVM=$(JAVA_HOME)/bin/java -d$(ARCH_DATA_MODEL) -server -XXaltjvm=$(MISC_DIR)/$(VM_FLAVOR) -Dsun.java.launcher=gamma >>>> 546 endif >>>> >>>> I have JAVA_HOME set in my environment for use by other tools/scripts and it points at JDK7. The existing logic does not use my environments JAVA_HOME setting so neither should the revised logic! >>> >>> That's not entirely correct. test_gamma uses your JAVA_HOME setting: >> >> This is so confusing. Our makefiles are an abomination! > > I couldn't agree more. > >> >> So this all started because the makefile has: >> >> JAVA_HOME=$(ABS_BOOTDIR) >> >> which was flagged as wrong because gamma would run in the boot JDK. But now it seems the make variable JAVA_HOME is irrelevant anyway because the test_gamma script will use the JAVA_HOME environment variable. >> >> So how did the boot JDK come back into this??? >> >>> cthaling at sc14a501:/export/twisti/build/graal/build/linux_amd64_compiler2/product$ export JAVA_HOME=/java/re/jdk/8/latest/binaries/linux-x64 >>> cthaling at sc14a501:/export/twisti/build/graal/build/linux_amd64_compiler2/product$ ./test_gamma >>> Using java runtime at: /java/re/jdk/8/latest/binaries/linux-x64/jre >>> >>> cthaling at sc14a501:/export/twisti/build/graal/build/linux_amd64_compiler2/product$ export JAVA_HOME=/foo >>> cthaling at sc14a501:/export/twisti/build/graal/build/linux_amd64_compiler2/product$ ./test_gamma >>> JAVA_HOME must point to a 64-bit OpenJDK. >>> >>> And here comes this little snippet into play: >>> >>> -MAKE_ARGS += JAVA_HOME=$(ABS_BOOTDIR) >>> +MAKE_ARGS += BOOTDIR=$(ABS_BOOTDIR) >>> >>> Only setting JAVA_HOME to ABS_BOOTDIR make test_gamma work even if you have a JAVA_HOME set. >> >> I still don't get this. What has BOOTDIR got to do with JAVA_HOME? Where is this BOOTDIR value being used? Ha! I can remember. It's used by jmvti.make (implicitly). The logic in rules.make is: ifdef ALT_BOOTDIR COMPILE.JAVAC = $(ALT_BOOTDIR)/bin/javac else ifdef BOOTDIR COMPILE.JAVAC = $(BOOTDIR)/bin/javac else ifdef JAVA_HOME else endif endif endif BOOTDIR is not defined in rules.make and JAVA_HOME is picked up (which is set to ABS_BOOTDIR). This all sucks and needs to be replaced by something completely different. Soon. -- Chris >> There is no use of it in http://cr.openjdk.java.net/~twisti/8006965/8006965.patch and I don't see it pre-existing ?? > > I talked to John Coomes about that yesterday and we can remove that line. ABS_BOOTDIR is only used by Windows. > > -- Chris > >> >> Thanks, >> David >> >>> I have added this logic so that users can control what JDK is used when running the test. In fact they should use ALT_JDK_IMPORT_PATH if they want to control that. >>> >>>> >>>> I also don't see why the above sets JAVA_HOME at #543 - what will read that environment variable? >>> >>> It's the odd logic in os::jvm_path guarded by Arguments::created_by_gamma_launcher(). A clean-up of that logic would be part of Fix 3. >>> >>>> >>>> I still have concerns over what JDK_IMPORT_PATH will point to for different JDK builders. >>> >>> It's either JDK_IMPORT_PATH or JDK_IMAGE_DIR. Since most people don't want to export their libjvm into a JDK we have to use JDK_IMPORT_PATH. We could add some logic that checks if JDK_IMAGE_DIR exists and use that one. >>> >>> -- Chris >>> >>>> >>>> And this addition still makes no sense to me: >>>> >>>> MAKE_ARGS += BOOTDIR=$(ABS_BOOTDIR) >>>> >>>> Why do you need to add BOOTDIR to the MAKE_ARGS? >>>> >>>> David >>>> >>>> >>>>> Fix 2) Remove gamma and all the ugly code that comes with it (copies of the jdk launcher in hotspot and other pieces); make the hotspot script work like the test targets in Fix 1 >>>>> >>>>> Fix 3) Remove the -Dsun.java.launcher=gamma and possibly replace the existing -Dsun.boot.library.path weirdness by explicit command line options like -Xbootlibrarypath:{/p,/a} >>>>> >>>>> -- Chris >>>>> >>>>> On Feb 22, 2013, at 3:21 PM, Christian Thalinger wrote: >>>>> >>>>>> >>>>>> On Feb 22, 2013, at 12:58 AM, Staffan Larsen wrote: >>>>>> >>>>>>> I'm not sure what the correct solution is, but when you do find out, the jdkpath.sh target should also be updated. >>>>>> >>>>>> How many are actually using the hotspot script? Would people be very sentimental if we would remove the gamma launcher altogether? >>>>>> >>>>>> Taking to people here it seems that most are copying their libjvm into a JDK and use java anyway. >>>>>> >>>>>> -- Chris >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> /Staffan >>>>>>> >>>>>>> On 22 feb 2013, at 03:40, Christian Thalinger wrote: >>>>>>> >>>>>>>> http://cr.openjdk.java.net/~twisti/8006965 >>>>>>>> >>>>>>>> 8006965: test_gamma should run with import JDK >>>>>>>> Reviewed-by: >>>>>>>> >>>>>>>> Right now test_gamma runs with the boot JDK which is JDK n-1 (where >>>>>>>> JDK n is the version we are actually compiling for). This setup is >>>>>>>> unsupported and thus should not be done during HotSpot builds. >>>>>>>> >>>>>>>> The fix is to always use JDK_IMPORT_PATH instead of JAVA_HOME when >>>>>>>> running test_gamma. >>>>>>>> >>>>>>>> make/bsd/makefiles/buildtree.make >>>>>>>> make/defs.make >>>>>>>> make/linux/makefiles/buildtree.make >>>>>>>> make/solaris/makefiles/buildtree.make >>>>>>>> >>>>>>> >>>>>> >>>>> >>> > From david.holmes at oracle.com Thu Mar 14 01:26:38 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 14 Mar 2013 11:26:38 +1000 Subject: Feedback on the New Build System In-Reply-To: <62528518.18066096.1363191366939.JavaMail.root@redhat.com> References: <62528518.18066096.1363191366939.JavaMail.root@redhat.com> Message-ID: <5141274E.8060805@oracle.com> Hi Andrew, On 14/03/2013 2:16 AM, Andrew Hughes wrote: > I've just got my first build out of the new system using the main jdk8/jdk8 tree (b80) and > so thought it was worth giving some feedback on the problems encountered and issues > with the end result: > > 1. It took some time to work out how to get back to the usual 'noisy' build as the > default seems to subdue all the useful output. VERBOSE=true broke the build when > it tried to use 'true' as a Makefile target. It turns out the solution is the rather > non-obvious VERBOSE= . Could we not have this documented somewhere and perhaps have > verbosity as a configure option? After grepping around, it's not very obvious to me > where it gets set. This has already been covered with LOG=trace (or DEBUG) but note that it is actually logged to disk - the output (regardless of the log level) goes to build.log in the configuration directory (by default). > 2. One of the javac calls in the jdk tree fails with: > > /home/andrew/projects/openjdk/upstream/jdk8/jdk/src/share/classes/javax/swing/JSpinner.java:43: error: package sun.util.locale.provider does not exist > /home/andrew/projects/openjdk/upstream/jdk8/jdk/src/share/classes/javax/swing/JSpinner.java:44: error: package sun.util.locale.provider does not exist > /home/andrew/projects/openjdk/upstream/jdk8/jdk/src/share/classes/javax/swing/JSpinner.java:45: error: package sun.util.locale.provider does not exist > > This package is in the jdk8 tree but not in the build JDK (7). Oddly, the build > continues despite this error and the final rt.jar does include JSpinner. I think this is actually a javadoc call (hence the non-fatal nature of the error). But it is very hard to associate the message with any given command due to all the interleaving (at least in my build). :( > 3. -Werror is set for the SCTP native code causing the build to fail: > > Lots of stuff like: > > /home/andrew/projects/openjdk/upstream/jdk8/jdk/src/solaris/native/sun/nio/ch/sctp/SctpChannelImpl.c:88:24: error: unused parameter 'klass' [-Werror=unused-parameter] > > as -Werror is passed and -Wno-unused doesn't seem to turn these off. SCTP_WERROR= > worked around it (perhaps this should at least be WARNINGS_ARE_ERRORS to match HotSpot?) > > Do we have a preferred way to fix these errors? I know about __unused__ but I believe this > is GCC-specific and I wouldn't want to break the build on other platforms (Solaris, MacOS X, BSD). What gcc version are you using? I don't see this with 4.6. Probably best to take this up with nio-dev folk. > 4. It's odd that the default 'make' no longer means 'make all' and 'make' on its own doesn't produce > a JDK image to use. This will be confusing for newcomers who miss that important 'all' word or people > like me who go by the usual presumption that the default argument to make is 'all', but appears to have > been subverted here. This is odd. The top-level Makefile in the forest has: default: all but the generated Makefile in the configuration directory simply includes NewMakefile.gmk which has # This must be the first rule default: I always use the generated Makefile as the entry point but then I never rely on default targets anyway. But this certainly is confusing. > 5. The final image produces: > > openjdk version "1.8.0-internal" > > from -version. I can't remember whether or not the internal was there before and we suppressed it in IcedTea, > but we've definitely always had 'java version' and not having this will break numerous applications (possibly > including the JDK build, as I know at least the old one used to check the version). Is this an old-build vs new-build issue or a 7 vs 8 issue? The default version information comes from files in the forest: ./common/autoconf/version-numbers JDK_MAJOR_VERSION=1 JDK_MINOR_VERSION=8 JDK_MICRO_VERSION=0 JDK_UPDATE_VERSION= LAUNCHER_NAME=openjdk PRODUCT_NAME=OpenJDK PRODUCT_SUFFIX="Runtime Environment" JDK_RC_PLATFORM_NAME=Platform COMPANY_NAME=N/A # Might need better names for these MACOSX_BUNDLE_NAME_BASE="OpenJDK" MACOSX_BUNDLE_ID_BASE="net.java.openjdk" Thanks, David > Hope this helps. I'm happy to produce patches for some of these issues, but wanted to discuss the best way > forward first. > > Thanks, > From jonathan.gibbons at oracle.com Thu Mar 14 01:43:03 2013 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 13 Mar 2013 18:43:03 -0700 Subject: RFR: 8009428 and 8009429 - Profile related fixes and clean ups In-Reply-To: <513D3257.2030801@oracle.com> References: <51394373.4040404@oracle.com> <5139AD05.1060208@oracle.com> <5139CB49.5000601@oracle.com> <513D3257.2030801@oracle.com> Message-ID: <51412B27.2070907@oracle.com> The langtools changes look OK to me. -- Jon On 03/10/2013 06:24 PM, David Holmes wrote: > I had overlooked the need to update the ct.sym creation tool to > recognize the new syntax in the profile spec file. That process also > uncovered a few bugs in the listing that needed correcting. > > The javadoc generation of compact profile information is not quite > right, but that will be handled in a seperate bug. > > Updated webrevs at: > > http://cr.openjdk.java.net/~dholmes/8009428_8009429.v2/ > > --- > > http://cr.openjdk.java.net/~dholmes/8009428_8009429.v2/webrev.root/ > > No change from v1. Simply reverses the Nashorn change to $ processing. > > --- > > http://cr.openjdk.java.net/~dholmes/8009428_8009429.v2/webrev.langtools/ > > Updated the logic to look for FULL_JRE instead of PROFILE_4. And as a > result of that needed to make the logic explicitly aware that there > are 3 compact profiles plus the full JRE. > > --- > > http://cr.openjdk.java.net/~dholmes/8009428_8009429.v2/webrev.jdk/ > > Changes from v1: > > - I stopped trying to use a new wildcard syntax for included/excluded > types. The only options are *.class else a full type name with $ > replaced by $$. (The wildcard support would need more extensive > changes to the ct.sym tool and for 4 classes it isn't worth it). > > - Types explicitly excluded from one profile must be explicitly > included in a higher one (or the full JRE). (This happened to work by > accident because we were dealing with compact3 and a full JRE). > > - The package sun/beans no longer exists > > - Fixed up include packages to capture new types ie jdk instead of > jdk/internal so that we include the jdk.Supported annotation class > > - Removed additional redundant sub-packages > > Thanks for the follow up reviews. Erik's review stands as no further > changes made to the actual build logic. > > David > ----- > > On 8/03/2013 9:28 PM, David Holmes wrote: >> On 8/03/2013 7:19 PM, Alan Bateman wrote: >>> On 08/03/2013 01:48, David Holmes wrote: >>>> Not sure which is best list for this given Alan will likely be the >>>> only reviewer anyway :) >>>> >>>> Webrevs under: >>>> >>>> http://cr.openjdk.java.net/~dholmes/8009428_8009429/ >>> As further background to others, the reverting of the $ substitution >>> became possible when Nashorn removed $ from its generated classes [1]. >>> >>> I've looked through the changes and they look really good to me. >>> Putting >>> $< in single quotes to avoid shell expansion is the solution that I >>> could not find when adding the de-beaning recipes a few months ago. >>> It's >>> great to see PROFILE_4 renamed to FULL_JRE and is also great to remove >>> the redundant sub-packages from the include lists. For >>> profiles-rtjar-includes then I think it makes it much more readable and >>> maintainable. Two minor inconsistencies: the sub-packages of >>> javax.naming are listed and com/sun/jndi/ has a trailing slash. >> >> Fixed - well spotted! >> >>> One probable side effect of removing the redundant sub-packages will be >>> the javadoc. The one case to date where we didn't list sub-packages is >>> java.time (because there are still changes going on there) and that the >>> result is that the sub-packages of java.time don't show up in the >>> profiles view. I created 8008367 a few weeks for that and I suspect >>> that >>> once these changes are pushed that the profiles view will be very >>> incomplete. I don't think this should be a reason to hold off your >>> changes as the profiles view isn't right now anyway. Hopefully Bhavesh >>> will get to this soon. >> >> Now I'm a little concerned. I had not considered whether javac/javadoc >> considered these to be complete lists. They have to know how to combine >> the includes at a low-level with the excludes of a higher-level - and >> potentially vice-versa. >> >>> I think Erik should review this too as it's important that the build >>> changes in jdk8/tl will merge easily with changes going into >>> jdk8/build. >> >> OK. >> >> Thanks, >> David >> >>> -Alan. >>> >>> [1] http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/fe5211fc3114 From david.holmes at oracle.com Thu Mar 14 02:02:02 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 14 Mar 2013 12:02:02 +1000 Subject: Allow configure to detect if EC implementation is present In-Reply-To: <5140DCF3.8020808@redhat.com> References: <5140DCF3.8020808@redhat.com> Message-ID: <51412F9A.4020309@oracle.com> On 14/03/2013 6:09 AM, Omair Majid wrote: > Hi, > > jdk/makefiles/CompileNativeLibraries.gmk has a little note: > > TODO Set DISABLE_INTREE_EC in configure if > src/share/native/sun/security/ec/impl is not present > > The webrev at http://cr.openjdk.java.net/~omajid/webrevs/intree-ec/00/ > implements this. Does this look okay for jdk8/build ? Can I get a bug id? Bug ID: 8010030 I think it is more consistent to set the variable to yes/no and change: ifndef DISABLE_INTREE_EC to ifeq ($DISABLE_INTREE_EC), yes) Thanks, David > Thanks, > Omair > From bradford.wetmore at oracle.com Thu Mar 14 04:38:14 2013 From: bradford.wetmore at oracle.com (Brad Wetmore) Date: Wed, 13 Mar 2013 21:38:14 -0700 Subject: Allow configure to detect if EC implementation is present In-Reply-To: <51412F9A.4020309@oracle.com> References: <5140DCF3.8020808@redhat.com> <51412F9A.4020309@oracle.com> Message-ID: <51415436.9020404@oracle.com> CC'ing security-dev. Vinnie, As owner of ECC, you should probably look at this. Brad On 3/13/2013 7:02 PM, David Holmes wrote: > On 14/03/2013 6:09 AM, Omair Majid wrote: >> Hi, >> >> jdk/makefiles/CompileNativeLibraries.gmk has a little note: >> >> TODO Set DISABLE_INTREE_EC in configure if >> src/share/native/sun/security/ec/impl is not present >> >> The webrev at http://cr.openjdk.java.net/~omajid/webrevs/intree-ec/00/ >> implements this. Does this look okay for jdk8/build ? Can I get a bug id? > > Bug ID: 8010030 > > I think it is more consistent to set the variable to yes/no and change: > > ifndef DISABLE_INTREE_EC > > to > > ifeq ($DISABLE_INTREE_EC), yes) > > Thanks, > David > > > >> Thanks, >> Omair >> From david.holmes at oracle.com Thu Mar 14 05:12:26 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 14 Mar 2013 15:12:26 +1000 Subject: Allow configure to detect if EC implementation is present In-Reply-To: <51415436.9020404@oracle.com> References: <5140DCF3.8020808@redhat.com> <51412F9A.4020309@oracle.com> <51415436.9020404@oracle.com> Message-ID: <51415C3A.6030304@oracle.com> Note that this isn't changing any functionality simply exposing an existing make variable at configure time. David On 14/03/2013 2:38 PM, Brad Wetmore wrote: > CC'ing security-dev. > > Vinnie, > > As owner of ECC, you should probably look at this. > > Brad > > > On 3/13/2013 7:02 PM, David Holmes wrote: >> On 14/03/2013 6:09 AM, Omair Majid wrote: >>> Hi, >>> >>> jdk/makefiles/CompileNativeLibraries.gmk has a little note: >>> >>> TODO Set DISABLE_INTREE_EC in configure if >>> src/share/native/sun/security/ec/impl is not present >>> >>> The webrev at http://cr.openjdk.java.net/~omajid/webrevs/intree-ec/00/ >>> implements this. Does this look okay for jdk8/build ? Can I get a bug >>> id? >> >> Bug ID: 8010030 >> >> I think it is more consistent to set the variable to yes/no and change: >> >> ifndef DISABLE_INTREE_EC >> >> to >> >> ifeq ($DISABLE_INTREE_EC), yes) >> >> Thanks, >> David >> >> >> >>> Thanks, >>> Omair >>> From david.holmes at oracle.com Thu Mar 14 05:36:19 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 14 Mar 2013 15:36:19 +1000 Subject: RFR: 8009428 and 8009429 - Profile related fixes and clean ups In-Reply-To: <513EFDCD.4040309@oracle.com> References: <51394373.4040404@oracle.com> <5139AD05.1060208@oracle.com> <5139CB49.5000601@oracle.com> <513D3257.2030801@oracle.com> <513D9BD1.6060807@oracle.com> <513ED503.6040000@oracle.com> <513EFDCD.4040309@oracle.com> Message-ID: <514161D3.9050601@oracle.com> Hi Alan, On 12/03/2013 8:05 PM, Alan Bateman wrote: > On 12/03/2013 07:10, David Holmes wrote: >> : >> >>> For the intro comment in profile-rtjar-includes.txt then it might be >>> useful to beef up the comment to explain what happens when an API >>> package does not match one of the rules, ie: does it go into compact1, >>> only the full JRE, or none. Also make it explicit that the form >>> DialogCallbackHandler*.class should not be used. I suggest this for the >>> benefit of someone needing to tweak this in the future. >> >> I have updated the webrev with additional commentary. > Thanks, that will be very useful to future maintainers. > >> >>> I have played with com.sun.tools.javac.sym.Profiles and so the changes >>> to MakefileProfiles look okay to me but Jon should really be the >>> reviewer for this. One thing about maxProfiles is that it should match >>> Profile.values.length maybe maxProfiles should not be hardcoded to 4. >> >> Sorry but what is Profiles.values.length? Previously we inferred the >> number of profiles from the fact that we failed to find PROFILE_n for >> some value n. That can't work (easily) now hence the hard limit. > I meant com.sun.tools.javac.jvm.Profile, it's an enum of the profiles so > it means that the knowledge about 3 + full JRE is now in two places. I decided not to do this because it turns out that "4" is hardwired within the internal debugging code of this class anyway. I'll file a RFE to clean this up in conjunction with the additional testing you mention below. Thanks, David > >> >>> Another thing is whether to add a test or beef up an existing test >>> (ProfileOptionTest.java in particular). >> >> What exactly is it that you would like to test for? > I think the test should include a few cases to cover a few selected > types in sub-packages to make sure they are in the right profile. > > -Alan. > > From Alan.Bateman at oracle.com Thu Mar 14 08:58:49 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 14 Mar 2013 08:58:49 +0000 Subject: Feedback on the New Build System In-Reply-To: <5141274E.8060805@oracle.com> References: <62528518.18066096.1363191366939.JavaMail.root@redhat.com> <5141274E.8060805@oracle.com> Message-ID: <51419149.2070204@oracle.com> On 14/03/2013 01:26, David Holmes wrote: > : > >> 3. -Werror is set for the SCTP native code causing the build to fail: >> >> Lots of stuff like: >> >> /home/andrew/projects/openjdk/upstream/jdk8/jdk/src/solaris/native/sun/nio/ch/sctp/SctpChannelImpl.c:88:24: >> error: unused parameter 'klass' [-Werror=unused-parameter] >> >> as -Werror is passed and -Wno-unused doesn't seem to turn these off. >> SCTP_WERROR= >> worked around it (perhaps this should at least be WARNINGS_ARE_ERRORS >> to match HotSpot?) >> >> Do we have a preferred way to fix these errors? I know about >> __unused__ but I believe this >> is GCC-specific and I wouldn't want to break the build on other >> platforms (Solaris, MacOS X, BSD). > > What gcc version are you using? I don't see this with 4.6. > > Probably best to take this up with nio-dev folk. I'm using 4.6.3 and don't see it either. In any case, this is SCTP so net-dev is the best place to review a patch to it (but it doesn't matter, the right people will see it either way). -Alan From erik.joelsson at oracle.com Thu Mar 14 09:11:27 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 14 Mar 2013 10:11:27 +0100 Subject: Feedback on the New Build System In-Reply-To: <62528518.18066096.1363191366939.JavaMail.root@redhat.com> References: <62528518.18066096.1363191366939.JavaMail.root@redhat.com> Message-ID: <5141943F.9080200@oracle.com> Hello Andrew, Thanks for the feedback! Adding in my view of things below. On 2013-03-13 17:16, Andrew Hughes wrote: > I've just got my first build out of the new system using the main jdk8/jdk8 tree (b80) and > so thought it was worth giving some feedback on the problems encountered and issues > with the end result: > > 1. It took some time to work out how to get back to the usual 'noisy' build as the > default seems to subdue all the useful output. VERBOSE=true broke the build when > it tried to use 'true' as a Makefile target. It turns out the solution is the rather > non-obvious VERBOSE= . Could we not have this documented somewhere and perhaps have > verbosity as a configure option? After grepping around, it's not very obvious to me > where it gets set. > As already pointed out, the preferred way is to use LOG=warn/info/debug/trace, where "debug" best matches what the old build did. I don't recommend trace for normal use. The default level tries to keep the user informed about what is happening without information overload. It also makes warning messages stand out more in the hope that it annoys someone enough to go fix them. I agree that adding a configure option for changing the default is a good idea and would welcome such a patch. Internally we encourage using "debug" for nightly/remote builds. The build output is also saved to build.log in the configure directory as David said. > 2. One of the javac calls in the jdk tree fails with: > > /home/andrew/projects/openjdk/upstream/jdk8/jdk/src/share/classes/javax/swing/JSpinner.java:43: error: package sun.util.locale.provider does not exist > /home/andrew/projects/openjdk/upstream/jdk8/jdk/src/share/classes/javax/swing/JSpinner.java:44: error: package sun.util.locale.provider does not exist > /home/andrew/projects/openjdk/upstream/jdk8/jdk/src/share/classes/javax/swing/JSpinner.java:45: error: package sun.util.locale.provider does not exist > > This package is in the jdk8 tree but not in the build JDK (7). Oddly, the build > continues despite this error and the final rt.jar does include JSpinner. > It's actually not javac, but probably javadoc as David said, and is part of java source generation. I'm guessing it's the swing beans (dt.jar) that previously were generated at image creation time. It seems harmless though, but perhaps it needs to be investigated. > 3. -Werror is set for the SCTP native code causing the build to fail: > > Lots of stuff like: > > /home/andrew/projects/openjdk/upstream/jdk8/jdk/src/solaris/native/sun/nio/ch/sctp/SctpChannelImpl.c:88:24: error: unused parameter 'klass' [-Werror=unused-parameter] > > as -Werror is passed and -Wno-unused doesn't seem to turn these off. SCTP_WERROR= > worked around it (perhaps this should at least be WARNINGS_ARE_ERRORS to match HotSpot?) > > Do we have a preferred way to fix these errors? I know about __unused__ but I believe this > is GCC-specific and I wouldn't want to break the build on other platforms (Solaris, MacOS X, BSD). > This I have not noticed. Is it specific to some GCC version? > 4. It's odd that the default 'make' no longer means 'make all' and 'make' on its own doesn't produce > a JDK image to use. This will be confusing for newcomers who miss that important 'all' word or people > like me who go by the usual presumption that the default argument to make is 'all', but appears to have > been subverted here. > I can agree that it's a bit odd. It was done this way early on to reduce build times for the average developer who usually isn't interested in images and certainly not docs. For openjdk, we have "default" which translates to "jdk" and "all" which translates to "images docs". One could argue that the developer wanting to save time could type "make jdk" instead, but then, the developer wanting save time probably just wants to type "make". The root Makefile is still the old build, but the first thing it does is calling NewMakefile.gmk unless NEWBUILD=false is set. When we finally remove the old build system, NewMakefile.gmk will replace Makefile in the root. > 5. The final image produces: > > openjdk version "1.8.0-internal" > > from -version. I can't remember whether or not the internal was there before and we suppressed it in IcedTea, > but we've definitely always had 'java version' and not having this will break numerous applications (possibly > including the JDK build, as I know at least the old one used to check the version). > AFAIK this is the same with the old build. We have certainly not tried to change it. If you need additional configure logic to change or remove that string that isn't already there, that shouldn't be a problem. /Erik From david.holmes at oracle.com Thu Mar 14 10:03:30 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 14 Mar 2013 20:03:30 +1000 Subject: Allow configure to detect if EC implementation is present In-Reply-To: <51415C3A.6030304@oracle.com> References: <5140DCF3.8020808@redhat.com> <51412F9A.4020309@oracle.com> <51415436.9020404@oracle.com> <51415C3A.6030304@oracle.com> Message-ID: <5141A072.6020005@oracle.com> On 14/03/2013 3:12 PM, David Holmes wrote: > Note that this isn't changing any functionality simply exposing an > existing make variable at configure time. Correction. I misunderstood what was being done here. This forcibly set/clears the make variable based solely on the existence of a directory: test -d "${SRC_ROOT}/jdk/src/share/native/sun/security/ec/impl" It doesn't expose a configure option for this. This may be perfectly fine but the person who wrote the original TODO comment needs to verify that. David > David > > On 14/03/2013 2:38 PM, Brad Wetmore wrote: >> CC'ing security-dev. >> >> Vinnie, >> >> As owner of ECC, you should probably look at this. >> >> Brad >> >> >> On 3/13/2013 7:02 PM, David Holmes wrote: >>> On 14/03/2013 6:09 AM, Omair Majid wrote: >>>> Hi, >>>> >>>> jdk/makefiles/CompileNativeLibraries.gmk has a little note: >>>> >>>> TODO Set DISABLE_INTREE_EC in configure if >>>> src/share/native/sun/security/ec/impl is not present >>>> >>>> The webrev at http://cr.openjdk.java.net/~omajid/webrevs/intree-ec/00/ >>>> implements this. Does this look okay for jdk8/build ? Can I get a bug >>>> id? >>> >>> Bug ID: 8010030 >>> >>> I think it is more consistent to set the variable to yes/no and change: >>> >>> ifndef DISABLE_INTREE_EC >>> >>> to >>> >>> ifeq ($DISABLE_INTREE_EC), yes) >>> >>> Thanks, >>> David >>> >>> >>> >>>> Thanks, >>>> Omair >>>> From chris.hegarty at oracle.com Thu Mar 14 10:03:49 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 14 Mar 2013 10:03:49 +0000 Subject: Feedback on the New Build System In-Reply-To: <51419149.2070204@oracle.com> References: <62528518.18066096.1363191366939.JavaMail.root@redhat.com> <5141274E.8060805@oracle.com> <51419149.2070204@oracle.com> Message-ID: <5141A085.9050803@oracle.com> On 03/14/2013 08:58 AM, Alan Bateman wrote: > On 14/03/2013 01:26, David Holmes wrote: >> : >> >>> 3. -Werror is set for the SCTP native code causing the build to fail: >>> >>> Lots of stuff like: >>> >>> /home/andrew/projects/openjdk/upstream/jdk8/jdk/src/solaris/native/sun/nio/ch/sctp/SctpChannelImpl.c:88:24: >>> error: unused parameter 'klass' [-Werror=unused-parameter] >>> >>> as -Werror is passed and -Wno-unused doesn't seem to turn these off. >>> SCTP_WERROR= >>> worked around it (perhaps this should at least be WARNINGS_ARE_ERRORS >>> to match HotSpot?) >>> >>> Do we have a preferred way to fix these errors? I know about >>> __unused__ but I believe this >>> is GCC-specific and I wouldn't want to break the build on other >>> platforms (Solaris, MacOS X, BSD). >> >> What gcc version are you using? I don't see this with 4.6. >> >> Probably best to take this up with nio-dev folk. > I'm using 4.6.3 and don't see it either. In any case, this is SCTP so > net-dev is the best place to review a patch to it (but it doesn't > matter, the right people will see it either way). I've not seen issues with SCTP compiles either. That said, the SCTP native code should be clean, where possible, from all warnings ( unless something has changed recently ). >>> /home/andrew/projects/openjdk/upstream/jdk8/jdk/src/solaris/native/sun/nio/ch/sctp/SctpChannelImpl.c:88:24: >>> error: unused parameter 'klass' [-Werror=unused-parameter] The above specific warning cannot be fixed in the code as the unused parameter is part of the JNI method declaration. If these are the only type of warnings in this area, and they cause the build to fail, then it is a build issue and not a source one. -Chris. > > -Alan From gnu.andrew at redhat.com Thu Mar 14 17:26:21 2013 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 14 Mar 2013 13:26:21 -0400 (EDT) Subject: Feedback on the New Build System In-Reply-To: <51419149.2070204@oracle.com> Message-ID: <1642314789.18941210.1363281981694.JavaMail.root@redhat.com> ----- Original Message ----- > On 14/03/2013 01:26, David Holmes wrote: > > : > > > >> 3. -Werror is set for the SCTP native code causing the build to > >> fail: > >> > >> Lots of stuff like: > >> > >> /home/andrew/projects/openjdk/upstream/jdk8/jdk/src/solaris/native/sun/nio/ch/sctp/SctpChannelImpl.c:88:24: > >> error: unused parameter 'klass' [-Werror=unused-parameter] > >> > >> as -Werror is passed and -Wno-unused doesn't seem to turn these > >> off. > >> SCTP_WERROR= > >> worked around it (perhaps this should at least be > >> WARNINGS_ARE_ERRORS > >> to match HotSpot?) > >> > >> Do we have a preferred way to fix these errors? I know about > >> __unused__ but I believe this > >> is GCC-specific and I wouldn't want to break the build on other > >> platforms (Solaris, MacOS X, BSD). > > > > What gcc version are you using? I don't see this with 4.6. > > > > Probably best to take this up with nio-dev folk. > I'm using 4.6.3 and don't see it either. In any case, this is SCTP so > net-dev is the best place to review a patch to it (but it doesn't > matter, the right people will see it either way). > Yeah, I'll take a patch to the right group if it's warranted. I just wanted to know whether it was generally something we fix and if so, how? This is with the upcoming 4.8.0 release which is why I'm seeing it locally and Omair's seeing it on Fedora 19/rawhide builds i.e. we're catching it early ;) > -Alan > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From gnu.andrew at redhat.com Thu Mar 14 17:28:02 2013 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 14 Mar 2013 13:28:02 -0400 (EDT) Subject: Feedback on the New Build System In-Reply-To: <5141A085.9050803@oracle.com> Message-ID: <822116354.18941678.1363282082510.JavaMail.root@redhat.com> ----- Original Message ----- > On 03/14/2013 08:58 AM, Alan Bateman wrote: > > On 14/03/2013 01:26, David Holmes wrote: > >> : > >> > >>> 3. -Werror is set for the SCTP native code causing the build to > >>> fail: > >>> > >>> Lots of stuff like: > >>> > >>> /home/andrew/projects/openjdk/upstream/jdk8/jdk/src/solaris/native/sun/nio/ch/sctp/SctpChannelImpl.c:88:24: > >>> error: unused parameter 'klass' [-Werror=unused-parameter] > >>> > >>> as -Werror is passed and -Wno-unused doesn't seem to turn these > >>> off. > >>> SCTP_WERROR= > >>> worked around it (perhaps this should at least be > >>> WARNINGS_ARE_ERRORS > >>> to match HotSpot?) > >>> > >>> Do we have a preferred way to fix these errors? I know about > >>> __unused__ but I believe this > >>> is GCC-specific and I wouldn't want to break the build on other > >>> platforms (Solaris, MacOS X, BSD). > >> > >> What gcc version are you using? I don't see this with 4.6. > >> > >> Probably best to take this up with nio-dev folk. > > I'm using 4.6.3 and don't see it either. In any case, this is SCTP > > so > > net-dev is the best place to review a patch to it (but it doesn't > > matter, the right people will see it either way). > > I've not seen issues with SCTP compiles either. That said, the SCTP > native code should be clean, where possible, from all warnings ( > unless > something has changed recently ). > > >>> > /home/andrew/projects/openjdk/upstream/jdk8/jdk/src/solaris/native/sun/nio/ch/sctp/SctpChannelImpl.c:88:24: > > >>> error: unused parameter 'klass' [-Werror=unused-parameter] > > The above specific warning cannot be fixed in the code as the unused > parameter is part of the JNI method declaration. If these are the > only > type of warnings in this area, and they cause the build to fail, then > it > is a build issue and not a source one. > > -Chris. > > > > > -Alan > The general issue, and one I've pointed out for HotSpot before, is don't turn on -Werror for everyone. It inevitably breaks someone's build somewhere at sometime. I believe you can use __unused__ on the parameters, but that's probably GCC-specific. -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From gnu.andrew at redhat.com Thu Mar 14 17:23:50 2013 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 14 Mar 2013 13:23:50 -0400 (EDT) Subject: Allow configure to detect if EC implementation is present In-Reply-To: <51412F9A.4020309@oracle.com> Message-ID: <1187486748.18940204.1363281830355.JavaMail.root@redhat.com> ----- Original Message ----- > On 14/03/2013 6:09 AM, Omair Majid wrote: > > Hi, > > > > jdk/makefiles/CompileNativeLibraries.gmk has a little note: > > > > TODO Set DISABLE_INTREE_EC in configure if > > src/share/native/sun/security/ec/impl is not present > > > > The webrev at > > http://cr.openjdk.java.net/~omajid/webrevs/intree-ec/00/ > > implements this. Does this look okay for jdk8/build ? Can I get a > > bug id? > > Bug ID: 8010030 > > I think it is more consistent to set the variable to yes/no and > change: > > ifndef DISABLE_INTREE_EC > > to > > ifeq ($DISABLE_INTREE_EC), yes) > I agree. I didn't suggest this myself because it was already being used as ifndef and I wasn't sure if there were other occurrences elsewhere. I think I may even be the person who introduced it in this form in the old build ;) Using the standard form is preferable, though you need to make sure all uses get changed. However, this test is the wrong way round. It needs to either check for no or the variable needs to be ENABLE_INTREE_EC :) It would be nice to turn this off via a configure option but that's really something for another patch. Note that, even with this patch, unless someone manually deletes that directory, configure will not set DISABLE_INTREE_EC. It's present in the OpenJDK tree. > Thanks, > David > > > > > Thanks, > > Omair > > > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From vincent.x.ryan at oracle.com Thu Mar 14 19:14:48 2013 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Thu, 14 Mar 2013 19:14:48 +0000 Subject: Allow configure to detect if EC implementation is present In-Reply-To: <5141A072.6020005@oracle.com> References: <5140DCF3.8020808@redhat.com> <51412F9A.4020309@oracle.com> <51415436.9020404@oracle.com> <51415C3A.6030304@oracle.com> <5141A072.6020005@oracle.com> Message-ID: The DISABLE_INTREE_EC flag is designed to control whether the Elliptic Curve support in the JDK source tree is skipped during a build. It is used to avoid the duplication of EC libraries on platforms where an EC library is already present. In the old build it was a build option. In the new build it appears to be controlled by the presence of a directory. That is incorrect as the directory is always present. The behaviour differs from the old build. On 14 Mar 2013, at 10:03, David Holmes wrote: > On 14/03/2013 3:12 PM, David Holmes wrote: >> Note that this isn't changing any functionality simply exposing an >> existing make variable at configure time. > > Correction. I misunderstood what was being done here. This forcibly set/clears the make variable based solely on the existence of a directory: > > test -d "${SRC_ROOT}/jdk/src/share/native/sun/security/ec/impl" > > It doesn't expose a configure option for this. This may be perfectly fine but the person who wrote the original TODO comment needs to verify that. > > David > >> David >> >> On 14/03/2013 2:38 PM, Brad Wetmore wrote: >>> CC'ing security-dev. >>> >>> Vinnie, >>> >>> As owner of ECC, you should probably look at this. >>> >>> Brad >>> >>> >>> On 3/13/2013 7:02 PM, David Holmes wrote: >>>> On 14/03/2013 6:09 AM, Omair Majid wrote: >>>>> Hi, >>>>> >>>>> jdk/makefiles/CompileNativeLibraries.gmk has a little note: >>>>> >>>>> TODO Set DISABLE_INTREE_EC in configure if >>>>> src/share/native/sun/security/ec/impl is not present >>>>> >>>>> The webrev at http://cr.openjdk.java.net/~omajid/webrevs/intree-ec/00/ >>>>> implements this. Does this look okay for jdk8/build ? Can I get a bug >>>>> id? >>>> >>>> Bug ID: 8010030 >>>> >>>> I think it is more consistent to set the variable to yes/no and change: >>>> >>>> ifndef DISABLE_INTREE_EC >>>> >>>> to >>>> >>>> ifeq ($DISABLE_INTREE_EC), yes) >>>> >>>> Thanks, >>>> David >>>> >>>> >>>> >>>>> Thanks, >>>>> Omair >>>>> From omajid at redhat.com Thu Mar 14 19:37:46 2013 From: omajid at redhat.com (Omair Majid) Date: Thu, 14 Mar 2013 15:37:46 -0400 Subject: Allow configure to detect if EC implementation is present In-Reply-To: <5141A072.6020005@oracle.com> References: <5140DCF3.8020808@redhat.com> <51412F9A.4020309@oracle.com> <51415436.9020404@oracle.com> <51415C3A.6030304@oracle.com> <5141A072.6020005@oracle.com> Message-ID: <5142270A.7040209@redhat.com> Hi, Updated webrev at: http://cr.openjdk.java.net/~omajid/webrevs/intree-ec/01/ I switched from DISABLE_INTREE_EC to ENABLE_INTREE_EC to avoid the confusion with double negatives. Note that because of the ifeq comparison, if you use the new build system and just update the jdk tree, the ifeq ($ENABLE_INTREE_EC), yes) comparison will fail (since ENABLE_INTREE_EC was not previously defined) and EC will not be part of the build. This problem wont happen if you update the root repo and re-run configure. On 03/14/2013 06:03 AM, David Holmes wrote: > On 14/03/2013 3:12 PM, David Holmes wrote: >> Note that this isn't changing any functionality simply exposing an >> existing make variable at configure time. > > Correction. I misunderstood what was being done here. This forcibly > set/clears the make variable based solely on the existence of a directory: > > test -d "${SRC_ROOT}/jdk/src/share/native/sun/security/ec/impl" Yes, it is forcibly set. But since this directory always exists in OpenJDK 8, this should never evaluate to false. This change is very useful for distributions, though, since they can delete the directory when creating a source tarball for OpenJDK8, and the ECC implementation will be automagically disabled from the build. > It doesn't expose a configure option for this. This may be perfectly > fine but the person who wrote the original TODO comment needs to verify > that. Andrew Hughes wrote the original changeset in the old build system [1] and I believe this is exactly what he wanted out of the changeset. I am CC'ing Erik, who wrote the TODO [2] so he can clarify what he meant. Thanks, Omair [1] http://hg.openjdk.java.net/jdk7/tl/jdk/rev/39c15c0a71f7 [2] http://hg.openjdk.java.net/build-infra/jdk8/jdk/diff/1953cf522107/makefiles/CompileNativeLibraries.gmk -- PGP Key: 66484681 (http://pgp.mit.edu/) Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 From omajid at redhat.com Thu Mar 14 19:50:08 2013 From: omajid at redhat.com (Omair Majid) Date: Thu, 14 Mar 2013 15:50:08 -0400 Subject: Allow configure to detect if EC implementation is present In-Reply-To: References: <5140DCF3.8020808@redhat.com> <51412F9A.4020309@oracle.com> <51415436.9020404@oracle.com> <51415C3A.6030304@oracle.com> <5141A072.6020005@oracle.com> Message-ID: <514229F0.60602@redhat.com> On 03/14/2013 03:14 PM, Vincent Ryan wrote: > The DISABLE_INTREE_EC flag is designed to control whether the Elliptic Curve support in the > JDK source tree is skipped during a build. It is used to avoid the duplication of EC libraries on > platforms where an EC library is already present. > > In the old build it was a build option. In the new build it appears to be controlled by the presence > of a directory. That is incorrect as the directory is always present. The behaviour differs from the old build. FWIW, the current new-build and the current old-build both allow you to specify 'make DISABLE_INTREE_EC=yes' and do the right thing. However, currently there is no way to say this using configure. The patch I posted makes configure automatically set DISABLE_INTREE_EC=yes if the directory is not found. The directory is always present in OpenJDK8. However, some Linux distributions prefer to build with ECC disabled due to legal reasons [1], and will remove the directory when they create the OpenJDK8 source tarball. Where they had to delete the directory _and_ set DISABLE_INTREE_EC before, with this patch they just have to delete the directory. If you would like me to add a configure option to control this as well, then I will be happy to add that too. May I do that as a separate patch? Thanks, Omair [1] http://en.wikipedia.org/wiki/ECC_patents -- PGP Key: 66484681 (http://pgp.mit.edu/) Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 From omajid at redhat.com Thu Mar 14 20:40:40 2013 From: omajid at redhat.com (Omair Majid) Date: Thu, 14 Mar 2013 16:40:40 -0400 Subject: Allow using a system-installed giflib In-Reply-To: <107580076.17765929.1363165703471.JavaMail.root@redhat.com> References: <107580076.17765929.1363165703471.JavaMail.root@redhat.com> Message-ID: <514235C8.3000803@redhat.com> Hi Andrew, On 03/13/2013 05:08 AM, Andrew Hughes wrote: > Given this is essentially a binary option (system giflib or bundled giflib), > why is AC_ARG_ENABLE not being used instead of AC_ARG_WITH? It would simplify > the logic here and is what we use in the equivalent IcedTea check which has > been in production use for almost two years. My goal was to minimize change. The larger the change, the harder it is for it to be accepted in OpenJDK :( > AC_CHECK_HEADER([gif_lib.h], > , [AC_MSG_ERROR([Could not find GIF header; install GIF or build with --disable-system-gif to use the in-tree copy.])]) > GIF_LIBS="-lgif" > AC_SUBST(GIF_LIBS) My patch does not make use of the system headers. I should fix that next. > Was there a reason to change main to DGifGetCode? No, it just seemed the right thing to do based on the autoconf docmentaton on AC_CHECK_LIB, which said that the /function/ should be part of the library we are testing for. > It seems a better choice, assuming that symbol > is available in all versions, but I'm just wondering if a problem with using main was exposed. DGifGetCode is present in giflib 4.1.3 (May 2004). It's not mentioned in the NEWS file or the ONEWS file of that release, which makes me suspect that it has been part of the API for a long time. And no, there was no problem with using "main", it just seemed wrong. Thanks, Omair -- PGP Key: 66484681 (http://pgp.mit.edu/) Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 From omajid at redhat.com Thu Mar 14 23:39:37 2013 From: omajid at redhat.com (Omair Majid) Date: Thu, 14 Mar 2013 19:39:37 -0400 Subject: Allow using a system-installed giflib In-Reply-To: <513A1F2F.3080300@oracle.com> References: <5139542B.5080100@redhat.com> <5139C797.6090009@oracle.com> <513A1F2F.3080300@oracle.com> Message-ID: <51425FB9.6010405@redhat.com> Hi, Updated webrev at: http://cr.openjdk.java.net/~omajid/webrevs/system-giflib/01/ The webrev borrows some idioms that Andrew Hughes pointed out, and uses system headers for giflib too. I checked this by building --with-libgif=system and also by removing the src/share/native/sun/awt/giflib dir and using --with-giflib=system. On 03/08/2013 12:26 PM, Phil Race wrote: > If I understand correctly, this removes the directory containing > the JDK's copy of giflib sources from the set of locations to be > compiled etc, and replaces it with just a link line pointer to use > "libgif" which is then expected to be on the default linker path, > ie in /usr/lib. > > I think this is fine except I would guard USE_EXTERNAL_LIBGIF > with an expectation that this is at least "not" windows, since > I'm pretty sure that option would always be a mistake there. The updated webrev does that. I don't have a windows machine to test this on, unfortunately. Any comments or suggestions? Thanks, Omair -- PGP Key: 66484681 (http://pgp.mit.edu/) Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 From omajid at redhat.com Thu Mar 14 23:44:32 2013 From: omajid at redhat.com (Omair Majid) Date: Thu, 14 Mar 2013 19:44:32 -0400 Subject: Allow using a system-installed giflib In-Reply-To: <51425FB9.6010405@redhat.com> References: <5139542B.5080100@redhat.com> <5139C797.6090009@oracle.com> <513A1F2F.3080300@oracle.com> <51425FB9.6010405@redhat.com> Message-ID: <514260E0.5010006@redhat.com> On 03/14/2013 07:39 PM, Omair Majid wrote: > I checked this by building --with-libgif=system Typo. I meant '--with-giflib=bundled' (I had also removed the system giflib headers at that point to ensure the bundled copy was used). Thanks, Omair -- PGP Key: 66484681 (http://pgp.mit.edu/) Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 From david.holmes at oracle.com Fri Mar 15 01:47:44 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 15 Mar 2013 11:47:44 +1000 Subject: Allow configure to detect if EC implementation is present In-Reply-To: <5142270A.7040209@redhat.com> References: <5140DCF3.8020808@redhat.com> <51412F9A.4020309@oracle.com> <51415436.9020404@oracle.com> <51415C3A.6030304@oracle.com> <5141A072.6020005@oracle.com> <5142270A.7040209@redhat.com> Message-ID: <51427DC0.8020203@oracle.com> On 15/03/2013 5:37 AM, Omair Majid wrote: > Hi, > > Updated webrev at: > http://cr.openjdk.java.net/~omajid/webrevs/intree-ec/01/ > > I switched from DISABLE_INTREE_EC to ENABLE_INTREE_EC to avoid the > confusion with double negatives. Looking just at the mechanics of this it looks fine to me. This needs to be coordinated with someone from the build team (which isn't me) so that we can keep the closed generated-configure.sh in sync. Personally I wonder whether the existence check should be in the Makefile rather than done at configure time? I worry that we end up with too many make variables becoming configure variables as well. David ----- > Note that because of the ifeq comparison, if you use the new build > system and just update the jdk tree, the ifeq ($ENABLE_INTREE_EC), yes) > comparison will fail (since ENABLE_INTREE_EC was not previously defined) > and EC will not be part of the build. > > This problem wont happen if you update the root repo and re-run configure. > > On 03/14/2013 06:03 AM, David Holmes wrote: >> On 14/03/2013 3:12 PM, David Holmes wrote: >>> Note that this isn't changing any functionality simply exposing an >>> existing make variable at configure time. >> >> Correction. I misunderstood what was being done here. This forcibly >> set/clears the make variable based solely on the existence of a directory: >> >> test -d "${SRC_ROOT}/jdk/src/share/native/sun/security/ec/impl" > > Yes, it is forcibly set. But since this directory always exists in > OpenJDK 8, this should never evaluate to false. > > This change is very useful for distributions, though, since they can > delete the directory when creating a source tarball for OpenJDK8, and > the ECC implementation will be automagically disabled from the build. > >> It doesn't expose a configure option for this. This may be perfectly >> fine but the person who wrote the original TODO comment needs to verify >> that. > > Andrew Hughes wrote the original changeset in the old build system [1] > and I believe this is exactly what he wanted out of the changeset. I am > CC'ing Erik, who wrote the TODO [2] so he can clarify what he meant. > > Thanks, > Omair > > [1] http://hg.openjdk.java.net/jdk7/tl/jdk/rev/39c15c0a71f7 > [2] > http://hg.openjdk.java.net/build-infra/jdk8/jdk/diff/1953cf522107/makefiles/CompileNativeLibraries.gmk > From gnu.andrew at redhat.com Fri Mar 15 02:55:29 2013 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 14 Mar 2013 22:55:29 -0400 (EDT) Subject: Allow configure to detect if EC implementation is present In-Reply-To: <51427DC0.8020203@oracle.com> Message-ID: <1878430105.19113975.1363316129472.JavaMail.root@redhat.com> ----- Original Message ----- > On 15/03/2013 5:37 AM, Omair Majid wrote: > > Hi, > > > > Updated webrev at: > > http://cr.openjdk.java.net/~omajid/webrevs/intree-ec/01/ > > > > I switched from DISABLE_INTREE_EC to ENABLE_INTREE_EC to avoid the > > confusion with double negatives. > > Looking just at the mechanics of this it looks fine to me. I concur. > This needs > to > be coordinated with someone from the build team (which isn't me) so > that > we can keep the closed generated-configure.sh in sync. I don't think this is a reasonable requirement generally, though it may be fine in this case. We should now be getting to the point where an OpenJDK committer can post a patch, an OpenJDK reviewer can review it and the committer can push it to an appropriate repository without either of these people being Oracle employees. Certainly, the bylaws allow this. What you're asking here seems no different than me asking for someone to co-ordinate with the IcedTea team to update their build machinery. I wouldn't expect this to happen and I don't think Oracle should either. > > Personally I wonder whether the existence check should be in the > Makefile rather than done at configure time? I worry that we end up > with > too many make variables becoming configure variables as well. > One of the main functions of a configure script is to make these variables more easily accessible to the point that you should only need to set make variables when you need to do a one-time override of something set by configure. We should no longer be passing a huge list of make variables. I'd argue that Omair's work could be extended, in a further patch, so that the option was set by --disable-intree-ec and the behaviour seen here was just the default if the option wasn't specified. Having configure options also acts as a means of documenting the various build options (see configure --help), something which doesn't happen when they are imposed via make. > David > ----- > > > Note that because of the ifeq comparison, if you use the new build > > system and just update the jdk tree, the ifeq ($ENABLE_INTREE_EC), > > yes) > > comparison will fail (since ENABLE_INTREE_EC was not previously > > defined) > > and EC will not be part of the build. > > > > This problem wont happen if you update the root repo and re-run > > configure. > > > > On 03/14/2013 06:03 AM, David Holmes wrote: > >> On 14/03/2013 3:12 PM, David Holmes wrote: > >>> Note that this isn't changing any functionality simply exposing > >>> an > >>> existing make variable at configure time. > >> > >> Correction. I misunderstood what was being done here. This > >> forcibly > >> set/clears the make variable based solely on the existence of a > >> directory: > >> > >> test -d "${SRC_ROOT}/jdk/src/share/native/sun/security/ec/impl" > > > > Yes, it is forcibly set. But since this directory always exists in > > OpenJDK 8, this should never evaluate to false. > > > > This change is very useful for distributions, though, since they > > can > > delete the directory when creating a source tarball for OpenJDK8, > > and > > the ECC implementation will be automagically disabled from the > > build. > > > >> It doesn't expose a configure option for this. This may be > >> perfectly > >> fine but the person who wrote the original TODO comment needs to > >> verify > >> that. > > > > Andrew Hughes wrote the original changeset in the old build system > > [1] > > and I believe this is exactly what he wanted out of the changeset. > > I am > > CC'ing Erik, who wrote the TODO [2] so he can clarify what he > > meant. > > > > Thanks, > > Omair > > > > [1] http://hg.openjdk.java.net/jdk7/tl/jdk/rev/39c15c0a71f7 > > [2] > > http://hg.openjdk.java.net/build-infra/jdk8/jdk/diff/1953cf522107/makefiles/CompileNativeLibraries.gmk > > > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From gnu.andrew at redhat.com Fri Mar 15 03:00:55 2013 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 14 Mar 2013 23:00:55 -0400 (EDT) Subject: Allow using a system-installed giflib In-Reply-To: <514235C8.3000803@redhat.com> Message-ID: <77764573.19114192.1363316455522.JavaMail.root@redhat.com> ----- Original Message ----- > Hi Andrew, > > On 03/13/2013 05:08 AM, Andrew Hughes wrote: > > Given this is essentially a binary option (system giflib or bundled > > giflib), > > why is AC_ARG_ENABLE not being used instead of AC_ARG_WITH? It > > would simplify > > the logic here and is what we use in the equivalent IcedTea check > > which has > > been in production use for almost two years. > > My goal was to minimize change. The larger the change, the harder it > is > for it to be accepted in OpenJDK :( Right, but I think a stronger case can be made for a change if it's been well-tested. Also, I don't think there's really much difference in size here. It just uses a different form to the existing zlib one. As I said before, there's also an issue with it testing for the system library when the bundled copy has been requested. I can however propose a patch following this to fix the two options (zlib & this). Just don't go and submit any more in this form. > > > AC_CHECK_HEADER([gif_lib.h], > > , [AC_MSG_ERROR([Could not find GIF header; install GIF or > > build with --disable-system-gif to use the in-tree > > copy.])]) > > GIF_LIBS="-lgif" > > AC_SUBST(GIF_LIBS) > > My patch does not make use of the system headers. I should fix that > next. > > > Was there a reason to change main to DGifGetCode? > > No, it just seemed the right thing to do based on the autoconf > docmentaton on AC_CHECK_LIB, which said that the /function/ should be > part of the library we are testing for. > > > It seems a better choice, assuming that symbol > > is available in all versions, but I'm just wondering if a problem > > with using main was exposed. > > DGifGetCode is present in giflib 4.1.3 (May 2004). It's not mentioned > in > the NEWS file or the ONEWS file of that release, which makes me > suspect > that it has been part of the API for a long time. > > And no, there was no problem with using "main", it just seemed wrong. > I agree it's better. I would why main was used to begin with. > Thanks, > Omair > > -- > PGP Key: 66484681 (http://pgp.mit.edu/) > Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From gnu.andrew at redhat.com Fri Mar 15 03:10:11 2013 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 14 Mar 2013 23:10:11 -0400 (EDT) Subject: Allow using a system-installed giflib In-Reply-To: <51425FB9.6010405@redhat.com> Message-ID: <1350720224.19115736.1363317011803.JavaMail.root@redhat.com> ----- Original Message ----- > Hi, > > Updated webrev at: > http://cr.openjdk.java.net/~omajid/webrevs/system-giflib/01/ > > The webrev borrows some idioms that Andrew Hughes pointed out, and > uses > system headers for giflib too. > > I checked this by building --with-libgif=system and also by removing > the > src/share/native/sun/awt/giflib dir and using --with-giflib=system. > This looks better, though I'd still like to see it using a more standard --enable format. That then removes the need to have that third error case. I'll post a webrev to fix both this and zlib once committed. > On 03/08/2013 12:26 PM, Phil Race wrote: > > If I understand correctly, this removes the directory containing > > the JDK's copy of giflib sources from the set of locations to be > > compiled etc, and replaces it with just a link line pointer to use > > "libgif" which is then expected to be on the default linker path, > > ie in /usr/lib. > > > > I think this is fine except I would guard USE_EXTERNAL_LIBGIF > > with an expectation that this is at least "not" windows, since > > I'm pretty sure that option would always be a mistake there. > > The updated webrev does that. I don't have a windows machine to test > this on, unfortunately. > This does cause some duplication. Is this really a major issue? It's not the default and, if I was someone on Windows trying to get system giflib working, this would just get in the way. We had to remove something similar in the zlib case that blocked it if not on Mac OS X. > Any comments or suggestions? > > Thanks, > Omair > > -- > PGP Key: 66484681 (http://pgp.mit.edu/) > Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From david.holmes at oracle.com Fri Mar 15 03:17:21 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 15 Mar 2013 13:17:21 +1000 Subject: Allow configure to detect if EC implementation is present In-Reply-To: <1878430105.19113975.1363316129472.JavaMail.root@redhat.com> References: <1878430105.19113975.1363316129472.JavaMail.root@redhat.com> Message-ID: <514292C1.3080601@oracle.com> On 15/03/2013 12:55 PM, Andrew Hughes wrote: > ----- Original Message ----- >> On 15/03/2013 5:37 AM, Omair Majid wrote: >>> Hi, >>> >>> Updated webrev at: >>> http://cr.openjdk.java.net/~omajid/webrevs/intree-ec/01/ >>> >>> I switched from DISABLE_INTREE_EC to ENABLE_INTREE_EC to avoid the >>> confusion with double negatives. >> >> Looking just at the mechanics of this it looks fine to me. > > I concur. > >> This needs to >> be coordinated with someone from the build team (which isn't me) so >> that we can keep the closed generated-configure.sh in sync. > > I don't think this is a reasonable requirement generally, though it > may be fine in this case. We should now be getting to the point > where an OpenJDK committer can post a patch, an OpenJDK reviewer > can review it and the committer can push it to an appropriate > repository without either of these people being Oracle employees. > Certainly, the bylaws allow this. > > What you're asking here seems no different than me asking for > someone to co-ordinate with the IcedTea team to update their > build machinery. I wouldn't expect this to happen and I don't think > Oracle should either. We know this is a problem. Hopefully we will have a solution soon that will alleviate the need for this. In the meantime I would request your forbearance. I should have said "Can you please ..." rather than "This needs ...". >> >> Personally I wonder whether the existence check should be in the >> Makefile rather than done at configure time? I worry that we end up >> with too many make variables becoming configure variables as well. >> > > One of the main functions of a configure script is to make these > variables more easily accessible to the point that you should > only need to set make variables when you need to do a one-time override > of something set by configure. We should no longer be passing a huge > list of make variables. Totally agreed with the last point. But to me the division of labor between configure and make is not always clear. David ----- > I'd argue that Omair's work could be extended, in a further patch, so > that the option was set by --disable-intree-ec and the behaviour > seen here was just the default if the option wasn't specified. > Having configure options also acts as a means of documenting the > various build options (see configure --help), something which > doesn't happen when they are imposed via make. >> David >> ----- >> >>> Note that because of the ifeq comparison, if you use the new build >>> system and just update the jdk tree, the ifeq ($ENABLE_INTREE_EC), >>> yes) >>> comparison will fail (since ENABLE_INTREE_EC was not previously >>> defined) >>> and EC will not be part of the build. >>> >>> This problem wont happen if you update the root repo and re-run >>> configure. >>> >>> On 03/14/2013 06:03 AM, David Holmes wrote: >>>> On 14/03/2013 3:12 PM, David Holmes wrote: >>>>> Note that this isn't changing any functionality simply exposing >>>>> an >>>>> existing make variable at configure time. >>>> >>>> Correction. I misunderstood what was being done here. This >>>> forcibly >>>> set/clears the make variable based solely on the existence of a >>>> directory: >>>> >>>> test -d "${SRC_ROOT}/jdk/src/share/native/sun/security/ec/impl" >>> >>> Yes, it is forcibly set. But since this directory always exists in >>> OpenJDK 8, this should never evaluate to false. >>> >>> This change is very useful for distributions, though, since they >>> can >>> delete the directory when creating a source tarball for OpenJDK8, >>> and >>> the ECC implementation will be automagically disabled from the >>> build. >>> >>>> It doesn't expose a configure option for this. This may be >>>> perfectly >>>> fine but the person who wrote the original TODO comment needs to >>>> verify >>>> that. >>> >>> Andrew Hughes wrote the original changeset in the old build system >>> [1] >>> and I believe this is exactly what he wanted out of the changeset. >>> I am >>> CC'ing Erik, who wrote the TODO [2] so he can clarify what he >>> meant. >>> >>> Thanks, >>> Omair >>> >>> [1] http://hg.openjdk.java.net/jdk7/tl/jdk/rev/39c15c0a71f7 >>> [2] >>> http://hg.openjdk.java.net/build-infra/jdk8/jdk/diff/1953cf522107/makefiles/CompileNativeLibraries.gmk >>> >> > From gnu.andrew at redhat.com Fri Mar 15 03:49:48 2013 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 14 Mar 2013 23:49:48 -0400 (EDT) Subject: Allow configure to detect if EC implementation is present In-Reply-To: <514292C1.3080601@oracle.com> Message-ID: <34311227.19119273.1363319388379.JavaMail.root@redhat.com> ----- Original Message ----- > On 15/03/2013 12:55 PM, Andrew Hughes wrote: > > ----- Original Message ----- > >> On 15/03/2013 5:37 AM, Omair Majid wrote: > >>> Hi, > >>> > >>> Updated webrev at: > >>> http://cr.openjdk.java.net/~omajid/webrevs/intree-ec/01/ > >>> > >>> I switched from DISABLE_INTREE_EC to ENABLE_INTREE_EC to avoid > >>> the > >>> confusion with double negatives. > >> > >> Looking just at the mechanics of this it looks fine to me. > > > > I concur. > > > >> This needs to > >> be coordinated with someone from the build team (which isn't me) > >> so > >> that we can keep the closed generated-configure.sh in sync. > > > > I don't think this is a reasonable requirement generally, though it > > may be fine in this case. We should now be getting to the point > > where an OpenJDK committer can post a patch, an OpenJDK reviewer > > can review it and the committer can push it to an appropriate > > repository without either of these people being Oracle employees. > > Certainly, the bylaws allow this. > > > > What you're asking here seems no different than me asking for > > someone to co-ordinate with the IcedTea team to update their > > build machinery. I wouldn't expect this to happen and I don't > > think > > Oracle should either. > > We know this is a problem. Hopefully we will have a solution soon > that > will alleviate the need for this. In the meantime I would request > your > forbearance. I should have said "Can you please ..." rather than > "This > needs ...". > Thanks :-) I'm just very wary of anything that looks like it will block people getting involved in OpenJDK. > >> > >> Personally I wonder whether the existence check should be in the > >> Makefile rather than done at configure time? I worry that we end > >> up > >> with too many make variables becoming configure variables as well. > >> > > > > One of the main functions of a configure script is to make these > > variables more easily accessible to the point that you should > > only need to set make variables when you need to do a one-time > > override > > of something set by configure. We should no longer be passing a > > huge > > list of make variables. > > Totally agreed with the last point. > > But to me the division of labor between configure and make is not > always > clear. > It's often not for me either, and the problem is twofold if you have an existing setup as with OpenJDK because you're not adding a new option so much as deciding how to access an old one. > David > ----- > > > I'd argue that Omair's work could be extended, in a further patch, > > so > > that the option was set by --disable-intree-ec and the behaviour > > seen here was just the default if the option wasn't specified. > > Having configure options also acts as a means of documenting the > > various build options (see configure --help), something which > > doesn't happen when they are imposed via make. > > > > >> David > >> ----- > >> > >>> Note that because of the ifeq comparison, if you use the new > >>> build > >>> system and just update the jdk tree, the ifeq > >>> ($ENABLE_INTREE_EC), > >>> yes) > >>> comparison will fail (since ENABLE_INTREE_EC was not previously > >>> defined) > >>> and EC will not be part of the build. > >>> > >>> This problem wont happen if you update the root repo and re-run > >>> configure. > >>> > >>> On 03/14/2013 06:03 AM, David Holmes wrote: > >>>> On 14/03/2013 3:12 PM, David Holmes wrote: > >>>>> Note that this isn't changing any functionality simply exposing > >>>>> an > >>>>> existing make variable at configure time. > >>>> > >>>> Correction. I misunderstood what was being done here. This > >>>> forcibly > >>>> set/clears the make variable based solely on the existence of a > >>>> directory: > >>>> > >>>> test -d "${SRC_ROOT}/jdk/src/share/native/sun/security/ec/impl" > >>> > >>> Yes, it is forcibly set. But since this directory always exists > >>> in > >>> OpenJDK 8, this should never evaluate to false. > >>> > >>> This change is very useful for distributions, though, since they > >>> can > >>> delete the directory when creating a source tarball for OpenJDK8, > >>> and > >>> the ECC implementation will be automagically disabled from the > >>> build. > >>> > >>>> It doesn't expose a configure option for this. This may be > >>>> perfectly > >>>> fine but the person who wrote the original TODO comment needs to > >>>> verify > >>>> that. > >>> > >>> Andrew Hughes wrote the original changeset in the old build > >>> system > >>> [1] > >>> and I believe this is exactly what he wanted out of the > >>> changeset. > >>> I am > >>> CC'ing Erik, who wrote the TODO [2] so he can clarify what he > >>> meant. > >>> > >>> Thanks, > >>> Omair > >>> > >>> [1] http://hg.openjdk.java.net/jdk7/tl/jdk/rev/39c15c0a71f7 > >>> [2] > >>> http://hg.openjdk.java.net/build-infra/jdk8/jdk/diff/1953cf522107/makefiles/CompileNativeLibraries.gmk > >>> > >> > > > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From erik.joelsson at oracle.com Fri Mar 15 09:04:23 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 15 Mar 2013 10:04:23 +0100 Subject: Allow configure to detect if EC implementation is present In-Reply-To: <5142270A.7040209@redhat.com> References: <5140DCF3.8020808@redhat.com> <51412F9A.4020309@oracle.com> <51415436.9020404@oracle.com> <51415C3A.6030304@oracle.com> <5141A072.6020005@oracle.com> <5142270A.7040209@redhat.com> Message-ID: <5142E417.3020504@oracle.com> On 2013-03-14 20:37, Omair Majid wrote: > Andrew Hughes wrote the original changeset in the old build system [1] > and I believe this is exactly what he wanted out of the changeset. I am > CC'ing Erik, who wrote the TODO [2] so he can clarify what he meant. > > I didn't actually create that comment in the first place, I just committed it as part of a big move of changes from the build-infra repos, where the work was done in small increments. Looking at this, I'm suspecting the comment was added due to this comment in jdk/make/sun/security/ec/Makefile: # # Some licensees do not get the native ECC sources, but we still need to # be able to build "all" for them. Check here to see if the sources are # available. If not, then skip them. # A usecase probably not that interesting to the OpenJDK community, but as Omair points out, it still applies, so I think this is a good idea. Adding a configure option for it would be nice too, but I don't see it as a requirement for this fix. I like the last suggestion with a clear yes/no with no double negatives, it looks ok. And as David pointed out, please notify me and Tim Bell when you push this so we may have a chance at keeping the Oracle internal configure script up to date. Also please avoid pushing on a Wednesday as that's when the integration to master happens and the likelihood of bad timing increases. I don't like this complication any more than any of you, but for the time being, that's the way it is. /Erik From erik.joelsson at oracle.com Fri Mar 15 09:42:20 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 15 Mar 2013 10:42:20 +0100 Subject: Allow using a system-installed giflib In-Reply-To: <1350720224.19115736.1363317011803.JavaMail.root@redhat.com> References: <1350720224.19115736.1363317011803.JavaMail.root@redhat.com> Message-ID: <5142ECFC.1090402@oracle.com> On 2013-03-15 04:10, Andrew Hughes wrote: > ----- Original Message ----- >> Hi, >> >> Updated webrev at: >> http://cr.openjdk.java.net/~omajid/webrevs/system-giflib/01/ >> >> The webrev borrows some idioms that Andrew Hughes pointed out, and >> uses >> system headers for giflib too. >> >> I checked this by building --with-libgif=system and also by removing >> the >> src/share/native/sun/awt/giflib dir and using --with-giflib=system. >> > This looks better, though I'd still like to see it using a more > standard --enable format. That then removes the need to have that > third error case. I'll post a webrev to fix both this and zlib once > committed. > Agree, ok from me. >> On 03/08/2013 12:26 PM, Phil Race wrote: >>> If I understand correctly, this removes the directory containing >>> the JDK's copy of giflib sources from the set of locations to be >>> compiled etc, and replaces it with just a link line pointer to use >>> "libgif" which is then expected to be on the default linker path, >>> ie in /usr/lib. >>> >>> I think this is fine except I would guard USE_EXTERNAL_LIBGIF >>> with an expectation that this is at least "not" windows, since >>> I'm pretty sure that option would always be a mistake there. >> The updated webrev does that. I don't have a windows machine to test >> this on, unfortunately. >> > This does cause some duplication. Is this really a major issue? It's > not the default and, if I was someone on Windows trying to get system > giflib working, this would just get in the way. We had to remove something > similar in the zlib case that blocked it if not on Mac OS X. > This part is weird to me. Sure, trying to set --with-giflib=system on windows is wrong, but that's why configure is verifying that it's actually there and that the toolchain is able to compile and link against it. I just tried the patch on windows, and configure fails at finding giflib, even if it's installed in cygwin, as expected. I do not think we should be hand holding to this extent in the makefiles. If we really want to guard this on windows, do it in configure, with a helpful error message, rather then silently ignoring the option in make. But as pointed out, it's really not necessary. /Erik From david.holmes at oracle.com Fri Mar 15 11:15:33 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 15 Mar 2013 21:15:33 +1000 Subject: Allow configure to detect if EC implementation is present In-Reply-To: <5142E417.3020504@oracle.com> References: <5140DCF3.8020808@redhat.com> <51412F9A.4020309@oracle.com> <51415436.9020404@oracle.com> <51415C3A.6030304@oracle.com> <5141A072.6020005@oracle.com> <5142270A.7040209@redhat.com> <5142E417.3020504@oracle.com> Message-ID: <514302D5.7080309@oracle.com> On 15/03/2013 7:04 PM, Erik Joelsson wrote: > And as David pointed out, please notify me and Tim Bell when you push If I am added to that list we will have global timezone coverage :) Though we should all see the push notifications anyway, it should minimize the window of potential breakage. I think as long as the pushes are to jdk8/build that will also minimise risk. Where we had problems last week was where pushes went to jdk8/tl. That may still be needed in some cases, but for pure build changes jdk8/build is best. Cheers, David > this so we may have a chance at keeping the Oracle internal configure > script up to date. Also please avoid pushing on a Wednesday as that's > when the integration to master happens and the likelihood of bad timing > increases. I don't like this complication any more than any of you, but > for the time being, that's the way it is. > > /Erik From vincent.x.ryan at oracle.com Fri Mar 15 11:25:16 2013 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Fri, 15 Mar 2013 11:25:16 +0000 Subject: Allow configure to detect if EC implementation is present In-Reply-To: <514229F0.60602@redhat.com> References: <5140DCF3.8020808@redhat.com> <51412F9A.4020309@oracle.com> <51415436.9020404@oracle.com> <51415C3A.6030304@oracle.com> <5141A072.6020005@oracle.com> <514229F0.60602@redhat.com> Message-ID: <841C1CCF-2052-4FD4-B548-7F7CE4445A97@oracle.com> You're correct Omar. That target directory is not always present as I had indicated below. The new and old builds are indeed consistent in the way they handle that. Thanks. On 14 Mar 2013, at 19:50, Omair Majid wrote: > On 03/14/2013 03:14 PM, Vincent Ryan wrote: >> The DISABLE_INTREE_EC flag is designed to control whether the Elliptic Curve support in the >> JDK source tree is skipped during a build. It is used to avoid the duplication of EC libraries on >> platforms where an EC library is already present. >> >> In the old build it was a build option. In the new build it appears to be controlled by the presence >> of a directory. That is incorrect as the directory is always present. The behaviour differs from the old build. > > FWIW, the current new-build and the current old-build both allow you to > specify 'make DISABLE_INTREE_EC=yes' and do the right thing. > > However, currently there is no way to say this using configure. The > patch I posted makes configure automatically set DISABLE_INTREE_EC=yes > if the directory is not found. The directory is always present in > OpenJDK8. However, some Linux distributions prefer to build with ECC > disabled due to legal reasons [1], and will remove the directory when > they create the OpenJDK8 source tarball. Where they had to delete the > directory _and_ set DISABLE_INTREE_EC before, with this patch they just > have to delete the directory. > > If you would like me to add a configure option to control this as well, > then I will be happy to add that too. May I do that as a separate patch? > > Thanks, > Omair > > [1] http://en.wikipedia.org/wiki/ECC_patents > > -- > PGP Key: 66484681 (http://pgp.mit.edu/) > Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 From akhil.arora at oracle.com Wed Mar 6 05:35:55 2013 From: akhil.arora at oracle.com (Akhil Arora) Date: Tue, 05 Mar 2013 21:35:55 -0800 Subject: New official README-builds.html In-Reply-To: References: Message-ID: <5136D5BB.8050007@oracle.com> I followed the instructions in the README and tried building on a new, blank ubuntu 12.04.2 LTS system. configure was able to detect that cups, asound & freetype libs were not installed, and provided helpful instructions to get them, but it failed to catch that X libraries were not installed - I had to install them 'manually' - sudo apt-get install libx11-dev libxext-dev libxt-dev libxrender-dev libxtst-dev Might want to update configure to check for these libs on linux. On 03/01/2013 09:18 AM, Kelly O'Hair wrote: > > Please do not 'reply all', send concerns or issues to just the build-dev or build-infra-dev aliases. > > The very latest README-builds.html file is: > http://hg.openjdk.java.net/jdk8/jdk8/raw-file/tip/README-builds.html > > This documents the new build makefiles only. > As with all documents of this type, it will always be a work in progress. > > -kto > From jlaskey at me.com Mon Mar 11 18:32:52 2013 From: jlaskey at me.com (Jim Laskey) Date: Mon, 11 Mar 2013 15:32:52 -0300 Subject: sjavac Message-ID: The Nashorn team is wondering about the status of sjavac and the builds. Note: https://jbs.oracle.com/bugs/browse/JDK-8009788 . There are two occurances of "-cp" which should be convered to "-classpath" in makefiles/BuildNashorn.gmk . Cheers, -- Jim From Peter.Zhelezniakov at oracle.com Tue Mar 12 08:06:36 2013 From: Peter.Zhelezniakov at oracle.com (Peter Zhelezniakov) Date: Tue, 12 Mar 2013 12:06:36 +0400 Subject: Building on Mac Message-ID: <432F8A89-C354-4E8D-9DF5-0BCB3DDB32C6@oracle.com> Hello, I'm trying to build jdk8 on Mac, cannot get past the configuration step. First configure asked for X11, which I believe is not needed on Mac. I worked around with --x-libraries. Then it stumbled upon freetype, which it should not need either. I added --with-freetype, but it failed to recognise .dylib as the library suffix: configure: error: Could not find libfreetype.so nor freetype.dll in /opt/local/lib Any advice? Thanks! -- Peter | x33066 | St Petersburg, Russia | timezone: GMT+04 From gnu.andrew at redhat.com Fri Mar 15 17:57:38 2013 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Fri, 15 Mar 2013 13:57:38 -0400 (EDT) Subject: sjavac In-Reply-To: Message-ID: <555886462.19465768.1363370258835.JavaMail.root@redhat.com> ----- Original Message ----- > The Nashorn team is wondering about the status of sjavac and the > builds. Note: https://jbs.oracle.com/bugs/browse/JDK-8009788 . > There are two occurances of "-cp" which should be convered to > "-classpath" in makefiles/BuildNashorn.gmk . > > Cheers, > > -- Jim > > Is there a difference between '-cp' and '-classpath'. I thought they were synonyms. -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From martinrb at google.com Fri Mar 15 18:00:14 2013 From: martinrb at google.com (Martin Buchholz) Date: Fri, 15 Mar 2013 11:00:14 -0700 Subject: sjavac In-Reply-To: <555886462.19465768.1363370258835.JavaMail.root@redhat.com> References: <555886462.19465768.1363370258835.JavaMail.root@redhat.com> Message-ID: (As I've complained about recently) Not all jdk commands (e.g. javap, and apparently sjavac) consistently support either both or neither of '-cp' and '-classpath' as synonyms. But that's being fixed. On Fri, Mar 15, 2013 at 10:57 AM, Andrew Hughes wrote: > > > ----- Original Message ----- > > The Nashorn team is wondering about the status of sjavac and the > > builds. Note: https://jbs.oracle.com/bugs/browse/JDK-8009788 . > > There are two occurances of "-cp" which should be convered to > > "-classpath" in makefiles/BuildNashorn.gmk . > > > > Cheers, > > > > -- Jim > > > > > > Is there a difference between '-cp' and '-classpath'. I thought > they were synonyms. > -- > Andrew :) > > Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > PGP Key: 248BDC07 (https://keys.indymedia.org/) > Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 > > From gnu.andrew at redhat.com Fri Mar 15 18:05:00 2013 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Fri, 15 Mar 2013 14:05:00 -0400 (EDT) Subject: New official README-builds.html In-Reply-To: <5136D5BB.8050007@oracle.com> Message-ID: <1889117016.19471000.1363370700860.JavaMail.root@redhat.com> ----- Original Message ----- > I followed the instructions in the README and tried building on a > new, > blank ubuntu 12.04.2 LTS system. configure was able to detect that > cups, > asound & freetype libs were not installed, and provided helpful > instructions to get them, but it failed to catch that X libraries > were > not installed - I had to install them 'manually' - > > sudo apt-get install libx11-dev libxext-dev libxt-dev libxrender-dev > libxtst-dev > > Might want to update configure to check for these libs on linux. > Well that won't work everywhere: $ apt-get install libx11-dev libxext-dev libxt-dev libxrender-dev bash: apt-get: command not found so this advice has limited usage anyway. How did it fail without the X libraries? > On 03/01/2013 09:18 AM, Kelly O'Hair wrote: > > > > Please do not 'reply all', send concerns or issues to just the > > build-dev or build-infra-dev aliases. > > > > The very latest README-builds.html file is: > > http://hg.openjdk.java.net/jdk8/jdk8/raw-file/tip/README-builds.html > > > > This documents the new build makefiles only. > > As with all documents of this type, it will always be a work in > > progress. > > > > -kto > > > > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From david.katleman at oracle.com Fri Mar 15 18:13:10 2013 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Fri, 15 Mar 2013 18:13:10 +0000 Subject: hg: jdk8/build: 16 new changesets Message-ID: <20130315181310.E74724819A@hg.openjdk.java.net> Changeset: 0dc28db6525f Author: katleman Date: 2013-03-14 15:00 -0700 URL: http://hg.openjdk.java.net/jdk8/build/rev/0dc28db6525f Added tag jdk8-b81 for changeset 145dbc56f931 ! .hgtags Changeset: ecc8fda8f187 Author: darcy Date: 2013-02-19 00:24 -0800 URL: http://hg.openjdk.java.net/jdk8/build/rev/ecc8fda8f187 8008435: Fix new build to include jdk.Supported in ct.sym Reviewed-by: erikj ! common/makefiles/javadoc/NON_CORE_PKGS.gmk Changeset: eca3bce3d151 Author: lana Date: 2013-02-19 20:48 -0800 URL: http://hg.openjdk.java.net/jdk8/build/rev/eca3bce3d151 Merge Changeset: c641268c4532 Author: mduigou Date: 2013-02-20 17:56 -0800 URL: http://hg.openjdk.java.net/jdk8/build/rev/c641268c4532 8008629: webrev.ksh needs to quote bug title it gets back from scraping bugs.sun.com Reviewed-by: darcy ! make/scripts/webrev.ksh Changeset: b70196e01c53 Author: lana Date: 2013-02-21 17:39 -0800 URL: http://hg.openjdk.java.net/jdk8/build/rev/b70196e01c53 Merge Changeset: 5b0b6ef58dbf Author: jjg Date: 2013-02-25 15:08 -0800 URL: http://hg.openjdk.java.net/jdk8/build/rev/5b0b6ef58dbf 8008914: Add nashorn to the tl build Reviewed-by: mr, tbell, jjh Contributed-by: erik.joelsson at oracle.com, james.laskey at oracle.com ! Makefile ! common/autoconf/generated-configure.sh ! common/autoconf/source-dirs.m4 ! common/autoconf/spec.gmk.in ! common/bin/hgforest.sh ! common/makefiles/Main.gmk ! common/makefiles/MakeBase.gmk ! make/Defs-internal.gmk ! make/jdk-rules.gmk ! make/sanity-rules.gmk ! make/scripts/hgforest.sh Changeset: e065107437b9 Author: alanb Date: 2013-02-26 14:08 +0000 URL: http://hg.openjdk.java.net/jdk8/build/rev/e065107437b9 8008978: nashorn-rules.gmk missing Reviewed-by: alanb Contributed-by: erik.joelsson at oracle.com, james.laskey at oracle.com + make/nashorn-rules.gmk Changeset: cb0ac8979caa Author: tbell Date: 2013-02-26 09:25 -0800 URL: http://hg.openjdk.java.net/jdk8/build/rev/cb0ac8979caa 8009019: Updates to generated-configure.sh required for 8008914 Reviewed-by: sundar, jlaskey, jjg ! common/autoconf/generated-configure.sh Changeset: a9c8a32d09f9 Author: martin Date: 2013-03-05 13:16 -0800 URL: http://hg.openjdk.java.net/jdk8/build/rev/a9c8a32d09f9 8006988: build-infra: Configure fails if 'cl' is in path on linux Summary: Respect user CC and CXX environment variables; use cl iff on windows Reviewed-by: erikj ! common/autoconf/generated-configure.sh ! common/autoconf/toolchain.m4 Changeset: c022bc48b7ed Author: lana Date: 2013-03-05 11:46 -0800 URL: http://hg.openjdk.java.net/jdk8/build/rev/c022bc48b7ed Merge ! common/autoconf/generated-configure.sh ! common/autoconf/spec.gmk.in Changeset: c4901c0e0579 Author: lana Date: 2013-03-05 15:09 -0800 URL: http://hg.openjdk.java.net/jdk8/build/rev/c4901c0e0579 Merge ! common/autoconf/generated-configure.sh ! common/autoconf/toolchain.m4 Changeset: 929e2461818b Author: dholmes Date: 2013-03-05 22:45 -0500 URL: http://hg.openjdk.java.net/jdk8/build/rev/929e2461818b 8009529: Fix for 8006988 missed closed configure changes Reviewed-by: mr ! common/autoconf/generated-configure.sh Changeset: b35d986ff276 Author: mduigou Date: 2013-03-06 08:37 -0800 URL: http://hg.openjdk.java.net/jdk8/build/rev/b35d986ff276 8009162: root repo "make test" target should run against image Reviewed-by: alanb, martin, erikj ! common/makefiles/Main.gmk Changeset: 980ccff2d4f5 Author: lana Date: 2013-03-12 16:38 -0700 URL: http://hg.openjdk.java.net/jdk8/build/rev/980ccff2d4f5 Merge ! common/autoconf/generated-configure.sh ! common/autoconf/spec.gmk.in ! common/makefiles/Main.gmk Changeset: 22b9a31a92eb Author: lana Date: 2013-03-13 23:21 -0700 URL: http://hg.openjdk.java.net/jdk8/build/rev/22b9a31a92eb Merge ! common/autoconf/generated-configure.sh ! common/autoconf/spec.gmk.in ! common/autoconf/toolchain.m4 Changeset: a69761ae281b Author: lana Date: 2013-03-14 19:33 -0700 URL: http://hg.openjdk.java.net/jdk8/build/rev/a69761ae281b Merge From david.katleman at oracle.com Fri Mar 15 18:13:17 2013 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Fri, 15 Mar 2013 18:13:17 +0000 Subject: hg: jdk8/build/corba: 13 new changesets Message-ID: <20130315181325.B42DA4819B@hg.openjdk.java.net> Changeset: 0ac9424678e7 Author: katleman Date: 2013-03-14 15:00 -0700 URL: http://hg.openjdk.java.net/jdk8/build/corba/rev/0ac9424678e7 Added tag jdk8-b81 for changeset 2a00aeeb466b ! .hgtags Changeset: e725dd195858 Author: dmeetry Date: 2013-02-15 01:49 +0400 URL: http://hg.openjdk.java.net/jdk8/build/corba/rev/e725dd195858 7199858: Marshal exception is wrong Reviewed-by: lancea ! src/share/classes/com/sun/corba/se/impl/corba/TypeCodeImpl.java Changeset: c528d8ce83f1 Author: lana Date: 2013-02-19 20:48 -0800 URL: http://hg.openjdk.java.net/jdk8/build/corba/rev/c528d8ce83f1 Merge Changeset: 67ef27b4e16c Author: lana Date: 2013-03-05 11:46 -0800 URL: http://hg.openjdk.java.net/jdk8/build/corba/rev/67ef27b4e16c Merge Changeset: 05386b4610e9 Author: lana Date: 2013-03-12 16:38 -0700 URL: http://hg.openjdk.java.net/jdk8/build/corba/rev/05386b4610e9 Merge Changeset: 3c73273667ae Author: coffeys Date: 2012-10-30 17:06 +0000 URL: http://hg.openjdk.java.net/jdk8/build/corba/rev/3c73273667ae 8000631: Restrict access to class constructor Reviewed-by: alanb, ahgross ! make/com/sun/corba/minclude/com_sun_corba_se_impl_orbutil.jmk ! src/share/classes/com/sun/corba/se/impl/corba/AnyImpl.java ! src/share/classes/com/sun/corba/se/impl/encoding/CDRInputStream_1_0.java ! src/share/classes/com/sun/corba/se/impl/encoding/CDROutputStream_1_0.java ! src/share/classes/com/sun/corba/se/impl/io/FVDCodeBaseImpl.java ! src/share/classes/com/sun/corba/se/impl/io/ValueHandlerImpl.java ! src/share/classes/com/sun/corba/se/impl/io/ValueUtility.java ! src/share/classes/com/sun/corba/se/impl/javax/rmi/CORBA/Util.java ! src/share/classes/com/sun/corba/se/impl/orb/ORBImpl.java - src/share/classes/com/sun/corba/se/impl/orbutil/IIOPInputStream_1_3.java - src/share/classes/com/sun/corba/se/impl/orbutil/IIOPInputStream_1_3_1.java - src/share/classes/com/sun/corba/se/impl/orbutil/IIOPOutputStream_1_3.java - src/share/classes/com/sun/corba/se/impl/orbutil/IIOPOutputStream_1_3_1.java ! src/share/classes/com/sun/corba/se/impl/orbutil/ORBUtility.java - src/share/classes/com/sun/corba/se/impl/orbutil/RepIdDelegator_1_3.java - src/share/classes/com/sun/corba/se/impl/orbutil/RepIdDelegator_1_3_1.java - src/share/classes/com/sun/corba/se/impl/orbutil/RepositoryIdCache_1_3.java - src/share/classes/com/sun/corba/se/impl/orbutil/RepositoryIdCache_1_3_1.java ! src/share/classes/com/sun/corba/se/impl/orbutil/RepositoryIdFactory.java - src/share/classes/com/sun/corba/se/impl/orbutil/RepositoryId_1_3.java - src/share/classes/com/sun/corba/se/impl/orbutil/RepositoryId_1_3_1.java - src/share/classes/com/sun/corba/se/impl/orbutil/ValueHandlerImpl_1_3.java - src/share/classes/com/sun/corba/se/impl/orbutil/ValueHandlerImpl_1_3_1.java + src/share/classes/sun/corba/JavaCorbaAccess.java + src/share/classes/sun/corba/SharedSecrets.java Changeset: 80882eae6279 Author: ngmr Date: 2012-10-30 17:15 +0000 URL: http://hg.openjdk.java.net/jdk8/build/corba/rev/80882eae6279 8000540: Improve IIOP type reuse management Reviewed-by: alanb, ahgross, coffeys ! src/share/classes/com/sun/corba/se/impl/io/ObjectStreamClass.java Changeset: 0ca1fc7c5f44 Author: mbankal Date: 2012-12-17 07:43 -0800 URL: http://hg.openjdk.java.net/jdk8/build/corba/rev/0ca1fc7c5f44 7141694: Improving CORBA internals Reviewed-by: coffeys, ahgross ! src/share/classes/com/sun/corba/se/spi/orb/ORB.java Changeset: f4f39d873b9a Author: coffeys Date: 2012-11-06 15:50 +0000 URL: http://hg.openjdk.java.net/jdk8/build/corba/rev/f4f39d873b9a 7201066: Change modifiers on unused fields Reviewed-by: alanb, skoivu ! src/share/classes/com/sun/corba/se/impl/activation/ServerMain.java ! src/share/classes/com/sun/corba/se/impl/io/ObjectStreamClass.java ! src/share/classes/com/sun/corba/se/impl/orbutil/ObjectStreamClass_1_3_1.java Changeset: 59bff16bc0bf Author: ewendeli Date: 2013-02-19 21:44 +0100 URL: http://hg.openjdk.java.net/jdk8/build/corba/rev/59bff16bc0bf Merge - src/share/classes/com/sun/corba/se/impl/orbutil/IIOPInputStream_1_3.java - src/share/classes/com/sun/corba/se/impl/orbutil/IIOPInputStream_1_3_1.java - src/share/classes/com/sun/corba/se/impl/orbutil/IIOPOutputStream_1_3.java - src/share/classes/com/sun/corba/se/impl/orbutil/IIOPOutputStream_1_3_1.java - src/share/classes/com/sun/corba/se/impl/orbutil/RepIdDelegator_1_3.java - src/share/classes/com/sun/corba/se/impl/orbutil/RepIdDelegator_1_3_1.java - src/share/classes/com/sun/corba/se/impl/orbutil/RepositoryIdCache_1_3.java - src/share/classes/com/sun/corba/se/impl/orbutil/RepositoryIdCache_1_3_1.java - src/share/classes/com/sun/corba/se/impl/orbutil/RepositoryId_1_3.java - src/share/classes/com/sun/corba/se/impl/orbutil/RepositoryId_1_3_1.java - src/share/classes/com/sun/corba/se/impl/orbutil/ValueHandlerImpl_1_3.java - src/share/classes/com/sun/corba/se/impl/orbutil/ValueHandlerImpl_1_3_1.java Changeset: 996bd5fd0941 Author: ewendeli Date: 2013-02-25 07:21 +0100 URL: http://hg.openjdk.java.net/jdk8/build/corba/rev/996bd5fd0941 Merge - src/share/classes/com/sun/corba/se/impl/orbutil/IIOPInputStream_1_3.java - src/share/classes/com/sun/corba/se/impl/orbutil/IIOPInputStream_1_3_1.java - src/share/classes/com/sun/corba/se/impl/orbutil/IIOPOutputStream_1_3.java - src/share/classes/com/sun/corba/se/impl/orbutil/IIOPOutputStream_1_3_1.java - src/share/classes/com/sun/corba/se/impl/orbutil/RepIdDelegator_1_3.java - src/share/classes/com/sun/corba/se/impl/orbutil/RepIdDelegator_1_3_1.java - src/share/classes/com/sun/corba/se/impl/orbutil/RepositoryIdCache_1_3.java - src/share/classes/com/sun/corba/se/impl/orbutil/RepositoryIdCache_1_3_1.java - src/share/classes/com/sun/corba/se/impl/orbutil/RepositoryId_1_3.java - src/share/classes/com/sun/corba/se/impl/orbutil/RepositoryId_1_3_1.java - src/share/classes/com/sun/corba/se/impl/orbutil/ValueHandlerImpl_1_3.java - src/share/classes/com/sun/corba/se/impl/orbutil/ValueHandlerImpl_1_3_1.java Changeset: 7341134e52ff Author: lana Date: 2013-03-12 18:16 -0700 URL: http://hg.openjdk.java.net/jdk8/build/corba/rev/7341134e52ff Merge - src/share/classes/com/sun/corba/se/impl/orbutil/IIOPInputStream_1_3.java - src/share/classes/com/sun/corba/se/impl/orbutil/IIOPInputStream_1_3_1.java - src/share/classes/com/sun/corba/se/impl/orbutil/IIOPOutputStream_1_3.java - src/share/classes/com/sun/corba/se/impl/orbutil/IIOPOutputStream_1_3_1.java - src/share/classes/com/sun/corba/se/impl/orbutil/RepIdDelegator_1_3.java - src/share/classes/com/sun/corba/se/impl/orbutil/RepIdDelegator_1_3_1.java - src/share/classes/com/sun/corba/se/impl/orbutil/RepositoryIdCache_1_3.java - src/share/classes/com/sun/corba/se/impl/orbutil/RepositoryIdCache_1_3_1.java - src/share/classes/com/sun/corba/se/impl/orbutil/RepositoryId_1_3.java - src/share/classes/com/sun/corba/se/impl/orbutil/RepositoryId_1_3_1.java - src/share/classes/com/sun/corba/se/impl/orbutil/ValueHandlerImpl_1_3.java - src/share/classes/com/sun/corba/se/impl/orbutil/ValueHandlerImpl_1_3_1.java Changeset: 48e1bc77004d Author: lana Date: 2013-03-14 19:33 -0700 URL: http://hg.openjdk.java.net/jdk8/build/corba/rev/48e1bc77004d Merge From david.katleman at oracle.com Fri Mar 15 18:15:41 2013 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Fri, 15 Mar 2013 18:15:41 +0000 Subject: hg: jdk8/build/hotspot: 8 new changesets Message-ID: <20130315181600.18F7F4819C@hg.openjdk.java.net> Changeset: f1629878512f Author: katleman Date: 2013-03-14 15:00 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/f1629878512f Added tag jdk8-b81 for changeset 65b797426a3b ! .hgtags Changeset: b95ad0610fef Author: asaha Date: 2012-10-26 09:27 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/b95ad0610fef Merge - agent/make/ClosureFinder.java - agent/src/share/classes/sun/jvm/hotspot/TestDebugger.java - agent/src/share/classes/sun/jvm/hotspot/asm/AbstractInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/Address.java - agent/src/share/classes/sun/jvm/hotspot/asm/Arithmetic.java - agent/src/share/classes/sun/jvm/hotspot/asm/ArithmeticInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/BaseIndexScaleDispAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/BranchInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/CPUHelper.java - agent/src/share/classes/sun/jvm/hotspot/asm/CallInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/DirectAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/Immediate.java - agent/src/share/classes/sun/jvm/hotspot/asm/IndirectAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/Instruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/LoadInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/LogicInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/MemoryInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/MoveInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/PCRelativeAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/RTLDataTypes.java - agent/src/share/classes/sun/jvm/hotspot/asm/RTLOperations.java - agent/src/share/classes/sun/jvm/hotspot/asm/ReturnInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/ShiftInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/StoreInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/amd64/AMD64FloatRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/amd64/AMD64Helper.java - agent/src/share/classes/sun/jvm/hotspot/asm/amd64/AMD64Register.java - agent/src/share/classes/sun/jvm/hotspot/asm/amd64/AMD64Registers.java - agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64FloatRegister.java - agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64FloatRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64Helper.java - agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64Register.java - agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64Registers.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/AlternateSpaceLdstubDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/AlternateSpaceLoadDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/AlternateSpaceStoreDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/AlternateSpaceSwapDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/ArithmeticDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/BranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/CallDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/CoprocessorBranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/CoprocessorDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FP2RegisterDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FPArithmeticDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FPMoveDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FPopDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FloatBranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FloatDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FlushDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/Format3ADecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/IllegalInstructionDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/InstructionDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/IntegerBranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/JmplDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/LdstubDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/LoadDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/LogicDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/MemoryInstructionDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/ReadDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/ReadWriteDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/RegisterDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/RestoreDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/RettDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCArithmeticInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCAtomicLoadStoreInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCBranchInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCCallInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCDisassembler.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFP2RegisterInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFPArithmeticInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFPMoveInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFloatRegister.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFloatRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFlushInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFormat3AInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCHelper.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCIllegalInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCIndirectCallInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCInstructionFactory.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCInstructionFactoryImpl.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCJmplInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCLdstubInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCLoadInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCLogicInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCMemoryInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCMoveInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCNoopInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCOpcodes.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCReadInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCRegisterIndirectAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCRestoreInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCRettInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCReturnInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSaveInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSethiInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCShiftInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSpecialLoadInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSpecialRegisterInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSpecialRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSpecialStoreInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCStbarInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCStoreInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSwapInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCTrapInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCUnimpInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV8Disassembler.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9BranchInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9CasInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9ConditionFlags.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9Disassembler.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9DoneInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9FMOVccInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9FMOVrInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9FlushwInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9IlltrapInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9ImpdepInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9Instruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9InstructionFactory.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9InstructionFactoryImpl.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9MOVccInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9MOVrInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9MembarInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9Opcodes.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9PopcInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9PrefetchInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9PrivilegedRegisterInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9PrivilegedRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RdprInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9ReadInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RegisterBranchInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RegisterIndirectAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RestoredInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RetryInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9ReturnInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9SavedInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9SirInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9SpecialRegisterInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9SpecialRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9WriteInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9WrprInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCWriteInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SaveDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SethiDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/ShiftDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SpecialLoadDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SpecialLoadStoreDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SpecialStoreDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/StoreDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SwapDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/TrapDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/UnimpDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V8FPop1Decoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V8FPop2Decoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceLdstubDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceLoadDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpacePrefetchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceStoreDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceSwapDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9BranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9CCBranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9CMoveDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9CasDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9DoneRetryDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FMOVccDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FMOVrDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FPop1Decoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FPop2Decoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FloatBranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FlushwDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9InstructionDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9IntRegisterBranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9IntegerBranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9MOVccDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9MOVrDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9PopcDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9PrefetchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9PrivilegedReadWriteDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9RdprDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9ReadDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9RegisterBranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9SavedRestoredDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9ShiftDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9SpecialLoadDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9SpecialStoreDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9WriteDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9WrprDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/WriteDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/ArithmeticDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/BranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/CallDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/ConditionalJmpDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/FPArithmeticDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/FPInstructionDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/FPLoadDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/FPStoreDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/FloatDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/FloatGRPDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/GRPDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/InstructionDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/JmpDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/LogicalDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/MoveDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/RotateDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSEArithmeticDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSEInstructionDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSELogicalDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSEMoveDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSEShiftDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/ShiftDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86ArithmeticInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86BranchInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86CallInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86CondJmpInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86DirectAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Disassembler.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FPArithmeticInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FPInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FPLoadInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FPStoreInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FloatRegister.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FloatRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86GeneralInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Helper.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86IllegalInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Instruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86InstructionFactory.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86InstructionFactoryImpl.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86JmpInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86LogicInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MMXRegister.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MMXRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MemoryIndirectAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MemoryInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MoveInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MoveLoadInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MoveStoreInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Opcodes.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86PCRelativeAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Register.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86RegisterDirectAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86RegisterIndirectAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86RegisterPart.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Registers.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86RotateInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86SegmentRegister.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86SegmentRegisterAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86SegmentRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86ShiftInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86XMMRegister.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86XMMRegisters.java - agent/src/share/classes/sun/jvm/hotspot/ci/ciArrayKlassKlass.java - agent/src/share/classes/sun/jvm/hotspot/ci/ciInstanceKlassKlass.java - agent/src/share/classes/sun/jvm/hotspot/ci/ciKlassKlass.java - agent/src/share/classes/sun/jvm/hotspot/ci/ciMethodKlass.java - agent/src/share/classes/sun/jvm/hotspot/ci/ciObjArrayKlassKlass.java - agent/src/share/classes/sun/jvm/hotspot/ci/ciTypeArrayKlassKlass.java - agent/src/share/classes/sun/jvm/hotspot/gc_implementation/parallelScavenge/PSPermGen.java - agent/src/share/classes/sun/jvm/hotspot/memory/CMSPermGen.java - agent/src/share/classes/sun/jvm/hotspot/memory/CMSPermGenGen.java - agent/src/share/classes/sun/jvm/hotspot/memory/CompactingPermGen.java - agent/src/share/classes/sun/jvm/hotspot/memory/CompactingPermGenGen.java - agent/src/share/classes/sun/jvm/hotspot/memory/ContigPermSpace.java - agent/src/share/classes/sun/jvm/hotspot/memory/PermGen.java - agent/src/share/classes/sun/jvm/hotspot/oops/ArrayKlassKlass.java - agent/src/share/classes/sun/jvm/hotspot/oops/CompiledICHolderKlass.java - agent/src/share/classes/sun/jvm/hotspot/oops/ConstMethodKlass.java - agent/src/share/classes/sun/jvm/hotspot/oops/ConstantPoolCacheKlass.java - agent/src/share/classes/sun/jvm/hotspot/oops/ConstantPoolKlass.java - agent/src/share/classes/sun/jvm/hotspot/oops/InstanceKlassKlass.java - agent/src/share/classes/sun/jvm/hotspot/oops/KlassKlass.java - agent/src/share/classes/sun/jvm/hotspot/oops/MethodDataKlass.java - agent/src/share/classes/sun/jvm/hotspot/oops/MethodKlass.java - agent/src/share/classes/sun/jvm/hotspot/oops/ObjArrayKlassKlass.java - agent/src/share/classes/sun/jvm/hotspot/oops/TypeArrayKlassKlass.java - agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/IA64CurrentFrameGuess.java - agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/IA64Frame.java - agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/IA64JavaCallWrapper.java - agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/IA64RegisterMap.java - agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/cInterpreter.java - agent/src/share/classes/sun/jvm/hotspot/runtime/linux_ia64/LinuxIA64JavaThreadPDAccess.java - agent/src/share/classes/sun/jvm/hotspot/runtime/win32_ia64/Win32IA64JavaThreadPDAccess.java - agent/src/share/classes/sun/jvm/hotspot/ui/tree/BadOopTreeNodeAdapter.java - make/solaris/makefiles/reorder_COMPILER1_amd64 - make/solaris/makefiles/reorder_COMPILER1_i486 - make/solaris/makefiles/reorder_COMPILER1_sparc - make/solaris/makefiles/reorder_COMPILER1_sparcv9 - make/solaris/makefiles/reorder_COMPILER2_amd64 - make/solaris/makefiles/reorder_COMPILER2_i486 - make/solaris/makefiles/reorder_COMPILER2_sparc - make/solaris/makefiles/reorder_COMPILER2_sparcv9 - make/solaris/makefiles/reorder_CORE_i486 - make/solaris/makefiles/reorder_CORE_sparc - make/solaris/makefiles/reorder_CORE_sparcv9 - make/solaris/makefiles/reorder_TIERED_amd64 - make/solaris/makefiles/reorder_TIERED_i486 - make/solaris/makefiles/reorder_TIERED_sparc - make/solaris/makefiles/reorder_TIERED_sparcv9 - make/solaris/reorder.sh - src/cpu/sparc/vm/dump_sparc.cpp - src/cpu/x86/vm/dump_x86_32.cpp - src/cpu/x86/vm/dump_x86_64.cpp - src/cpu/zero/vm/dump_zero.cpp - src/share/tools/ProjectCreator/DirectoryTree.java - src/share/tools/ProjectCreator/DirectoryTreeNode.java - src/share/tools/ProjectCreator/FileFormatException.java - src/share/tools/ProjectCreator/WinGammaPlatformVC6.java - src/share/vm/ci/ciArrayKlassKlass.hpp - src/share/vm/ci/ciCPCache.cpp - src/share/vm/ci/ciCPCache.hpp - src/share/vm/ci/ciInstanceKlassKlass.cpp - src/share/vm/ci/ciInstanceKlassKlass.hpp - src/share/vm/ci/ciKlassKlass.cpp - src/share/vm/ci/ciKlassKlass.hpp - src/share/vm/ci/ciMethodKlass.cpp - src/share/vm/ci/ciMethodKlass.hpp - src/share/vm/ci/ciObjArrayKlassKlass.cpp - src/share/vm/ci/ciObjArrayKlassKlass.hpp - src/share/vm/ci/ciTypeArrayKlassKlass.cpp - src/share/vm/ci/ciTypeArrayKlassKlass.hpp ! src/share/vm/compiler/compilerOracle.cpp - src/share/vm/gc_implementation/concurrentMarkSweep/cmsPermGen.cpp - src/share/vm/gc_implementation/concurrentMarkSweep/cmsPermGen.hpp - src/share/vm/gc_implementation/parallelScavenge/psPermGen.cpp - src/share/vm/gc_implementation/parallelScavenge/psPermGen.hpp - src/share/vm/memory/classify.cpp - src/share/vm/memory/classify.hpp - src/share/vm/memory/compactPermGen.hpp - src/share/vm/memory/compactingPermGenGen.cpp - src/share/vm/memory/compactingPermGenGen.hpp - src/share/vm/memory/dump.cpp - src/share/vm/memory/permGen.cpp - src/share/vm/memory/permGen.hpp - src/share/vm/memory/restore.cpp - src/share/vm/memory/serialize.cpp - src/share/vm/oops/arrayKlassKlass.cpp - src/share/vm/oops/arrayKlassKlass.hpp - src/share/vm/oops/compiledICHolderKlass.cpp - src/share/vm/oops/compiledICHolderKlass.hpp - src/share/vm/oops/compiledICHolderOop.cpp - src/share/vm/oops/compiledICHolderOop.hpp - src/share/vm/oops/constMethodKlass.cpp - src/share/vm/oops/constMethodKlass.hpp - src/share/vm/oops/constMethodOop.cpp - src/share/vm/oops/constMethodOop.hpp - src/share/vm/oops/constantPoolKlass.cpp - src/share/vm/oops/constantPoolKlass.hpp - src/share/vm/oops/constantPoolOop.cpp - src/share/vm/oops/constantPoolOop.hpp - src/share/vm/oops/cpCacheKlass.cpp - src/share/vm/oops/cpCacheKlass.hpp - src/share/vm/oops/cpCacheOop.cpp - src/share/vm/oops/cpCacheOop.hpp - src/share/vm/oops/instanceKlassKlass.cpp - src/share/vm/oops/instanceKlassKlass.hpp - src/share/vm/oops/klassKlass.cpp - src/share/vm/oops/klassKlass.hpp - src/share/vm/oops/klassOop.cpp - src/share/vm/oops/klassOop.hpp - src/share/vm/oops/methodDataKlass.cpp - src/share/vm/oops/methodDataKlass.hpp - src/share/vm/oops/methodDataOop.cpp - src/share/vm/oops/methodDataOop.hpp - src/share/vm/oops/methodKlass.cpp - src/share/vm/oops/methodKlass.hpp - src/share/vm/oops/methodOop.cpp - src/share/vm/oops/methodOop.hpp - src/share/vm/oops/objArrayKlassKlass.cpp - src/share/vm/oops/objArrayKlassKlass.hpp - src/share/vm/oops/typeArrayKlassKlass.cpp - src/share/vm/oops/typeArrayKlassKlass.hpp ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/runtime/arguments.cpp Changeset: 77443715ec55 Author: kamg Date: 2012-11-05 17:03 -0500 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/77443715ec55 8001307: Modify ACC_SUPER behavior Summary: Disallow non-virtual calls even when ACC_SUPER is absent. Reviewed-by: kvn, acorn ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/runtime/globals.hpp Changeset: b5cb079ecaa4 Author: ewendeli Date: 2013-02-03 22:43 +0100 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/b5cb079ecaa4 Merge ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: 1cabf9c80e84 Author: ewendeli Date: 2013-02-19 21:45 +0100 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/1cabf9c80e84 Merge ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/runtime/arguments.cpp Changeset: d4a32a6f8c82 Author: ewendeli Date: 2013-02-25 07:22 +0100 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/d4a32a6f8c82 Merge ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: 11d5942ef9c7 Author: lana Date: 2013-03-12 18:22 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/11d5942ef9c7 Merge ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: 5ee744831dcb Author: lana Date: 2013-03-14 19:26 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/5ee744831dcb Merge From david.katleman at oracle.com Fri Mar 15 18:18:32 2013 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Fri, 15 Mar 2013 18:18:32 +0000 Subject: hg: jdk8/build/jaxws: Added tag jdk8-b81 for changeset c88bb21560cc Message-ID: <20130315181836.891674819E@hg.openjdk.java.net> Changeset: d8d8032d02d7 Author: katleman Date: 2013-03-14 15:00 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jaxws/rev/d8d8032d02d7 Added tag jdk8-b81 for changeset c88bb21560cc ! .hgtags From david.katleman at oracle.com Fri Mar 15 18:18:05 2013 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Fri, 15 Mar 2013 18:18:05 +0000 Subject: hg: jdk8/build/jaxp: 6 new changesets Message-ID: <20130315181822.B19E14819D@hg.openjdk.java.net> Changeset: 94000590f01f Author: katleman Date: 2013-03-14 15:00 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jaxp/rev/94000590f01f Added tag jdk8-b81 for changeset ef3495555a4c ! .hgtags Changeset: f4898ff0aff1 Author: joehw Date: 2012-12-12 15:19 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jaxp/rev/f4898ff0aff1 8001235: Improve JAXP HTTP handling Reviewed-by: lancea, skoivu ! src/com/sun/org/apache/xpath/internal/functions/FuncSystemProperty.java Changeset: 3206516132e8 Author: ewendeli Date: 2013-02-19 21:45 +0100 URL: http://hg.openjdk.java.net/jdk8/build/jaxp/rev/3206516132e8 Merge Changeset: 46ce56a4e40f Author: ewendeli Date: 2013-02-25 07:22 +0100 URL: http://hg.openjdk.java.net/jdk8/build/jaxp/rev/46ce56a4e40f Merge Changeset: 8a0cb78fefbc Author: lana Date: 2013-03-12 18:22 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jaxp/rev/8a0cb78fefbc Merge Changeset: d5a58291f09a Author: lana Date: 2013-03-14 19:33 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jaxp/rev/d5a58291f09a Merge From david.dehaven at oracle.com Fri Mar 15 18:53:02 2013 From: david.dehaven at oracle.com (David DeHaven) Date: Fri, 15 Mar 2013 11:53:02 -0700 Subject: Building on Mac In-Reply-To: <432F8A89-C354-4E8D-9DF5-0BCB3DDB32C6@oracle.com> References: <432F8A89-C354-4E8D-9DF5-0BCB3DDB32C6@oracle.com> Message-ID: > Then it stumbled upon freetype, which it should not need either. I added --with-freetype, but it failed to recognise .dylib as the library suffix: > > configure: error: Could not find libfreetype.so nor freetype.dll in /opt/local/lib IIRC Freetype is required for libfontmanager when building OpenJDK (not closed) but it doesn't seem to differentiate when configure is run. Look in config.log to see why it's failing. The error message is misleading, it's not actually looking for those extensions it's checking by using the CFLAGS returned by pkg-config. Mine works fine with the MacPorts freetype port. -DrD- From david.katleman at oracle.com Fri Mar 15 18:25:16 2013 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Fri, 15 Mar 2013 18:25:16 +0000 Subject: hg: jdk8/build/jdk: 164 new changesets Message-ID: <20130315185831.9B9AE4819F@hg.openjdk.java.net> Changeset: 509c45748f3e Author: katleman Date: 2013-03-14 15:00 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/509c45748f3e Added tag jdk8-b81 for changeset c0f8022eba53 ! .hgtags Changeset: f6eb212081b2 Author: jgodinez Date: 2013-02-14 14:14 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/f6eb212081b2 8008173: [parfait] #1173 Uninitialised variable -- TransformHelper.cpp Reviewed-by: prr, vadim Contributed-by: jia-hong.chen at oracle.com ! src/share/native/sun/java2d/loops/TransformHelper.c Changeset: 4b11045a9c4c Author: jgodinez Date: 2013-02-18 14:04 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/4b11045a9c4c 8005191: [parfait] #384 sun/font/layout/LookupProcessor.cpp Null pointer dereference Reviewed-by: prr, vadim Contributed-by: jia-hong.chen at oracle.com ! src/share/native/sun/font/layout/LookupProcessor.cpp Changeset: 41008f5cef1a Author: lana Date: 2013-02-19 22:10 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/41008f5cef1a Merge - src/macosx/classes/sun/lwawt/macosx/EventDispatchAccess.java - src/share/classes/java/time/PeriodParser.java - src/share/classes/java/time/calendar/ChronoDateImpl.java - src/share/classes/java/time/calendar/HijrahChrono.java - src/share/classes/java/time/calendar/HijrahDate.java - src/share/classes/java/time/calendar/HijrahDeviationReader.java - src/share/classes/java/time/calendar/HijrahEra.java - src/share/classes/java/time/calendar/JapaneseChrono.java - src/share/classes/java/time/calendar/JapaneseDate.java - src/share/classes/java/time/calendar/JapaneseEra.java - src/share/classes/java/time/calendar/MinguoChrono.java - src/share/classes/java/time/calendar/MinguoDate.java - src/share/classes/java/time/calendar/MinguoEra.java - src/share/classes/java/time/calendar/Ser.java - src/share/classes/java/time/calendar/ThaiBuddhistChrono.java - src/share/classes/java/time/calendar/ThaiBuddhistDate.java - src/share/classes/java/time/calendar/ThaiBuddhistEra.java - src/share/classes/java/time/calendar/package-info.java - src/share/classes/java/time/format/DateTimeFormatters.java - src/share/classes/java/time/format/DateTimePrintException.java - src/share/classes/java/time/temporal/Chrono.java - src/share/classes/java/time/temporal/ChronoLocalDate.java - src/share/classes/java/time/temporal/ChronoLocalDateTime.java - src/share/classes/java/time/temporal/ChronoLocalDateTimeImpl.java - src/share/classes/java/time/temporal/ChronoZonedDateTime.java - src/share/classes/java/time/temporal/ChronoZonedDateTimeImpl.java - src/share/classes/java/time/temporal/Era.java - src/share/classes/java/time/temporal/ISOChrono.java - src/share/classes/java/time/temporal/ISOEra.java - src/share/classes/java/time/temporal/ISOFields.java - src/share/classes/java/time/temporal/MonthDay.java - src/share/classes/java/time/temporal/OffsetDate.java - src/share/classes/java/time/temporal/OffsetDateTime.java - src/share/classes/java/time/temporal/OffsetTime.java - src/share/classes/java/time/temporal/Ser.java - src/share/classes/java/time/temporal/SimplePeriod.java - src/share/classes/java/time/temporal/TemporalAdder.java - src/share/classes/java/time/temporal/TemporalSubtractor.java - src/share/classes/java/time/temporal/Year.java - src/share/classes/java/time/temporal/YearMonth.java - src/share/classes/sun/util/calendar/TzIDOldMapping.java - test/java/time/META-INF/services/java.time.temporal.Chrono - test/java/time/tck/java/time/calendar/CopticChrono.java - test/java/time/tck/java/time/calendar/CopticDate.java - test/java/time/tck/java/time/calendar/CopticEra.java - test/java/time/tck/java/time/calendar/TestChronoLocalDate.java - test/java/time/tck/java/time/calendar/TestChronoLocalDateTime.java - test/java/time/tck/java/time/calendar/TestHijrahChrono.java - test/java/time/tck/java/time/calendar/TestJapaneseChrono.java - test/java/time/tck/java/time/calendar/TestMinguoChrono.java - test/java/time/tck/java/time/calendar/TestServiceLoader.java - test/java/time/tck/java/time/calendar/TestThaiBuddhistChrono.java - test/java/time/tck/java/time/format/TCKDateTimePrintException.java - test/java/time/tck/java/time/temporal/TCKISOFields.java - test/java/time/tck/java/time/temporal/TCKMonthDay.java - test/java/time/tck/java/time/temporal/TCKOffsetDate.java - test/java/time/tck/java/time/temporal/TCKOffsetDateTime.java - test/java/time/tck/java/time/temporal/TCKOffsetTime.java - test/java/time/tck/java/time/temporal/TCKSimplePeriod.java - test/java/time/tck/java/time/temporal/TCKYear.java - test/java/time/tck/java/time/temporal/TCKYearMonth.java - test/java/time/tck/java/time/temporal/TestChrono.java - test/java/time/tck/java/time/temporal/TestISOChrono.java - test/java/time/test/java/time/TestPeriodParser.java - test/java/time/test/java/time/format/TestDateTimeFormatters.java - test/java/time/test/java/time/format/TestDateTimePrintException.java - test/java/time/test/java/time/format/TestPadParserDecorator.java - test/java/time/test/java/time/format/TestZoneIdParser.java - test/java/time/test/java/time/temporal/TestISOChronoImpl.java - test/java/time/test/java/time/temporal/TestMonthDay.java - test/java/time/test/java/time/temporal/TestOffsetDate.java - test/java/time/test/java/time/temporal/TestOffsetDateTime.java - test/java/time/test/java/time/temporal/TestOffsetDateTime_instants.java - test/java/time/test/java/time/temporal/TestOffsetTime.java - test/java/time/test/java/time/temporal/TestYear.java - test/java/time/test/java/time/temporal/TestYearMonth.java Changeset: d2d7da120c37 Author: jgodinez Date: 2013-02-22 11:01 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/d2d7da120c37 8006110: pageDialog is showing the swing dialog with DialogTypeSelection.NATIVE Reviewed-by: bae, prr ! src/share/classes/sun/print/RasterPrinterJob.java Changeset: 99c1f910abcc Author: jgodinez Date: 2013-02-22 13:20 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/99c1f910abcc 8005796: [parfait] Possible uninitialised variable at jdk/src/share/native/sun/java2d/loops/ByteBinary1Bit.c Reviewed-by: prr, vadim, flar Contributed-by: jia-hong.chen at oracle.com ! src/share/native/sun/java2d/loops/AnyByteBinary.h ! src/share/native/sun/java2d/loops/ByteIndexed.h ! src/share/native/sun/java2d/loops/IntArgb.h ! src/share/native/sun/java2d/loops/IntArgbBm.h ! src/share/native/sun/java2d/loops/IntArgbPre.h ! src/share/native/sun/java2d/loops/Ushort4444Argb.h ! src/share/native/sun/java2d/loops/UshortIndexed.h Changeset: 934f5f10107d Author: lana Date: 2013-02-22 11:37 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/934f5f10107d Merge Changeset: 4fd6048a78c0 Author: lana Date: 2013-02-22 23:12 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/4fd6048a78c0 Merge Changeset: f3368a3fc023 Author: bae Date: 2013-03-05 17:18 +0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/f3368a3fc023 7152608: [macosx] Crash in liblwawt.dylib in AccelGlyphCache_RemoveCellInfo Reviewed-by: jgodinez, ant ! src/macosx/classes/sun/font/CStrike.java ! src/macosx/classes/sun/font/CStrikeDisposer.java ! src/macosx/native/sun/font/AWTStrike.m Changeset: fd8810d50c99 Author: bae Date: 2013-03-07 14:05 +0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/fd8810d50c99 8005530: [lcms] Improve performance of ColorConverOp for default destinations Reviewed-by: prr, jgodinez ! make/sun/cmm/lcms/Makefile ! make/sun/cmm/lcms/mapfile-vers ! makefiles/CompileNativeLibraries.gmk ! makefiles/mapfiles/liblcms/mapfile-vers ! src/share/classes/sun/java2d/cmm/lcms/LCMS.java ! src/share/classes/sun/java2d/cmm/lcms/LCMSImageLayout.java ! src/share/classes/sun/java2d/cmm/lcms/LCMSTransform.java ! src/share/demo/java2d/J2DBench/build.xml + src/share/demo/java2d/J2DBench/resources/cmm_images/img_icc_large.jpg + src/share/demo/java2d/J2DBench/resources/cmm_images/img_icc_medium.jpg + src/share/demo/java2d/J2DBench/resources/cmm_images/img_icc_small.jpg ! src/share/demo/java2d/J2DBench/src/j2dbench/tests/cmm/ColorConversionTests.java + src/share/demo/java2d/J2DBench/src/j2dbench/tests/cmm/EmbeddedProfileTests.java ! src/share/native/sun/java2d/cmm/lcms/LCMS.c Changeset: 8e9b133dcec9 Author: lana Date: 2013-03-12 16:26 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/8e9b133dcec9 Merge Changeset: e6c94a202bfd Author: alexsch Date: 2013-02-15 14:24 +0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/e6c94a202bfd 7173873: JFrame.setDefaultCloseOperation(EXIT_ON_CLOSE) will never lead to SE if EXIT_ON_CLOSE is already set Reviewed-by: malenkov, serb ! src/share/classes/javax/swing/JFrame.java Changeset: 4bf242def958 Author: dingxmin Date: 2013-02-15 15:05 +0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/4bf242def958 8008289: DefaultButtonModel instance keeps stale listeners in html FormView Reviewed-by: malenkov, alexsch ! src/share/classes/javax/swing/text/html/FormView.java + test/javax/swing/text/html/7189299/bug7189299.java Changeset: 88a83b9e9baa Author: kshefov Date: 2013-02-15 17:46 +0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/88a83b9e9baa 8005920: After pressing combination Windows Key and M key, the frame, the instruction and the dialog can't be minimized. Reviewed-by: serb, denis Contributed-by: Vera Akulova ! test/java/awt/Modal/WsDisabledStyle/Winkey/Winkey.java Changeset: 0fe12ecf80b2 Author: pchelko Date: 2013-02-19 11:26 +0000 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/0fe12ecf80b2 8008374: Build failure (NEWBUILD=false) on Mac Summary: Fixed an old build system failure Reviewed-by: art, anthony ! make/sun/lwawt/FILES_export_macosx.gmk Changeset: 5ad0bd367f6d Author: kshefov Date: 2013-02-19 17:26 +0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/5ad0bd367f6d 8008379: TEST_BUG: Fail automatically with java.lang.NullPointerException. Reviewed-by: serb, anthony + test/java/awt/Modal/ModalDialogMultiscreenTest/ModalDialogMultiscreenTest.java Changeset: a43115c6359d Author: kshefov Date: 2013-02-19 20:00 +0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/a43115c6359d 8006070: TEST_BUG: Up and down the Y coordinate of the mouse position, the selected item doesn't change for the single list. Reviewed-by: serb, anthony + test/java/awt/List/MouseDraggedOutCauseScrollingTest/MouseDraggedOutCauseScrollingTest.html + test/java/awt/List/MouseDraggedOutCauseScrollingTest/MouseDraggedOutCauseScrollingTest.java Changeset: 9bc26b7b8b47 Author: lana Date: 2013-02-19 22:23 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/9bc26b7b8b47 Merge - src/share/classes/java/time/PeriodParser.java - src/share/classes/java/time/calendar/ChronoDateImpl.java - src/share/classes/java/time/calendar/HijrahChrono.java - src/share/classes/java/time/calendar/HijrahDate.java - src/share/classes/java/time/calendar/HijrahDeviationReader.java - src/share/classes/java/time/calendar/HijrahEra.java - src/share/classes/java/time/calendar/JapaneseChrono.java - src/share/classes/java/time/calendar/JapaneseDate.java - src/share/classes/java/time/calendar/JapaneseEra.java - src/share/classes/java/time/calendar/MinguoChrono.java - src/share/classes/java/time/calendar/MinguoDate.java - src/share/classes/java/time/calendar/MinguoEra.java - src/share/classes/java/time/calendar/Ser.java - src/share/classes/java/time/calendar/ThaiBuddhistChrono.java - src/share/classes/java/time/calendar/ThaiBuddhistDate.java - src/share/classes/java/time/calendar/ThaiBuddhistEra.java - src/share/classes/java/time/calendar/package-info.java - src/share/classes/java/time/format/DateTimeFormatters.java - src/share/classes/java/time/format/DateTimePrintException.java - src/share/classes/java/time/temporal/Chrono.java - src/share/classes/java/time/temporal/ChronoLocalDate.java - src/share/classes/java/time/temporal/ChronoLocalDateTime.java - src/share/classes/java/time/temporal/ChronoLocalDateTimeImpl.java - src/share/classes/java/time/temporal/ChronoZonedDateTime.java - src/share/classes/java/time/temporal/ChronoZonedDateTimeImpl.java - src/share/classes/java/time/temporal/Era.java - src/share/classes/java/time/temporal/ISOChrono.java - src/share/classes/java/time/temporal/ISOEra.java - src/share/classes/java/time/temporal/ISOFields.java - src/share/classes/java/time/temporal/MonthDay.java - src/share/classes/java/time/temporal/OffsetDate.java - src/share/classes/java/time/temporal/OffsetDateTime.java - src/share/classes/java/time/temporal/OffsetTime.java - src/share/classes/java/time/temporal/Ser.java - src/share/classes/java/time/temporal/SimplePeriod.java - src/share/classes/java/time/temporal/TemporalAdder.java - src/share/classes/java/time/temporal/TemporalSubtractor.java - src/share/classes/java/time/temporal/Year.java - src/share/classes/java/time/temporal/YearMonth.java - src/share/classes/sun/util/calendar/TzIDOldMapping.java - test/java/time/META-INF/services/java.time.temporal.Chrono - test/java/time/tck/java/time/calendar/CopticChrono.java - test/java/time/tck/java/time/calendar/CopticDate.java - test/java/time/tck/java/time/calendar/CopticEra.java - test/java/time/tck/java/time/calendar/TestChronoLocalDate.java - test/java/time/tck/java/time/calendar/TestChronoLocalDateTime.java - test/java/time/tck/java/time/calendar/TestHijrahChrono.java - test/java/time/tck/java/time/calendar/TestJapaneseChrono.java - test/java/time/tck/java/time/calendar/TestMinguoChrono.java - test/java/time/tck/java/time/calendar/TestServiceLoader.java - test/java/time/tck/java/time/calendar/TestThaiBuddhistChrono.java - test/java/time/tck/java/time/format/TCKDateTimePrintException.java - test/java/time/tck/java/time/temporal/TCKISOFields.java - test/java/time/tck/java/time/temporal/TCKMonthDay.java - test/java/time/tck/java/time/temporal/TCKOffsetDate.java - test/java/time/tck/java/time/temporal/TCKOffsetDateTime.java - test/java/time/tck/java/time/temporal/TCKOffsetTime.java - test/java/time/tck/java/time/temporal/TCKSimplePeriod.java - test/java/time/tck/java/time/temporal/TCKYear.java - test/java/time/tck/java/time/temporal/TCKYearMonth.java - test/java/time/tck/java/time/temporal/TestChrono.java - test/java/time/tck/java/time/temporal/TestISOChrono.java - test/java/time/test/java/time/TestPeriodParser.java - test/java/time/test/java/time/format/TestDateTimeFormatters.java - test/java/time/test/java/time/format/TestDateTimePrintException.java - test/java/time/test/java/time/format/TestPadParserDecorator.java - test/java/time/test/java/time/format/TestZoneIdParser.java - test/java/time/test/java/time/temporal/TestISOChronoImpl.java - test/java/time/test/java/time/temporal/TestMonthDay.java - test/java/time/test/java/time/temporal/TestOffsetDate.java - test/java/time/test/java/time/temporal/TestOffsetDateTime.java - test/java/time/test/java/time/temporal/TestOffsetDateTime_instants.java - test/java/time/test/java/time/temporal/TestOffsetTime.java - test/java/time/test/java/time/temporal/TestYear.java - test/java/time/test/java/time/temporal/TestYearMonth.java Changeset: 73d1efc4710a Author: ant Date: 2013-02-22 15:13 +0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/73d1efc4710a 8006406: lightweight embedding in other Java UI toolkits Reviewed-by: serb, anthony, art ! src/macosx/classes/sun/lwawt/LWComponentPeer.java + src/macosx/classes/sun/lwawt/LWLightweightFramePeer.java ! src/macosx/classes/sun/lwawt/LWToolkit.java ! src/macosx/classes/sun/lwawt/LWWindowPeer.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformComponent.java + src/macosx/classes/sun/lwawt/macosx/CPlatformLWComponent.java + src/macosx/classes/sun/lwawt/macosx/CPlatformLWView.java + src/macosx/classes/sun/lwawt/macosx/CPlatformLWWindow.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformView.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java ! src/macosx/classes/sun/lwawt/macosx/LWCToolkit.java ! src/share/classes/java/awt/peer/FramePeer.java ! src/share/classes/java/awt/peer/WindowPeer.java ! src/share/classes/sun/awt/EmbeddedFrame.java ! src/share/classes/sun/awt/HToolkit.java + src/share/classes/sun/awt/LightweightFrame.java ! src/share/classes/sun/awt/SunToolkit.java + src/share/classes/sun/swing/JLightweightFrame.java + src/share/classes/sun/swing/LightweightContent.java ! src/solaris/classes/sun/awt/X11/XFramePeer.java ! src/solaris/classes/sun/awt/X11/XToolkit.java ! src/windows/classes/sun/awt/windows/WEmbeddedFrame.java ! src/windows/classes/sun/awt/windows/WEmbeddedFramePeer.java ! src/windows/classes/sun/awt/windows/WFramePeer.java + src/windows/classes/sun/awt/windows/WLightweightFramePeer.java ! src/windows/classes/sun/awt/windows/WToolkit.java ! src/windows/native/sun/windows/awt_Frame.cpp ! src/windows/native/sun/windows/awt_Frame.h ! src/windows/native/sun/windows/awt_Window.h Changeset: 63bb402d4a6a Author: lana Date: 2013-02-23 19:49 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/63bb402d4a6a Merge Changeset: d502cc7bcc3d Author: pchelko Date: 2013-02-25 10:17 +0000 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/d502cc7bcc3d 8006634: Unify LWCToolkit.invokeAndWait() and sun.awt.datatransfer.ToolkitThreadBlockedHandler Summary: Changed the logic for the nested event loops and deleted deadlock detection Reviewed-by: art, denis ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java ! src/macosx/classes/sun/lwawt/macosx/CToolkitThreadBlockedHandler.java ! src/macosx/classes/sun/lwawt/macosx/LWCToolkit.java ! src/macosx/native/sun/awt/AWTView.m ! src/macosx/native/sun/awt/ApplicationDelegate.m ! src/macosx/native/sun/awt/CClipboard.m ! src/macosx/native/sun/awt/CDropTarget.m ! src/macosx/native/sun/awt/CMenu.m ! src/macosx/native/sun/awt/CMenuBar.m ! src/macosx/native/sun/awt/CMenuItem.m ! src/macosx/native/sun/awt/JavaComponentAccessibility.m ! src/macosx/native/sun/awt/LWCToolkit.m ! src/macosx/native/sun/osxapp/ThreadUtilities.h ! src/macosx/native/sun/osxapp/ThreadUtilities.m Changeset: e58f0b163f43 Author: denis Date: 2013-02-27 19:38 +0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/e58f0b163f43 7178079: REGRESSION: Some AWT Drag-n-Drop tests fail since JDK 7u6 b13 Reviewed-by: serb, anthony ! src/macosx/classes/sun/lwawt/macosx/CDropTargetContextPeer.java Changeset: bc914b7f0878 Author: denis Date: 2013-02-27 20:34 +0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/bc914b7f0878 8009158: Incomplete fix for 7178079 Reviewed-by: serb, anthony ! src/share/classes/sun/awt/dnd/SunDropTargetContextPeer.java Changeset: 3dee850e2653 Author: serb Date: 2013-02-28 17:04 +0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/3dee850e2653 8008660: Failure in 2D Queue Flusher thread on Mac Reviewed-by: swingler, bae ! src/macosx/classes/sun/awt/CGraphicsConfig.java ! src/macosx/classes/sun/awt/CGraphicsDevice.java ! src/macosx/classes/sun/java2d/opengl/CGLGraphicsConfig.java ! src/macosx/classes/sun/lwawt/macosx/CRobot.java ! src/macosx/classes/sun/lwawt/macosx/LWCToolkit.java ! src/macosx/native/sun/awt/CRobot.m ! src/macosx/native/sun/awt/LWCToolkit.h ! src/macosx/native/sun/awt/LWCToolkit.m ! src/macosx/native/sun/java2d/opengl/CGLGraphicsConfig.m Changeset: 554d0f41a6ab Author: serb Date: 2013-02-28 20:27 +0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/554d0f41a6ab 8003169: [macosx] JVM crash after disconnecting from projector Reviewed-by: anthony, alexsch ! src/macosx/classes/sun/awt/CGraphicsDevice.java ! src/macosx/classes/sun/lwawt/macosx/LWCToolkit.java ! src/macosx/native/sun/awt/CGraphicsDevice.m Changeset: 657a02fcaa00 Author: malenkov Date: 2013-03-01 14:30 +0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/657a02fcaa00 7163696: JCK Swing interactive test JScrollBarTest0013 fails with Nimbus and GTK L&Fs Reviewed-by: alexsch ! src/share/classes/java/beans/PropertyDescriptor.java ! test/java/beans/Introspector/Test7192955.java Changeset: 5816595a4cdc Author: serb Date: 2013-03-01 15:31 +0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/5816595a4cdc 7194902: [macosx] closed/java/awt/Button/DoubleActionEventTest/DoubleActionEventTest failed since jdk8b49 7181403: Invalid MouseEvent conversion with SwingUtilities.convertMouseEvent Reviewed-by: malenkov, alexsch ! src/macosx/classes/sun/lwawt/LWComponentPeer.java ! src/share/classes/javax/swing/SwingUtilities.java Changeset: 4912a9e3a95e Author: serb Date: 2013-03-01 21:50 +0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/4912a9e3a95e 7184945: [macosx] NPE in AquaComboBoxUI since jdk7u6b17, jdk8b47 Reviewed-by: malenkov, alexsch ! src/macosx/classes/com/apple/laf/AquaComboBoxUI.java Changeset: 91e17a813483 Author: alexsch Date: 2013-03-06 19:42 +0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/91e17a813483 6877495: JTextField and JTextArea does not support supplementary characters Reviewed-by: serb, alexp ! src/share/classes/sun/awt/datatransfer/DataTransferer.java + test/sun/awt/datatransfer/SuplementaryCharactersTransferTest.java Changeset: 7962014b1729 Author: mcherkas Date: 2013-03-06 20:10 +0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/7962014b1729 8007295: Reduce number of warnings in awt classes Reviewed-by: bae, anthony ! src/share/classes/java/awt/CheckboxMenuItem.java ! src/share/classes/java/awt/Cursor.java ! src/share/classes/java/awt/EventQueue.java ! src/share/classes/java/awt/Menu.java ! src/share/classes/java/awt/MenuBar.java ! src/share/classes/java/awt/MenuComponent.java ! src/share/classes/java/awt/MenuItem.java ! src/share/classes/java/awt/RenderingHints.java ! src/share/classes/java/awt/datatransfer/Clipboard.java ! src/share/classes/java/awt/dnd/DragGestureEvent.java ! src/share/classes/java/awt/dnd/DragGestureRecognizer.java ! src/share/classes/java/awt/dnd/DragSource.java ! src/share/classes/java/awt/dnd/InvalidDnDOperationException.java ! src/share/classes/java/awt/geom/AffineTransform.java Changeset: f3ffead3069e Author: lana Date: 2013-03-12 16:28 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/f3ffead3069e Merge Changeset: 153884b550f0 Author: chegar Date: 2013-02-14 13:01 +0000 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/153884b550f0 8008201: Add java/lang/Class/asSubclass/BasicUnit.java to the ProblemList Reviewed-by: mcimadamore ! test/ProblemList.txt Changeset: e57019d2f34a Author: mduigou Date: 2013-02-13 14:50 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/e57019d2f34a 8008167: IdentityHashMap.[keySet|values|entrySet].toArray speed-up Reviewed-by: mduigou, martin Contributed-by: Peter Levart ! src/share/classes/java/util/IdentityHashMap.java Changeset: 1405ad6afb1e Author: bharadwaj Date: 2013-02-14 11:09 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/1405ad6afb1e 8007736: VerifyError for use of static method in interface Reviewed-by: mchung ! src/share/native/common/check_code.c + test/vm/verifier/TestStaticIF.java Changeset: 1ce1a307cded Author: sherman Date: 2013-02-15 01:17 +0000 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/1ce1a307cded 8008254: j.u.Calendar.JavatimeTest failed at TL b78 pit testing Summary: to use j.t.ZoneId zone name to keep round-trip Reviewed-by: okutsu ! test/java/util/Calendar/JavatimeTest.java Changeset: 048637b40787 Author: chegar Date: 2013-02-15 11:06 +0000 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/048637b40787 8008223: java/net/BindException/Test.java fails rarely Reviewed-by: khazra, alanb ! test/java/net/BindException/Test.java Changeset: 7748ffdca16a Author: rfield Date: 2013-02-16 12:36 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/7748ffdca16a 8004970: Implement serialization in the lambda metafactory Reviewed-by: forax ! src/share/classes/java/lang/invoke/AbstractValidatingLambdaMetafactory.java ! src/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java ! src/share/classes/java/lang/invoke/LambdaMetafactory.java ! src/share/classes/java/lang/invoke/MethodHandleInfo.java + src/share/classes/java/lang/invoke/SerializedLambda.java ! src/share/classes/java/lang/invoke/TypeConvertingMethodAdapter.java + test/java/lang/invoke/lambda/LambdaSerialization.java Changeset: 43726ed11fb3 Author: sherman Date: 2013-02-17 01:01 +0000 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/43726ed11fb3 8008348: The leftover jdk/make/tools/javazic causes build problems with hs25-b19 control Summary: To remove jdk/make/tools/javazic from the jdk repo Reviewed-by: alanb - make/tools/javazic/Makefile - make/tools/src/build/tools/javazic/BackEnd.java - make/tools/src/build/tools/javazic/Checksum.java - make/tools/src/build/tools/javazic/DayOfWeek.java - make/tools/src/build/tools/javazic/Gen.java - make/tools/src/build/tools/javazic/GenDoc.java - make/tools/src/build/tools/javazic/Main.java - make/tools/src/build/tools/javazic/Mappings.java - make/tools/src/build/tools/javazic/Month.java - make/tools/src/build/tools/javazic/Rule.java - make/tools/src/build/tools/javazic/RuleDay.java - make/tools/src/build/tools/javazic/RuleRec.java - make/tools/src/build/tools/javazic/Simple.java - make/tools/src/build/tools/javazic/Time.java - make/tools/src/build/tools/javazic/Timezone.java - make/tools/src/build/tools/javazic/Zone.java - make/tools/src/build/tools/javazic/ZoneRec.java - make/tools/src/build/tools/javazic/Zoneinfo.java Changeset: ce6a2fcb4c9b Author: yhuang Date: 2013-02-16 21:22 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/ce6a2fcb4c9b 8006748: getISO3Country() returns wrong value Reviewed-by: naoto ! src/share/classes/java/util/LocaleISOData.java Changeset: bcde0486261e Author: dingxmin Date: 2013-02-18 08:14 +0000 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/bcde0486261e 6429204: (se) Concurrent Selector.register and SelectionKey.interestOps can ignore interestOps Reviewed-by: alanb ! src/windows/classes/sun/nio/ch/WindowsSelectorImpl.java + test/java/nio/channels/Selector/RacyDeregister.java Changeset: 49b3d8efd30a Author: darcy Date: 2013-02-19 00:19 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/49b3d8efd30a 8008434: Misc javadoc warning fixes in DateTimeFormatterBuilder and TimeZone Reviewed-by: mduigou, okutsu ! src/share/classes/java/time/format/DateTimeFormatterBuilder.java ! src/share/classes/java/util/TimeZone.java Changeset: 885bb24f6018 Author: coffeys Date: 2013-02-19 14:07 +0000 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/885bb24f6018 7197187: Currency.isPastCutoverDate should be made more robust Reviewed-by: alanb ! src/share/classes/java/util/Currency.java Changeset: 01b6b0dd2006 Author: coffeys Date: 2013-02-19 14:12 +0000 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/01b6b0dd2006 8007315: HttpURLConnection.filterHeaderField method returns null where empty string is expected Reviewed-by: chegar ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java ! test/sun/net/www/protocol/http/HttpOnly.java Changeset: 824187de1591 Author: jzavgren Date: 2013-02-19 16:19 +0000 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/824187de1591 8007609: WinNTFileSystem_md.c should correctly check value returned from realloc Reviewed-by: alanb, chegar, dholmes ! src/windows/native/java/io/WinNTFileSystem_md.c Changeset: e20c1c9197bf Author: emc Date: 2013-02-19 17:09 +0000 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/e20c1c9197bf 8008312: Re-enable MethodParameter tests in JDK Reviewed-by: darcy ! src/share/classes/java/lang/reflect/Parameter.java ! test/java/lang/reflect/Parameter/WithParameters.java Changeset: af396ec087f4 Author: naoto Date: 2013-02-19 10:34 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/af396ec087f4 7092447: Clarify the default locale used in each locale sensitive operation Reviewed-by: okutsu ! src/share/classes/java/text/DateFormat.java ! src/share/classes/java/text/DateFormatSymbols.java ! src/share/classes/java/text/DecimalFormat.java ! src/share/classes/java/text/DecimalFormatSymbols.java ! src/share/classes/java/text/MessageFormat.java ! src/share/classes/java/text/NumberFormat.java ! src/share/classes/java/text/SimpleDateFormat.java ! src/share/classes/java/time/format/DateTimeFormatSymbols.java ! src/share/classes/java/util/Calendar.java ! src/share/classes/java/util/Currency.java ! src/share/classes/java/util/Formatter.java ! src/share/classes/java/util/GregorianCalendar.java ! src/share/classes/java/util/Locale.java ! src/share/classes/java/util/Scanner.java Changeset: 16efb7ba188f Author: mduigou Date: 2013-02-19 11:56 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/16efb7ba188f 8004561: Additional functional interfaces, extension methods and name changes Summary: Adds additional functional interfaces for primitives and "Bi" (two operand). Adds utility extension methods. Includes some name changes for existing functional interfaces per EG decisions. Reviewed-by: briangoetz, darcy, chegar, dholmes ! src/share/classes/java/time/chrono/HijrahDeviationReader.java ! src/share/classes/java/util/concurrent/atomic/AtomicInteger.java ! src/share/classes/java/util/concurrent/atomic/AtomicIntegerArray.java ! src/share/classes/java/util/concurrent/atomic/AtomicIntegerFieldUpdater.java ! src/share/classes/java/util/concurrent/atomic/AtomicLong.java ! src/share/classes/java/util/concurrent/atomic/AtomicLongArray.java ! src/share/classes/java/util/concurrent/atomic/AtomicLongFieldUpdater.java ! src/share/classes/java/util/concurrent/atomic/AtomicReference.java ! src/share/classes/java/util/concurrent/atomic/AtomicReferenceArray.java ! src/share/classes/java/util/concurrent/atomic/AtomicReferenceFieldUpdater.java ! src/share/classes/java/util/concurrent/atomic/DoubleAccumulator.java ! src/share/classes/java/util/concurrent/atomic/LongAccumulator.java ! src/share/classes/java/util/concurrent/atomic/Striped64.java + src/share/classes/java/util/function/BiConsumer.java + src/share/classes/java/util/function/BiFunction.java + src/share/classes/java/util/function/BiPredicate.java ! src/share/classes/java/util/function/BinaryOperator.java - src/share/classes/java/util/function/Block.java + src/share/classes/java/util/function/BooleanSupplier.java + src/share/classes/java/util/function/Consumer.java ! src/share/classes/java/util/function/DoubleBinaryOperator.java - src/share/classes/java/util/function/DoubleBlock.java + src/share/classes/java/util/function/DoubleConsumer.java ! src/share/classes/java/util/function/DoubleFunction.java + src/share/classes/java/util/function/DoublePredicate.java ! src/share/classes/java/util/function/DoubleSupplier.java ! src/share/classes/java/util/function/DoubleUnaryOperator.java ! src/share/classes/java/util/function/Function.java ! src/share/classes/java/util/function/IntBinaryOperator.java - src/share/classes/java/util/function/IntBlock.java + src/share/classes/java/util/function/IntConsumer.java ! src/share/classes/java/util/function/IntFunction.java + src/share/classes/java/util/function/IntPredicate.java ! src/share/classes/java/util/function/IntSupplier.java ! src/share/classes/java/util/function/IntUnaryOperator.java ! src/share/classes/java/util/function/LongBinaryOperator.java - src/share/classes/java/util/function/LongBlock.java + src/share/classes/java/util/function/LongConsumer.java ! src/share/classes/java/util/function/LongFunction.java + src/share/classes/java/util/function/LongPredicate.java ! src/share/classes/java/util/function/LongSupplier.java ! src/share/classes/java/util/function/LongUnaryOperator.java + src/share/classes/java/util/function/ObjDoubleConsumer.java + src/share/classes/java/util/function/ObjIntConsumer.java + src/share/classes/java/util/function/ObjLongConsumer.java ! src/share/classes/java/util/function/Predicate.java + src/share/classes/java/util/function/ToDoubleBiFunction.java + src/share/classes/java/util/function/ToDoubleFunction.java + src/share/classes/java/util/function/ToIntBiFunction.java + src/share/classes/java/util/function/ToIntFunction.java + src/share/classes/java/util/function/ToLongBiFunction.java + src/share/classes/java/util/function/ToLongFunction.java ! src/share/classes/java/util/function/UnaryOperator.java ! src/share/classes/java/util/function/package-info.java ! test/java/lang/PrimitiveSumMinMaxTest.java Changeset: 267bca6af07e Author: jzavgren Date: 2013-02-19 15:31 -0500 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/267bca6af07e 8008107: [parfait] Use after free of pointer in jdk/src/share/native/sun/security/pkcs11/wrapper/p11_convert.c Reviewed-by: mullan, chegar ! src/share/native/sun/security/pkcs11/wrapper/p11_convert.c Changeset: ec1a79c3a99c Author: ksrini Date: 2013-02-19 16:49 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/ec1a79c3a99c 8008262: pack200 should support MethodParameters - part 2 Reviewed-by: jrose ! src/share/classes/com/sun/java/util/jar/pack/Attribute.java ! src/share/classes/com/sun/java/util/jar/pack/BandStructure.java ! src/share/classes/com/sun/java/util/jar/pack/PackageReader.java ! src/share/native/com/sun/java/util/jar/pack/bands.cpp ! src/share/native/com/sun/java/util/jar/pack/bands.h ! src/share/native/com/sun/java/util/jar/pack/unpack.cpp ! test/tools/pack200/AttributeTests.java ! test/tools/pack200/Utils.java Changeset: 85a44860f5bb Author: lana Date: 2013-02-19 20:52 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/85a44860f5bb Merge - src/macosx/classes/sun/lwawt/macosx/EventDispatchAccess.java Changeset: ca43e2761a1d Author: ykantser Date: 2013-02-13 10:24 +0100 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/ca43e2761a1d 8008089: Delete OS dependent check in JdkFinder.getExecutable() Reviewed-by: egahlin, alanb ! test/lib/testlibrary/jdk/testlibrary/JdkFinder.java Changeset: 0a2b308cc82d Author: uta Date: 2013-02-20 16:39 +0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/0a2b308cc82d 8007454: (process) SetHandleInformation parameters DWORD (not BOOLEAN) Summary: the SetHandleInformation arguments list was fixed. Reviewed-by: alanb ! src/windows/native/java/lang/ProcessImpl_md.c Changeset: 5772e9edbc4c Author: dcubed Date: 2013-02-20 13:23 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/5772e9edbc4c 8008352: java/lang/instrument/RedefineSubclassWithTwoInterfaces.sh fails on MKS Summary: Use more portable pattern counting constructs in test driver. Reviewed-by: sspitsyn, sla, coleenp ! test/java/lang/instrument/RedefineSubclassWithTwoInterfaces.sh Changeset: 1da987f0311a Author: rfield Date: 2013-02-21 15:46 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/1da987f0311a 8008356: Test LambdaSerialization.java failing Summary: run in /othervm mode Reviewed-by: ksrini ! test/java/lang/invoke/lambda/LambdaSerialization.java Changeset: 03db11a7fb8e Author: lana Date: 2013-02-21 17:43 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/03db11a7fb8e Merge Changeset: 9078c34437ab Author: msheppar Date: 2013-02-21 20:01 +0000 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/9078c34437ab 8006182: cleanup to use java.util.Base64 in java security component, providers, and regression tests Summary: Refactored code to use java.util.Base64 Mime Encoder and Decoder as a replacement for sun.misc.BASE64Encoder and sun.misc.BASE64Decoder Reviewed-by: vinnie, chegar, sherman ! src/share/classes/sun/security/pkcs10/PKCS10.java ! src/share/classes/sun/security/provider/X509Factory.java ! src/share/classes/sun/security/tools/jarsigner/Main.java ! src/share/classes/sun/security/tools/keytool/Main.java ! src/share/classes/sun/security/util/ManifestEntryVerifier.java ! src/share/classes/sun/security/util/SignatureFileVerifier.java ! src/share/classes/sun/security/x509/X509CertImpl.java ! src/share/classes/sun/tools/jar/Manifest.java ! src/share/classes/sun/tools/jar/SignatureFile.java ! test/javax/security/auth/kerberos/KerberosTixDateTest.java ! test/sun/security/krb5/auto/HttpNegotiateServer.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLContextImpl/MD2InTrustAnchor.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLContextImpl/TrustTrustedCert.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/BasicConstraints.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/SelfIssuedCert.java ! test/sun/security/ssl/com/sun/net/ssl/internal/www/protocol/https/HttpsClient/ProxyTunnelServer.java ! test/sun/security/ssl/javax/net/ssl/ServerName/SSLSocketSNISensitive.java ! test/sun/security/ssl/javax/net/ssl/TLSv12/DisabledShortRSAKeys.java ! test/sun/security/ssl/javax/net/ssl/TLSv12/ShortRSAKey512.java ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/ProxyTunnelServer.java Changeset: c6d77b2b4478 Author: stefank Date: 2013-01-22 13:53 +0100 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/c6d77b2b4478 8006506: Add test for redefining methods in backtraces to java/lang/instrument tests Reviewed-by: sspitsyn, coleenp + test/java/lang/instrument/RedefineMethodInBacktrace.sh + test/java/lang/instrument/RedefineMethodInBacktraceAgent.java + test/java/lang/instrument/RedefineMethodInBacktraceApp.java + test/java/lang/instrument/RedefineMethodInBacktraceTarget.java + test/java/lang/instrument/RedefineMethodInBacktraceTarget_2.java Changeset: 0e93015e77f6 Author: stefank Date: 2013-01-22 15:25 +0100 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/0e93015e77f6 7140852: Add test for 7022100 Reviewed-by: sspitsyn, coleenp + test/java/lang/instrument/RedefineMethodWithAnnotations.sh + test/java/lang/instrument/RedefineMethodWithAnnotationsAgent.java + test/java/lang/instrument/RedefineMethodWithAnnotationsAnnotations.java + test/java/lang/instrument/RedefineMethodWithAnnotationsApp.java + test/java/lang/instrument/RedefineMethodWithAnnotationsTarget.java + test/java/lang/instrument/RedefineMethodWithAnnotationsTarget_2.java Changeset: 63fe6a9820b6 Author: alanb Date: 2013-02-22 14:04 +0000 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/63fe6a9820b6 8008290: (profiles) Startup regression due to additional checking of JAR file manifests Reviewed-by: lancea, chegar, iris, mchung, sherman ! src/share/classes/java/util/jar/JarFile.java ! src/share/classes/java/util/jar/JavaUtilJarAccessImpl.java ! src/share/classes/sun/misc/JavaUtilJarAccess.java ! src/share/classes/sun/misc/URLClassPath.java Changeset: 9f9dac5a9e74 Author: lancea Date: 2013-02-22 09:29 -0500 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/9f9dac5a9e74 8008716: address typo in CallableStatement javadocs Reviewed-by: chegar ! src/share/classes/java/sql/CallableStatement.java Changeset: 8d8a35ac7d40 Author: lancea Date: 2013-02-22 09:58 -0500 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/8d8a35ac7d40 Merge Changeset: 6f9b3e216b01 Author: darcy Date: 2013-02-23 13:32 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/6f9b3e216b01 6556996: (ann spec) SuppressWarnings strings should be documented Reviewed-by: mduigou, chegar, abuckley ! src/share/classes/java/lang/Deprecated.java ! src/share/classes/java/lang/Override.java ! src/share/classes/java/lang/SafeVarargs.java ! src/share/classes/java/lang/SuppressWarnings.java ! src/share/classes/java/lang/annotation/Inherited.java ! src/share/classes/java/lang/annotation/Retention.java ! src/share/classes/java/lang/annotation/Target.java Changeset: 155095c245b4 Author: alanb Date: 2013-02-25 17:17 +0000 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/155095c245b4 8008808: Allowed dependencies added by JDK-8008481 no longer required Reviewed-by: tbell, chegar ! make/tools/src/build/tools/deps/refs.allowed Changeset: 58f829566fe3 Author: bchristi Date: 2013-02-25 14:19 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/58f829566fe3 8006039: test/tools/launcher/I18NJarTest.java fails on Mac w/ LANG=C, LC_ALL=C Summary: Avoid automated test failure by just exiting when in 'C' locale Reviewed-by: naoto, ksrini ! test/ProblemList.txt ! test/tools/launcher/I18NJarTest.java Changeset: 4cf4403c9bf2 Author: jjg Date: 2013-02-25 15:08 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/4cf4403c9bf2 8008914: Add nashorn to the tl build Reviewed-by: mr, tbell, jjh Contributed-by: erik.joelsson at oracle.com, james.laskey at oracle.com ! make/launchers/Makefile ! makefiles/CompileLaunchers.gmk ! makefiles/CreateJars.gmk ! test/tools/launcher/VersionCheck.java Changeset: bc92e4b044e2 Author: kmo Date: 2013-02-26 11:05 +0000 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/bc92e4b044e2 7087570: java.lang.invoke.MemberName information wrong for method handles created with findConstructor Summary: REF_invokeSpecial DMHs (which are unusual) get marked explicitly; tweak the MHI to use this bit Reviewed-by: jrose, twisti ! src/share/classes/java/lang/invoke/DirectMethodHandle.java ! src/share/classes/java/lang/invoke/MethodHandle.java ! src/share/classes/java/lang/invoke/MethodHandleImpl.java ! src/share/classes/java/lang/invoke/MethodHandleInfo.java ! src/share/classes/java/lang/invoke/MethodHandles.java + test/java/lang/invoke/7087570/Test7087570.java Changeset: 5fcecbcefb71 Author: chegar Date: 2013-02-26 11:06 +0000 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/5fcecbcefb71 Merge Changeset: 77447981db73 Author: chegar Date: 2013-02-26 11:18 +0000 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/77447981db73 Merge Changeset: 022cd5adc0fa Author: alanb Date: 2013-02-26 14:16 +0000 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/022cd5adc0fa 8008977: profiles build broken by Nashorn build changes Reviewed-by: chegar ! makefiles/profile-rtjar-includes.txt Changeset: 5ebc62421717 Author: rfield Date: 2013-02-26 10:38 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/5ebc62421717 8008770: SerializedLambda incorrect class loader for lambda deserializing class Summary: current thread's context ClassLoader was used to load class by name, pass class not name in serialization (Thank you Peter Levart for test and prototype. Thank you Sundar and Peter for unofficial reviews) Reviewed-by: forax ! src/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java ! src/share/classes/java/lang/invoke/SerializedLambda.java + test/java/lang/invoke/lambda/LambdaClassLoaderSerialization.java ! test/java/lang/invoke/lambda/LambdaSerialization.java Changeset: ecd33c6ab12f Author: alanb Date: 2013-02-26 22:39 +0000 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/ecd33c6ab12f 8009029: SunEC provider classes ending up in rt.jar after Nashorn build changes Reviewed-by: mduigou ! makefiles/CreateJars.gmk Changeset: 543be9488e50 Author: darcy Date: 2013-02-26 17:01 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/543be9488e50 8009102: Several docs warnings in Project Lambda APIs Reviewed-by: mduigou ! src/share/classes/java/lang/invoke/LambdaMetafactory.java ! src/share/classes/java/util/function/BinaryOperator.java ! src/share/classes/java/util/function/ToDoubleBiFunction.java Changeset: d623f520557b Author: darcy Date: 2013-02-26 17:38 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/d623f520557b 8008279: Remove InvalidContainerAnnotationError.java Reviewed-by: jfranck - src/share/classes/java/lang/annotation/InvalidContainerAnnotationError.java ! src/share/classes/java/lang/reflect/AnnotatedElement.java ! src/share/classes/sun/reflect/annotation/AnnotationSupport.java Changeset: f5416026cdf5 Author: sundar Date: 2013-02-27 17:22 +0530 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/f5416026cdf5 8009115: jtreg tests under jdk/test/javax/script should use nashorn as script engine Reviewed-by: alanb ! test/javax/script/CauseExceptionTest.java + test/javax/script/ExceptionTest.java ! test/javax/script/GetInterfaceTest.java ! test/javax/script/Helper.java - test/javax/script/RhinoExceptionTest.java ! test/javax/script/StringWriterPrintTest.java ! test/javax/script/Test3.js ! test/javax/script/Test5.java ! test/javax/script/Test5.js ! test/javax/script/Test6.java ! test/javax/script/Test7.js ! test/javax/script/UnescapedBracketRegExTest.java ! test/javax/script/VersionTest.java Changeset: 13013dedcdfd Author: alanb Date: 2013-02-27 14:24 +0000 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/13013dedcdfd 8008793: SecurityManager.checkXXX behavior not specified for methods that check AWTPermission and AWT not present Reviewed-by: hawtin, mullan, dsamersoff, mchung ! src/share/classes/java/lang/SecurityManager.java ! src/share/classes/sun/security/util/SecurityConstants.java ! test/java/lang/SecurityManager/NoAWT.java Changeset: 1b3173c326e6 Author: sundar Date: 2013-02-27 20:34 +0530 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/1b3173c326e6 8009140: jtreg tests under sun/tools/jrunscript should use nashorn engine Reviewed-by: alanb ! test/sun/tools/jrunscript/CheckEngine.java ! test/sun/tools/jrunscript/jrunscript-DTest.sh ! test/sun/tools/jrunscript/jrunscript-argsTest.sh ! test/sun/tools/jrunscript/jrunscript-cpTest.sh ! test/sun/tools/jrunscript/jrunscript-eTest.sh ! test/sun/tools/jrunscript/jrunscript-fTest.sh ! test/sun/tools/jrunscript/jrunscriptTest.sh ! test/sun/tools/jrunscript/repl.out Changeset: 093fdf8937bd Author: vladidan Date: 2013-02-22 17:12 -0500 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/093fdf8937bd 8005545: Add System property to identify ARCH specific details such as ARM hard-float binaries Summary: Adding sun.os.abi Java Property support Reviewed-by: bobv, alanb, dholmes ! makefiles/Images.gmk ! src/share/native/java/lang/System.c ! src/share/native/java/lang/java_props.h ! src/solaris/native/java/lang/java_props_md.c Changeset: f4b01f4e8f35 Author: mduigou Date: 2013-02-27 11:00 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/f4b01f4e8f35 8008785: IdentityHashMap.values().toArray(V[]) broken by JDK-8008167 Reviewed-by: alanb ! src/share/classes/java/util/IdentityHashMap.java + test/java/util/Map/ToArray.java Changeset: 7d272e524768 Author: chegar Date: 2013-02-28 12:39 +0000 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/7d272e524768 8006409: ThreadLocalRandom should dropping padding fields from its serialized form Reviewed-by: dl, martin, alanb, shade ! src/share/classes/java/util/concurrent/ThreadLocalRandom.java Changeset: 7246a6e4dd5a Author: juh Date: 2013-02-28 16:36 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/7246a6e4dd5a 8006853: OCSP timeout set to wrong value if com.sun.security.ocsp.timeout < 0 Reviewed-by: mullan ! src/share/classes/sun/security/provider/certpath/OCSP.java Changeset: def2e05299b7 Author: xuelei Date: 2013-03-01 02:34 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/def2e05299b7 7030966: Support AEAD CipherSuites Reviewed-by: weijun, wetmore, valeriep ! src/share/classes/com/sun/crypto/provider/TlsKeyMaterialGenerator.java ! src/share/classes/sun/security/internal/spec/TlsKeyMaterialParameterSpec.java ! src/share/classes/sun/security/internal/spec/TlsKeyMaterialSpec.java ! src/share/classes/sun/security/pkcs11/P11TlsKeyMaterialGenerator.java + src/share/classes/sun/security/ssl/Authenticator.java ! src/share/classes/sun/security/ssl/CipherBox.java ! src/share/classes/sun/security/ssl/CipherSuite.java ! src/share/classes/sun/security/ssl/EngineInputRecord.java ! src/share/classes/sun/security/ssl/EngineOutputRecord.java ! src/share/classes/sun/security/ssl/EngineWriter.java ! src/share/classes/sun/security/ssl/Handshaker.java ! src/share/classes/sun/security/ssl/InputRecord.java ! src/share/classes/sun/security/ssl/JsseJce.java ! src/share/classes/sun/security/ssl/MAC.java ! src/share/classes/sun/security/ssl/OutputRecord.java ! src/share/classes/sun/security/ssl/Record.java ! src/share/classes/sun/security/ssl/SSLEngineImpl.java ! src/share/classes/sun/security/ssl/SSLSocketImpl.java ! test/sun/security/ec/TestEC.java ! test/sun/security/pkcs11/fips/CipherTest.java ! test/sun/security/pkcs11/sslecc/CipherTest.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl/SSLEngineBadBufferArrayAccess.java + test/sun/security/ssl/javax/net/ssl/TLSv12/ShortRSAKeyGCM.java ! test/sun/security/ssl/sanity/ciphersuites/CipherSuitesInOrder.java ! test/sun/security/ssl/sanity/interop/CipherTest.java ! test/sun/security/ssl/templates/SSLSocketSSLEngineTemplate.java Changeset: 1652ac7b4bfd Author: mullan Date: 2013-03-01 16:12 -0500 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/1652ac7b4bfd 8008908: Access denied when invoking Subject.doAsPrivileged() Summary: wildcard principal names are not processed correctly Reviewed-by: xuelei ! src/share/classes/sun/security/provider/PolicyFile.java + test/sun/security/provider/PolicyFile/WildcardPrincipalName.java + test/sun/security/provider/PolicyFile/wildcard.policy Changeset: 1ca712765acb Author: mullan Date: 2013-03-01 16:15 -0500 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/1ca712765acb Merge Changeset: 30e30ef6077e Author: dxu Date: 2013-03-01 14:12 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/30e30ef6077e 8006645: TEST_BUG: java/nio/file/Files/CopyAndMove.java failing intermittently (sol) Summary: Fix test failures and update java doc of Files.move Reviewed-by: alanb, chegar ! src/share/classes/java/nio/file/Files.java ! test/java/nio/file/Files/CopyAndMove.java Changeset: f08ad5938709 Author: chegar Date: 2013-03-02 08:54 +0000 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/f08ad5938709 8008378: FJP.commonPool support parallelism 0, add awaitQuiescence Reviewed-by: chegar Contributed-by: Doug Lea
, Chris Hegarty ! src/share/classes/java/util/concurrent/ForkJoinPool.java ! src/share/classes/java/util/concurrent/ForkJoinTask.java + test/java/util/concurrent/forkjoin/ThreadLessCommon.java + test/java/util/concurrent/forkjoin/ThrowingRunnable.java Changeset: df76ba760eec Author: ksrini Date: 2013-03-03 20:52 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/df76ba760eec 8007297: [pack200] allow opcodes with InterfaceMethodRefs Reviewed-by: jrose ! src/share/classes/com/sun/java/util/jar/pack/ClassReader.java ! src/share/classes/com/sun/java/util/jar/pack/ConstantPool.java ! src/share/classes/com/sun/java/util/jar/pack/Constants.java ! src/share/classes/com/sun/java/util/jar/pack/Instruction.java ! src/share/classes/com/sun/java/util/jar/pack/PackageReader.java ! src/share/classes/com/sun/java/util/jar/pack/PackageWriter.java ! src/share/native/com/sun/java/util/jar/pack/constants.h ! src/share/native/com/sun/java/util/jar/pack/unpack.cpp ! test/tools/pack200/AttributeTests.java ! test/tools/pack200/InstructionTests.java ! test/tools/pack200/Utils.java Changeset: 83e847f59fd6 Author: darcy Date: 2013-03-04 19:42 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/83e847f59fd6 8009267: Restore isAnnotationPresent methods in public AnnotatedElement implementations Reviewed-by: jjg ! src/share/classes/java/lang/Class.java ! src/share/classes/java/lang/Package.java ! src/share/classes/java/lang/reflect/AccessibleObject.java + test/java/lang/reflect/OldenCompilingWithDefaults.java Changeset: 1a2e59d19d3e Author: naoto Date: 2013-03-04 20:46 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/1a2e59d19d3e 8004240: Return value from getAdapterPrefence() can be modified Reviewed-by: okutsu ! src/share/classes/sun/util/locale/provider/LocaleProviderAdapter.java + test/java/util/Locale/Bug8004240.java Changeset: 62639ca66ab9 Author: ewang Date: 2013-03-05 10:10 +0000 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/62639ca66ab9 8009259: TEST_BUG: sun/misc/Cleaner/exitOnThrow.sh failing intermittently Reviewed-by: chegar, alanb ! test/sun/misc/Cleaner/ExitOnThrow.java ! test/sun/misc/Cleaner/exitOnThrow.sh Changeset: b5bef1f71de6 Author: jzavgren Date: 2013-03-05 14:30 +0000 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/b5bef1f71de6 8008804: file descriptor leak in src/windows/native/java/net/DualStackPlainSocketImpl.c Reviewed-by: alanb, chegar, dsamersoff ! src/windows/native/java/net/DualStackPlainDatagramSocketImpl.c Changeset: be79440b8026 Author: jzavgren Date: 2013-03-05 09:50 -0500 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/be79440b8026 4880778: URL final class has protected methods Summary: The two set() methods have been defined to be package private. Reviewed-by: alanb, chegar, khazra ! src/share/classes/java/net/URL.java ! src/share/classes/java/net/URLStreamHandler.java Changeset: f960a34f05ce Author: lana Date: 2013-03-05 11:49 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/f960a34f05ce Merge ! makefiles/Images.gmk Changeset: 34372bb9115d Author: sla Date: 2013-03-05 19:25 +0100 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/34372bb9115d 8009397: test/com/sun/jdi/PrivateTransportTest.sh: ERROR: transport library missing onLoad entry: private_dt_socket Reviewed-by: alanb ! src/share/back/transport.c ! src/share/demo/jvmti/hprof/hprof_init.c ! src/solaris/back/linker_md.c ! src/solaris/demo/jvmti/hprof/hprof_md.c ! src/windows/back/linker_md.c ! src/windows/demo/jvmti/hprof/hprof_md.c Changeset: 38e1821c4472 Author: jfranck Date: 2013-03-06 18:35 +0100 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/38e1821c4472 8007808: Missing method: Executable.getAnnotatedReturnType() Reviewed-by: darcy, forax ! src/share/classes/java/lang/reflect/Constructor.java ! src/share/classes/java/lang/reflect/Executable.java ! src/share/classes/java/lang/reflect/Method.java Changeset: 14e49a70729a Author: martin Date: 2013-03-06 17:43 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/14e49a70729a 8008759: Do not let internal JDK zlib symbols leak out of fastdebug libzip.so Summary: Define FILES_m to force use of linker script Reviewed-by: sherman, alanb, ohair ! make/java/zip/Makefile ! src/share/native/java/util/zip/Inflater.c Changeset: cf54f6be3e9e Author: weijun Date: 2013-03-07 11:32 +0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/cf54f6be3e9e 8009604: old make images failed: JarBASE64Encoder class not found Reviewed-by: xuelei, wetmore ! make/common/Release.gmk Changeset: 48b7295f02f8 Author: chegar Date: 2013-03-07 10:07 +0000 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/48b7295f02f8 6370908: Add support for HTTP_CONNECT proxy in Socket class Reviewed-by: chegar Contributed-by: Damjan Jovanovic , Chris Hegarty + src/share/classes/java/net/HttpConnectSocketImpl.java ! src/share/classes/java/net/Socket.java + test/java/net/Socket/HttpProxy.java Changeset: 98cf76df3e6e Author: alanb Date: 2013-03-08 12:03 +0000 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/98cf76df3e6e 8006000: TEST_BUG: java/lang/invoke/lambda/LambdaAccessControlTest.java fails intermittently Reviewed-by: chegar + test/java/lang/invoke/lambda/LUtils.java ! test/java/lang/invoke/lambda/LambdaAccessControlDoPrivilegedTest.java ! test/java/lang/invoke/lambda/LambdaAccessControlTest.java Changeset: 01908630df14 Author: alanb Date: 2013-03-08 19:51 +0000 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/01908630df14 8009645: ClassFileTransformer hooks in ClassLoader no longer required Reviewed-by: mchung, iris ! src/share/classes/java/lang/ClassLoader.java ! src/share/classes/sun/misc/ClassFileTransformer.java Changeset: e38b46041049 Author: mduigou Date: 2013-03-08 15:45 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/e38b46041049 8001667: Comparator combinators and extension methods Reviewed-by: mduigou, briangoetz Contributed-by: henry.jen at oracle.com ! make/java/java/FILES_java.gmk ! src/share/classes/java/util/Collections.java ! src/share/classes/java/util/Comparator.java + src/share/classes/java/util/Comparators.java ! test/java/util/Collections/ReverseOrder.java + test/java/util/ComparatorsTest.java Changeset: 230bafd05509 Author: weijun Date: 2013-03-09 17:27 +0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/230bafd05509 8000653: SPNEGO tests fail at context.getDelegCred().getRemainingInitLifetime(mechOid) Reviewed-by: valeriep ! src/share/classes/sun/security/jgss/GSSCredentialImpl.java ! src/share/classes/sun/security/jgss/spnego/SpNegoCredElement.java ! test/sun/security/krb5/auto/Context.java + test/sun/security/krb5/auto/SpnegoLifeTime.java Changeset: 334ddf3b101f Author: coleenp Date: 2013-03-12 10:35 -0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/334ddf3b101f 7154889: Non-zero padding is still not allowed in the tableswitch/lookupswitch instructions. Summary: Do not check that the padding bytes are zero if class file format version >=51. Reviewed-by: dholmes, coleenp, mullan, kvn Contributed-by: harold.seigel at oracle.com ! src/share/native/common/check_code.c Changeset: 6379415d8fca Author: wetmore Date: 2013-03-12 15:31 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/6379415d8fca 8009925: Back out AEAD CipherSuites temporarily Reviewed-by: valeriep ! src/share/classes/com/sun/crypto/provider/TlsKeyMaterialGenerator.java ! src/share/classes/sun/security/internal/spec/TlsKeyMaterialParameterSpec.java ! src/share/classes/sun/security/internal/spec/TlsKeyMaterialSpec.java ! src/share/classes/sun/security/pkcs11/P11TlsKeyMaterialGenerator.java - src/share/classes/sun/security/ssl/Authenticator.java ! src/share/classes/sun/security/ssl/CipherBox.java ! src/share/classes/sun/security/ssl/CipherSuite.java ! src/share/classes/sun/security/ssl/EngineInputRecord.java ! src/share/classes/sun/security/ssl/EngineOutputRecord.java ! src/share/classes/sun/security/ssl/EngineWriter.java ! src/share/classes/sun/security/ssl/Handshaker.java ! src/share/classes/sun/security/ssl/InputRecord.java ! src/share/classes/sun/security/ssl/JsseJce.java ! src/share/classes/sun/security/ssl/MAC.java ! src/share/classes/sun/security/ssl/OutputRecord.java ! src/share/classes/sun/security/ssl/Record.java ! src/share/classes/sun/security/ssl/SSLEngineImpl.java ! src/share/classes/sun/security/ssl/SSLSocketImpl.java ! test/sun/security/ec/TestEC.java ! test/sun/security/pkcs11/fips/CipherTest.java ! test/sun/security/pkcs11/sslecc/CipherTest.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl/SSLEngineBadBufferArrayAccess.java - test/sun/security/ssl/javax/net/ssl/TLSv12/ShortRSAKeyGCM.java ! test/sun/security/ssl/sanity/ciphersuites/CipherSuitesInOrder.java ! test/sun/security/ssl/sanity/interop/CipherTest.java ! test/sun/security/ssl/templates/SSLSocketSSLEngineTemplate.java Changeset: 5880bfd30db1 Author: lana Date: 2013-03-12 16:40 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/5880bfd30db1 Merge - make/tools/javazic/Makefile - make/tools/src/build/tools/javazic/BackEnd.java - make/tools/src/build/tools/javazic/Checksum.java - make/tools/src/build/tools/javazic/DayOfWeek.java - make/tools/src/build/tools/javazic/Gen.java - make/tools/src/build/tools/javazic/GenDoc.java - make/tools/src/build/tools/javazic/Main.java - make/tools/src/build/tools/javazic/Mappings.java - make/tools/src/build/tools/javazic/Month.java - make/tools/src/build/tools/javazic/Rule.java - make/tools/src/build/tools/javazic/RuleDay.java - make/tools/src/build/tools/javazic/RuleRec.java - make/tools/src/build/tools/javazic/Simple.java - make/tools/src/build/tools/javazic/Time.java - make/tools/src/build/tools/javazic/Timezone.java - make/tools/src/build/tools/javazic/Zone.java - make/tools/src/build/tools/javazic/ZoneRec.java - make/tools/src/build/tools/javazic/Zoneinfo.java - src/share/classes/java/lang/annotation/InvalidContainerAnnotationError.java - src/share/classes/java/util/function/Block.java - src/share/classes/java/util/function/DoubleBlock.java - src/share/classes/java/util/function/IntBlock.java - src/share/classes/java/util/function/LongBlock.java - test/javax/script/RhinoExceptionTest.java Changeset: 72ffb2bc15bb Author: lana Date: 2013-03-12 18:12 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/72ffb2bc15bb Merge - make/tools/javazic/Makefile - make/tools/src/build/tools/javazic/BackEnd.java - make/tools/src/build/tools/javazic/Checksum.java - make/tools/src/build/tools/javazic/DayOfWeek.java - make/tools/src/build/tools/javazic/Gen.java - make/tools/src/build/tools/javazic/GenDoc.java - make/tools/src/build/tools/javazic/Main.java - make/tools/src/build/tools/javazic/Mappings.java - make/tools/src/build/tools/javazic/Month.java - make/tools/src/build/tools/javazic/Rule.java - make/tools/src/build/tools/javazic/RuleDay.java - make/tools/src/build/tools/javazic/RuleRec.java - make/tools/src/build/tools/javazic/Simple.java - make/tools/src/build/tools/javazic/Time.java - make/tools/src/build/tools/javazic/Timezone.java - make/tools/src/build/tools/javazic/Zone.java - make/tools/src/build/tools/javazic/ZoneRec.java - make/tools/src/build/tools/javazic/Zoneinfo.java - src/share/classes/java/lang/annotation/InvalidContainerAnnotationError.java - src/share/classes/java/util/function/Block.java - src/share/classes/java/util/function/DoubleBlock.java - src/share/classes/java/util/function/IntBlock.java - src/share/classes/java/util/function/LongBlock.java ! test/ProblemList.txt - test/javax/script/RhinoExceptionTest.java Changeset: 66a892bb28b7 Author: anthony Date: 2012-10-12 15:51 +0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/66a892bb28b7 7173145: Improve in-memory representation of splashscreens Reviewed-by: bae, mschoene ! src/share/native/sun/awt/splashscreen/splashscreen_jpeg.c Changeset: 85bf51db473c Author: xuelei Date: 2012-10-15 07:42 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/85bf51db473c 7192393: Better Checking of order of TLS Messages Summary: Also reviewed by Andrew Gross Reviewed-by: weijun ! src/share/classes/sun/security/ssl/ClientHandshaker.java ! src/share/classes/sun/security/ssl/ServerHandshaker.java Changeset: 24a3eb2f0553 Author: malenkov Date: 2012-10-15 19:00 +0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/24a3eb2f0553 7200493: Improve cache handling Reviewed-by: art, ahgross ! src/share/classes/com/sun/beans/finder/MethodFinder.java Changeset: c7c39320bc6c Author: rupashka Date: 2012-10-16 14:13 +0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/c7c39320bc6c 7186948: Improve Swing data validation Reviewed-by: art, ahgross ! src/share/classes/javax/swing/UIDefaults.java Changeset: 3c8d0085b094 Author: ksrini Date: 2012-10-16 12:29 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/3c8d0085b094 7186945: Unpack200 improvement Reviewed-by: jrose, jjh, mschoene ! src/share/native/com/sun/java/util/jar/pack/jni.cpp Changeset: 01f67953c057 Author: ksrini Date: 2012-10-16 12:35 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/01f67953c057 7186957: Improve Pack200 data validation Reviewed-by: jrose, jjh, mschoene ! src/share/classes/com/sun/java/util/jar/pack/BandStructure.java ! src/share/classes/com/sun/java/util/jar/pack/ConstantPool.java ! src/share/native/com/sun/java/util/jar/pack/bands.cpp ! src/share/native/com/sun/java/util/jar/pack/bands.h ! src/share/native/com/sun/java/util/jar/pack/unpack.cpp Changeset: b0bf41ba1cf8 Author: ksrini Date: 2012-10-16 12:38 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/b0bf41ba1cf8 7186946: Refine unpacker resource usage Reviewed-by: jrose, jjh, mschoene ! src/share/classes/com/sun/java/util/jar/pack/NativeUnpack.java ! src/share/classes/com/sun/java/util/jar/pack/PackerImpl.java ! src/share/classes/com/sun/java/util/jar/pack/UnpackerImpl.java ! src/share/native/com/sun/java/util/jar/pack/jni.cpp ! src/share/native/com/sun/java/util/jar/pack/unpack.cpp Changeset: f0bc5a6dff2b Author: ksrini Date: 2012-10-16 16:38 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/f0bc5a6dff2b 7200499: Better data validation for options Reviewed-by: darcy, jjh, mschoene ! src/share/bin/jli_util.h ! src/windows/bin/java_md.c Changeset: 7e19ab4ff5d3 Author: ksrini Date: 2012-10-16 10:56 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/7e19ab4ff5d3 7200500: Launcher better input validation Reviewed-by: darcy, jjh, mschoene ! src/share/bin/parse_manifest.c Changeset: 62f3270f03fa Author: dholmes Date: 2012-08-22 21:40 -0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/62f3270f03fa 6776941: Improve thread pool shutdown Reviewed-by: dl, skoivu ! src/share/classes/java/util/concurrent/ThreadPoolExecutor.java Changeset: e7cce63bf293 Author: xuelei Date: 2012-10-22 07:28 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/e7cce63bf293 7192392: Better validation of client keys Summary: Also reviewed by Andrew Gross Reviewed-by: vinnie ! src/share/classes/com/sun/crypto/provider/DHKeyAgreement.java ! src/share/classes/sun/security/pkcs11/P11KeyAgreement.java ! src/share/classes/sun/security/ssl/ClientHandshaker.java ! src/share/classes/sun/security/ssl/DHClientKeyExchange.java ! src/share/classes/sun/security/ssl/DHCrypt.java ! src/share/classes/sun/security/ssl/HandshakeMessage.java ! src/share/classes/sun/security/ssl/RSAClientKeyExchange.java ! src/share/classes/sun/security/ssl/ServerHandshaker.java ! src/share/classes/sun/security/ssl/SignatureAndHashAlgorithm.java ! src/share/classes/sun/security/util/DisabledAlgorithmConstraints.java - src/share/classes/sun/security/util/KeyLength.java + src/share/classes/sun/security/util/KeyUtil.java ! test/sun/security/mscapi/ShortRSAKeyWithinTLS.java Changeset: 091dd6eb30aa Author: khazra Date: 2012-10-22 11:49 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/091dd6eb30aa 7186954: Improve connection performance Reviewed-by: chegar, skoivu ! src/share/classes/sun/net/httpserver/ChunkedInputStream.java ! src/share/classes/sun/net/www/http/ChunkedInputStream.java Changeset: c26d42a92bd8 Author: weijun Date: 2012-09-19 12:58 +0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/c26d42a92bd8 8000210: Improve JarFile code quality Reviewed-by: ahgross, xuelei, mschoene ! src/share/classes/java/util/jar/JarFile.java ! src/share/classes/sun/security/util/DerIndefLenConverter.java Changeset: a54b61ae6f12 Author: mullan Date: 2012-10-26 15:21 -0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/a54b61ae6f12 7201068: Better handling of UI elements Reviewed-by: xuelei ! src/share/lib/security/java.security ! src/share/lib/security/java.security-macosx ! src/share/lib/security/java.security-solaris ! src/share/lib/security/java.security-windows Changeset: 71ab8d79c6b4 Author: asaha Date: 2012-10-26 10:01 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/71ab8d79c6b4 Merge - src/macosx/classes/sun/awt/SunToolkitSubclass.java ! src/share/classes/java/io/FilePermission.java ! src/share/classes/java/lang/invoke/MethodHandleImpl.java ! src/share/classes/java/lang/invoke/MethodHandleStatics.java ! src/share/classes/java/util/ServiceLoader.java ! src/share/classes/sun/invoke/util/ValueConversions.java - src/share/classes/sun/management/LockDataConverter.java - src/share/classes/sun/management/LockDataConverterMXBean.java ! src/share/classes/sun/security/ssl/HandshakeMessage.java - src/share/classes/sun/security/x509/CertificateIssuerUniqueIdentity.java - src/share/classes/sun/security/x509/CertificateSubjectUniqueIdentity.java - src/share/classes/sun/util/xml/XMLUtils.java - src/share/test/pack200/pack.conf - test/sun/misc/URLClassPath/ClassnameCharTest.sh - test/sun/net/www/httptest/HttpServer.java - test/sun/security/ssl/sun/net/www/httpstest/HttpServer.java Changeset: be07910b3fad Author: asaha Date: 2012-10-26 13:48 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/be07910b3fad Merge Changeset: e14221289076 Author: dsamersoff Date: 2012-10-30 17:05 +0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/e14221289076 8000539: JMX implementation allows invocation of methods of a system class Summary: Added extra packageAccess check call Reviewed-by: ahgross, dfuchs Contributed-by: jaroslav.bachorik at oracle.com ! src/share/classes/com/sun/jmx/mbeanserver/Introspector.java Changeset: 64440cc2ea8b Author: mchung Date: 2012-11-02 16:50 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/64440cc2ea8b 7197546: (proxy) Reflect about creating reflective proxies Reviewed-by: alanb, jdn, jrose ! src/share/classes/java/lang/Class.java ! src/share/classes/java/lang/invoke/MethodHandleProxies.java ! src/share/classes/java/lang/reflect/Proxy.java ! src/share/classes/sun/reflect/misc/ReflectUtil.java ! test/java/rmi/server/RMIClassLoader/loadProxyClasses/security.policy Changeset: f936be5be1e7 Author: rupashka Date: 2012-11-06 15:30 +0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/f936be5be1e7 7200491: Tighten up JTable layout code Reviewed-by: art, skoivu ! src/share/classes/javax/swing/JTable.java ! src/share/classes/javax/swing/plaf/nimbus/NimbusLookAndFeel.java Changeset: 3069b91ff041 Author: chegar Date: 2012-11-07 14:26 +0000 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/3069b91ff041 7201071: InetSocketAddress serialization issue Reviewed-by: alanb, michaelm, skoivu ! src/share/classes/java/net/InetSocketAddress.java ! src/share/classes/sun/nio/ch/DatagramChannelImpl.java ! src/solaris/classes/sun/nio/ch/sctp/SctpChannelImpl.java ! src/solaris/classes/sun/nio/ch/sctp/SctpMultiChannelImpl.java ! src/solaris/native/sun/nio/ch/DatagramChannelImpl.c ! src/solaris/native/sun/nio/ch/sctp/SctpChannelImpl.c ! src/windows/native/sun/nio/ch/DatagramChannelImpl.c ! test/java/nio/channels/DatagramChannel/SendToUnresolved.java Changeset: 69fd15e0437d Author: smarks Date: 2012-11-08 15:41 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/69fd15e0437d 7201070: Serialization to conform to protocol Reviewed-by: dmocek, ahgross, skoivu ! src/share/classes/java/io/ObjectInputStream.java Changeset: 9097b6ec0ecd Author: ksrini Date: 2012-11-09 14:36 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/9097b6ec0ecd 8002091: tools/launcher/ToolsOpts.java test started to fail since 7u11 b01 on Windows Reviewed-by: darcy, jjh, mschoene ! src/share/bin/jli_util.h ! src/windows/bin/java_md.c ! test/tools/launcher/ToolsOpts.java Changeset: 7bc8d5a63d9e Author: bagiras Date: 2012-11-15 23:03 +0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/7bc8d5a63d9e 7192977: Issue in toolkit thread Reviewed-by: skoivu, rupashka, art ! src/share/classes/java/awt/EventQueue.java ! src/share/classes/java/awt/Window.java ! src/share/classes/javax/swing/RepaintManager.java ! src/share/classes/sun/applet/AppletPanel.java ! src/share/classes/sun/awt/AWTAccessor.java ! src/windows/classes/sun/awt/windows/WComponentPeer.java ! src/windows/classes/sun/awt/windows/WEmbeddedFrame.java Changeset: 09e2dcd476cf Author: bae Date: 2012-11-16 11:05 +0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/09e2dcd476cf 8001972: Improve image processing Reviewed-by: prr, ahgross ! src/share/classes/sun/awt/image/ByteComponentRaster.java ! src/share/classes/sun/awt/image/ByteInterleavedRaster.java ! src/share/classes/sun/awt/image/ShortComponentRaster.java ! src/share/classes/sun/awt/image/ShortInterleavedRaster.java ! src/share/native/sun/awt/image/awt_parseImage.c ! src/share/native/sun/awt/medialib/safe_alloc.h Changeset: 1b616e1ca09c Author: dmocek Date: 2012-11-19 13:54 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/1b616e1ca09c 6563318: RMI data sanitization Reviewed-by: ahgross, hawtin, mchung, smarks ! src/share/classes/sun/rmi/transport/proxy/CGIHandler.java ! test/java/rmi/testlibrary/JavaVM.java Changeset: aa8717a5c9cd Author: dmocek Date: 2012-11-19 15:38 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/aa8717a5c9cd 8001242: Improve RMI HTTP conformance Reviewed-by: ahgross, mchung, smarks ! src/share/classes/sun/rmi/transport/proxy/CGIHandler.java ! src/share/classes/sun/rmi/transport/proxy/HttpInputStream.java Changeset: ecedf46ae7db Author: bae Date: 2012-11-20 11:46 +0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/ecedf46ae7db 8002325: Improve management of images Reviewed-by: prr, ahgross ! src/share/native/sun/awt/image/awt_parseImage.c ! src/share/native/sun/awt/image/awt_parseImage.h Changeset: eda84d5738e3 Author: denis Date: 2012-11-26 20:49 +0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/eda84d5738e3 7186952: Improve clipboard access Reviewed-by: serb, ahgross ! src/share/classes/java/awt/TextComponent.java ! src/windows/native/sun/windows/awt_TextComponent.cpp ! src/windows/native/sun/windows/awt_TextComponent.h Changeset: d1668eca22bf Author: mchung Date: 2012-11-26 22:49 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/d1668eca22bf 6664509: Add logging context 6664528: Find log level matching its name or value given at construction time Reviewed-by: alanb, ahgross, jgish, hawtin ! src/share/classes/java/util/logging/Level.java ! src/share/classes/java/util/logging/LogManager.java ! src/share/classes/java/util/logging/Logger.java ! src/share/classes/java/util/logging/Logging.java ! src/share/classes/java/util/logging/LoggingProxyImpl.java ! src/share/classes/java/util/logging/SimpleFormatter.java ! src/share/classes/sun/awt/AppContext.java ! src/share/classes/sun/misc/JavaAWTAccess.java ! src/share/lib/security/java.security Changeset: b8ee2e9ff7e3 Author: denis Date: 2012-11-30 15:51 +0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/b8ee2e9ff7e3 7201064: Better dialogue checking Reviewed-by: serb, skoivu ! src/share/classes/java/awt/Dialog.java Changeset: 90bbdae7aaa4 Author: ewendeli Date: 2013-02-03 23:25 +0100 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/90bbdae7aaa4 Merge ! src/share/classes/com/sun/java/util/jar/pack/BandStructure.java ! src/share/classes/com/sun/java/util/jar/pack/NativeUnpack.java ! src/share/classes/java/awt/Dialog.java ! src/share/classes/java/awt/TextComponent.java ! src/share/classes/java/awt/Window.java ! src/share/classes/java/io/FilePermission.java ! src/share/classes/java/io/ObjectInputStream.java ! src/share/classes/java/lang/Class.java ! src/share/classes/java/lang/invoke/MethodHandleProxies.java ! src/share/classes/java/lang/invoke/MethodHandleStatics.java ! src/share/classes/java/lang/reflect/Proxy.java ! src/share/classes/java/util/logging/LogManager.java ! src/share/classes/java/util/logging/Logger.java ! src/share/classes/java/util/logging/Logging.java ! src/share/classes/java/util/logging/LoggingProxyImpl.java ! src/share/classes/java/util/logging/SimpleFormatter.java ! src/share/classes/javax/swing/JTable.java ! src/share/classes/sun/awt/AWTAccessor.java ! src/share/classes/sun/invoke/util/ValueConversions.java ! src/share/classes/sun/reflect/misc/ReflectUtil.java ! src/share/classes/sun/rmi/transport/proxy/CGIHandler.java ! src/share/classes/sun/rmi/transport/proxy/HttpInputStream.java ! src/share/classes/sun/security/ssl/ClientHandshaker.java ! src/share/classes/sun/security/ssl/DHClientKeyExchange.java ! src/share/classes/sun/security/ssl/HandshakeMessage.java ! src/share/classes/sun/security/ssl/RSAClientKeyExchange.java ! src/share/classes/sun/security/ssl/ServerHandshaker.java ! src/share/classes/sun/security/ssl/SignatureAndHashAlgorithm.java - src/share/classes/sun/security/util/KeyLength.java ! src/share/lib/security/java.security-macosx ! src/share/lib/security/java.security-solaris ! src/share/lib/security/java.security-windows ! src/share/native/com/sun/java/util/jar/pack/bands.cpp ! src/share/native/com/sun/java/util/jar/pack/bands.h ! src/share/native/com/sun/java/util/jar/pack/unpack.cpp ! src/solaris/classes/sun/nio/ch/sctp/SctpChannelImpl.java ! src/solaris/classes/sun/nio/ch/sctp/SctpMultiChannelImpl.java ! src/solaris/native/sun/nio/ch/DatagramChannelImpl.c ! src/solaris/native/sun/nio/ch/sctp/SctpChannelImpl.c ! src/windows/native/sun/nio/ch/DatagramChannelImpl.c ! test/java/rmi/testlibrary/JavaVM.java Changeset: cc2057f84eb7 Author: mchung Date: 2012-12-05 14:02 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/cc2057f84eb7 8004175: Restricted packages added in java.security are missing in java.security-{macosx, solaris, windows} Reviewed-by: alanb, ahgross, mullan ! src/share/lib/security/java.security-macosx ! src/share/lib/security/java.security-solaris ! src/share/lib/security/java.security-windows Changeset: 89e43b8940c9 Author: dsamersoff Date: 2012-12-07 22:49 +0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/89e43b8940c9 8000537: Contextualize RequiredModelMBean class Summary: Contextualize RequiredModelMBean class Reviewed-by: asaha Contributed-by: jaroslav.bachorik at oracle.com ! src/share/classes/javax/management/modelmbean/RequiredModelMBean.java Changeset: 7933c80c162a Author: denis Date: 2012-12-12 21:08 +0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/7933c80c162a 8004341: Two JCK tests fails with 7u11 b06 Reviewed-by: serb, skoivu ! src/share/classes/java/awt/Dialog.java Changeset: ed08394e1a15 Author: mullan Date: 2012-12-18 13:48 -0500 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/ed08394e1a15 8004302: javax/xml/soap/Test7013971.java fails since jdk6u39b01 Reviewed-by: vinnie, skoivu, mgrebac, ohair, tbell ! src/share/lib/security/java.security-macosx ! src/share/lib/security/java.security-solaris ! src/share/lib/security/java.security-windows ! test/Makefile Changeset: 32cd4975d2d6 Author: mchung Date: 2013-01-10 19:43 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/32cd4975d2d6 8005615: Java Logger fails to load tomcat logger implementation (JULI) Reviewed-by: alanb, ahgross ! src/share/classes/java/util/logging/LogManager.java ! src/share/classes/java/util/logging/Logger.java + test/java/util/logging/CustomLogManager.java + test/java/util/logging/CustomLogManagerTest.java + test/java/util/logging/SimpleLogManager.java Changeset: c0fbd737aef0 Author: ewendeli Date: 2013-01-28 11:07 +0100 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/c0fbd737aef0 8006864: Update java.security-linux to include changes in java.security Reviewed-by: mchung, mullan ! src/share/lib/security/java.security-linux ! src/share/lib/security/java.security-macosx ! src/share/lib/security/java.security-solaris ! src/share/lib/security/java.security-windows Changeset: 12491fa16985 Author: ewendeli Date: 2013-02-05 15:35 +0100 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/12491fa16985 Merge ! src/share/classes/com/sun/java/util/jar/pack/ConstantPool.java ! src/share/classes/com/sun/java/util/jar/pack/PackerImpl.java ! src/share/classes/com/sun/jmx/mbeanserver/Introspector.java ! src/share/classes/java/lang/Class.java - src/share/classes/sun/security/util/KeyLength.java Changeset: de419ea8ed8f Author: mchung Date: 2013-01-28 15:53 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/de419ea8ed8f 8006882: Proxy generated classes in sun.proxy package breaks JMockit Reviewed-by: alanb, ahgross ! src/share/classes/java/lang/reflect/Proxy.java ! src/share/classes/sun/reflect/misc/ReflectUtil.java ! src/share/lib/security/java.security-linux ! src/share/lib/security/java.security-macosx ! src/share/lib/security/java.security-solaris ! src/share/lib/security/java.security-windows Changeset: 8effe3b7489d Author: dfuchs Date: 2013-01-30 11:33 +0100 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/8effe3b7489d 8006446: Restrict MBeanServer access Reviewed-by: alanb, mchung, darcy, jrose, ahgross, skoivu ! src/share/classes/com/sun/jmx/mbeanserver/ClassLoaderRepositorySupport.java ! src/share/classes/com/sun/jmx/mbeanserver/JmxMBeanServer.java ! src/share/classes/com/sun/jmx/mbeanserver/MBeanInstantiator.java ! src/share/classes/com/sun/jmx/mbeanserver/MBeanSupport.java ! src/share/classes/java/lang/management/ManagementFactory.java ! src/share/lib/security/java.security-linux ! src/share/lib/security/java.security-macosx ! src/share/lib/security/java.security-solaris ! src/share/lib/security/java.security-windows ! test/javax/management/remote/mandatory/subjectDelegation/SubjectDelegation2Test.java ! test/javax/management/remote/mandatory/subjectDelegation/SubjectDelegation3Test.java Changeset: ebfb0bb58428 Author: mchung Date: 2013-01-24 16:45 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/ebfb0bb58428 8004937: Improve proxy construction Reviewed-by: jrose, ahgross ! src/share/classes/java/lang/invoke/MethodHandleNatives.java ! src/share/classes/java/lang/invoke/MethodHandleProxies.java Changeset: af11c227a91e Author: mchung Date: 2013-02-05 22:56 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/af11c227a91e 8007393: Possible race condition after JDK-6664509 Reviewed-by: alanb, jgish ! src/share/classes/java/util/logging/LogManager.java Changeset: 1143bb5e7064 Author: mchung Date: 2013-02-07 09:41 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/1143bb5e7064 8007611: logging behavior in applet changed Reviewed-by: alanb, jgish ! src/share/classes/java/util/logging/LogManager.java Changeset: 5925630b7a7d Author: xuelei Date: 2013-02-07 16:05 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/5925630b7a7d 8006777: Improve TLS handling of invalid messages Reviewed-by: wetmore, ahgross ! src/share/classes/sun/security/ssl/CipherBox.java ! src/share/classes/sun/security/ssl/CipherSuite.java ! src/share/classes/sun/security/ssl/EngineInputRecord.java ! src/share/classes/sun/security/ssl/EngineOutputRecord.java ! src/share/classes/sun/security/ssl/InputRecord.java ! src/share/classes/sun/security/ssl/MAC.java ! src/share/classes/sun/security/ssl/OutputRecord.java ! src/share/classes/sun/security/ssl/SSLEngineImpl.java ! src/share/classes/sun/security/ssl/SSLSocketImpl.java Changeset: d57363ff612f Author: valeriep Date: 2013-02-07 16:03 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/d57363ff612f 8007688: Blacklist known bad certificate Summary: Added two known bad certs to the blacklist certs. Reviewed-by: mullan ! src/share/classes/sun/security/util/UntrustedCertificates.java Changeset: c18aeb4ca957 Author: ewendeli Date: 2013-02-19 21:48 +0100 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/c18aeb4ca957 Merge ! src/share/bin/parse_manifest.c ! src/share/classes/java/lang/Class.java - src/share/classes/sun/security/util/KeyLength.java ! src/share/native/com/sun/java/util/jar/pack/unpack.cpp ! src/share/native/sun/awt/image/awt_parseImage.c ! test/Makefile Changeset: f7fb3de623ba Author: ewendeli Date: 2013-02-19 21:53 +0100 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/f7fb3de623ba Merge Changeset: f686c8e3c8e0 Author: ewendeli Date: 2013-02-25 08:44 +0100 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/f686c8e3c8e0 Merge ! src/share/classes/com/sun/java/util/jar/pack/BandStructure.java ! src/share/classes/java/util/jar/JarFile.java ! src/share/classes/java/util/logging/LogManager.java - src/share/classes/sun/security/util/KeyLength.java ! src/share/native/com/sun/java/util/jar/pack/bands.cpp ! src/share/native/com/sun/java/util/jar/pack/bands.h ! src/share/native/com/sun/java/util/jar/pack/unpack.cpp Changeset: e3cac5962e32 Author: vlivanov Date: 2013-02-22 03:00 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/e3cac5962e32 8006439: Improve MethodHandles coverage Reviewed-by: jrose, twisti ! src/share/classes/java/lang/invoke/MethodHandleImpl.java ! src/share/classes/java/lang/invoke/MethodHandleNatives.java ! src/share/classes/java/lang/invoke/MethodHandles.java Changeset: 62be74f35886 Author: vlivanov Date: 2013-02-22 03:00 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/62be74f35886 8006179: JSR292 MethodHandles lookup with interface using findVirtual() Reviewed-by: jrose, twisti ! src/share/classes/java/lang/invoke/DirectMethodHandle.java Changeset: 9995881dfb4e Author: vlivanov Date: 2013-02-22 02:59 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/9995881dfb4e 8006125: Update MethodHandles library interactions Reviewed-by: jrose ! src/share/classes/sun/reflect/misc/MethodUtil.java Changeset: 0807820fca96 Author: vlivanov Date: 2013-02-22 02:58 -0800 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/0807820fca96 8004933: Improve MethodHandle interaction with libraries Reviewed-by: jrose ! src/share/classes/java/lang/invoke/MethodHandleNatives.java Changeset: ae1fed8d80e1 Author: ewendeli Date: 2013-02-26 06:47 +0100 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/ae1fed8d80e1 Merge - src/share/classes/sun/security/util/KeyLength.java Changeset: 5e4c2d7f3b67 Author: ewendeli Date: 2013-02-26 20:36 +0100 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/5e4c2d7f3b67 Merge ! src/share/classes/java/lang/invoke/DirectMethodHandle.java ! src/share/classes/java/lang/invoke/MethodHandleImpl.java ! src/share/classes/java/lang/invoke/MethodHandles.java - src/share/classes/sun/security/util/KeyLength.java Changeset: 4d4848124bff Author: ewendeli Date: 2013-02-27 09:28 +0100 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/4d4848124bff Merge - src/share/classes/sun/security/util/KeyLength.java Changeset: 36ff48ae6ffe Author: ewendeli Date: 2013-02-27 18:13 +0100 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/36ff48ae6ffe Merge - src/share/classes/sun/security/util/KeyLength.java Changeset: 931fb59eae26 Author: lana Date: 2013-03-12 19:04 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/931fb59eae26 Merge ! src/share/classes/com/sun/java/util/jar/pack/ConstantPool.java ! src/share/classes/java/awt/EventQueue.java ! src/share/classes/java/lang/Class.java ! src/share/classes/sun/security/ssl/CipherBox.java ! src/share/classes/sun/security/ssl/CipherSuite.java ! src/share/classes/sun/security/ssl/EngineInputRecord.java ! src/share/classes/sun/security/ssl/EngineOutputRecord.java ! src/share/classes/sun/security/ssl/InputRecord.java ! src/share/classes/sun/security/ssl/MAC.java ! src/share/classes/sun/security/ssl/OutputRecord.java ! src/share/classes/sun/security/ssl/SSLEngineImpl.java ! src/share/classes/sun/security/ssl/SSLSocketImpl.java - src/share/classes/sun/security/util/KeyLength.java ! src/share/native/com/sun/java/util/jar/pack/unpack.cpp ! src/windows/classes/sun/awt/windows/WEmbeddedFrame.java Changeset: 9528e88f8d53 Author: lana Date: 2013-03-13 23:39 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/9528e88f8d53 Merge - make/tools/javazic/Makefile - make/tools/src/build/tools/javazic/BackEnd.java - make/tools/src/build/tools/javazic/Checksum.java - make/tools/src/build/tools/javazic/DayOfWeek.java - make/tools/src/build/tools/javazic/Gen.java - make/tools/src/build/tools/javazic/GenDoc.java - make/tools/src/build/tools/javazic/Main.java - make/tools/src/build/tools/javazic/Mappings.java - make/tools/src/build/tools/javazic/Month.java - make/tools/src/build/tools/javazic/Rule.java - make/tools/src/build/tools/javazic/RuleDay.java - make/tools/src/build/tools/javazic/RuleRec.java - make/tools/src/build/tools/javazic/Simple.java - make/tools/src/build/tools/javazic/Time.java - make/tools/src/build/tools/javazic/Timezone.java - make/tools/src/build/tools/javazic/Zone.java - make/tools/src/build/tools/javazic/ZoneRec.java - make/tools/src/build/tools/javazic/Zoneinfo.java ! makefiles/CompileNativeLibraries.gmk ! makefiles/Images.gmk - src/share/classes/java/lang/annotation/InvalidContainerAnnotationError.java - src/share/classes/java/util/function/Block.java - src/share/classes/java/util/function/DoubleBlock.java - src/share/classes/java/util/function/IntBlock.java - src/share/classes/java/util/function/LongBlock.java - src/share/classes/sun/security/util/KeyLength.java - test/javax/script/RhinoExceptionTest.java Changeset: f282190e931a Author: lana Date: 2013-03-14 19:26 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/f282190e931a Merge From david.katleman at oracle.com Fri Mar 15 19:08:17 2013 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Fri, 15 Mar 2013 19:08:17 +0000 Subject: hg: jdk8/build/langtools: 57 new changesets Message-ID: <20130315191055.F0CF1481A0@hg.openjdk.java.net> Changeset: 58289451d9ed Author: katleman Date: 2013-03-14 15:00 -0700 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/58289451d9ed Added tag jdk8-b81 for changeset ed69d087fdfd ! .hgtags Changeset: 63872da94576 Author: darcy Date: 2013-02-13 23:05 -0800 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/63872da94576 8001457: New tests needed for library-side changes for repeating annotations Reviewed-by: darcy Contributed-by: sonali.goel at oracle.com ! test/tools/javac/annotations/repeatingAnnotations/combo/Helper.java + test/tools/javac/annotations/repeatingAnnotations/combo/ReflectionTest.java + test/tools/javac/annotations/repeatingAnnotations/combo/expectedFiles/ExpectedBase.java + test/tools/javac/annotations/repeatingAnnotations/combo/expectedFiles/ExpectedContainer.java Changeset: 88286a36bb34 Author: mchung Date: 2013-02-14 09:43 -0800 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/88286a36bb34 8006225: tools/jdeps/Basic.java failes with AssertionError Reviewed-by: alanb + src/share/classes/com/sun/tools/jdeps/Analyzer.java ! src/share/classes/com/sun/tools/jdeps/Archive.java ! src/share/classes/com/sun/tools/jdeps/JdepsTask.java ! test/tools/jdeps/Basic.java Changeset: 040f02711b73 Author: jjg Date: 2013-02-15 08:28 -0800 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/040f02711b73 8007052: javap should include the descriptor for a method in verbose mode Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javap/ClassWriter.java ! src/share/classes/com/sun/tools/javap/JavapTask.java ! src/share/classes/com/sun/tools/javap/Options.java + test/tools/javap/DescriptorTest.java Changeset: 0baaae675b19 Author: mcimadamore Date: 2013-02-15 16:28 +0000 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/0baaae675b19 8006749: compiler does not allow Object protected methods to be used in lambda Summary: Check.checkFunctionalInterface should take into account 'fake' override Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Check.java + test/tools/javac/lambda/LambdaConv26.java Changeset: f6e667f52af4 Author: mcimadamore Date: 2013-02-15 16:28 +0000 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/f6e667f52af4 8007285: AbstractMethodError instead of compile-time error when method reference with super and abstract Summary: Missing abstractness check on super rmethod references Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Attr.java + test/tools/javac/lambda/MethodReference62.java + test/tools/javac/lambda/MethodReference62.out Changeset: 4ff468de829d Author: mcimadamore Date: 2013-02-15 16:29 +0000 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/4ff468de829d 8007462: Fix provisional applicability for method references Summary: Add speculative arity-based check to rule out potential candidates when stuck reference is passed to method Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/DeferredAttr.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties + test/tools/javac/diags/examples/IncompatibleArgTypesInMethodRef.java + test/tools/javac/lambda/TargetType60.java + test/tools/javac/lambda/TargetType60.out Changeset: 3cd997b9fd84 Author: mcimadamore Date: 2013-02-15 16:30 +0000 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/3cd997b9fd84 8007535: Compiler crashes on @FunctionalInterface used on interface with two inherited methods with same signatures Summary: Bad check in Types.interfaceCandidates Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Types.java + test/tools/javac/lambda/FunctionalInterfaceAnno02.java Changeset: 186023614cd3 Author: mcimadamore Date: 2013-02-15 16:31 +0000 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/186023614cd3 8007427: Annotation element as '_' gives compiler error instead of a warning 8007401: Write test to check for generation of warnings when '_' is used as an identifier Summary: Extended identifier production not used in annotation values Reviewed-by: jjg Contributed-by: sonali.goel at oracle.com ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java + test/tools/javac/lambda/IdentifierTest.java + test/tools/javac/lambda/IdentifierTest.out Changeset: 258c72fa7fa2 Author: mcimadamore Date: 2013-02-15 16:37 +0000 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/258c72fa7fa2 Merge Changeset: da2f7dd53915 Author: mcimadamore Date: 2013-02-15 18:13 +0000 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/da2f7dd53915 8008309: TargetType60 fails because of bad golden file Summary: bad golden file Reviewed-by: jjg ! test/tools/javac/lambda/TargetType60.out Changeset: 9fb4f223a90d Author: jjg Date: 2013-02-15 11:26 -0800 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/9fb4f223a90d 8008313: 8007052 breaks test/tools/javap/MethodParameters.java Reviewed-by: darcy ! test/tools/javap/MethodParameters.java Changeset: f1f605f85850 Author: rfield Date: 2013-02-15 18:40 -0800 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/f1f605f85850 8004969: Generate $deserializeLambda$ method 8006763: super in method reference used in anonymous class - ClassFormatError is produced 8005632: Inner classes within lambdas cause build failures 8005653: Lambdas containing inner classes referencing external type variables do not correctly parameterize the inner classes Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/code/Symtab.java ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.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/Names.java + test/tools/javac/lambda/LambdaInnerTypeVarArgs.java + test/tools/javac/lambda/LambdaInnerTypeVarReflect.java + test/tools/javac/lambda/MethodReference61.java Changeset: 2620c953e9fe Author: vromero Date: 2013-02-18 14:33 +0000 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/2620c953e9fe 6563143: javac should issue a warning for overriding equals without hashCode Reviewed-by: jjg, mcimadamore ! src/share/classes/com/sun/tools/javac/code/Flags.java ! src/share/classes/com/sun/tools/javac/code/Lint.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/sjavac/comp/Dependencies.java + test/tools/javac/6563143/OverridesEqualsButNotHashCodeTest.java + test/tools/javac/6563143/OverridesEqualsButNotHashCodeTest.out ! test/tools/javac/diags/examples.not-yet.txt Changeset: 87884cd0fea3 Author: jjg Date: 2013-02-18 14:29 -0800 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/87884cd0fea3 8008339: Test TargetAnnoCombo.java is broken Reviewed-by: jjh ! test/tools/javac/annotations/repeatingAnnotations/combo/TargetAnnoCombo.java Changeset: 011cf7e0a148 Author: darcy Date: 2013-02-19 00:31 -0800 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/011cf7e0a148 8008267: Add @Supported annotation to com.sun.source types Reviewed-by: jjg ! src/share/classes/com/sun/source/doctree/AttributeTree.java ! src/share/classes/com/sun/source/doctree/AuthorTree.java ! src/share/classes/com/sun/source/doctree/BlockTagTree.java ! src/share/classes/com/sun/source/doctree/CommentTree.java ! src/share/classes/com/sun/source/doctree/DeprecatedTree.java ! src/share/classes/com/sun/source/doctree/DocCommentTree.java ! src/share/classes/com/sun/source/doctree/DocRootTree.java ! src/share/classes/com/sun/source/doctree/DocTree.java ! src/share/classes/com/sun/source/doctree/DocTreeVisitor.java ! src/share/classes/com/sun/source/doctree/EndElementTree.java ! src/share/classes/com/sun/source/doctree/EntityTree.java ! src/share/classes/com/sun/source/doctree/ErroneousTree.java ! src/share/classes/com/sun/source/doctree/IdentifierTree.java ! src/share/classes/com/sun/source/doctree/InheritDocTree.java ! src/share/classes/com/sun/source/doctree/InlineTagTree.java ! src/share/classes/com/sun/source/doctree/LinkTree.java ! src/share/classes/com/sun/source/doctree/LiteralTree.java ! src/share/classes/com/sun/source/doctree/ParamTree.java ! src/share/classes/com/sun/source/doctree/ReferenceTree.java ! src/share/classes/com/sun/source/doctree/ReturnTree.java ! src/share/classes/com/sun/source/doctree/SeeTree.java ! src/share/classes/com/sun/source/doctree/SerialDataTree.java ! src/share/classes/com/sun/source/doctree/SerialFieldTree.java ! src/share/classes/com/sun/source/doctree/SerialTree.java ! src/share/classes/com/sun/source/doctree/SinceTree.java ! src/share/classes/com/sun/source/doctree/StartElementTree.java ! src/share/classes/com/sun/source/doctree/TextTree.java ! src/share/classes/com/sun/source/doctree/ThrowsTree.java ! src/share/classes/com/sun/source/doctree/UnknownBlockTagTree.java ! src/share/classes/com/sun/source/doctree/UnknownInlineTagTree.java ! src/share/classes/com/sun/source/doctree/ValueTree.java ! src/share/classes/com/sun/source/doctree/VersionTree.java ! src/share/classes/com/sun/source/doctree/package-info.java ! src/share/classes/com/sun/source/tree/AnnotatedTypeTree.java ! src/share/classes/com/sun/source/tree/AnnotationTree.java ! src/share/classes/com/sun/source/tree/ArrayAccessTree.java ! src/share/classes/com/sun/source/tree/ArrayTypeTree.java ! src/share/classes/com/sun/source/tree/AssertTree.java ! src/share/classes/com/sun/source/tree/AssignmentTree.java ! src/share/classes/com/sun/source/tree/BinaryTree.java ! src/share/classes/com/sun/source/tree/BlockTree.java ! src/share/classes/com/sun/source/tree/BreakTree.java ! src/share/classes/com/sun/source/tree/CaseTree.java ! src/share/classes/com/sun/source/tree/CatchTree.java ! src/share/classes/com/sun/source/tree/ClassTree.java ! src/share/classes/com/sun/source/tree/CompilationUnitTree.java ! src/share/classes/com/sun/source/tree/CompoundAssignmentTree.java ! src/share/classes/com/sun/source/tree/ConditionalExpressionTree.java ! src/share/classes/com/sun/source/tree/ContinueTree.java ! src/share/classes/com/sun/source/tree/DoWhileLoopTree.java ! src/share/classes/com/sun/source/tree/EmptyStatementTree.java ! src/share/classes/com/sun/source/tree/EnhancedForLoopTree.java ! src/share/classes/com/sun/source/tree/ErroneousTree.java ! src/share/classes/com/sun/source/tree/ExpressionStatementTree.java ! src/share/classes/com/sun/source/tree/ExpressionTree.java ! src/share/classes/com/sun/source/tree/ForLoopTree.java ! src/share/classes/com/sun/source/tree/IdentifierTree.java ! src/share/classes/com/sun/source/tree/IfTree.java ! src/share/classes/com/sun/source/tree/ImportTree.java ! src/share/classes/com/sun/source/tree/InstanceOfTree.java ! src/share/classes/com/sun/source/tree/IntersectionTypeTree.java ! src/share/classes/com/sun/source/tree/LabeledStatementTree.java ! src/share/classes/com/sun/source/tree/LambdaExpressionTree.java ! src/share/classes/com/sun/source/tree/LineMap.java ! src/share/classes/com/sun/source/tree/LiteralTree.java ! src/share/classes/com/sun/source/tree/MemberReferenceTree.java ! src/share/classes/com/sun/source/tree/MemberSelectTree.java ! src/share/classes/com/sun/source/tree/MethodInvocationTree.java ! src/share/classes/com/sun/source/tree/MethodTree.java ! src/share/classes/com/sun/source/tree/ModifiersTree.java ! src/share/classes/com/sun/source/tree/NewArrayTree.java ! src/share/classes/com/sun/source/tree/NewClassTree.java ! src/share/classes/com/sun/source/tree/ParameterizedTypeTree.java ! src/share/classes/com/sun/source/tree/ParenthesizedTree.java ! src/share/classes/com/sun/source/tree/PrimitiveTypeTree.java ! src/share/classes/com/sun/source/tree/ReturnTree.java ! src/share/classes/com/sun/source/tree/Scope.java ! src/share/classes/com/sun/source/tree/StatementTree.java ! src/share/classes/com/sun/source/tree/SwitchTree.java ! src/share/classes/com/sun/source/tree/SynchronizedTree.java ! src/share/classes/com/sun/source/tree/ThrowTree.java ! src/share/classes/com/sun/source/tree/Tree.java ! src/share/classes/com/sun/source/tree/TreeVisitor.java ! src/share/classes/com/sun/source/tree/TryTree.java ! src/share/classes/com/sun/source/tree/TypeCastTree.java ! src/share/classes/com/sun/source/tree/TypeParameterTree.java ! src/share/classes/com/sun/source/tree/UnaryTree.java ! src/share/classes/com/sun/source/tree/UnionTypeTree.java ! src/share/classes/com/sun/source/tree/VariableTree.java ! src/share/classes/com/sun/source/tree/WhileLoopTree.java ! src/share/classes/com/sun/source/tree/WildcardTree.java ! src/share/classes/com/sun/source/tree/package-info.java ! src/share/classes/com/sun/source/util/DocTreeScanner.java ! src/share/classes/com/sun/source/util/DocTrees.java ! src/share/classes/com/sun/source/util/JavacTask.java ! src/share/classes/com/sun/source/util/Plugin.java ! src/share/classes/com/sun/source/util/SimpleDocTreeVisitor.java ! src/share/classes/com/sun/source/util/SimpleTreeVisitor.java ! src/share/classes/com/sun/source/util/SourcePositions.java ! src/share/classes/com/sun/source/util/TaskEvent.java ! src/share/classes/com/sun/source/util/TaskListener.java ! src/share/classes/com/sun/source/util/TreePath.java ! src/share/classes/com/sun/source/util/TreePathScanner.java ! src/share/classes/com/sun/source/util/TreeScanner.java ! src/share/classes/com/sun/source/util/Trees.java ! src/share/classes/com/sun/source/util/package-info.java ! src/share/classes/com/sun/tools/javac/Main.java ! src/share/classes/com/sun/tools/javac/Server.java Changeset: dc8b7aa7cef3 Author: vromero Date: 2013-02-19 17:53 +0000 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/dc8b7aa7cef3 8006212: javac, convert jtreg tests from shell script to java Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/api/JavacTaskImpl.java ! src/share/classes/com/sun/tools/javac/util/ArrayUtils.java + test/tools/apt/Basics/CheckAptIsRemovedTest.java - test/tools/apt/Basics/NullAPF.java - test/tools/apt/Basics/apt.sh - test/tools/apt/verifyVariables.sh + test/tools/javac/4846262/CheckEBCDICLocaleTest.java - test/tools/javac/4846262/Test.java - test/tools/javac/4846262/Test.out - test/tools/javac/4846262/Test.sh + test/tools/javac/6302184/HiddenOptionsShouldUseGivenEncodingTest.java - test/tools/javac/6302184/T6302184.sh + test/tools/javac/ClassPathTest/ClassPathTest.java - test/tools/javac/ClassPathTest/ClassPathTest.sh - test/tools/javac/ClassPathTest/ClassPathTest1.java - test/tools/javac/ClassPathTest/ClassPathTest2.java - test/tools/javac/ClassPathTest/ClassPathTest3.java - test/tools/javac/ClassPathTest/bar/pkg/ClassPathTestAux2.java - test/tools/javac/ClassPathTest/foo/pkg/ClassPathTestAux1.java - test/tools/javac/ClassPathTest/pkg/ClassPathTestAux3.java + test/tools/javac/ExtDirs/ExtDirTest.java - test/tools/javac/ExtDirs/ExtDirTest_1.java - test/tools/javac/ExtDirs/ExtDirTest_2.java - test/tools/javac/ExtDirs/ExtDirTest_3.java - test/tools/javac/ExtDirs/ExtDirs.sh - test/tools/javac/MissingInclude.java - test/tools/javac/MissingInclude.sh + test/tools/javac/MissingInclude/MissingIncludeTest.java - test/tools/javac/ProtectedInnerClass/ProtectedInnerClass.sh - test/tools/javac/ProtectedInnerClass/ProtectedInnerClass_2.java + test/tools/javac/ProtectedInnerClass/ProtectedInnerClassesTest.java - test/tools/javac/ProtectedInnerClass/p1/ProtectedInnerClass1.java - test/tools/javac/ProtectedInnerClass/p2/ProtectedInnerClass2.java - test/tools/javac/ProtectedInnerClass/p2/ProtectedInnerClass3.java + test/tools/javac/T5090006/AssertionFailureTest.java - test/tools/javac/T5090006/T5090006.java - test/tools/javac/T5090006/compiler.sh - test/tools/javac/constDebug/ConstDebug.java - test/tools/javac/constDebug/ConstDebug.sh + test/tools/javac/constDebug/ConstDebugTest.java - test/tools/javac/fatalErrors/NoJavaLang.java - test/tools/javac/fatalErrors/NoJavaLang.out - test/tools/javac/fatalErrors/NoJavaLang.sh + test/tools/javac/fatalErrors/NoJavaLangTest.java - test/tools/javac/innerClassFile/Driver.sh + test/tools/javac/innerClassFile/InnerClassFileTest.java - test/tools/javac/innerClassFile/x/B.java - test/tools/javac/innerClassFile/x/C.java - test/tools/javac/innerClassFile/y/Main.java - test/tools/javac/innerClassFile/y/R1.java - test/tools/javac/innerClassFile/y/R2.java - test/tools/javac/innerClassFile/y/R3.java - test/tools/javac/javazip/A.java + test/tools/javac/javazip/JavaZipTest.java - test/tools/javac/javazip/Test.sh - test/tools/javac/javazip/bad/B.java - test/tools/javac/javazip/good/B.java + test/tools/javac/lib/ToolBox.java + test/tools/javac/links/LinksTest.java - test/tools/javac/links/T.java - test/tools/javac/links/b/B.java - test/tools/javac/links/links.sh + test/tools/javac/newlines/NewLineTest.java - test/tools/javac/newlines/Newlines.sh + test/tools/javac/stackmap/StackMapTest.java - test/tools/javac/stackmap/T4955930.java - test/tools/javac/stackmap/T4955930.sh ! test/tools/javac/unicode/SupplementaryJavaID6.java - test/tools/javac/unicode/SupplementaryJavaID6.sh + test/tools/javah/6257087/T6257087.java - test/tools/javah/6257087/foo.java - test/tools/javah/6257087/foo.sh - test/tools/javah/6257087/foo_bar.h - test/tools/javah/ConstMacroTest.sh - test/tools/javah/MissingParamClassException.java - test/tools/javah/MissingParamClassTest.sh - test/tools/javah/ParamClassTest.java - test/tools/javah/SubClassConsts.java - test/tools/javah/SubClassConsts.out - test/tools/javah/SubClassConsts.win - test/tools/javah/SuperClassConsts.java + test/tools/javah/T4942232/MissingParamClassTest.java + test/tools/javah/constMacroTest/ConstMacroTest.java + test/tools/javap/4798312/JavapShouldLoadClassesFromRTJarTest.java + test/tools/javap/4866831/PublicInterfaceTest.java - test/tools/javap/NotPackagePrivateInterface.java - test/tools/javap/PublicInterfaceTest.sh - test/tools/javap/pathsep.sh + test/tools/javap/stackmap/StackmapTest.java - test/tools/javap/stackmap/T6271292.java - test/tools/javap/stackmap/T6271292.out - test/tools/javap/stackmap/T6271292.sh Changeset: 9345394ac8fe Author: ksrini Date: 2013-02-19 17:19 -0800 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/9345394ac8fe 8006948: Update javac for MethodParameters format change Reviewed-by: ksrini, forax Contributed-by: eric.mccorkle at oracle.com ! src/share/classes/com/sun/tools/classfile/ClassWriter.java ! src/share/classes/com/sun/tools/classfile/MethodParameters_attribute.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java Changeset: 4cf6e84f844f Author: lana Date: 2013-02-19 20:53 -0800 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/4cf6e84f844f Merge Changeset: 267225edc1fe Author: strarup Date: 2013-02-20 15:47 -0800 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/267225edc1fe 8006582: Test for parameter names feature Reviewed-by: jjg, darcy, emc - test/tools/javac/MethodParameters.java + test/tools/javac/MethodParameters/AnnotationTest.java + test/tools/javac/MethodParameters/AnonymousClass.java + test/tools/javac/MethodParameters/AttributeVisitor.java + test/tools/javac/MethodParameters/ClassFileVisitor.java + test/tools/javac/MethodParameters/Constructors.java + test/tools/javac/MethodParameters/EnumTest.java + test/tools/javac/MethodParameters/InstanceMethods.java + test/tools/javac/MethodParameters/LambdaTest.java + test/tools/javac/MethodParameters/LocalClassTest.java + test/tools/javac/MethodParameters/MemberClassTest.java + test/tools/javac/MethodParameters/ReflectionVisitor.java + test/tools/javac/MethodParameters/StaticMethods.java + test/tools/javac/MethodParameters/Tester.java + test/tools/javac/MethodParameters/UncommonParamNames.java + test/tools/javac/MethodParametersTest.java Changeset: d686d8a7eb78 Author: mcimadamore Date: 2013-02-21 15:19 +0000 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/d686d8a7eb78 8008227: Mixing lambdas with anonymous classes leads to NPE thrown by compiler Summary: Disentangle cyclic dependency between static-ness of synthetic lambda method and static-ness of classes nested within lambdas Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java + test/tools/javac/lambda/LambdaConv27.java Changeset: 3a39d123d33a Author: mcimadamore Date: 2013-02-21 15:21 +0000 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/3a39d123d33a 8008276: assertion error in com.sun.tools.javac.comp.TransTypes.visitApply Summary: DiagnosticFilter used during speculative attribution is too broad Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/DeferredAttr.java ! src/share/classes/com/sun/tools/javac/util/JCDiagnostic.java + test/tools/javac/lambda/speculative/MissingError.java + test/tools/javac/lambda/speculative/MissingError.out Changeset: f4fdd53f8b3e Author: mcimadamore Date: 2013-02-21 15:23 +0000 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/f4fdd53f8b3e 8005183: Missing accessor for constructor reference pointing to private inner class ctor Summary: Compiler should add bridges when translating private constructor reference Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java + test/tools/javac/lambda/MethodReference63.java Changeset: 7ac9242d2ca6 Author: mcimadamore Date: 2013-02-21 15:25 +0000 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/7ac9242d2ca6 8008293: Declared bounds not considered when functional interface containing unbound wildcards is instantiated Summary: Wildcards inference should re-use some of the bounds info generated during capture conversion Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Types.java + test/tools/javac/lambda/TargetType64.java Changeset: 9f0ec00514b6 Author: mcimadamore Date: 2013-02-21 15:26 +0000 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/9f0ec00514b6 8007461: Regression: bad overload resolution when inner class and outer class have method with same name Summary: Fix regression in varargs method resolution introduced by bad refactoring Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! test/tools/javac/resolve/Pos.java + test/tools/javac/resolve/tests/InnerOverOuter.java Changeset: 3fef0cae83b3 Author: mcimadamore Date: 2013-02-21 15:27 +0000 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/3fef0cae83b3 8008444: Inherited generic functional descriptors are merged incorrectly Summary: Missing call to Types.createMethodWithThrownTypes Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Types.java + test/tools/javac/lambda/LambdaConv25.java + test/tools/javac/lambda/LambdaConv25.out Changeset: cd7340a84bb8 Author: rfield Date: 2013-02-21 14:43 -0800 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/cd7340a84bb8 8008405: Now that metafactory is in place, add javac lambda serialization tests Summary: Tests part of original langtools serialization review. Reviewed-by: mcimadamore + test/tools/javac/T8004969.java + test/tools/javac/lambda/LambdaInnerTypeVarArgsSerialize.java + test/tools/javac/lambda/LambdaInnerTypeVarSerialize.java Changeset: dabb36173c63 Author: ksrini Date: 2013-02-21 12:23 -0800 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/dabb36173c63 8008658: Four new method param jtreg tests fail in nightly tests Reviewed-by: jjg, ksrini, mcimadamore Contributed-by: eric.mccorkle at oracle.com ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java ! test/tools/javac/MethodParameters/EnumTest.java ! test/tools/javac/MethodParameters/LocalClassTest.java ! test/tools/javac/MethodParameters/MemberClassTest.java Changeset: 6118072811e5 Author: lana Date: 2013-02-21 17:49 -0800 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/6118072811e5 Merge ! src/share/classes/com/sun/tools/javac/api/JavacTaskImpl.java ! src/share/classes/com/sun/tools/javac/code/Flags.java ! src/share/classes/com/sun/tools/javac/code/Symtab.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties Changeset: 8e82e4f225e4 Author: mcimadamore Date: 2013-02-22 13:31 +0000 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/8e82e4f225e4 8008337: Write test to check for compiler error when static method in interface is called via super() Reviewed-by: mcimadamore Contributed-by: sonali.goel at oracle.com + test/tools/javac/lambda/StaticMethodNegTest.java + test/tools/javac/lambda/StaticMethodNegTest.out Changeset: 94e67bed460d Author: mcimadamore Date: 2013-02-22 18:19 +0000 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/94e67bed460d 8008708: Regression: separate compilation causes crash in wildcards inference logic Summary: Invalid use of WildcardType.bound in Types.removeWildcards Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Types.java + test/tools/javac/lambda/separate/Foo.java + test/tools/javac/lambda/separate/Test.java Changeset: ccbe7ffdd867 Author: jjg Date: 2013-02-24 11:36 -0800 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/ccbe7ffdd867 7112427: The doclet needs to be able to generate JavaFX documentation. Reviewed-by: jjg Contributed-by: jan.valenta at oracle.com ! src/share/classes/com/sun/tools/doclets/formats/html/ConstructorWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/LinkInfoImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageFrameWriter.java + src/share/classes/com/sun/tools/doclets/formats/html/PropertyWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/WriterFactoryImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlConstants.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/resources/standard.properties ! src/share/classes/com/sun/tools/doclets/internal/toolkit/Configuration.java + src/share/classes/com/sun/tools/doclets/internal/toolkit/PropertyWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/WriterFactory.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AnnotationTypeRequiredMemberBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/BuilderFactory.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ClassBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ConstantsSummaryBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ConstructorBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/EnumConstantBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/FieldBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/MemberSummaryBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/MethodBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/PackageSummaryBuilder.java + src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/PropertyBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclet.xml ! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclets.properties + src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/BasePropertyTaglet.java + src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/ExpertTaglet.java + src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/PropertyGetterTaglet.java + src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/PropertySetterTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/TagletManager.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/TagletWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/ClassTree.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/IndexBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Util.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/VisibleMemberMap.java + test/com/sun/javadoc/testJavaFX/C.java + test/com/sun/javadoc/testJavaFX/D.java + test/com/sun/javadoc/testJavaFX/TestJavaFX.java ! test/com/sun/javadoc/testLambdaFeature/TestLambdaFeature.java Changeset: bd49e0304281 Author: vromero Date: 2013-02-26 09:04 +0000 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/bd49e0304281 8008436: javac should not issue a warning for overriding equals without hasCode if hashCode has been overriden by a superclass Reviewed-by: jjg, mcimadamore ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! test/tools/javac/6563143/OverridesEqualsButNotHashCodeTest.java ! test/tools/javac/6563143/OverridesEqualsButNotHashCodeTest.out Changeset: 133a0a0c2cbc Author: mcimadamore Date: 2013-02-28 14:00 +0000 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/133a0a0c2cbc 8008723: Graph Inference: bad graph calculation leads to assertion error Summary: Dependencies are not propagated correctly through merged nodes during inference graph initialization Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Infer.java + test/tools/javac/lambda/TargetType65.java Changeset: 332f23993353 Author: mcimadamore Date: 2013-02-28 14:05 +0000 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/332f23993353 8008813: Structural most specific fails when method reference is passed to overloaded method Summary: Bad logic for checking most specific method reference type Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Resolve.java + test/tools/javac/lambda/MostSpecific08.java Changeset: 08782b8b03ce Author: mcimadamore Date: 2013-02-28 14:05 +0000 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/08782b8b03ce 8008537: Missing method reference lookup error when unbound search finds a static method Summary: Static-ness check should be applied after member reference resolution Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! test/tools/javac/diags/examples/NonStaticCantBeRefFragment.java + test/tools/javac/diags/examples/StaticMethodInUnboundLookup.java ! test/tools/javac/lambda/MethodReference22.java ! test/tools/javac/lambda/MethodReference22.out ! test/tools/javac/lambda/MethodReference28.out ! test/tools/javac/lambda/MethodReference51.out ! test/tools/javac/lambda/TargetType60.java ! test/tools/javac/lambda/TargetType60.out Changeset: 6f988040a1c8 Author: jjg Date: 2013-03-01 10:47 -0800 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/6f988040a1c8 8008949: javadoc stopped copying doc-files Reviewed-by: bpatel ! src/share/classes/com/sun/tools/doclets/internal/toolkit/AbstractDoclet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/Configuration.java + test/com/sun/javadoc/testDocFiles/TestDocFiles.java + test/com/sun/javadoc/testDocFiles/pkg/Test.java + test/com/sun/javadoc/testDocFiles/pkg/doc-files/test.txt Changeset: 69cd2bfd4a31 Author: mcimadamore Date: 2013-03-05 14:04 +0000 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/69cd2bfd4a31 8004962: Code generation crash with lambda and local classes Summary: Translation info should be propagated from LambdaToMethod to Lower Reviewed-by: jjg, rfield ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java ! src/share/classes/com/sun/tools/javac/comp/Lower.java + test/tools/javac/lambda/LambdaCapture07.java Changeset: d2a98dde7ecc Author: mcimadamore Date: 2013-03-05 14:12 +0000 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/d2a98dde7ecc 8009227: Certain diagnostics should not be deferred Summary: Add new diagnostic flag to mark non deferrable diagnostics Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/DeferredAttr.java ! src/share/classes/com/sun/tools/javac/util/JCDiagnostic.java ! src/share/classes/com/sun/tools/javac/util/Log.java + test/tools/javac/lambda/abort/CompletionFailure.java Changeset: a708c5f1da06 Author: mcimadamore Date: 2013-03-05 14:16 +0000 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/a708c5f1da06 8009154: Missing cast in method reference bridge leads to NoSuchMethodError Summary: Missing cast in generated method reference bridge Reviewed-by: rfield, jjg ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java + test/tools/javac/lambda/MethodReference65.java Changeset: 12202e6ab78a Author: mcimadamore Date: 2013-03-05 14:19 +0000 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/12202e6ab78a 8009129: Illegal access error when calling method reference Summary: Javac generates method handle referencing non public type Reviewed-by: jjg, rfield ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/tree/JCTree.java + test/tools/javac/diags/examples/NotDefPublicCantAccessFragment/NotDefPublicCantAccessFragment.java + test/tools/javac/diags/examples/NotDefPublicCantAccessFragment/p/C.java + test/tools/javac/lambda/inaccessibleMref01/InaccessibleMref01.java + test/tools/javac/lambda/inaccessibleMref01/InaccessibleMref01.out + test/tools/javac/lambda/inaccessibleMref01/p1/C.java + test/tools/javac/lambda/inaccessibleMref02/InaccessibleMref02.java + test/tools/javac/lambda/inaccessibleMref02/p1/C.java Changeset: 188a07a0a7a0 Author: lana Date: 2013-03-05 11:51 -0800 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/188a07a0a7a0 Merge Changeset: d0178bd8125c Author: mcimadamore Date: 2013-03-06 15:29 +0000 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/d0178bd8125c 8009299: Javac crashes when compiling method reference to static interface method Summary: Assertion in Check.checMethod is too strict Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/jvm/Pool.java + test/tools/javac/lambda/MethodReference66.java Changeset: 8a78243291ef Author: mcimadamore Date: 2013-03-06 15:33 +0000 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/8a78243291ef 8009459: Wrong behavior of diamond finder with source level 7 Summary: Diamond finder doesn't take into account different inference behaviors Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Attr.java + test/tools/javac/generics/diamond/6939780/T6939780.java + test/tools/javac/generics/diamond/6939780/T6939780_7.out + test/tools/javac/generics/diamond/6939780/T6939780_8.out - test/tools/javac/generics/diamond/T6939780.java - test/tools/javac/generics/diamond/T6939780.out Changeset: c98b3e96c726 Author: mcimadamore Date: 2013-03-06 15:33 +0000 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/c98b3e96c726 8009391: Synthetic name of serializable lambda methods should not contain negative numbers Summary: Use hex representation of method signature hashcode to avoid negative numbers Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java Changeset: 3806171b52d8 Author: vromero Date: 2013-03-07 10:04 +0000 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/3806171b52d8 8009138: javac, equals-hashCode warning tuning Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javac/code/Symtab.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties + test/tools/javac/6563143/EqualsHashCodeWarningTest.java + test/tools/javac/6563143/EqualsHashCodeWarningTest.out - test/tools/javac/6563143/OverridesEqualsButNotHashCodeTest.java - test/tools/javac/6563143/OverridesEqualsButNotHashCodeTest.out Changeset: 823fb9229724 Author: vromero Date: 2013-03-07 10:12 +0000 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/823fb9229724 8009170: Regression: javac generates redundant bytecode in assignop involving arrays Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/comp/Lower.java ! test/tools/javac/7167125/DiffResultAfterSameOperationInnerClasses.java + test/tools/javac/8009170/RedundantByteCodeInArrayTest.java Changeset: a02c3ddc182b Author: rfield Date: 2013-03-07 08:26 -0800 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/a02c3ddc182b 8009582: Method reference generic constructor gives: IllegalArgumentException: Invalid lambda deserialization Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java + test/tools/javac/lambda/GenericMethodRefImplClass.java Changeset: c61add6bf8ac Author: vromero Date: 2013-03-11 15:35 +0000 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/c61add6bf8ac 6181889: Empty try/finally results in bytecodes being generated Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/comp/Lower.java + test/tools/javac/T6181889/EmptyFinallyTest.java Changeset: d0ae21e3a382 Author: rfield Date: 2013-03-11 10:02 -0700 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/d0ae21e3a382 8009742: Bad lambda name for lambda in a static initializer or ctor Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java + test/tools/javac/lambda/SerializedLambdaInInit.java Changeset: fbb6e470079d Author: ohrstrom Date: 2013-03-11 19:03 -0700 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/fbb6e470079d 8009843: sjavac should accept -cp as synonym for -classpath Reviewed-by: jjg ! src/share/classes/com/sun/tools/sjavac/Main.java Changeset: 7fe9b9d29095 Author: jfranck Date: 2013-03-12 11:16 +0100 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/7fe9b9d29095 8005205: tests missing bugid for repeating annotation change Reviewed-by: jjg, ssides ! test/tools/javac/annotations/repeatingAnnotations/MissingContainer.java ! test/tools/javac/annotations/repeatingAnnotations/MissingDefaultCase1.java Changeset: 6db9a3b1a93f Author: mcimadamore Date: 2013-03-12 16:02 +0000 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/6db9a3b1a93f 8008540: Constructor reference to non-reifiable array should be rejected 8008539: Spurious error when constructor reference mention an interface type 8008538: Constructor reference accepts wildcard parameterized types Summary: Overhaul of Check.checkConstructorRefType Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Check.java ! test/tools/javac/lambda/MethodReference38.out + test/tools/javac/lambda/MethodReference64.java + test/tools/javac/lambda/MethodReference64.out Changeset: 5ddecb91d843 Author: mcimadamore Date: 2013-03-12 16:02 +0000 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/5ddecb91d843 8009545: Graph inference: dependencies between inference variables should be set during incorporation Summary: Move all transitivity checks into the incorporation round Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Type.java ! src/share/classes/com/sun/tools/javac/comp/Infer.java ! test/tools/javac/lambda/TargetType28.out Changeset: f427043f8c65 Author: jfranck Date: 2013-03-12 17:39 +0100 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/f427043f8c65 7196531: Duplicate error messages on repeating annotations Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Annotate.java + test/tools/javac/annotations/repeatingAnnotations/DuplicateErrors.java + test/tools/javac/annotations/repeatingAnnotations/DuplicateErrors.out ! test/tools/javac/annotations/repeatingAnnotations/NoRepeatableAnno.out ! test/tools/javac/annotations/typeAnnotations/failures/common/arrays/DuplicateTypeAnnotation.out ! test/tools/javac/annotations/typeAnnotations/failures/common/innertypeparams/DuplicateTypeAnnotation.out ! test/tools/javac/annotations/typeAnnotations/failures/common/newarray/DuplicateTypeAnnotation.out ! test/tools/javac/annotations/typeAnnotations/failures/common/parambounds/DuplicateTypeAnnotation.out ! test/tools/javac/annotations/typeAnnotations/failures/common/receiver/DuplicateTypeAnnotation.out ! test/tools/javac/annotations/typeAnnotations/failures/common/rest/DuplicateTypeAnnotation.out ! test/tools/javac/annotations/typeAnnotations/failures/common/typeArgs/DuplicateTypeAnnotation.out ! test/tools/javac/annotations/typeAnnotations/failures/common/typeparams/DuplicateTypeAnnotation.out ! test/tools/javac/annotations/typeAnnotations/failures/common/wildcards/DuplicateTypeAnnotation.out ! test/tools/javac/annotations/typeAnnotations/newlocations/RepeatingTypeAnnotations.out Changeset: 39f8eb897ec6 Author: lana Date: 2013-03-12 16:43 -0700 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/39f8eb897ec6 Merge - test/tools/apt/Basics/NullAPF.java - test/tools/apt/Basics/apt.sh - test/tools/apt/verifyVariables.sh - test/tools/javac/4846262/Test.java - test/tools/javac/4846262/Test.out - test/tools/javac/4846262/Test.sh - test/tools/javac/6302184/T6302184.sh - test/tools/javac/ClassPathTest/ClassPathTest.sh - test/tools/javac/ClassPathTest/ClassPathTest1.java - test/tools/javac/ClassPathTest/ClassPathTest2.java - test/tools/javac/ClassPathTest/ClassPathTest3.java - test/tools/javac/ClassPathTest/bar/pkg/ClassPathTestAux2.java - test/tools/javac/ClassPathTest/foo/pkg/ClassPathTestAux1.java - test/tools/javac/ClassPathTest/pkg/ClassPathTestAux3.java - test/tools/javac/ExtDirs/ExtDirTest_1.java - test/tools/javac/ExtDirs/ExtDirTest_2.java - test/tools/javac/ExtDirs/ExtDirTest_3.java - test/tools/javac/ExtDirs/ExtDirs.sh - test/tools/javac/MethodParameters.java - test/tools/javac/MissingInclude.java - test/tools/javac/MissingInclude.sh - test/tools/javac/ProtectedInnerClass/ProtectedInnerClass.sh - test/tools/javac/ProtectedInnerClass/ProtectedInnerClass_2.java - test/tools/javac/ProtectedInnerClass/p1/ProtectedInnerClass1.java - test/tools/javac/ProtectedInnerClass/p2/ProtectedInnerClass2.java - test/tools/javac/ProtectedInnerClass/p2/ProtectedInnerClass3.java - test/tools/javac/T5090006/T5090006.java - test/tools/javac/T5090006/compiler.sh - test/tools/javac/constDebug/ConstDebug.java - test/tools/javac/constDebug/ConstDebug.sh - test/tools/javac/fatalErrors/NoJavaLang.java - test/tools/javac/fatalErrors/NoJavaLang.out - test/tools/javac/fatalErrors/NoJavaLang.sh - test/tools/javac/generics/diamond/T6939780.java - test/tools/javac/generics/diamond/T6939780.out - test/tools/javac/innerClassFile/Driver.sh - test/tools/javac/innerClassFile/x/B.java - test/tools/javac/innerClassFile/x/C.java - test/tools/javac/innerClassFile/y/Main.java - test/tools/javac/innerClassFile/y/R1.java - test/tools/javac/innerClassFile/y/R2.java - test/tools/javac/innerClassFile/y/R3.java - test/tools/javac/javazip/A.java - test/tools/javac/javazip/Test.sh - test/tools/javac/javazip/bad/B.java - test/tools/javac/javazip/good/B.java - test/tools/javac/links/T.java - test/tools/javac/links/b/B.java - test/tools/javac/links/links.sh - test/tools/javac/newlines/Newlines.sh - test/tools/javac/stackmap/T4955930.java - test/tools/javac/stackmap/T4955930.sh - test/tools/javac/unicode/SupplementaryJavaID6.sh - test/tools/javah/6257087/foo.java - test/tools/javah/6257087/foo.sh - test/tools/javah/6257087/foo_bar.h - test/tools/javah/ConstMacroTest.sh - test/tools/javah/MissingParamClassException.java - test/tools/javah/MissingParamClassTest.sh - test/tools/javah/ParamClassTest.java - test/tools/javah/SubClassConsts.java - test/tools/javah/SubClassConsts.out - test/tools/javah/SubClassConsts.win - test/tools/javah/SuperClassConsts.java - test/tools/javap/NotPackagePrivateInterface.java - test/tools/javap/PublicInterfaceTest.sh - test/tools/javap/pathsep.sh - test/tools/javap/stackmap/T6271292.java - test/tools/javap/stackmap/T6271292.out - test/tools/javap/stackmap/T6271292.sh Changeset: 825da6847791 Author: lana Date: 2013-03-14 19:33 -0700 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/825da6847791 Merge From omajid at redhat.com Fri Mar 15 19:55:20 2013 From: omajid at redhat.com (Omair Majid) Date: Fri, 15 Mar 2013 15:55:20 -0400 Subject: New official README-builds.html In-Reply-To: <1889117016.19471000.1363370700860.JavaMail.root@redhat.com> References: <1889117016.19471000.1363370700860.JavaMail.root@redhat.com> Message-ID: <51437CA8.20406@redhat.com> On 03/15/2013 02:05 PM, Andrew Hughes wrote: >> Might want to update configure to check for these libs on linux. >> > > Well that won't work everywhere: > > $ apt-get install libx11-dev libxext-dev libxt-dev libxrender-dev > bash: apt-get: command not found > > so this advice has limited usage anyway. Well, configure checks for these would be nice to have anyway (even if the package names for these are different). I ran into this last week too. > How did it fail without the X libraries? Here's what the failure looks like on Fedora 19: http://kojipkgs.fedoraproject.org//work/tasks/9190/5109190/build.log I don't know how long this build log would be around for, so here's the snippet of the build log around the error: (snip) + /usr/bin/mkdir -p /builddir/build/BUILD/java-1.8.0-openjdk/jdk8/build/jdk8.build/jdk/gensrc_x11wrappers (cd /builddir/build/BUILD/java-1.8.0-openjdk/jdk8/build/jdk8.build/jdk/gensrc_x11wrappers && /usr/bin/gcc -m64 -o /builddir/build/BUILD/java-1.8.0-openjdk/jdk8/build/jdk8.build/jdk/gensrc_x11wrappers/sizer.64.exe /builddir/build/BUILD/java-1.8.0-openjdk/jdk8/build/jdk8.build/jdk/gensrc_x11wrappers/sizer.64.c \ \ \ -I/builddir/build/BUILD/java-1.8.0-openjdk/jdk8/build/jdk8.build/jdk/include \ -I/builddir/build/BUILD/java-1.8.0-openjdk/jdk8/jdk/src/share/javavm/export \ -I/builddir/build/BUILD/java-1.8.0-openjdk/jdk8/jdk/src/solaris/javavm/export \ -I/builddir/build/BUILD/java-1.8.0-openjdk/jdk8/jdk/src/share/native/common \ -I/builddir/build/BUILD/java-1.8.0-openjdk/jdk8/jdk/src/solaris/native/common \ -I/builddir/build/BUILD/java-1.8.0-openjdk/jdk8/jdk/src/solaris/native/sun/awt \ -I/builddir/build/BUILD/java-1.8.0-openjdk/jdk8/jdk/src/share/native/sun/awt/debug \ -I/builddir/build/BUILD/java-1.8.0-openjdk/jdk8/jdk/src/share/native/sun/awt/image/cvutils -lc) GensrcX11Wrappers.gmk:91: Building /builddir/build/BUILD/java-1.8.0-openjdk/jdk8/build/jdk8.build/jdk/gensrc_x11wrappers/sizer.64.exe (from /builddir/build/BUILD/java-1.8.0-openjdk/jdk8/build/jdk8.build/jdk/gensrc_x11wrappers/sizer.64.c) (/builddir/build/BUILD/java-1.8.0-openjdk/jdk8/build/jdk8.build/jdk/gensrc_x11wrappers/sizer.64.c newer) + cd /builddir/build/BUILD/java-1.8.0-openjdk/jdk8/build/jdk8.build/jdk/gensrc_x11wrappers + /usr/bin/gcc -m64 -o /builddir/build/BUILD/java-1.8.0-openjdk/jdk8/build/jdk8.build/jdk/gensrc_x11wrappers/sizer.64.exe /builddir/build/BUILD/java-1.8.0-openjdk/jdk8/build/jdk8.build/jdk/gensrc_x11wrappers/sizer.64.c -I/builddir/build/BUILD/java-1.8.0-openjdk/jdk8/build/jdk8.build/jdk/include -I/builddir/build/BUILD/java-1.8.0-openjdk/jdk8/jdk/src/share/javavm/export -I/builddir/build/BUILD/java-1.8.0-openjdk/jdk8/jdk/src/solaris/javavm/export -I/builddir/build/BUILD/java-1.8.0-openjdk/jdk8/jdk/src/share/native/common -I/builddir/build/BUILD/java-1.8.0-openjdk/jdk8/jdk/src/solaris/native/common -I/builddir/build/BUILD/java-1.8.0-openjdk/jdk8/jdk/src/solaris/native/sun/awt -I/builddir/build/BUILD/java-1.8.0-openjdk/jdk8/jdk/src/share/native/sun/awt/debug -I/builddir/build/BUILD/java-1.8.0-openjdk/jdk8/jdk/src/share/native/sun/awt/image/cvutils -lc (snip) In file included from /builddir/build/BUILD/java-1.8.0-openjdk/jdk8/build/jdk8.build/jdk/gensrc_x11wrappers/sizer.64.c:11:0: /builddir/build/BUILD/java-1.8.0-openjdk/jdk8/jdk/src/solaris/native/sun/awt/awt_p.h:51:36: fatal error: X11/extensions/Xrender.h: No such file or directory #include ^ (snip) Cheers, Omair -- PGP Key: 66484681 (http://pgp.mit.edu/) Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 From david.r.chase at oracle.com Fri Mar 15 20:49:41 2013 From: david.r.chase at oracle.com (David Chase) Date: Fri, 15 Mar 2013 16:49:41 -0400 Subject: Building on Mac In-Reply-To: References: <432F8A89-C354-4E8D-9DF5-0BCB3DDB32C6@oracle.com> Message-ID: For reference, I build on Mountain Lion, with latest XCode, recent XQuartz, and some MacPorts. "grep opt/local config.log" produces: configure:6295: result: /opt/local/bin/gsed configure:8107: found /opt/local/bin/port configure:10420: found /opt/local/bin/pkg-config configure:10432: result: /opt/local/bin/pkg-config configure:30314: /usr/llvm-gcc-4.2/bin/llvm-g++-4.2 -o conftest -L/opt/local/lib -lfreetype conftest.cpp -lfreetype >&5 configure:31661: found /opt/local/bin/ccache configure:31673: result: /opt/local/bin/ccache ac_cv_path_CCACHE=/opt/local/bin/ccache ac_cv_path_SED=/opt/local/bin/gsed ac_cv_path_ac_pt_PKG_CONFIG=/opt/local/bin/pkg-config pkg_cv_FREETYPE2_CFLAGS='-I/opt/local/include/freetype2 -I/opt/local/include ' pkg_cv_FREETYPE2_LIBS='-L/opt/local/lib -lfreetype ' CCACHE='CCACHE_COMPRESS=1 CCACHE_SLOPPINESS=time_macros /opt/local/bin/ccache' FREETYPE2_CFLAGS='-I/opt/local/include/freetype2 -I/opt/local/include ' FREETYPE2_LIBS='-L/opt/local/lib -lfreetype' PACKAGE_PATH='/opt/local' PKG_CONFIG='/opt/local/bin/pkg-config' SED='/opt/local/bin/gsed' and also: port list installed | egrep 'ccache|freetype|gsed|pkg-config' ccache @3.1.9 devel/ccache freetype @2.4.10 print/freetype gsed @4.2.2 textproc/gsed On 2013-03-15, at 2:53 PM, David DeHaven wrote: > >> Then it stumbled upon freetype, which it should not need either. I added --with-freetype, but it failed to recognise .dylib as the library suffix: >> >> configure: error: Could not find libfreetype.so nor freetype.dll in /opt/local/lib > > > IIRC Freetype is required for libfontmanager when building OpenJDK (not closed) but it doesn't seem to differentiate when configure is run. > > Look in config.log to see why it's failing. The error message is misleading, it's not actually looking for those extensions it's checking by using the CFLAGS returned by pkg-config. Mine works fine with the MacPorts freetype port. > > -DrD- > From mike.duigou at oracle.com Fri Mar 15 21:07:11 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Fri, 15 Mar 2013 14:07:11 -0700 Subject: Building on Mac In-Reply-To: References: <432F8A89-C354-4E8D-9DF5-0BCB3DDB32C6@oracle.com> Message-ID: Be warned that if you use macports you'll need to make sure that ports is at the end of your path. The ports version of "file" doesn't correctly detect 64 bit executables. Mike On Mar 15 2013, at 13:49 , David Chase wrote: > For reference, I build on Mountain Lion, with latest XCode, recent XQuartz, and some MacPorts. > > "grep opt/local config.log" produces: > > configure:6295: result: /opt/local/bin/gsed > configure:8107: found /opt/local/bin/port > configure:10420: found /opt/local/bin/pkg-config > configure:10432: result: /opt/local/bin/pkg-config > configure:30314: /usr/llvm-gcc-4.2/bin/llvm-g++-4.2 -o conftest -L/opt/local/lib -lfreetype conftest.cpp -lfreetype >&5 > configure:31661: found /opt/local/bin/ccache > configure:31673: result: /opt/local/bin/ccache > ac_cv_path_CCACHE=/opt/local/bin/ccache > ac_cv_path_SED=/opt/local/bin/gsed > ac_cv_path_ac_pt_PKG_CONFIG=/opt/local/bin/pkg-config > pkg_cv_FREETYPE2_CFLAGS='-I/opt/local/include/freetype2 -I/opt/local/include ' > pkg_cv_FREETYPE2_LIBS='-L/opt/local/lib -lfreetype ' > CCACHE='CCACHE_COMPRESS=1 CCACHE_SLOPPINESS=time_macros /opt/local/bin/ccache' > FREETYPE2_CFLAGS='-I/opt/local/include/freetype2 -I/opt/local/include ' > FREETYPE2_LIBS='-L/opt/local/lib -lfreetype' > PACKAGE_PATH='/opt/local' > PKG_CONFIG='/opt/local/bin/pkg-config' > SED='/opt/local/bin/gsed' > > and also: > > port list installed | egrep 'ccache|freetype|gsed|pkg-config' > ccache @3.1.9 devel/ccache > freetype @2.4.10 print/freetype > gsed @4.2.2 textproc/gsed > > > > On 2013-03-15, at 2:53 PM, David DeHaven wrote: > >> >>> Then it stumbled upon freetype, which it should not need either. I added --with-freetype, but it failed to recognise .dylib as the library suffix: >>> >>> configure: error: Could not find libfreetype.so nor freetype.dll in /opt/local/lib >> >> >> IIRC Freetype is required for libfontmanager when building OpenJDK (not closed) but it doesn't seem to differentiate when configure is run. >> >> Look in config.log to see why it's failing. The error message is misleading, it's not actually looking for those extensions it's checking by using the CFLAGS returned by pkg-config. Mine works fine with the MacPorts freetype port. >> >> -DrD- >> > From david.dehaven at oracle.com Fri Mar 15 21:17:53 2013 From: david.dehaven at oracle.com (David DeHaven) Date: Fri, 15 Mar 2013 14:17:53 -0700 Subject: Building on Mac In-Reply-To: References: <432F8A89-C354-4E8D-9DF5-0BCB3DDB32C6@oracle.com> Message-ID: <53012722-9F7D-4F83-A78E-0DA55D185683@oracle.com> It's not installed by default, and I'm not sure why you'd want to since Apple provides it. But if it's there that could be a concern. Incidentally, someone else got a build working with brew so there's an alternative to MacPorts for those who don't want to use it. The only caveat is that brew installs everything into the system paths, which could cause problems later on. And it uses Ruby *hack cough*... -DrD- > Be warned that if you use macports you'll need to make sure that ports is at the end of your path. The ports version of "file" doesn't correctly detect 64 bit executables. > > Mike > > On Mar 15 2013, at 13:49 , David Chase wrote: > >> For reference, I build on Mountain Lion, with latest XCode, recent XQuartz, and some MacPorts. >> >> "grep opt/local config.log" produces: >> >> configure:6295: result: /opt/local/bin/gsed >> configure:8107: found /opt/local/bin/port >> configure:10420: found /opt/local/bin/pkg-config >> configure:10432: result: /opt/local/bin/pkg-config >> configure:30314: /usr/llvm-gcc-4.2/bin/llvm-g++-4.2 -o conftest -L/opt/local/lib -lfreetype conftest.cpp -lfreetype >&5 >> configure:31661: found /opt/local/bin/ccache >> configure:31673: result: /opt/local/bin/ccache >> ac_cv_path_CCACHE=/opt/local/bin/ccache >> ac_cv_path_SED=/opt/local/bin/gsed >> ac_cv_path_ac_pt_PKG_CONFIG=/opt/local/bin/pkg-config >> pkg_cv_FREETYPE2_CFLAGS='-I/opt/local/include/freetype2 -I/opt/local/include ' >> pkg_cv_FREETYPE2_LIBS='-L/opt/local/lib -lfreetype ' >> CCACHE='CCACHE_COMPRESS=1 CCACHE_SLOPPINESS=time_macros /opt/local/bin/ccache' >> FREETYPE2_CFLAGS='-I/opt/local/include/freetype2 -I/opt/local/include ' >> FREETYPE2_LIBS='-L/opt/local/lib -lfreetype' >> PACKAGE_PATH='/opt/local' >> PKG_CONFIG='/opt/local/bin/pkg-config' >> SED='/opt/local/bin/gsed' >> >> and also: >> >> port list installed | egrep 'ccache|freetype|gsed|pkg-config' >> ccache @3.1.9 devel/ccache >> freetype @2.4.10 print/freetype >> gsed @4.2.2 textproc/gsed >> >> >> >> On 2013-03-15, at 2:53 PM, David DeHaven wrote: >> >>> >>>> Then it stumbled upon freetype, which it should not need either. I added --with-freetype, but it failed to recognise .dylib as the library suffix: >>>> >>>> configure: error: Could not find libfreetype.so nor freetype.dll in /opt/local/lib >>> >>> >>> IIRC Freetype is required for libfontmanager when building OpenJDK (not closed) but it doesn't seem to differentiate when configure is run. >>> >>> Look in config.log to see why it's failing. The error message is misleading, it's not actually looking for those extensions it's checking by using the CFLAGS returned by pkg-config. Mine works fine with the MacPorts freetype port. >>> >>> -DrD- >>> >> > From omajid at redhat.com Fri Mar 15 22:34:32 2013 From: omajid at redhat.com (Omair Majid) Date: Fri, 15 Mar 2013 18:34:32 -0400 Subject: Allow configure to detect if EC implementation is present In-Reply-To: <51412F9A.4020309@oracle.com> References: <5140DCF3.8020808@redhat.com> <51412F9A.4020309@oracle.com> Message-ID: <5143A1F8.9000500@redhat.com> On 03/13/2013 10:02 PM, David Holmes wrote: > Bug ID: 8010030 The bug is not public, so I am not sure what the summary of the issue is. Is it "Allow configure to detect if EC implementation is present"? I ask because often the developer who files the bug gives it a different (often better) summary. Thanks, Omair -- PGP Key: 66484681 (http://pgp.mit.edu/) Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 From david.holmes at oracle.com Fri Mar 15 23:44:28 2013 From: david.holmes at oracle.com (David Holmes) Date: Sat, 16 Mar 2013 09:44:28 +1000 Subject: Allow configure to detect if EC implementation is present In-Reply-To: <5143A1F8.9000500@redhat.com> References: <5140DCF3.8020808@redhat.com> <51412F9A.4020309@oracle.com> <5143A1F8.9000500@redhat.com> Message-ID: <5143B25C.4010101@oracle.com> On 16/03/2013 8:34 AM, Omair Majid wrote: > On 03/13/2013 10:02 PM, David Holmes wrote: >> Bug ID: 8010030 > > The bug is not public, so I am not sure what the summary of the issue > is. Is it "Allow configure to detect if EC implementation is present"? I > ask because often the developer who files the bug gives it a different > (often better) summary. Yes it is: "Allow configure to detect if EC implementation is present" The bug should be visible by now :( David > Thanks, > Omair > From david.r.chase at oracle.com Sat Mar 16 00:15:44 2013 From: david.r.chase at oracle.com (David Chase) Date: Fri, 15 Mar 2013 20:15:44 -0400 Subject: Building on Mac In-Reply-To: <53012722-9F7D-4F83-A78E-0DA55D185683@oracle.com> References: <432F8A89-C354-4E8D-9DF5-0BCB3DDB32C6@oracle.com> <53012722-9F7D-4F83-A78E-0DA55D185683@oracle.com> Message-ID: <1E282B51-DEB3-49EC-B858-57184961E1B6@oracle.com> On 2013-03-15, at 5:17 PM, David DeHaven wrote: > It's not installed by default, and I'm not sure why you'd want to since Apple provides it. But if it's there that could be a concern. If you install subversion, you get file, and there are other things that (if installed) will pull in subversion (e.g., trac). Similarly if you install one of the Gnu Fortrans, you get /usr/local/gcc, version 4.8.0. Oops. > Incidentally, someone else got a build working with brew so there's an alternative to MacPorts for those who don't want to use it. The only caveat is that brew installs everything into the system paths, which could cause problems later on. And it uses Ruby *hack cough*... Installing stuff on system paths is not what I want. David From mike.duigou at oracle.com Sat Mar 16 00:34:17 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Fri, 15 Mar 2013 17:34:17 -0700 Subject: Building on Mac In-Reply-To: <1E282B51-DEB3-49EC-B858-57184961E1B6@oracle.com> References: <432F8A89-C354-4E8D-9DF5-0BCB3DDB32C6@oracle.com> <53012722-9F7D-4F83-A78E-0DA55D185683@oracle.com> <1E282B51-DEB3-49EC-B858-57184961E1B6@oracle.com> Message-ID: On Mar 15 2013, at 17:15 , David Chase wrote: > > On 2013-03-15, at 5:17 PM, David DeHaven wrote: > >> It's not installed by default, and I'm not sure why you'd want to since Apple provides it. But if it's there that could be a concern. > > If you install subversion, you get file, and there are other things that (if installed) will pull in subversion (e.g., trac). Aha! That must be where it came from. (Though I now wonder why subversion can't use the Apple version of file) > Similarly if you install one of the Gnu Fortrans, you get /usr/local/gcc, version 4.8.0. Oops. > >> Incidentally, someone else got a build working with brew so there's an alternative to MacPorts for those who don't want to use it. The only caveat is that brew installs everything into the system paths, which could cause problems later on. And it uses Ruby *hack cough*... > > Installing stuff on system paths is not what I want. Agreed! Mike From david.dehaven at oracle.com Sat Mar 16 00:48:13 2013 From: david.dehaven at oracle.com (David DeHaven) Date: Fri, 15 Mar 2013 17:48:13 -0700 Subject: Building on Mac In-Reply-To: <1E282B51-DEB3-49EC-B858-57184961E1B6@oracle.com> References: <432F8A89-C354-4E8D-9DF5-0BCB3DDB32C6@oracle.com> <53012722-9F7D-4F83-A78E-0DA55D185683@oracle.com> <1E282B51-DEB3-49EC-B858-57184961E1B6@oracle.com> Message-ID: <26FD875D-3870-4D8F-9C51-836E73CC05EA@oracle.com> >> It's not installed by default, and I'm not sure why you'd want to since Apple provides it. But if it's there that could be a concern. > > If you install subversion, you get file, and there are other things that (if installed) will pull in subversion (e.g., trac). Ah Trac, how I remember thee... >> Incidentally, someone else got a build working with brew so there's an alternative to MacPorts for those who don't want to use it. The only caveat is that brew installs everything into the system paths, which could cause problems later on. And it uses Ruby *hack cough*... > > Installing stuff on system paths is not what I want. Same here, which is one reason I stick with MacPorts. I'm not sure what the fuss is anyways, once binaries are available ports come in very fast. -DrD- From sadhak001 at gmail.com Sat Mar 16 20:38:07 2013 From: sadhak001 at gmail.com (Mani Sarkar) Date: Sat, 16 Mar 2013 20:38:07 +0000 Subject: Building on Mac (David DeHaven) Message-ID: Hi, The OpenJDK adopters in the community have been testing out the steps lately to build OpenJDK on the MacOS and so far things are fine, we didn't need to install MacPort or have major issues with the Mac. You can have a look at the steps if these help with your issues: http://java.net/projects/adoptopenjdk/pages/AdoptOpenJDKBuildInstructions http://java.net/projects/adoptopenjdk/pages/GetSource http://java.net/projects/adoptopenjdk/pages/GetSource#Mac_OS_X http://java.net/projects/adoptopenjdk/pages/Build#Mac_OS_X http://java.net/projects/adoptopenjdk/pages/MakeImages Any feedback is welcome. Cheers, mani > >> It's not installed by default, and I'm not sure why you'd want to since > Apple provides it. But if it's there that could be a concern. > > > > If you install subversion, you get file, and there are other things that > (if installed) will pull in subversion (e.g., trac). > > Ah Trac, how I remember thee... > > > >> Incidentally, someone else got a build working with brew so there's an > alternative to MacPorts for those who don't want to use it. The only caveat > is that brew installs everything into the system paths, which could cause > problems later on. And it uses Ruby *hack cough*... > > > > Installing stuff on system paths is not what I want. > > Same here, which is one reason I stick with MacPorts. I'm not sure what > the fuss is anyways, once binaries are available ports come in very fast. > > -DrD- > -- *Twitter:* @theNeomatrix369 *Blog:* http://neomatrix369.wordpress.com *JUG activity:* LJC Advocate (@adoptopenjdk & @adoptajsr programs) *Meet-a-Project:* https://github.com/MutabilityDetector *Come to Devoxx UK 2013:* http://www.devoxx.com/display/UK13/Home *Don't chase success, rather aim for "Excellence", and success will come chasing after you!* From oehrstroem at gmail.com Sun Mar 17 19:52:45 2013 From: oehrstroem at gmail.com (=?ISO-8859-1?Q?Fredrik_=D6hrstr=F6m?=) Date: Sun, 17 Mar 2013 20:52:45 +0100 Subject: New official README-builds.html In-Reply-To: <1889117016.19471000.1363370700860.JavaMail.root@redhat.com> References: <5136D5BB.8050007@oracle.com> <1889117016.19471000.1363370700860.JavaMail.root@redhat.com> Message-ID: 2013/3/15 Andrew Hughes : >> Might want to update configure to check for these libs on linux. >> > > Well that won't work everywhere: > > $ apt-get install libx11-dev libxext-dev libxt-dev libxrender-dev > bash: apt-get: command not found > > so this advice has limited usage anyway. Actually the configure script does detect wether you are using debs or rpms and gives advice accordingly. It does check for some X11 libraries, but as the OpenJDK has moved on, there are new dependencies that are not checked. This should be fixed. The suggestions are easy to maintain and the package names do not change that often. //Fredrik From david.holmes at oracle.com Sun Mar 17 23:41:09 2013 From: david.holmes at oracle.com (David Holmes) Date: Mon, 18 Mar 2013 09:41:09 +1000 Subject: Building on Mac In-Reply-To: <432F8A89-C354-4E8D-9DF5-0BCB3DDB32C6@oracle.com> References: <432F8A89-C354-4E8D-9DF5-0BCB3DDB32C6@oracle.com> Message-ID: <51465495.9040508@oracle.com> Hi Peter, On 12/03/2013 6:06 PM, Peter Zhelezniakov wrote: > Hello, > I'm trying to build jdk8 on Mac, cannot get past the configuration step. Are you trying to build OpenJDK or Oracle JDK? There are a number of differences in the build requirements and processes. If the closed repos are found you will default to Oracle JDK, else OpenJDK. David Holmes > First configure asked for X11, which I believe is not needed on Mac. I worked around with --x-libraries. Then it stumbled upon freetype, which it should not need either. I added --with-freetype, but it failed to recognise .dylib as the library suffix: > > configure: error: Could not find libfreetype.so nor freetype.dll in /opt/local/lib > > Any advice? > Thanks! > From Peter.Zhelezniakov at oracle.com Mon Mar 18 06:56:42 2013 From: Peter.Zhelezniakov at oracle.com (Peter Zhelezniakov) Date: Mon, 18 Mar 2013 10:56:42 +0400 Subject: Building on Mac In-Reply-To: <51465495.9040508@oracle.com> References: <432F8A89-C354-4E8D-9DF5-0BCB3DDB32C6@oracle.com> <51465495.9040508@oracle.com> Message-ID: On Mar 18, 2013, at 3:41 AM, David Holmes wrote: > Are you trying to build OpenJDK or Oracle JDK? Oracle JDK -- I have jdk/make/closed and jdk/src/closed. I've parsed the output of --debug-configure, and realised I need the --enable-macosx-runtime-support option. With this option, configure requires neither X11 nor freetype. However, the build still fails without X headers. So the complete command line that led to successful build for me was: bash ./configure \ --x-includes=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/usr/X11/include \ --x-libraries=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/usr/X11/lib \ --enable-macosx-runtime-support Thanks! -- Peter From erik.joelsson at oracle.com Mon Mar 18 08:20:01 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 18 Mar 2013 09:20:01 +0100 Subject: Building on Mac (David DeHaven) In-Reply-To: References: Message-ID: <5146CE31.7090005@oracle.com> A few comments inline. On 2013-03-16 21:38, Mani Sarkar wrote: > Hi, > > The OpenJDK adopters in the community have been testing out > the steps lately to build OpenJDK on the MacOS and so far things are fine, > we didn't need to install MacPort or have major issues with the Mac. > > You can have a look at the steps if these help with your issues: > http://java.net/projects/adoptopenjdk/pages/AdoptOpenJDKBuildInstructions > http://java.net/projects/adoptopenjdk/pages/GetSource > http://java.net/projects/adoptopenjdk/pages/GetSource#Mac_OS_X > http://java.net/projects/adoptopenjdk/pages/Build#Mac_OS_X There is no need to cd down to common/makefiles anymore. We hid the new build system there before making it default. Now you can run bash configure and make from the root. Please see README-builds.html in the src root for more details. It should be up to date now, thanks to Kelly. > http://java.net/projects/adoptopenjdk/pages/MakeImages > To get verbose build logs, the preferred way is to use the LOG variable and not VERBOSE. LOG can be set to warn, info, debug or trace. Again see README-builds.html. Also, the build output is always saved to a log file in the build output directory unless disabled, so no need to pipe yourself. /Erik > Any feedback is welcome. > > Cheers, > mani > > >>>> It's not installed by default, and I'm not sure why you'd want to since >> Apple provides it. But if it's there that could be a concern. >>> If you install subversion, you get file, and there are other things that >> (if installed) will pull in subversion (e.g., trac). >> >> Ah Trac, how I remember thee... >> >> >>>> Incidentally, someone else got a build working with brew so there's an >> alternative to MacPorts for those who don't want to use it. The only caveat >> is that brew installs everything into the system paths, which could cause >> problems later on. And it uses Ruby *hack cough*... >>> Installing stuff on system paths is not what I want. >> Same here, which is one reason I stick with MacPorts. I'm not sure what >> the fuss is anyways, once binaries are available ports come in very fast. >> >> -DrD- >> From daniel.fuchs at oracle.com Mon Mar 18 08:40:57 2013 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Mon, 18 Mar 2013 09:40:57 +0100 Subject: Building on Mac In-Reply-To: References: <432F8A89-C354-4E8D-9DF5-0BCB3DDB32C6@oracle.com> <51465495.9040508@oracle.com> Message-ID: <5146D319.8070809@oracle.com> Hi Peter, Did you 'install the command line tools' in Xcode? The fact that you have to refer to /Applications/Xcode.app/... let me think that perhaps you didn't. Start Xcode, go to preferences, and explore the different panes: there's one that will let you install the command line tools. If that was the issue - then after installing the command line tools you should be able to run configure without the two options below. Hope this helps, -- daniel On 3/18/13 7:56 AM, Peter Zhelezniakov wrote: > On Mar 18, 2013, at 3:41 AM, David Holmes wrote: >> Are you trying to build OpenJDK or Oracle JDK? > Oracle JDK -- I have jdk/make/closed and jdk/src/closed. > > I've parsed the output of --debug-configure, and realised I need the --enable-macosx-runtime-support option. With this option, configure requires neither X11 nor freetype. However, the build still fails without X headers. So the complete command line that led to successful build for me was: > > bash ./configure \ > --x-includes=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/usr/X11/include \ > --x-libraries=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/usr/X11/lib \ > --enable-macosx-runtime-support > > Thanks! From weijun.wang at oracle.com Mon Mar 18 11:00:29 2013 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 18 Mar 2013 19:00:29 +0800 Subject: Code review request: 8010192: Enable native JGSS provider on Mac Message-ID: <5146F3CD.3000903@oracle.com> Please take a look at http://cr.openjdk.java.net/~weijun/8010192/webrev.00/ The Mac native JGSS provider is back. Besides reverting changes made in http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5a2ab2c3f106, there are: 1. GSSManagerImpl.java: enable the provider 2. SunNativeProvider.java: library name from MIT added 3. Update gssapi.h, new lines copied from Mac's gssapi.h 4. Liberate a test. Thanks Max From erik.joelsson at oracle.com Mon Mar 18 12:38:53 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 18 Mar 2013 13:38:53 +0100 Subject: Code review request: 8010192: Enable native JGSS provider on Mac In-Reply-To: <5146F3CD.3000903@oracle.com> References: <5146F3CD.3000903@oracle.com> Message-ID: <51470ADD.1040001@oracle.com> The build changes look ok. /Erik On 2013-03-18 12:00, Weijun Wang wrote: > Please take a look at > > http://cr.openjdk.java.net/~weijun/8010192/webrev.00/ > > The Mac native JGSS provider is back. Besides reverting changes made > in http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5a2ab2c3f106, there are: > > 1. GSSManagerImpl.java: enable the provider > 2. SunNativeProvider.java: library name from MIT added > 3. Update gssapi.h, new lines copied from Mac's gssapi.h > 4. Liberate a test. > > Thanks > Max From omajid at redhat.com Mon Mar 18 14:48:59 2013 From: omajid at redhat.com (omajid at redhat.com) Date: Mon, 18 Mar 2013 14:48:59 +0000 Subject: hg: jdk8/build: 8010030: Allow configure to detect if EC implementation is present Message-ID: <20130318144900.6FFFD4820F@hg.openjdk.java.net> Changeset: e2057191f6da Author: omajid Date: 2013-03-18 10:47 -0400 URL: http://hg.openjdk.java.net/jdk8/build/rev/e2057191f6da 8010030: Allow configure to detect if EC implementation is present Reviewed-by: andrew, dholmes ! common/autoconf/configure.ac ! common/autoconf/generated-configure.sh ! common/autoconf/jdk-options.m4 ! common/autoconf/spec.gmk.in From omajid at redhat.com Mon Mar 18 14:52:57 2013 From: omajid at redhat.com (Omair Majid) Date: Mon, 18 Mar 2013 10:52:57 -0400 Subject: Allow configure to detect if EC implementation is present In-Reply-To: <514302D5.7080309@oracle.com> References: <5140DCF3.8020808@redhat.com> <51412F9A.4020309@oracle.com> <51415436.9020404@oracle.com> <51415C3A.6030304@oracle.com> <5141A072.6020005@oracle.com> <5142270A.7040209@redhat.com> <5142E417.3020504@oracle.com> <514302D5.7080309@oracle.com> Message-ID: <51472A49.7020009@redhat.com> Hi, On 03/15/2013 07:15 AM, David Holmes wrote: > On 15/03/2013 7:04 PM, Erik Joelsson wrote: >> And as David pointed out, please notify me and Tim Bell when you push > > If I am added to that list we will have global timezone coverage :) > Though we should all see the push notifications anyway, it should > minimize the window of potential breakage. > > I think as long as the pushes are to jdk8/build that will also minimise > risk. Where we had problems last week was where pushes went to jdk8/tl. > That may still be needed in some cases, but for pure build changes > jdk8/build is best. I have pushed the changes: http://hg.openjdk.java.net/jdk8/build/rev/e2057191f6da http://hg.openjdk.java.net/jdk8/build/jdk/rev/624bcb480006 Thanks, Omair -- PGP Key: 66484681 (http://pgp.mit.edu/) Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 From omajid at redhat.com Mon Mar 18 14:49:23 2013 From: omajid at redhat.com (omajid at redhat.com) Date: Mon, 18 Mar 2013 14:49:23 +0000 Subject: hg: jdk8/build/jdk: 8010030: Allow configure to detect if EC implementation is present Message-ID: <20130318144950.E346548210@hg.openjdk.java.net> Changeset: 624bcb480006 Author: omajid Date: 2013-03-18 10:46 -0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/624bcb480006 8010030: Allow configure to detect if EC implementation is present Reviewed-by: andrew, dholmes ! makefiles/CompileNativeLibraries.gmk From omajid at redhat.com Mon Mar 18 17:39:58 2013 From: omajid at redhat.com (Omair Majid) Date: Mon, 18 Mar 2013 13:39:58 -0400 Subject: Empty jdk8/build/nashorn repository Message-ID: <5147516E.8030706@redhat.com> Hi, The repository at http://hg.openjdk.java.net/jdk8/build/nashorn is empty with no changesets. Now the build fails (on 'make all') with an error: ## Starting nashorn /bin/sh: line 0: cd: /home/omajid/devel/jdk8-build/nashorn/makefiles: No such file or directory make: *** [nashorn-only] Error 1 Is this expected? Thanks, Omair -- PGP Key: 66484681 (http://pgp.mit.edu/) Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 From gnu.andrew at redhat.com Mon Mar 18 17:56:52 2013 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Mon, 18 Mar 2013 13:56:52 -0400 (EDT) Subject: New official README-builds.html In-Reply-To: <51437CA8.20406@redhat.com> Message-ID: <1564699338.20465086.1363629412718.JavaMail.root@redhat.com> ----- Original Message ----- > On 03/15/2013 02:05 PM, Andrew Hughes wrote: > >> Might want to update configure to check for these libs on linux. > >> > > > > Well that won't work everywhere: > > > > $ apt-get install libx11-dev libxext-dev libxt-dev libxrender-dev > > bash: apt-get: command not found > > > > so this advice has limited usage anyway. > > Well, configure checks for these would be nice to have anyway (even > if > the package names for these are different). I ran into this last week > too. > > > How did it fail without the X libraries? > > Here's what the failure looks like on Fedora 19: > http://kojipkgs.fedoraproject.org//work/tasks/9190/5109190/build.log > > I don't know how long this build log would be around for, so here's > the > snippet of the build log around the error: > > (snip) > > + /usr/bin/mkdir -p > /builddir/build/BUILD/java-1.8.0-openjdk/jdk8/build/jdk8.build/jdk/gensrc_x11wrappers > (cd > /builddir/build/BUILD/java-1.8.0-openjdk/jdk8/build/jdk8.build/jdk/gensrc_x11wrappers > && /usr/bin/gcc -m64 -o > /builddir/build/BUILD/java-1.8.0-openjdk/jdk8/build/jdk8.build/jdk/gensrc_x11wrappers/sizer.64.exe > /builddir/build/BUILD/java-1.8.0-openjdk/jdk8/build/jdk8.build/jdk/gensrc_x11wrappers/sizer.64.c > \ > \ > \ > > -I/builddir/build/BUILD/java-1.8.0-openjdk/jdk8/build/jdk8.build/jdk/include > \ > > -I/builddir/build/BUILD/java-1.8.0-openjdk/jdk8/jdk/src/share/javavm/export > \ > > -I/builddir/build/BUILD/java-1.8.0-openjdk/jdk8/jdk/src/solaris/javavm/export > \ > > -I/builddir/build/BUILD/java-1.8.0-openjdk/jdk8/jdk/src/share/native/common > \ > > -I/builddir/build/BUILD/java-1.8.0-openjdk/jdk8/jdk/src/solaris/native/common > \ > > -I/builddir/build/BUILD/java-1.8.0-openjdk/jdk8/jdk/src/solaris/native/sun/awt > \ > > -I/builddir/build/BUILD/java-1.8.0-openjdk/jdk8/jdk/src/share/native/sun/awt/debug > \ > > -I/builddir/build/BUILD/java-1.8.0-openjdk/jdk8/jdk/src/share/native/sun/awt/image/cvutils > -lc) > GensrcX11Wrappers.gmk:91: Building > /builddir/build/BUILD/java-1.8.0-openjdk/jdk8/build/jdk8.build/jdk/gensrc_x11wrappers/sizer.64.exe > (from > /builddir/build/BUILD/java-1.8.0-openjdk/jdk8/build/jdk8.build/jdk/gensrc_x11wrappers/sizer.64.c) > (/builddir/build/BUILD/java-1.8.0-openjdk/jdk8/build/jdk8.build/jdk/gensrc_x11wrappers/sizer.64.c > newer) > + cd > /builddir/build/BUILD/java-1.8.0-openjdk/jdk8/build/jdk8.build/jdk/gensrc_x11wrappers > + /usr/bin/gcc -m64 -o > /builddir/build/BUILD/java-1.8.0-openjdk/jdk8/build/jdk8.build/jdk/gensrc_x11wrappers/sizer.64.exe > /builddir/build/BUILD/java-1.8.0-openjdk/jdk8/build/jdk8.build/jdk/gensrc_x11wrappers/sizer.64.c > -I/builddir/build/BUILD/java-1.8.0-openjdk/jdk8/build/jdk8.build/jdk/include > -I/builddir/build/BUILD/java-1.8.0-openjdk/jdk8/jdk/src/share/javavm/export > -I/builddir/build/BUILD/java-1.8.0-openjdk/jdk8/jdk/src/solaris/javavm/export > -I/builddir/build/BUILD/java-1.8.0-openjdk/jdk8/jdk/src/share/native/common > -I/builddir/build/BUILD/java-1.8.0-openjdk/jdk8/jdk/src/solaris/native/common > -I/builddir/build/BUILD/java-1.8.0-openjdk/jdk8/jdk/src/solaris/native/sun/awt > -I/builddir/build/BUILD/java-1.8.0-openjdk/jdk8/jdk/src/share/native/sun/awt/debug > -I/builddir/build/BUILD/java-1.8.0-openjdk/jdk8/jdk/src/share/native/sun/awt/image/cvutils > -lc > > (snip) > > In file included from > /builddir/build/BUILD/java-1.8.0-openjdk/jdk8/build/jdk8.build/jdk/gensrc_x11wrappers/sizer.64.c:11:0: > /builddir/build/BUILD/java-1.8.0-openjdk/jdk8/jdk/src/solaris/native/sun/awt/awt_p.h:51:36: > fatal error: X11/extensions/Xrender.h: No such file or directory > #include > ^ > (snip) > > Cheers, > Omair > > -- > PGP Key: 66484681 (http://pgp.mit.edu/) > Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 > Ugh. That's failing way too late and needs to be caught by configure. -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From gnu.andrew at redhat.com Mon Mar 18 18:03:07 2013 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Mon, 18 Mar 2013 14:03:07 -0400 (EDT) Subject: New official README-builds.html In-Reply-To: Message-ID: <1287171251.20467164.1363629787636.JavaMail.root@redhat.com> ----- Original Message ----- > 2013/3/15 Andrew Hughes : > >> Might want to update configure to check for these libs on linux. > >> > > > > Well that won't work everywhere: > > > > $ apt-get install libx11-dev libxext-dev libxt-dev libxrender-dev > > bash: apt-get: command not found > > > > so this advice has limited usage anyway. > > Actually the configure script does detect wether you are using debs > or rpms > and gives advice accordingly. And what if you're using neither? > It does check for some X11 libraries, > but as the OpenJDK has moved on, there are new dependencies that are > not checked. Hmmm, the failure Omair quotes in: http://mail.openjdk.java.net/pipermail/build-dev/2013-March/008375.html is for XRender which has been a dependency since 7. It's even in IcedTea6 as we backported it. I'll bring the check from IcedTea over to OpenJDK. > This should be fixed. The suggestions are easy to > maintain > and the package names do not change that often. Depends how many distros you intend to support. > > //Fredrik > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From gnu.andrew at redhat.com Mon Mar 18 17:54:21 2013 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Mon, 18 Mar 2013 13:54:21 -0400 (EDT) Subject: Empty jdk8/build/nashorn repository In-Reply-To: <5147516E.8030706@redhat.com> Message-ID: <243914179.20464042.1363629261446.JavaMail.root@redhat.com> ----- Original Message ----- > Hi, > > The repository at http://hg.openjdk.java.net/jdk8/build/nashorn is > empty > with no changesets. Now the build fails (on 'make all') with an > error: > > ## Starting nashorn > /bin/sh: line 0: cd: /home/omajid/devel/jdk8-build/nashorn/makefiles: > No > such file or directory > make: *** [nashorn-only] Error 1 > > Is this expected? > Yes & no: http://mail.openjdk.java.net/pipermail/jdk8-dev/2013-February/002065.html > Thanks, > Omair > > -- > PGP Key: 66484681 (http://pgp.mit.edu/) > Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From neugens.limasoftware at gmail.com Mon Mar 18 18:09:47 2013 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Mon, 18 Mar 2013 19:09:47 +0100 Subject: New official README-builds.html In-Reply-To: <1287171251.20467164.1363629787636.JavaMail.root@redhat.com> References: <1287171251.20467164.1363629787636.JavaMail.root@redhat.com> Message-ID: 2013/3/18 Andrew Hughes : > > Depends how many distros you intend to support. Well, I guess that if somebody doesn't use one between rhel/fedora/suse/ubuntu/mint/debian than most likely will figure out the exact commands anyway, I think those are still good suggestions to keep around. Cheers, Mario -- pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF IcedRobot: www.icedrobot.org Proud GNU Classpath developer: http://www.classpath.org/ Read About us at: http://planet.classpath.org OpenJDK: http://openjdk.java.net/projects/caciocavallo/ Please, support open standards: http://endsoftpatents.org/ From david.katleman at oracle.com Mon Mar 18 19:00:11 2013 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Mon, 18 Mar 2013 19:00:11 +0000 Subject: hg: jdk8/build/nashorn: 133 new changesets Message-ID: <20130318190130.8A9224821A@hg.openjdk.java.net> Changeset: b8a1b238c77c Author: duke Date: 2007-12-01 00:00 +0000 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/b8a1b238c77c Initial load + .hgignore + .jcheck/conf Changeset: 6031a0bc0ae2 Author: jcoomes Date: 2012-12-20 14:16 -0800 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/6031a0bc0ae2 8005364: initial hg tags for nashorn repo Reviewed-by: amurillo + .hgtags Changeset: da1e581c933b Author: jlaskey Date: 2012-12-21 16:36 -0400 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/da1e581c933b 8005403: Open-source Nashorn Reviewed-by: attila, hannesw, lagergren, sundar Contributed-by: james.laskey at oracle.com, akhil.arora at oracle.com, andreas.woess at jku.at, attila.szegedi at oracle.com, hannes.wallnoefer at oracle.com, henry.jen at oracle.com, marcus.lagergren at oracle.com, pavel.semenov at oracle.com, pavel.stepanov at oracle.com, petr.hejl at oracle.com, petr.pisl at oracle.com, sundararajan.athijegannathan at oracle.com ! .hgignore + ASSEMBLY_EXCEPTION + LICENSE + README + RELEASE_README + THIRD_PARTY_README + bin/checkintest.sh + bin/fixorphantests.sh + bin/fixwhitespace.sh + bin/jjs + bin/jjs.bat + bin/jjssecure + bin/jjssecure.bat + bin/nashorn + bin/nashorn.bat + bin/rm-non-tracked.sh + bin/verbose_octane.bat + bin/verbose_octane.sh + buildtools/nasgen/README + buildtools/nasgen/build.xml + buildtools/nasgen/nasgen.iml + buildtools/nasgen/project.properties + buildtools/nasgen/src/META-INF/MANIFEST.MF + buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/ClassGenerator.java + buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/ConstructorGenerator.java + buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/Main.java + buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/MemberInfo.java + buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/MethodGenerator.java + buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/NullVisitor.java + buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/PrototypeGenerator.java + buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/ScriptClassInfo.java + buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/ScriptClassInfoCollector.java + buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/ScriptClassInstrumentor.java + buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/StringConstants.java + docs/DEVELOPER_README + docs/genshelldoc.js + make/Makefile + make/build-benchmark.xml + make/build-nasgen.xml + make/build.xml + make/nbproject/ide-file-targets.xml + make/nbproject/ide-targets.xml + make/nbproject/jdk.xml + make/nbproject/nbjdk.properties + make/nbproject/nbjdk.xml + make/nbproject/project.xml + make/project.properties + samples/counters.js + samples/letter.js + samples/parser.js + samples/shell.js + samples/test.js + samples/uniq.js + src/META-INF/MANIFEST.MF + src/META-INF/services/javax.script.ScriptEngineFactory + src/jdk/nashorn/api/scripting/NashornException.java + src/jdk/nashorn/api/scripting/NashornScriptEngine.java + src/jdk/nashorn/api/scripting/NashornScriptEngineFactory.java + src/jdk/nashorn/api/scripting/ScriptObjectMirror.java + src/jdk/nashorn/api/scripting/package-info.java + src/jdk/nashorn/api/scripting/resources/engine.js + src/jdk/nashorn/internal/codegen/AccessSpecializer.java + src/jdk/nashorn/internal/codegen/BranchOptimizer.java + src/jdk/nashorn/internal/codegen/ClassEmitter.java + src/jdk/nashorn/internal/codegen/CodeGenerator.java + src/jdk/nashorn/internal/codegen/CompileUnit.java + src/jdk/nashorn/internal/codegen/Compiler.java + src/jdk/nashorn/internal/codegen/CompilerConstants.java + src/jdk/nashorn/internal/codegen/ConstantData.java + src/jdk/nashorn/internal/codegen/Emitter.java + src/jdk/nashorn/internal/codegen/Frame.java + src/jdk/nashorn/internal/codegen/FunctionSignature.java + src/jdk/nashorn/internal/codegen/Lower.java + src/jdk/nashorn/internal/codegen/MethodEmitter.java + src/jdk/nashorn/internal/codegen/Namespace.java + src/jdk/nashorn/internal/codegen/RuntimeCallSite.java + src/jdk/nashorn/internal/codegen/SharedScopeCall.java + src/jdk/nashorn/internal/codegen/Splitter.java + src/jdk/nashorn/internal/codegen/Transform.java + src/jdk/nashorn/internal/codegen/WeighNodes.java + src/jdk/nashorn/internal/codegen/objects/FieldObjectCreator.java + src/jdk/nashorn/internal/codegen/objects/FunctionObjectCreator.java + src/jdk/nashorn/internal/codegen/objects/MapCreator.java + src/jdk/nashorn/internal/codegen/objects/ObjectClassGenerator.java + src/jdk/nashorn/internal/codegen/objects/ObjectCreator.java + src/jdk/nashorn/internal/codegen/objects/ObjectMapCreator.java + src/jdk/nashorn/internal/codegen/types/ArrayType.java + src/jdk/nashorn/internal/codegen/types/BitwiseType.java + src/jdk/nashorn/internal/codegen/types/BooleanType.java + src/jdk/nashorn/internal/codegen/types/BytecodeArrayOps.java + src/jdk/nashorn/internal/codegen/types/BytecodeBitwiseOps.java + src/jdk/nashorn/internal/codegen/types/BytecodeNumericOps.java + src/jdk/nashorn/internal/codegen/types/BytecodeOps.java + src/jdk/nashorn/internal/codegen/types/IntType.java + src/jdk/nashorn/internal/codegen/types/LongType.java + src/jdk/nashorn/internal/codegen/types/NumberType.java + src/jdk/nashorn/internal/codegen/types/NumericType.java + src/jdk/nashorn/internal/codegen/types/ObjectType.java + src/jdk/nashorn/internal/codegen/types/Type.java + src/jdk/nashorn/internal/ir/AccessNode.java + src/jdk/nashorn/internal/ir/Assignment.java + src/jdk/nashorn/internal/ir/BaseNode.java + src/jdk/nashorn/internal/ir/BinaryNode.java + src/jdk/nashorn/internal/ir/Block.java + src/jdk/nashorn/internal/ir/BreakNode.java + src/jdk/nashorn/internal/ir/BreakableNode.java + src/jdk/nashorn/internal/ir/CallNode.java + src/jdk/nashorn/internal/ir/CaseNode.java + src/jdk/nashorn/internal/ir/CatchNode.java + src/jdk/nashorn/internal/ir/ContinueNode.java + src/jdk/nashorn/internal/ir/DoWhileNode.java + src/jdk/nashorn/internal/ir/EmptyNode.java + src/jdk/nashorn/internal/ir/ExecuteNode.java + src/jdk/nashorn/internal/ir/ForNode.java + src/jdk/nashorn/internal/ir/FunctionCall.java + src/jdk/nashorn/internal/ir/FunctionNode.java + src/jdk/nashorn/internal/ir/IdentNode.java + src/jdk/nashorn/internal/ir/IfNode.java + src/jdk/nashorn/internal/ir/IndexNode.java + src/jdk/nashorn/internal/ir/LabelNode.java + src/jdk/nashorn/internal/ir/LabeledNode.java + src/jdk/nashorn/internal/ir/LineNumberNode.java + src/jdk/nashorn/internal/ir/LiteralNode.java + src/jdk/nashorn/internal/ir/Location.java + src/jdk/nashorn/internal/ir/Node.java + src/jdk/nashorn/internal/ir/ObjectNode.java + src/jdk/nashorn/internal/ir/PropertyKey.java + src/jdk/nashorn/internal/ir/PropertyNode.java + src/jdk/nashorn/internal/ir/ReferenceNode.java + src/jdk/nashorn/internal/ir/ReturnNode.java + src/jdk/nashorn/internal/ir/RuntimeNode.java + src/jdk/nashorn/internal/ir/SplitNode.java + src/jdk/nashorn/internal/ir/SwitchNode.java + src/jdk/nashorn/internal/ir/Symbol.java + src/jdk/nashorn/internal/ir/TernaryNode.java + src/jdk/nashorn/internal/ir/ThrowNode.java + src/jdk/nashorn/internal/ir/TryNode.java + src/jdk/nashorn/internal/ir/TypeOverride.java + src/jdk/nashorn/internal/ir/UnaryNode.java + src/jdk/nashorn/internal/ir/VarNode.java + src/jdk/nashorn/internal/ir/WhileNode.java + src/jdk/nashorn/internal/ir/WithNode.java + src/jdk/nashorn/internal/ir/annotations/ChildNode.java + src/jdk/nashorn/internal/ir/annotations/Ignore.java + src/jdk/nashorn/internal/ir/annotations/ParentNode.java + src/jdk/nashorn/internal/ir/annotations/Reference.java + src/jdk/nashorn/internal/ir/debug/ASTWriter.java + src/jdk/nashorn/internal/ir/debug/JSONWriter.java + src/jdk/nashorn/internal/ir/debug/PrintVisitor.java + src/jdk/nashorn/internal/ir/visitor/NodeOperatorVisitor.java + src/jdk/nashorn/internal/ir/visitor/NodeVisitor.java + src/jdk/nashorn/internal/objects/AccessorPropertyDescriptor.java + src/jdk/nashorn/internal/objects/ArrayBufferView.java + src/jdk/nashorn/internal/objects/DataPropertyDescriptor.java + src/jdk/nashorn/internal/objects/DateParser.java + src/jdk/nashorn/internal/objects/GenericPropertyDescriptor.java + src/jdk/nashorn/internal/objects/Global.java + src/jdk/nashorn/internal/objects/NativeArguments.java + src/jdk/nashorn/internal/objects/NativeArray.java + src/jdk/nashorn/internal/objects/NativeArrayBuffer.java + src/jdk/nashorn/internal/objects/NativeBoolean.java + src/jdk/nashorn/internal/objects/NativeDate.java + src/jdk/nashorn/internal/objects/NativeDebug.java + src/jdk/nashorn/internal/objects/NativeError.java + src/jdk/nashorn/internal/objects/NativeEvalError.java + src/jdk/nashorn/internal/objects/NativeFloat32Array.java + src/jdk/nashorn/internal/objects/NativeFloat64Array.java + src/jdk/nashorn/internal/objects/NativeFunction.java + src/jdk/nashorn/internal/objects/NativeInt16Array.java + src/jdk/nashorn/internal/objects/NativeInt32Array.java + src/jdk/nashorn/internal/objects/NativeInt8Array.java + src/jdk/nashorn/internal/objects/NativeJSAdapter.java + src/jdk/nashorn/internal/objects/NativeJSON.java + src/jdk/nashorn/internal/objects/NativeJava.java + src/jdk/nashorn/internal/objects/NativeJavaImporter.java + src/jdk/nashorn/internal/objects/NativeMath.java + src/jdk/nashorn/internal/objects/NativeNumber.java + src/jdk/nashorn/internal/objects/NativeObject.java + src/jdk/nashorn/internal/objects/NativeRangeError.java + src/jdk/nashorn/internal/objects/NativeReferenceError.java + src/jdk/nashorn/internal/objects/NativeRegExp.java + src/jdk/nashorn/internal/objects/NativeRegExpExecResult.java + src/jdk/nashorn/internal/objects/NativeStrictArguments.java + src/jdk/nashorn/internal/objects/NativeString.java + src/jdk/nashorn/internal/objects/NativeSyntaxError.java + src/jdk/nashorn/internal/objects/NativeTypeError.java + src/jdk/nashorn/internal/objects/NativeURIError.java + src/jdk/nashorn/internal/objects/NativeUint16Array.java + src/jdk/nashorn/internal/objects/NativeUint32Array.java + src/jdk/nashorn/internal/objects/NativeUint8Array.java + src/jdk/nashorn/internal/objects/NativeUint8ClampedArray.java + src/jdk/nashorn/internal/objects/PrototypeObject.java + src/jdk/nashorn/internal/objects/ScriptFunctionImpl.java + src/jdk/nashorn/internal/objects/annotations/Attribute.java + src/jdk/nashorn/internal/objects/annotations/Constructor.java + src/jdk/nashorn/internal/objects/annotations/Function.java + src/jdk/nashorn/internal/objects/annotations/Getter.java + src/jdk/nashorn/internal/objects/annotations/Property.java + src/jdk/nashorn/internal/objects/annotations/ScriptClass.java + src/jdk/nashorn/internal/objects/annotations/Setter.java + src/jdk/nashorn/internal/objects/annotations/SpecializedConstructor.java + src/jdk/nashorn/internal/objects/annotations/SpecializedFunction.java + src/jdk/nashorn/internal/objects/annotations/Where.java + src/jdk/nashorn/internal/objects/package-info.java + src/jdk/nashorn/internal/parser/AbstractParser.java + src/jdk/nashorn/internal/parser/JSONParser.java + src/jdk/nashorn/internal/parser/Lexer.java + src/jdk/nashorn/internal/parser/Parser.java + src/jdk/nashorn/internal/parser/RegExp.java + src/jdk/nashorn/internal/parser/RegExpScanner.java + src/jdk/nashorn/internal/parser/Scanner.java + src/jdk/nashorn/internal/parser/Token.java + src/jdk/nashorn/internal/parser/TokenKind.java + src/jdk/nashorn/internal/parser/TokenLookup.java + src/jdk/nashorn/internal/parser/TokenStream.java + src/jdk/nashorn/internal/parser/TokenType.java + src/jdk/nashorn/internal/runtime/AccessorProperty.java + src/jdk/nashorn/internal/runtime/BitVector.java + src/jdk/nashorn/internal/runtime/CodeInstaller.java + src/jdk/nashorn/internal/runtime/ConsString.java + src/jdk/nashorn/internal/runtime/Context.java + src/jdk/nashorn/internal/runtime/Debug.java + src/jdk/nashorn/internal/runtime/DebugLogger.java + src/jdk/nashorn/internal/runtime/DefaultPropertyAccess.java + src/jdk/nashorn/internal/runtime/ECMAErrors.java + src/jdk/nashorn/internal/runtime/ECMAException.java + src/jdk/nashorn/internal/runtime/ErrorManager.java + src/jdk/nashorn/internal/runtime/FindProperty.java + src/jdk/nashorn/internal/runtime/FunctionScope.java + src/jdk/nashorn/internal/runtime/GlobalFunctions.java + src/jdk/nashorn/internal/runtime/GlobalObject.java + src/jdk/nashorn/internal/runtime/JSErrorType.java + src/jdk/nashorn/internal/runtime/JSType.java + src/jdk/nashorn/internal/runtime/Logging.java + src/jdk/nashorn/internal/runtime/NashornLoader.java + src/jdk/nashorn/internal/runtime/NativeJavaPackage.java + src/jdk/nashorn/internal/runtime/NumberToString.java + src/jdk/nashorn/internal/runtime/ParserException.java + src/jdk/nashorn/internal/runtime/Property.java + src/jdk/nashorn/internal/runtime/PropertyAccess.java + src/jdk/nashorn/internal/runtime/PropertyDescriptor.java + src/jdk/nashorn/internal/runtime/PropertyHashMap.java + src/jdk/nashorn/internal/runtime/PropertyListener.java + src/jdk/nashorn/internal/runtime/PropertyListenerManager.java + src/jdk/nashorn/internal/runtime/PropertyMap.java + src/jdk/nashorn/internal/runtime/QuotedStringTokenizer.java + src/jdk/nashorn/internal/runtime/RegExpMatch.java + src/jdk/nashorn/internal/runtime/Scope.java + src/jdk/nashorn/internal/runtime/ScriptFunction.java + src/jdk/nashorn/internal/runtime/ScriptLoader.java + src/jdk/nashorn/internal/runtime/ScriptObject.java + src/jdk/nashorn/internal/runtime/ScriptRuntime.java + src/jdk/nashorn/internal/runtime/ScriptingFunctions.java + src/jdk/nashorn/internal/runtime/Source.java + src/jdk/nashorn/internal/runtime/SpillProperty.java + src/jdk/nashorn/internal/runtime/StructureLoader.java + src/jdk/nashorn/internal/runtime/URIUtils.java + src/jdk/nashorn/internal/runtime/Undefined.java + src/jdk/nashorn/internal/runtime/UserAccessorProperty.java + src/jdk/nashorn/internal/runtime/Version.java + src/jdk/nashorn/internal/runtime/WithObject.java + src/jdk/nashorn/internal/runtime/arrays/ArrayData.java + src/jdk/nashorn/internal/runtime/arrays/ArrayFilter.java + src/jdk/nashorn/internal/runtime/arrays/ArrayIndex.java + src/jdk/nashorn/internal/runtime/arrays/ArrayIterator.java + src/jdk/nashorn/internal/runtime/arrays/ArrayLikeIterator.java + src/jdk/nashorn/internal/runtime/arrays/DeletedArrayFilter.java + src/jdk/nashorn/internal/runtime/arrays/DeletedRangeArrayFilter.java + src/jdk/nashorn/internal/runtime/arrays/EmptyArrayLikeIterator.java + src/jdk/nashorn/internal/runtime/arrays/FrozenArrayFilter.java + src/jdk/nashorn/internal/runtime/arrays/IntArrayData.java + src/jdk/nashorn/internal/runtime/arrays/InvalidArrayIndexException.java + src/jdk/nashorn/internal/runtime/arrays/IteratorAction.java + src/jdk/nashorn/internal/runtime/arrays/LongArrayData.java + src/jdk/nashorn/internal/runtime/arrays/MapIterator.java + src/jdk/nashorn/internal/runtime/arrays/NoTypeArrayData.java + src/jdk/nashorn/internal/runtime/arrays/NumberArrayData.java + src/jdk/nashorn/internal/runtime/arrays/ObjectArrayData.java + src/jdk/nashorn/internal/runtime/arrays/ReverseArrayIterator.java + src/jdk/nashorn/internal/runtime/arrays/ReverseMapIterator.java + src/jdk/nashorn/internal/runtime/arrays/SealedArrayFilter.java + src/jdk/nashorn/internal/runtime/arrays/SparseArrayData.java + src/jdk/nashorn/internal/runtime/arrays/UndefinedArrayFilter.java + src/jdk/nashorn/internal/runtime/linker/Bootstrap.java + src/jdk/nashorn/internal/runtime/linker/InvokeByName.java + src/jdk/nashorn/internal/runtime/linker/JSObjectLinker.java + src/jdk/nashorn/internal/runtime/linker/JavaAdapterFactory.java + src/jdk/nashorn/internal/runtime/linker/JavaArgumentConverters.java + src/jdk/nashorn/internal/runtime/linker/LinkerCallSite.java + src/jdk/nashorn/internal/runtime/linker/Lookup.java + src/jdk/nashorn/internal/runtime/linker/Mangler.java + src/jdk/nashorn/internal/runtime/linker/MethodHandleFactory.java + src/jdk/nashorn/internal/runtime/linker/MethodHandleFunctionality.java + src/jdk/nashorn/internal/runtime/linker/NashornBottomLinker.java + src/jdk/nashorn/internal/runtime/linker/NashornCallSiteDescriptor.java + src/jdk/nashorn/internal/runtime/linker/NashornGuardedInvocation.java + src/jdk/nashorn/internal/runtime/linker/NashornGuards.java + src/jdk/nashorn/internal/runtime/linker/NashornLinker.java + src/jdk/nashorn/internal/runtime/linker/NashornPrimitiveLinker.java + src/jdk/nashorn/internal/runtime/linker/PrimitiveLookup.java + src/jdk/nashorn/internal/runtime/options/KeyValueOption.java + src/jdk/nashorn/internal/runtime/options/Option.java + src/jdk/nashorn/internal/runtime/options/OptionTemplate.java + src/jdk/nashorn/internal/runtime/options/Options.java + src/jdk/nashorn/internal/runtime/options/ValueOption.java + src/jdk/nashorn/internal/runtime/resources/Messages.properties + src/jdk/nashorn/internal/runtime/resources/Options.properties + src/jdk/nashorn/internal/runtime/resources/mozilla_compat.js + src/jdk/nashorn/internal/runtime/resources/parser.js + src/jdk/nashorn/internal/runtime/resources/version.properties-template + src/jdk/nashorn/internal/scripts/JO$.java + src/jdk/nashorn/internal/scripts/JS$.java + src/jdk/nashorn/tools/Shell.java + src/jdk/nashorn/tools/resources/Shell.properties + src/jdk/nashorn/tools/resources/shell.js + src/netscape/javascript/JSObject.java + src/overview.html + test/README + test/examples/dual-fields-micro.js + test/examples/innerbench.js + test/examples/typechain.js + test/lib/benchmark.js + test/opt/add.js + test/opt/add_constant.js + test/opt/add_reuse_callsite.js + test/opt/add_revert2.js + test/opt/cascade_specialize.js + test/script/assert.js + test/script/basic/NASHORN-100.js + test/script/basic/NASHORN-100.js.EXPECTED + test/script/basic/NASHORN-101.js + test/script/basic/NASHORN-101.js.EXPECTED + test/script/basic/NASHORN-102.js + test/script/basic/NASHORN-102.js.EXPECTED + test/script/basic/NASHORN-103.js + test/script/basic/NASHORN-104.js + test/script/basic/NASHORN-104.js.EXPECTED + test/script/basic/NASHORN-105.js + test/script/basic/NASHORN-105.js.EXPECTED + test/script/basic/NASHORN-106.js + test/script/basic/NASHORN-106.js.EXPECTED + test/script/basic/NASHORN-107.js + test/script/basic/NASHORN-108.js + test/script/basic/NASHORN-108.js.EXPECTED + test/script/basic/NASHORN-109.js + test/script/basic/NASHORN-109.js.EXPECTED + test/script/basic/NASHORN-11.js + test/script/basic/NASHORN-11.js.EXPECTED + test/script/basic/NASHORN-111.js + test/script/basic/NASHORN-111.js.EXPECTED + test/script/basic/NASHORN-113.js + test/script/basic/NASHORN-113.js.EXPECTED + test/script/basic/NASHORN-114.js + test/script/basic/NASHORN-115.js + test/script/basic/NASHORN-115.js.EXPECTED + test/script/basic/NASHORN-117.js + test/script/basic/NASHORN-118.js + test/script/basic/NASHORN-118.js.EXPECTED + test/script/basic/NASHORN-119.js + test/script/basic/NASHORN-119.js.EXPECTED + test/script/basic/NASHORN-12.js + test/script/basic/NASHORN-120.js + test/script/basic/NASHORN-122.js + test/script/basic/NASHORN-122.js.EXPECTED + test/script/basic/NASHORN-126.js + test/script/basic/NASHORN-126.js.EXPECTED + test/script/basic/NASHORN-127.js + test/script/basic/NASHORN-127.js.EXPECTED + test/script/basic/NASHORN-130.js + test/script/basic/NASHORN-132.js + test/script/basic/NASHORN-132.js.EXPECTED + test/script/basic/NASHORN-133.js + test/script/basic/NASHORN-133.js.EXPECTED + test/script/basic/NASHORN-135.js + test/script/basic/NASHORN-136.js + test/script/basic/NASHORN-136.js.EXPECTED + test/script/basic/NASHORN-14.js + test/script/basic/NASHORN-14.js.EXPECTED + test/script/basic/NASHORN-148.js + test/script/basic/NASHORN-148.js.EXPECTED + test/script/basic/NASHORN-15.js + test/script/basic/NASHORN-15.js.EXPECTED + test/script/basic/NASHORN-153.js + test/script/basic/NASHORN-156.js + test/script/basic/NASHORN-157.js + test/script/basic/NASHORN-163.js + test/script/basic/NASHORN-163.js.EXPECTED + test/script/basic/NASHORN-164.js + test/script/basic/NASHORN-165.js + test/script/basic/NASHORN-166.js + test/script/basic/NASHORN-168.js + test/script/basic/NASHORN-168.js.EXPECTED + test/script/basic/NASHORN-169.js + test/script/basic/NASHORN-172.js + test/script/basic/NASHORN-173.js + test/script/basic/NASHORN-173.js.EXPECTED + test/script/basic/NASHORN-174.js + test/script/basic/NASHORN-175.js + test/script/basic/NASHORN-176.js + test/script/basic/NASHORN-177.js + test/script/basic/NASHORN-177.js.EXPECTED + test/script/basic/NASHORN-178.js + test/script/basic/NASHORN-178.js.EXPECTED + test/script/basic/NASHORN-179.js + test/script/basic/NASHORN-18.js + test/script/basic/NASHORN-18.js.EXPECTED + test/script/basic/NASHORN-181.js + test/script/basic/NASHORN-182.js + test/script/basic/NASHORN-183.js + test/script/basic/NASHORN-184.js + test/script/basic/NASHORN-184.js.EXPECTED + test/script/basic/NASHORN-185.js + test/script/basic/NASHORN-185.js.EXPECTED + test/script/basic/NASHORN-187.js + test/script/basic/NASHORN-188.js + test/script/basic/NASHORN-188.js.EXPECTED + test/script/basic/NASHORN-19.js + test/script/basic/NASHORN-19.js.EXPECTED + test/script/basic/NASHORN-190.js + test/script/basic/NASHORN-192.js + test/script/basic/NASHORN-194.js + test/script/basic/NASHORN-196.js + test/script/basic/NASHORN-198.js + test/script/basic/NASHORN-20.js + test/script/basic/NASHORN-20.js.EXPECTED + test/script/basic/NASHORN-201.js + test/script/basic/NASHORN-202.js + test/script/basic/NASHORN-203.js + test/script/basic/NASHORN-204.js + test/script/basic/NASHORN-205.js + test/script/basic/NASHORN-206.js + test/script/basic/NASHORN-207.js + test/script/basic/NASHORN-207_2.js + test/script/basic/NASHORN-208.js + test/script/basic/NASHORN-208.js.EXPECTED + test/script/basic/NASHORN-209.js + test/script/basic/NASHORN-209.js.EXPECTED + test/script/basic/NASHORN-21.js + test/script/basic/NASHORN-21.js.EXPECTED + test/script/basic/NASHORN-211.js + test/script/basic/NASHORN-212.js + test/script/basic/NASHORN-213.js + test/script/basic/NASHORN-215.js + test/script/basic/NASHORN-215.js.EXPECTED + test/script/basic/NASHORN-216.js + test/script/basic/NASHORN-217.js + test/script/basic/NASHORN-217.js.EXPECTED + test/script/basic/NASHORN-219.js + test/script/basic/NASHORN-219.js.EXPECTED + test/script/basic/NASHORN-22.js + test/script/basic/NASHORN-22.js.EXPECTED + test/script/basic/NASHORN-221.js + test/script/basic/NASHORN-222.js + test/script/basic/NASHORN-223.js + test/script/basic/NASHORN-225.js + test/script/basic/NASHORN-226.js + test/script/basic/NASHORN-227.js + test/script/basic/NASHORN-228.js + test/script/basic/NASHORN-229.js + test/script/basic/NASHORN-229_subtest.js + test/script/basic/NASHORN-23.js + test/script/basic/NASHORN-23.js.EXPECTED + test/script/basic/NASHORN-232.js + test/script/basic/NASHORN-234.js + test/script/basic/NASHORN-235.js + test/script/basic/NASHORN-236.js + test/script/basic/NASHORN-237.js + test/script/basic/NASHORN-239.js + test/script/basic/NASHORN-24.js + test/script/basic/NASHORN-24.js.EXPECTED + test/script/basic/NASHORN-241.js + test/script/basic/NASHORN-242.js + test/script/basic/NASHORN-245.js + test/script/basic/NASHORN-247.js + test/script/basic/NASHORN-25.js + test/script/basic/NASHORN-25.js.EXPECTED + test/script/basic/NASHORN-251.js + test/script/basic/NASHORN-252.js + test/script/basic/NASHORN-253.js + test/script/basic/NASHORN-256.js + test/script/basic/NASHORN-258.js + test/script/basic/NASHORN-258.js.EXPECTED + test/script/basic/NASHORN-26.js + test/script/basic/NASHORN-26.js.EXPECTED + test/script/basic/NASHORN-260.js + test/script/basic/NASHORN-261.js + test/script/basic/NASHORN-262.js + test/script/basic/NASHORN-263.js + test/script/basic/NASHORN-264.js + test/script/basic/NASHORN-265.js + test/script/basic/NASHORN-265.js.EXPECTED + test/script/basic/NASHORN-266.js + test/script/basic/NASHORN-269.js + test/script/basic/NASHORN-27.js + test/script/basic/NASHORN-27.js.EXPECTED + test/script/basic/NASHORN-270.js + test/script/basic/NASHORN-271.js + test/script/basic/NASHORN-275.js + test/script/basic/NASHORN-276.js + test/script/basic/NASHORN-277.js + test/script/basic/NASHORN-278.js + test/script/basic/NASHORN-28.js + test/script/basic/NASHORN-28.js.EXPECTED + test/script/basic/NASHORN-281.js + test/script/basic/NASHORN-284.js + test/script/basic/NASHORN-284.js.EXPECTED + test/script/basic/NASHORN-285.js + test/script/basic/NASHORN-285.js.EXPECTED + test/script/basic/NASHORN-288.js + test/script/basic/NASHORN-29.js + test/script/basic/NASHORN-29.js.EXPECTED + test/script/basic/NASHORN-293.js + test/script/basic/NASHORN-293.js.EXPECTED + test/script/basic/NASHORN-294.js + test/script/basic/NASHORN-296.js + test/script/basic/NASHORN-297.js + test/script/basic/NASHORN-30.js + test/script/basic/NASHORN-30.js.EXPECTED + test/script/basic/NASHORN-300.js + test/script/basic/NASHORN-301.js + test/script/basic/NASHORN-301.js.EXPECTED + test/script/basic/NASHORN-304.js + test/script/basic/NASHORN-310.js + test/script/basic/NASHORN-310.js.EXPECTED + test/script/basic/NASHORN-318.js + test/script/basic/NASHORN-318.js.EXPECTED + test/script/basic/NASHORN-32.js + test/script/basic/NASHORN-32.js.EXPECTED + test/script/basic/NASHORN-321.js + test/script/basic/NASHORN-321.js.EXPECTED + test/script/basic/NASHORN-323.js + test/script/basic/NASHORN-323.js.EXPECTED + test/script/basic/NASHORN-324.js + test/script/basic/NASHORN-33.js + test/script/basic/NASHORN-33.js.EXPECTED + test/script/basic/NASHORN-331.js + test/script/basic/NASHORN-331.js.EXPECTED + test/script/basic/NASHORN-337.js + test/script/basic/NASHORN-337.js.EXPECTED + test/script/basic/NASHORN-34.js + test/script/basic/NASHORN-34.js.EXPECTED + test/script/basic/NASHORN-340.js + test/script/basic/NASHORN-340.js.EXPECTED + test/script/basic/NASHORN-349.js + test/script/basic/NASHORN-354.js + test/script/basic/NASHORN-354.js.EXPECTED + test/script/basic/NASHORN-355.js + test/script/basic/NASHORN-355.js.EXPECTED + test/script/basic/NASHORN-36.js + test/script/basic/NASHORN-36.js.EXPECTED + test/script/basic/NASHORN-365.js + test/script/basic/NASHORN-366.js + test/script/basic/NASHORN-366.js.EXPECTED + test/script/basic/NASHORN-368.js + test/script/basic/NASHORN-368.js.EXPECTED + test/script/basic/NASHORN-37.js + test/script/basic/NASHORN-37.js.EXPECTED + test/script/basic/NASHORN-375.js + test/script/basic/NASHORN-376.js + test/script/basic/NASHORN-377.js + test/script/basic/NASHORN-377.js.EXPECTED + test/script/basic/NASHORN-378.js + test/script/basic/NASHORN-38.js + test/script/basic/NASHORN-38.js.EXPECTED + test/script/basic/NASHORN-380.js + test/script/basic/NASHORN-380.js.EXPECTED + test/script/basic/NASHORN-381.js + test/script/basic/NASHORN-382.js + test/script/basic/NASHORN-383.js + test/script/basic/NASHORN-384.js + test/script/basic/NASHORN-384.js.EXPECTED + test/script/basic/NASHORN-385.js + test/script/basic/NASHORN-385.js.EXPECTED + test/script/basic/NASHORN-389.js + test/script/basic/NASHORN-389.js.EXPECTED + test/script/basic/NASHORN-393.js + test/script/basic/NASHORN-393.js.EXPECTED + test/script/basic/NASHORN-394.js + test/script/basic/NASHORN-394.js.EXPECTED + test/script/basic/NASHORN-396.js + test/script/basic/NASHORN-397.js + test/script/basic/NASHORN-398.js + test/script/basic/NASHORN-40.js + test/script/basic/NASHORN-40.js.EXPECTED + test/script/basic/NASHORN-400.js + test/script/basic/NASHORN-400.js.EXPECTED + test/script/basic/NASHORN-401.js + test/script/basic/NASHORN-401.js.EXPECTED + test/script/basic/NASHORN-402.js + test/script/basic/NASHORN-402.js.EXPECTED + test/script/basic/NASHORN-404.js + test/script/basic/NASHORN-405.js + test/script/basic/NASHORN-405.js.EXPECTED + test/script/basic/NASHORN-406.js + test/script/basic/NASHORN-408.js + test/script/basic/NASHORN-408.js.EXPECTED + test/script/basic/NASHORN-415.js + test/script/basic/NASHORN-415.js.EXPECTED + test/script/basic/NASHORN-416.js + test/script/basic/NASHORN-417.js + test/script/basic/NASHORN-418.js + test/script/basic/NASHORN-420.js + test/script/basic/NASHORN-421.js + test/script/basic/NASHORN-423.js + test/script/basic/NASHORN-423.js.EXPECTED + test/script/basic/NASHORN-423a.js + test/script/basic/NASHORN-424.js + test/script/basic/NASHORN-424.js.EXPECTED + test/script/basic/NASHORN-425.js + test/script/basic/NASHORN-425.js.EXPECTED + test/script/basic/NASHORN-426.js + test/script/basic/NASHORN-427.js + test/script/basic/NASHORN-428.js + test/script/basic/NASHORN-429.js + test/script/basic/NASHORN-432.js + test/script/basic/NASHORN-433.js + test/script/basic/NASHORN-434.js + test/script/basic/NASHORN-435.js + test/script/basic/NASHORN-437.js + test/script/basic/NASHORN-44.js + test/script/basic/NASHORN-44.js.EXPECTED + test/script/basic/NASHORN-441.js + test/script/basic/NASHORN-441.js.EXPECTED + test/script/basic/NASHORN-442.js + test/script/basic/NASHORN-443.js + test/script/basic/NASHORN-444.js + test/script/basic/NASHORN-444.js.EXPECTED + test/script/basic/NASHORN-445.js + test/script/basic/NASHORN-446.js + test/script/basic/NASHORN-447.js + test/script/basic/NASHORN-448.js + test/script/basic/NASHORN-449.js + test/script/basic/NASHORN-449.js.EXPECTED + test/script/basic/NASHORN-45.js + test/script/basic/NASHORN-45.js.EXPECTED + test/script/basic/NASHORN-450.js + test/script/basic/NASHORN-452.js + test/script/basic/NASHORN-459.js + test/script/basic/NASHORN-46.js + test/script/basic/NASHORN-46.js.EXPECTED + test/script/basic/NASHORN-462.js + test/script/basic/NASHORN-463.js + test/script/basic/NASHORN-468.js + test/script/basic/NASHORN-47.js + test/script/basic/NASHORN-473.js + test/script/basic/NASHORN-473.js.EXPECTED + test/script/basic/NASHORN-474.js + test/script/basic/NASHORN-474.js.EXPECTED + test/script/basic/NASHORN-478.js + test/script/basic/NASHORN-48.js + test/script/basic/NASHORN-48.js.EXPECTED + test/script/basic/NASHORN-481.js + test/script/basic/NASHORN-481.js.EXPECTED + test/script/basic/NASHORN-482.js + test/script/basic/NASHORN-484.js + test/script/basic/NASHORN-484.js.EXPECTED + test/script/basic/NASHORN-486.js + test/script/basic/NASHORN-487.js + test/script/basic/NASHORN-488.js + test/script/basic/NASHORN-49.js + test/script/basic/NASHORN-49.js.EXPECTED + test/script/basic/NASHORN-490.js + test/script/basic/NASHORN-494.js + test/script/basic/NASHORN-497.js + test/script/basic/NASHORN-498.js + test/script/basic/NASHORN-499.js + test/script/basic/NASHORN-50.js + test/script/basic/NASHORN-50.js.EXPECTED + test/script/basic/NASHORN-500.js + test/script/basic/NASHORN-503.js + test/script/basic/NASHORN-503.js.EXPECTED + test/script/basic/NASHORN-51.js + test/script/basic/NASHORN-51.js.EXPECTED + test/script/basic/NASHORN-511.js + test/script/basic/NASHORN-515.js + test/script/basic/NASHORN-515.js.EXPECTED + test/script/basic/NASHORN-516.js + test/script/basic/NASHORN-52.js + test/script/basic/NASHORN-534.js + test/script/basic/NASHORN-534.js.EXPECTED + test/script/basic/NASHORN-535.js + test/script/basic/NASHORN-535.js.EXPECTED + test/script/basic/NASHORN-544.js + test/script/basic/NASHORN-55.js + test/script/basic/NASHORN-554.js + test/script/basic/NASHORN-554.js.EXPECTED + test/script/basic/NASHORN-556.js + test/script/basic/NASHORN-556.js.EXPECTED + test/script/basic/NASHORN-56.js + test/script/basic/NASHORN-56.js.EXPECTED + test/script/basic/NASHORN-562.js + test/script/basic/NASHORN-565.js + test/script/basic/NASHORN-565.js.EXPECTED + test/script/basic/NASHORN-575.js + test/script/basic/NASHORN-575.js.EXPECTED + test/script/basic/NASHORN-58.js + test/script/basic/NASHORN-58.js.EXPECTED + test/script/basic/NASHORN-59.js + test/script/basic/NASHORN-59.js.EXPECTED + test/script/basic/NASHORN-592.js + test/script/basic/NASHORN-592.js.EXPECTED + test/script/basic/NASHORN-597.js + test/script/basic/NASHORN-597.js.EXPECTED + test/script/basic/NASHORN-60.js + test/script/basic/NASHORN-60.js.EXPECTED + test/script/basic/NASHORN-609.js + test/script/basic/NASHORN-609.js.EXPECTED + test/script/basic/NASHORN-61.js + test/script/basic/NASHORN-61.js.EXPECTED + test/script/basic/NASHORN-62.js + test/script/basic/NASHORN-62.js.EXPECTED + test/script/basic/NASHORN-620.js + test/script/basic/NASHORN-620.js.EXPECTED + test/script/basic/NASHORN-623.js + test/script/basic/NASHORN-623.js.EXPECTED + test/script/basic/NASHORN-627.js + test/script/basic/NASHORN-627.js.EXPECTED + test/script/basic/NASHORN-63.js + test/script/basic/NASHORN-631.js.EXPECTED + test/script/basic/NASHORN-637.js + test/script/basic/NASHORN-637.js.EXPECTED + test/script/basic/NASHORN-638.js + test/script/basic/NASHORN-638.js.EXPECTED + test/script/basic/NASHORN-639.js + test/script/basic/NASHORN-64.js + test/script/basic/NASHORN-642.js + test/script/basic/NASHORN-642.js.EXPECTED + test/script/basic/NASHORN-646.js + test/script/basic/NASHORN-653.js + test/script/basic/NASHORN-658.js + test/script/basic/NASHORN-659.js + test/script/basic/NASHORN-66.js + test/script/basic/NASHORN-66.js.EXPECTED + test/script/basic/NASHORN-664.js + test/script/basic/NASHORN-665.js + test/script/basic/NASHORN-67.js + test/script/basic/NASHORN-67.js.EXPECTED + test/script/basic/NASHORN-678.js + test/script/basic/NASHORN-68.js + test/script/basic/NASHORN-68.js.EXPECTED + test/script/basic/NASHORN-689.js + test/script/basic/NASHORN-689.js.EXPECTED + test/script/basic/NASHORN-69.js + test/script/basic/NASHORN-69.js.EXPECTED + test/script/basic/NASHORN-691.js + test/script/basic/NASHORN-691.js.EXPECTED + test/script/basic/NASHORN-694.js + test/script/basic/NASHORN-694.js.EXPECTED + test/script/basic/NASHORN-697.js + test/script/basic/NASHORN-703.js + test/script/basic/NASHORN-703.js.EXPECTED + test/script/basic/NASHORN-703a.js + test/script/basic/NASHORN-703a.js.EXPECTED + test/script/basic/NASHORN-705.js + test/script/basic/NASHORN-71.js + test/script/basic/NASHORN-71.js.EXPECTED + test/script/basic/NASHORN-710.js + test/script/basic/NASHORN-711.js + test/script/basic/NASHORN-711.js.EXPECTED + test/script/basic/NASHORN-72.js + test/script/basic/NASHORN-72.js.EXPECTED + test/script/basic/NASHORN-722.js + test/script/basic/NASHORN-73.js + test/script/basic/NASHORN-73.js.EXPECTED + test/script/basic/NASHORN-737.js + test/script/basic/NASHORN-737.js.EXPECTED + test/script/basic/NASHORN-74.js + test/script/basic/NASHORN-74.js.EXPECTED + test/script/basic/NASHORN-740.js + test/script/basic/NASHORN-740.js.EXPECTED + test/script/basic/NASHORN-75.js + test/script/basic/NASHORN-75.js.EXPECTED + test/script/basic/NASHORN-758.js + test/script/basic/NASHORN-759.js + test/script/basic/NASHORN-759.js.EXPECTED + test/script/basic/NASHORN-760.js + test/script/basic/NASHORN-768.js + test/script/basic/NASHORN-778.js + test/script/basic/NASHORN-78.js + test/script/basic/NASHORN-79.js + test/script/basic/NASHORN-79.js.EXPECTED + test/script/basic/NASHORN-792.js + test/script/basic/NASHORN-792.js.EXPECTED + test/script/basic/NASHORN-80.js + test/script/basic/NASHORN-80.js.EXPECTED + test/script/basic/NASHORN-81.js + test/script/basic/NASHORN-833.js + test/script/basic/NASHORN-833.js.EXPECTED + test/script/basic/NASHORN-85.js + test/script/basic/NASHORN-85.js.EXPECTED + test/script/basic/NASHORN-86.js + test/script/basic/NASHORN-87.js + test/script/basic/NASHORN-89.js + test/script/basic/NASHORN-90.js + test/script/basic/NASHORN-90.js.EXPECTED + test/script/basic/NASHORN-91.js + test/script/basic/NASHORN-91.js.EXPECTED + test/script/basic/NASHORN-92.js + test/script/basic/NASHORN-92.js.EXPECTED + test/script/basic/NASHORN-93.js + test/script/basic/NASHORN-95.js + test/script/basic/NASHORN-95.js.EXPECTED + test/script/basic/NASHORN-96.js + test/script/basic/NASHORN-96.js.EXPECTED + test/script/basic/NASHORN-97.js + test/script/basic/NASHORN-98.js + test/script/basic/NASHORN-98.js.EXPECTED + test/script/basic/NASHORN-99.js + test/script/basic/addition.js + test/script/basic/addition.js.EXPECTED + test/script/basic/allgettersetters.js + test/script/basic/andor.js + test/script/basic/andor.js.EXPECTED + test/script/basic/anonrecur.js + test/script/basic/anonrecur.js.EXPECTED + test/script/basic/applycall.js + test/script/basic/applycall.js.EXPECTED + test/script/basic/args.js + test/script/basic/args.js.EXPECTED + test/script/basic/arity.js + test/script/basic/arity.js.EXPECTED + test/script/basic/arrayprotoclass.js + test/script/basic/arrayprotoclass.js.EXPECTED + test/script/basic/arrays.js + test/script/basic/arrays.js.EXPECTED + test/script/basic/arrays2.js + test/script/basic/arrays2.js.EXPECTED + test/script/basic/arraysIntKey.js + test/script/basic/arraysIntKey.js.EXPECTED + test/script/basic/arrayset.js + test/script/basic/arrayset.js.EXPECTED + test/script/basic/arrayundefined.js + test/script/basic/arrayundefined.js.EXPECTED + test/script/basic/assign.js + test/script/basic/assign.js.EXPECTED + test/script/basic/bitwise_and.js + test/script/basic/bitwise_and.js.EXPECTED + test/script/basic/booleangetter.js + test/script/basic/booleangetter.js.EXPECTED + test/script/basic/builtin.js + test/script/basic/builtin.js.EXPECTED + test/script/basic/builtin_assign.js + test/script/basic/builtin_assign.js.EXPECTED + test/script/basic/builtinchain.js + test/script/basic/builtinchain.js.EXPECTED + test/script/basic/calllink.js + test/script/basic/calllink.js.EXPECTED + test/script/basic/closure.js + test/script/basic/closure.js.EXPECTED + test/script/basic/commandargs.js + test/script/basic/commandargs.js.EXPECTED + test/script/basic/compile-octane.js + test/script/basic/compile-octane.js.EXPECTED + test/script/basic/condassign.js + test/script/basic/condassign.js.EXPECTED + test/script/basic/construct.js + test/script/basic/construct.js.EXPECTED + test/script/basic/constructorname.js + test/script/basic/constructorname.js.EXPECTED + test/script/basic/date.js + test/script/basic/date.js.EXPECTED + test/script/basic/dateparse.js + test/script/basic/dateparse.js.EXPECTED + test/script/basic/decinc.js + test/script/basic/decinc.js.EXPECTED + test/script/basic/delete.js + test/script/basic/delete.js.EXPECTED + test/script/basic/delete2.js + test/script/basic/delete2.js.EXPECTED + test/script/basic/dotpropname.js + test/script/basic/dotpropname.js.EXPECTED + test/script/basic/doublecache.js + test/script/basic/doublecache.js.EXPECTED + test/script/basic/enumeration.js + test/script/basic/enumeration.js.EXPECTED + test/script/basic/errors.js + test/script/basic/errors.js.EXPECTED + test/script/basic/errorstack.js + test/script/basic/errorstack.js.EXPECTED + test/script/basic/eval.js + test/script/basic/eval.js.EXPECTED + test/script/basic/evalreturn.js + test/script/basic/evalreturn.js.EXPECTED + test/script/basic/exprclosure.js + test/script/basic/exprclosure.js.EXPECTED + test/script/basic/extensibility.js + test/script/basic/extensibility.js.EXPECTED + test/script/basic/fileline.js + test/script/basic/fileline.js.EXPECTED + test/script/basic/finally-catchalls.js + test/script/basic/finally-catchalls.js.EXPECTED + test/script/basic/finallyreturn.js + test/script/basic/finallyreturn.js.EXPECTED + test/script/basic/forin.js + test/script/basic/forin.js.EXPECTED + test/script/basic/forin2.js + test/script/basic/forin2.js.EXPECTED + test/script/basic/funcarray.js + test/script/basic/funcarray.js.EXPECTED + test/script/basic/funcbind.js + test/script/basic/funcbind.js.EXPECTED + test/script/basic/funcconstructor.js + test/script/basic/funcconstructor.js.EXPECTED + test/script/basic/getclassname.js + test/script/basic/getenv.js + test/script/basic/getenv.js.EXPECTED + test/script/basic/getter_callsite.js + test/script/basic/getter_callsite.js.EXPECTED + test/script/basic/gettercalls.js + test/script/basic/gettercalls.js.EXPECTED + test/script/basic/getterfunc.js + test/script/basic/getterfunc.js.EXPECTED + test/script/basic/gettersetter.js + test/script/basic/gettersetter.js.EXPECTED + test/script/basic/globalaccess.js + test/script/basic/globalaccess.js.EXPECTED + test/script/basic/globals.js + test/script/basic/globals.js.EXPECTED + test/script/basic/globalscope.js + test/script/basic/globalscope.js.EXPECTED + test/script/basic/hello.js + test/script/basic/hello.js.EXPECTED + test/script/basic/herestr_operator.js + test/script/basic/herestr_operator.js.EXPECTED + test/script/basic/illegaljavaname.js + test/script/basic/illegaljavaname.js.EXPECTED + test/script/basic/incheck.js + test/script/basic/incheck.js.EXPECTED + test/script/basic/indexedcall.js + test/script/basic/indexedcall.js.EXPECTED + test/script/basic/info.js + test/script/basic/info.js.EXPECTED + test/script/basic/inherited_nonwritable.js + test/script/basic/instanceof.js + test/script/basic/instanceof.js.EXPECTED + test/script/basic/instanceof2.js + test/script/basic/instanceof2.js.EXPECTED + test/script/basic/interfaces.js + test/script/basic/interfaces.js.EXPECTED + test/script/basic/iterator.js + test/script/basic/iterator.js.EXPECTED + test/script/basic/java.js + test/script/basic/java.js.EXPECTED + test/script/basic/javaarray.js + test/script/basic/javaarray.js.EXPECTED + test/script/basic/javaarrayconversion.js + test/script/basic/javaarrayconversion.js.EXPECTED + test/script/basic/javaexceptions.js + test/script/basic/javaexceptions.js.EXPECTED + test/script/basic/javaimporter.js + test/script/basic/javaimporter.js.EXPECTED + test/script/basic/javainnerclasses.js + test/script/basic/javainnerclasses.js.EXPECTED + test/script/basic/javasigcall.js + test/script/basic/javasigcall.js.EXPECTED + test/script/basic/jquery.js + test/script/basic/jquery.js.EXPECTED + test/script/basic/jsadapter.js + test/script/basic/jsadapter.js.EXPECTED + test/script/basic/jsadapterlink.js + test/script/basic/jsadapterlink.js.EXPECTED + test/script/basic/json.js + test/script/basic/json.js.EXPECTED + test/script/basic/list.js + test/script/basic/list.js.EXPECTED + test/script/basic/literal.js + test/script/basic/literal.js.EXPECTED + test/script/basic/load.js + test/script/basic/load.js.EXPECTED + test/script/basic/loadedfile.js + test/script/basic/localundef.js + test/script/basic/localundef.js.EXPECTED + test/script/basic/map.js + test/script/basic/map.js.EXPECTED + test/script/basic/math.js + test/script/basic/math.js.EXPECTED + test/script/basic/minuszero.js + test/script/basic/minuszero.js.EXPECTED + test/script/basic/module.js + test/script/basic/moduleload.js + test/script/basic/moduleload.js.EXPECTED + test/script/basic/nashorn2.js + test/script/basic/nashorn2.js.EXPECTED + test/script/basic/natives.js + test/script/basic/natives.js.EXPECTED + test/script/basic/new.js + test/script/basic/new.js.EXPECTED + test/script/basic/newexpr.js + test/script/basic/newexpr.js.EXPECTED + test/script/basic/newnew.js + test/script/basic/newnew.js.EXPECTED + test/script/basic/nonconstructors.js + test/script/basic/nonconstructors.js.EXPECTED + test/script/basic/nosuchmethod.js + test/script/basic/nosuchmethod.js.EXPECTED + test/script/basic/nosuchproperty.js + test/script/basic/nosuchproperty.js.EXPECTED + test/script/basic/number.js + test/script/basic/number.js.EXPECTED + test/script/basic/numberstring.js + test/script/basic/numberstring.js.EXPECTED + test/script/basic/objectprops.js + test/script/basic/objectprops.js.EXPECTED + test/script/basic/objects.js + test/script/basic/objects.js.EXPECTED + test/script/basic/options.js + test/script/basic/options.js.EXPECTED + test/script/basic/propchange.js + test/script/basic/propchange.js.EXPECTED + test/script/basic/propertycheck.js + test/script/basic/propertycheck.js.EXPECTED + test/script/basic/proto.js.EXPECTED + test/script/basic/prototype.js + test/script/basic/prototype.js.EXPECTED + test/script/basic/pushpull.js + test/script/basic/pushpull.js.EXPECTED + test/script/basic/regex.js + test/script/basic/regex.js.EXPECTED + test/script/basic/regexp_flags.js + test/script/basic/run-octane.js + test/script/basic/runsunspider.js + test/script/basic/runsunspider.js.EXPECTED + test/script/basic/samfunc.js + test/script/basic/samfunc.js.EXPECTED + test/script/basic/scripting.js + test/script/basic/scripting.js.EXPECTED + test/script/basic/sealfreeze.js + test/script/basic/sealfreeze.js.EXPECTED + test/script/basic/setlength.js + test/script/basic/setlength.js.EXPECTED + test/script/basic/stdin.js + test/script/basic/stdin.js.EXPECTED + test/script/basic/strings.js + test/script/basic/strings.js.EXPECTED + test/script/basic/throws.js + test/script/basic/throws.js.EXPECTED + test/script/basic/tosource.js + test/script/basic/tosource.js.EXPECTED + test/script/basic/tostring.js + test/script/basic/tostring.js.EXPECTED + test/script/basic/try.js + test/script/basic/try.js.EXPECTED + test/script/basic/trybreakcont.js + test/script/basic/trybreakcont.js.EXPECTED + test/script/basic/trycatch.js + test/script/basic/trycatch.js.EXPECTED + test/script/basic/trycatchfor.js + test/script/basic/trycatchfor.js.EXPECTED + test/script/basic/tryfinallyreturn.js + test/script/basic/tryfinallyreturn.js.EXPECTED + test/script/basic/tryforbreak.js + test/script/basic/tryforbreak.js.EXPECTED + test/script/basic/typechange.js + test/script/basic/typechange.js.EXPECTED + test/script/basic/typeof.js + test/script/basic/typeof.js.EXPECTED + test/script/basic/typeof2.js + test/script/basic/typeof2.js.EXPECTED + test/script/basic/undefined.js + test/script/basic/undefined.js.EXPECTED + test/script/basic/underscore.js + test/script/basic/underscore.js.EXPECTED + test/script/basic/varargs.js + test/script/basic/varargs.js.EXPECTED + test/script/basic/void.js + test/script/basic/void.js.EXPECTED + test/script/basic/with.js + test/script/basic/with.js.EXPECTED + test/script/basic/withprimitive.js + test/script/basic/withprimitive.js.EXPECTED + test/script/basic/writable_relink.js + test/script/basic/writable_relink.js.EXPECTED + test/script/basic/xmlStrings.js.EXPECTED + test/script/basic/xorassign.js + test/script/basic/xorassign.js.EXPECTED + test/script/basic/yui.js + test/script/basic/yui.js.EXPECTED + test/script/error/NASHORN-154/README + test/script/error/NASHORN-154/function_mult_params_in_strict.js + test/script/error/NASHORN-154/function_mult_params_in_strict.js.EXPECTED + test/script/error/NASHORN-154/improper_return_break_continue.js + test/script/error/NASHORN-154/improper_return_break_continue.js.EXPECTED + test/script/error/NASHORN-154/invalid_lvalue.js + test/script/error/NASHORN-154/invalid_lvalue.js.EXPECTED + test/script/error/NASHORN-154/literal_data_and_accessor.js + test/script/error/NASHORN-154/literal_data_and_accessor.js.EXPECTED + test/script/error/NASHORN-154/literal_mult_getters.js + test/script/error/NASHORN-154/literal_mult_getters.js.EXPECTED + test/script/error/NASHORN-154/literal_mult_prop_in_strict.js + test/script/error/NASHORN-154/literal_mult_prop_in_strict.js.EXPECTED + test/script/error/NASHORN-154/with_in_strict.js + test/script/error/NASHORN-154/with_in_strict.js.EXPECTED + test/script/error/NASHORN-214.js + test/script/error/NASHORN-214.js.EXPECTED + test/script/error/NASHORN-35.js + test/script/error/NASHORN-35.js.EXPECTED + test/script/error/NASHORN-39.js + test/script/error/NASHORN-39.js.EXPECTED + test/script/error/NASHORN-568.js + test/script/error/NASHORN-568.js.EXPECTED + test/script/error/NASHORN-57.js + test/script/error/NASHORN-57.js.EXPECTED + test/script/error/NASHORN-668.js + test/script/error/NASHORN-668.js.EXPECTED + test/script/error/quotemissing.js + test/script/error/quotemissing.js.EXPECTED + test/script/error/strictmode.js + test/script/error/strictmode.js.EXPECTED + test/script/representations/NASHORN-592a.js + test/script/sandbox/NASHORN-525.js + test/script/sandbox/README + test/script/sandbox/classloader.js + test/script/sandbox/classloader.js.EXPECTED + test/script/sandbox/doprivileged.js + test/script/sandbox/doprivileged.js.EXPECTED + test/script/sandbox/exit.js + test/script/sandbox/exit.js.EXPECTED + test/script/sandbox/file.js + test/script/sandbox/file.js.EXPECTED + test/script/sandbox/javaextend.js + test/script/sandbox/javaextend.js.EXPECTED + test/script/sandbox/loadLibrary.js + test/script/sandbox/net.js + test/script/sandbox/net.js.EXPECTED + test/script/sandbox/property.js + test/script/sandbox/property.js.EXPECTED + test/script/sandbox/reflection.js + test/script/sandbox/reflection.js.EXPECTED + test/script/sandbox/runnable.js + test/script/sandbox/runnable.js.EXPECTED + test/script/sandbox/unsafe.js + test/script/sandbox/unsafe.js.EXPECTED + test/script/test262.js + test/script/test262_single.js + test/src/UnnamedPackageTestCallback.java + test/src/jdk/nashorn/api/scripting/MultipleEngineTest.java + test/src/jdk/nashorn/api/scripting/ScriptEngineTest.java + test/src/jdk/nashorn/api/scripting/Window.java + test/src/jdk/nashorn/api/scripting/WindowEventHandler.java + test/src/jdk/nashorn/internal/access/BooleanAccessTest.java + test/src/jdk/nashorn/internal/access/MethodAccessTest.java + test/src/jdk/nashorn/internal/access/NumberAccessTest.java + test/src/jdk/nashorn/internal/access/NumberBoxingTest.java + test/src/jdk/nashorn/internal/access/ObjectAccessTest.java + test/src/jdk/nashorn/internal/access/Person.java + test/src/jdk/nashorn/internal/access/SharedObject.java + test/src/jdk/nashorn/internal/access/StringAccessTest.java + test/src/jdk/nashorn/internal/codegen/CompilerTest.java + test/src/jdk/nashorn/internal/parser/ParserTest.java + test/src/jdk/nashorn/internal/performance/AuroraWrapper.java + test/src/jdk/nashorn/internal/performance/OctaneTest.java + test/src/jdk/nashorn/internal/performance/PerformanceWrapper.java + test/src/jdk/nashorn/internal/performance/SplayTest.java + test/src/jdk/nashorn/internal/runtime/ContextTest.java + test/src/jdk/nashorn/internal/runtime/JSTypeTest.java + test/src/jdk/nashorn/internal/runtime/Nashorn401TestSubject.java + test/src/jdk/nashorn/internal/test/framework/AbstractScriptRunnable.java + test/src/jdk/nashorn/internal/test/framework/JSJUnitReportReporter.java + test/src/jdk/nashorn/internal/test/framework/OrphanTestFinder.java + test/src/jdk/nashorn/internal/test/framework/ParallelTestRunner.java + test/src/jdk/nashorn/internal/test/framework/ScriptEvaluator.java + test/src/jdk/nashorn/internal/test/framework/ScriptRunnable.java + test/src/jdk/nashorn/internal/test/framework/ScriptTest.java + test/src/jdk/nashorn/internal/test/framework/SeparateContextEvaluator.java + test/src/jdk/nashorn/internal/test/framework/SharedContextEvaluator.java + test/src/jdk/nashorn/internal/test/framework/TestConfig.java + test/src/jdk/nashorn/internal/test/framework/TestFinder.java + test/src/jdk/nashorn/internal/test/framework/TestHelper.java + test/src/jdk/nashorn/internal/test/framework/TestReorderInterceptor.java + test/src/jdk/nashorn/internal/test/models/ConstructorWithArgument.java + test/src/jdk/nashorn/internal/test/models/FinalClass.java + test/src/jdk/nashorn/internal/test/models/NoAccessibleConstructorClass.java + test/src/jdk/nashorn/internal/test/models/NonPublicClass.java + test/src/jdk/nashorn/internal/test/models/OuterClass.java + test/src/jdk/nashorn/internal/test/models/OverloadedSam.java + test/src/jdk/nashorn/internal/test/models/OverrideObject.java Changeset: b4b05457b8b2 Author: jlaskey Date: 2012-12-22 08:49 -0400 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/b4b05457b8b2 8005440: Improve .hgignore filtering for Nashorn repo Reviewed-by: sundar Contributed-by: james.laskey at oracle.com ! .hgignore Changeset: 3a7e1580bc0a Author: jlaskey Date: 2013-01-04 09:58 -0400 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/3a7e1580bc0a 8005666: Add webrev to .hgignore Reviewed-by: sundar Contributed-by: james.laskey at oracle.com ! .hgignore Changeset: c6e194450af7 Author: jlaskey Date: 2013-01-04 09:58 -0400 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/c6e194450af7 8005665: JavaDoc should only display public interfaces Reviewed-by: sundar Contributed-by: james.laskey at oracle.com ! make/build.xml Changeset: 5a1b0714df0e Author: jlaskey Date: 2013-01-04 09:58 -0400 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/5a1b0714df0e 8005663: Update copyright year to 2013 Reviewed-by: sundar Contributed-by: james.laskey at oracle.com ! bin/checkintest.sh ! bin/fixorphantests.sh ! bin/fixwhitespace.sh ! bin/jjs ! bin/jjs.bat ! bin/jjssecure ! bin/jjssecure.bat ! bin/nashorn ! bin/nashorn.bat ! bin/rm-non-tracked.sh ! bin/verbose_octane.bat ! bin/verbose_octane.sh ! buildtools/nasgen/build.xml ! buildtools/nasgen/nasgen.iml ! buildtools/nasgen/project.properties ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/ClassGenerator.java ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/ConstructorGenerator.java ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/Main.java ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/MemberInfo.java ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/MethodGenerator.java ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/NullVisitor.java ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/PrototypeGenerator.java ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/ScriptClassInfo.java ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/ScriptClassInfoCollector.java ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/ScriptClassInstrumentor.java ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/StringConstants.java ! docs/genshelldoc.js ! make/Makefile ! make/build-benchmark.xml ! make/build-nasgen.xml ! make/build.xml ! make/nbproject/ide-file-targets.xml ! make/nbproject/ide-targets.xml ! make/nbproject/jdk.xml ! make/nbproject/nbjdk.properties ! make/nbproject/nbjdk.xml ! make/nbproject/project.xml ! make/project.properties ! samples/counters.js ! samples/letter.js ! samples/parser.js ! samples/shell.js ! samples/test.js ! samples/uniq.js ! src/META-INF/services/javax.script.ScriptEngineFactory ! src/jdk/nashorn/api/scripting/NashornException.java ! src/jdk/nashorn/api/scripting/NashornScriptEngine.java ! src/jdk/nashorn/api/scripting/NashornScriptEngineFactory.java ! src/jdk/nashorn/api/scripting/ScriptObjectMirror.java ! src/jdk/nashorn/api/scripting/package-info.java ! src/jdk/nashorn/api/scripting/resources/engine.js ! src/jdk/nashorn/internal/codegen/AccessSpecializer.java ! src/jdk/nashorn/internal/codegen/BranchOptimizer.java ! src/jdk/nashorn/internal/codegen/ClassEmitter.java ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/codegen/CompileUnit.java ! src/jdk/nashorn/internal/codegen/Compiler.java ! src/jdk/nashorn/internal/codegen/CompilerConstants.java ! src/jdk/nashorn/internal/codegen/ConstantData.java ! src/jdk/nashorn/internal/codegen/Emitter.java ! src/jdk/nashorn/internal/codegen/Frame.java ! src/jdk/nashorn/internal/codegen/FunctionSignature.java ! src/jdk/nashorn/internal/codegen/Lower.java ! src/jdk/nashorn/internal/codegen/MethodEmitter.java ! src/jdk/nashorn/internal/codegen/Namespace.java ! src/jdk/nashorn/internal/codegen/RuntimeCallSite.java ! src/jdk/nashorn/internal/codegen/SharedScopeCall.java ! src/jdk/nashorn/internal/codegen/Splitter.java ! src/jdk/nashorn/internal/codegen/Transform.java ! src/jdk/nashorn/internal/codegen/WeighNodes.java ! src/jdk/nashorn/internal/codegen/objects/FieldObjectCreator.java ! src/jdk/nashorn/internal/codegen/objects/FunctionObjectCreator.java ! src/jdk/nashorn/internal/codegen/objects/MapCreator.java ! src/jdk/nashorn/internal/codegen/objects/ObjectClassGenerator.java ! src/jdk/nashorn/internal/codegen/objects/ObjectCreator.java ! src/jdk/nashorn/internal/codegen/objects/ObjectMapCreator.java ! src/jdk/nashorn/internal/codegen/types/ArrayType.java ! src/jdk/nashorn/internal/codegen/types/BitwiseType.java ! src/jdk/nashorn/internal/codegen/types/BooleanType.java ! src/jdk/nashorn/internal/codegen/types/BytecodeArrayOps.java ! src/jdk/nashorn/internal/codegen/types/BytecodeBitwiseOps.java ! src/jdk/nashorn/internal/codegen/types/BytecodeNumericOps.java ! src/jdk/nashorn/internal/codegen/types/BytecodeOps.java ! src/jdk/nashorn/internal/codegen/types/IntType.java ! src/jdk/nashorn/internal/codegen/types/LongType.java ! src/jdk/nashorn/internal/codegen/types/NumberType.java ! src/jdk/nashorn/internal/codegen/types/NumericType.java ! src/jdk/nashorn/internal/codegen/types/ObjectType.java ! src/jdk/nashorn/internal/codegen/types/Type.java ! src/jdk/nashorn/internal/ir/AccessNode.java ! src/jdk/nashorn/internal/ir/Assignment.java ! src/jdk/nashorn/internal/ir/BaseNode.java ! src/jdk/nashorn/internal/ir/BinaryNode.java ! src/jdk/nashorn/internal/ir/Block.java ! src/jdk/nashorn/internal/ir/BreakNode.java ! src/jdk/nashorn/internal/ir/BreakableNode.java ! src/jdk/nashorn/internal/ir/CallNode.java ! src/jdk/nashorn/internal/ir/CaseNode.java ! src/jdk/nashorn/internal/ir/CatchNode.java ! src/jdk/nashorn/internal/ir/ContinueNode.java ! src/jdk/nashorn/internal/ir/DoWhileNode.java ! src/jdk/nashorn/internal/ir/EmptyNode.java ! src/jdk/nashorn/internal/ir/ExecuteNode.java ! src/jdk/nashorn/internal/ir/ForNode.java ! src/jdk/nashorn/internal/ir/FunctionCall.java ! src/jdk/nashorn/internal/ir/FunctionNode.java ! src/jdk/nashorn/internal/ir/IdentNode.java ! src/jdk/nashorn/internal/ir/IfNode.java ! src/jdk/nashorn/internal/ir/IndexNode.java ! src/jdk/nashorn/internal/ir/LabelNode.java ! src/jdk/nashorn/internal/ir/LabeledNode.java ! src/jdk/nashorn/internal/ir/LineNumberNode.java ! src/jdk/nashorn/internal/ir/LiteralNode.java ! src/jdk/nashorn/internal/ir/Location.java ! src/jdk/nashorn/internal/ir/Node.java ! src/jdk/nashorn/internal/ir/ObjectNode.java ! src/jdk/nashorn/internal/ir/PropertyKey.java ! src/jdk/nashorn/internal/ir/PropertyNode.java ! src/jdk/nashorn/internal/ir/ReferenceNode.java ! src/jdk/nashorn/internal/ir/ReturnNode.java ! src/jdk/nashorn/internal/ir/RuntimeNode.java ! src/jdk/nashorn/internal/ir/SplitNode.java ! src/jdk/nashorn/internal/ir/SwitchNode.java ! src/jdk/nashorn/internal/ir/Symbol.java ! src/jdk/nashorn/internal/ir/TernaryNode.java ! src/jdk/nashorn/internal/ir/ThrowNode.java ! src/jdk/nashorn/internal/ir/TryNode.java ! src/jdk/nashorn/internal/ir/TypeOverride.java ! src/jdk/nashorn/internal/ir/UnaryNode.java ! src/jdk/nashorn/internal/ir/VarNode.java ! src/jdk/nashorn/internal/ir/WhileNode.java ! src/jdk/nashorn/internal/ir/WithNode.java ! src/jdk/nashorn/internal/ir/annotations/ChildNode.java ! src/jdk/nashorn/internal/ir/annotations/Ignore.java ! src/jdk/nashorn/internal/ir/annotations/ParentNode.java ! src/jdk/nashorn/internal/ir/annotations/Reference.java ! src/jdk/nashorn/internal/ir/debug/ASTWriter.java ! src/jdk/nashorn/internal/ir/debug/JSONWriter.java ! src/jdk/nashorn/internal/ir/debug/PrintVisitor.java ! src/jdk/nashorn/internal/ir/visitor/NodeOperatorVisitor.java ! src/jdk/nashorn/internal/ir/visitor/NodeVisitor.java ! src/jdk/nashorn/internal/objects/AccessorPropertyDescriptor.java ! src/jdk/nashorn/internal/objects/ArrayBufferView.java ! src/jdk/nashorn/internal/objects/DataPropertyDescriptor.java ! src/jdk/nashorn/internal/objects/DateParser.java ! src/jdk/nashorn/internal/objects/GenericPropertyDescriptor.java ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeArguments.java ! src/jdk/nashorn/internal/objects/NativeArray.java ! src/jdk/nashorn/internal/objects/NativeArrayBuffer.java ! src/jdk/nashorn/internal/objects/NativeBoolean.java ! src/jdk/nashorn/internal/objects/NativeDate.java ! src/jdk/nashorn/internal/objects/NativeDebug.java ! src/jdk/nashorn/internal/objects/NativeError.java ! src/jdk/nashorn/internal/objects/NativeEvalError.java ! src/jdk/nashorn/internal/objects/NativeFloat32Array.java ! src/jdk/nashorn/internal/objects/NativeFloat64Array.java ! src/jdk/nashorn/internal/objects/NativeFunction.java ! src/jdk/nashorn/internal/objects/NativeInt16Array.java ! src/jdk/nashorn/internal/objects/NativeInt32Array.java ! src/jdk/nashorn/internal/objects/NativeInt8Array.java ! src/jdk/nashorn/internal/objects/NativeJSAdapter.java ! src/jdk/nashorn/internal/objects/NativeJSON.java ! src/jdk/nashorn/internal/objects/NativeJava.java ! src/jdk/nashorn/internal/objects/NativeJavaImporter.java ! src/jdk/nashorn/internal/objects/NativeMath.java ! src/jdk/nashorn/internal/objects/NativeNumber.java ! src/jdk/nashorn/internal/objects/NativeObject.java ! src/jdk/nashorn/internal/objects/NativeRangeError.java ! src/jdk/nashorn/internal/objects/NativeReferenceError.java ! src/jdk/nashorn/internal/objects/NativeRegExp.java ! src/jdk/nashorn/internal/objects/NativeRegExpExecResult.java ! src/jdk/nashorn/internal/objects/NativeStrictArguments.java ! src/jdk/nashorn/internal/objects/NativeString.java ! src/jdk/nashorn/internal/objects/NativeSyntaxError.java ! src/jdk/nashorn/internal/objects/NativeTypeError.java ! src/jdk/nashorn/internal/objects/NativeURIError.java ! src/jdk/nashorn/internal/objects/NativeUint16Array.java ! src/jdk/nashorn/internal/objects/NativeUint32Array.java ! src/jdk/nashorn/internal/objects/NativeUint8Array.java ! src/jdk/nashorn/internal/objects/NativeUint8ClampedArray.java ! src/jdk/nashorn/internal/objects/PrototypeObject.java ! src/jdk/nashorn/internal/objects/ScriptFunctionImpl.java ! src/jdk/nashorn/internal/objects/annotations/Attribute.java ! src/jdk/nashorn/internal/objects/annotations/Constructor.java ! src/jdk/nashorn/internal/objects/annotations/Function.java ! src/jdk/nashorn/internal/objects/annotations/Getter.java ! src/jdk/nashorn/internal/objects/annotations/Property.java ! src/jdk/nashorn/internal/objects/annotations/ScriptClass.java ! src/jdk/nashorn/internal/objects/annotations/Setter.java ! src/jdk/nashorn/internal/objects/annotations/SpecializedConstructor.java ! src/jdk/nashorn/internal/objects/annotations/SpecializedFunction.java ! src/jdk/nashorn/internal/objects/annotations/Where.java ! src/jdk/nashorn/internal/objects/package-info.java ! src/jdk/nashorn/internal/parser/AbstractParser.java ! src/jdk/nashorn/internal/parser/JSONParser.java ! src/jdk/nashorn/internal/parser/Lexer.java ! src/jdk/nashorn/internal/parser/Parser.java ! src/jdk/nashorn/internal/parser/RegExp.java ! src/jdk/nashorn/internal/parser/RegExpScanner.java ! src/jdk/nashorn/internal/parser/Scanner.java ! src/jdk/nashorn/internal/parser/Token.java ! src/jdk/nashorn/internal/parser/TokenKind.java ! src/jdk/nashorn/internal/parser/TokenLookup.java ! src/jdk/nashorn/internal/parser/TokenStream.java ! src/jdk/nashorn/internal/parser/TokenType.java ! src/jdk/nashorn/internal/runtime/AccessorProperty.java ! src/jdk/nashorn/internal/runtime/BitVector.java ! src/jdk/nashorn/internal/runtime/CodeInstaller.java ! src/jdk/nashorn/internal/runtime/ConsString.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/Debug.java ! src/jdk/nashorn/internal/runtime/DebugLogger.java ! src/jdk/nashorn/internal/runtime/DefaultPropertyAccess.java ! src/jdk/nashorn/internal/runtime/ECMAErrors.java ! src/jdk/nashorn/internal/runtime/ECMAException.java ! src/jdk/nashorn/internal/runtime/ErrorManager.java ! src/jdk/nashorn/internal/runtime/FindProperty.java ! src/jdk/nashorn/internal/runtime/FunctionScope.java ! src/jdk/nashorn/internal/runtime/GlobalFunctions.java ! src/jdk/nashorn/internal/runtime/GlobalObject.java ! src/jdk/nashorn/internal/runtime/JSErrorType.java ! src/jdk/nashorn/internal/runtime/JSType.java ! src/jdk/nashorn/internal/runtime/Logging.java ! src/jdk/nashorn/internal/runtime/NashornLoader.java ! src/jdk/nashorn/internal/runtime/NativeJavaPackage.java ! src/jdk/nashorn/internal/runtime/NumberToString.java ! src/jdk/nashorn/internal/runtime/ParserException.java ! src/jdk/nashorn/internal/runtime/Property.java ! src/jdk/nashorn/internal/runtime/PropertyAccess.java ! src/jdk/nashorn/internal/runtime/PropertyDescriptor.java ! src/jdk/nashorn/internal/runtime/PropertyHashMap.java ! src/jdk/nashorn/internal/runtime/PropertyListener.java ! src/jdk/nashorn/internal/runtime/PropertyListenerManager.java ! src/jdk/nashorn/internal/runtime/PropertyMap.java ! src/jdk/nashorn/internal/runtime/QuotedStringTokenizer.java ! src/jdk/nashorn/internal/runtime/RegExpMatch.java ! src/jdk/nashorn/internal/runtime/Scope.java ! src/jdk/nashorn/internal/runtime/ScriptFunction.java ! src/jdk/nashorn/internal/runtime/ScriptLoader.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/ScriptRuntime.java ! src/jdk/nashorn/internal/runtime/ScriptingFunctions.java ! src/jdk/nashorn/internal/runtime/Source.java ! src/jdk/nashorn/internal/runtime/SpillProperty.java ! src/jdk/nashorn/internal/runtime/StructureLoader.java ! src/jdk/nashorn/internal/runtime/URIUtils.java ! src/jdk/nashorn/internal/runtime/Undefined.java ! src/jdk/nashorn/internal/runtime/UserAccessorProperty.java ! src/jdk/nashorn/internal/runtime/Version.java ! src/jdk/nashorn/internal/runtime/WithObject.java ! src/jdk/nashorn/internal/runtime/arrays/ArrayData.java ! src/jdk/nashorn/internal/runtime/arrays/ArrayFilter.java ! src/jdk/nashorn/internal/runtime/arrays/ArrayIndex.java ! src/jdk/nashorn/internal/runtime/arrays/ArrayIterator.java ! src/jdk/nashorn/internal/runtime/arrays/ArrayLikeIterator.java ! src/jdk/nashorn/internal/runtime/arrays/DeletedArrayFilter.java ! src/jdk/nashorn/internal/runtime/arrays/DeletedRangeArrayFilter.java ! src/jdk/nashorn/internal/runtime/arrays/EmptyArrayLikeIterator.java ! src/jdk/nashorn/internal/runtime/arrays/FrozenArrayFilter.java ! src/jdk/nashorn/internal/runtime/arrays/IntArrayData.java ! src/jdk/nashorn/internal/runtime/arrays/InvalidArrayIndexException.java ! src/jdk/nashorn/internal/runtime/arrays/IteratorAction.java ! src/jdk/nashorn/internal/runtime/arrays/LongArrayData.java ! src/jdk/nashorn/internal/runtime/arrays/MapIterator.java ! src/jdk/nashorn/internal/runtime/arrays/NoTypeArrayData.java ! src/jdk/nashorn/internal/runtime/arrays/NumberArrayData.java ! src/jdk/nashorn/internal/runtime/arrays/ObjectArrayData.java ! src/jdk/nashorn/internal/runtime/arrays/ReverseArrayIterator.java ! src/jdk/nashorn/internal/runtime/arrays/ReverseMapIterator.java ! src/jdk/nashorn/internal/runtime/arrays/SealedArrayFilter.java ! src/jdk/nashorn/internal/runtime/arrays/SparseArrayData.java ! src/jdk/nashorn/internal/runtime/arrays/UndefinedArrayFilter.java ! src/jdk/nashorn/internal/runtime/linker/Bootstrap.java ! src/jdk/nashorn/internal/runtime/linker/InvokeByName.java ! src/jdk/nashorn/internal/runtime/linker/JSObjectLinker.java ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterFactory.java ! src/jdk/nashorn/internal/runtime/linker/JavaArgumentConverters.java ! src/jdk/nashorn/internal/runtime/linker/LinkerCallSite.java ! src/jdk/nashorn/internal/runtime/linker/Lookup.java ! src/jdk/nashorn/internal/runtime/linker/Mangler.java ! src/jdk/nashorn/internal/runtime/linker/MethodHandleFactory.java ! src/jdk/nashorn/internal/runtime/linker/MethodHandleFunctionality.java ! src/jdk/nashorn/internal/runtime/linker/NashornBottomLinker.java ! src/jdk/nashorn/internal/runtime/linker/NashornCallSiteDescriptor.java ! src/jdk/nashorn/internal/runtime/linker/NashornGuardedInvocation.java ! src/jdk/nashorn/internal/runtime/linker/NashornGuards.java ! src/jdk/nashorn/internal/runtime/linker/NashornLinker.java ! src/jdk/nashorn/internal/runtime/linker/NashornPrimitiveLinker.java ! src/jdk/nashorn/internal/runtime/linker/PrimitiveLookup.java ! src/jdk/nashorn/internal/runtime/options/KeyValueOption.java ! src/jdk/nashorn/internal/runtime/options/Option.java ! src/jdk/nashorn/internal/runtime/options/OptionTemplate.java ! src/jdk/nashorn/internal/runtime/options/Options.java ! src/jdk/nashorn/internal/runtime/options/ValueOption.java ! src/jdk/nashorn/internal/runtime/resources/Messages.properties ! src/jdk/nashorn/internal/runtime/resources/Options.properties ! src/jdk/nashorn/internal/runtime/resources/mozilla_compat.js ! src/jdk/nashorn/internal/runtime/resources/parser.js ! src/jdk/nashorn/internal/runtime/resources/version.properties-template ! src/jdk/nashorn/internal/scripts/JO$.java ! src/jdk/nashorn/internal/scripts/JS$.java ! src/jdk/nashorn/tools/Shell.java ! src/jdk/nashorn/tools/resources/Shell.properties ! src/jdk/nashorn/tools/resources/shell.js ! src/netscape/javascript/JSObject.java ! src/overview.html ! test/examples/dual-fields-micro.js ! test/examples/innerbench.js ! test/examples/typechain.js ! test/lib/benchmark.js ! test/opt/add.js ! test/opt/add_constant.js ! test/opt/add_reuse_callsite.js ! test/opt/add_revert2.js ! test/opt/cascade_specialize.js ! test/script/assert.js ! test/script/basic/NASHORN-100.js ! test/script/basic/NASHORN-101.js ! test/script/basic/NASHORN-102.js ! test/script/basic/NASHORN-103.js ! test/script/basic/NASHORN-104.js ! test/script/basic/NASHORN-105.js ! test/script/basic/NASHORN-106.js ! test/script/basic/NASHORN-107.js ! test/script/basic/NASHORN-108.js ! test/script/basic/NASHORN-109.js ! test/script/basic/NASHORN-11.js ! test/script/basic/NASHORN-111.js ! test/script/basic/NASHORN-113.js ! test/script/basic/NASHORN-114.js ! test/script/basic/NASHORN-115.js ! test/script/basic/NASHORN-117.js ! test/script/basic/NASHORN-118.js ! test/script/basic/NASHORN-119.js ! test/script/basic/NASHORN-12.js ! test/script/basic/NASHORN-120.js ! test/script/basic/NASHORN-122.js ! test/script/basic/NASHORN-126.js ! test/script/basic/NASHORN-127.js ! test/script/basic/NASHORN-130.js ! test/script/basic/NASHORN-132.js ! test/script/basic/NASHORN-133.js ! test/script/basic/NASHORN-135.js ! test/script/basic/NASHORN-136.js ! test/script/basic/NASHORN-14.js ! test/script/basic/NASHORN-148.js ! test/script/basic/NASHORN-15.js ! test/script/basic/NASHORN-153.js ! test/script/basic/NASHORN-156.js ! test/script/basic/NASHORN-157.js ! test/script/basic/NASHORN-163.js ! test/script/basic/NASHORN-164.js ! test/script/basic/NASHORN-165.js ! test/script/basic/NASHORN-166.js ! test/script/basic/NASHORN-168.js ! test/script/basic/NASHORN-169.js ! test/script/basic/NASHORN-172.js ! test/script/basic/NASHORN-173.js ! test/script/basic/NASHORN-174.js ! test/script/basic/NASHORN-175.js ! test/script/basic/NASHORN-176.js ! test/script/basic/NASHORN-177.js ! test/script/basic/NASHORN-178.js ! test/script/basic/NASHORN-179.js ! test/script/basic/NASHORN-18.js ! test/script/basic/NASHORN-181.js ! test/script/basic/NASHORN-182.js ! test/script/basic/NASHORN-183.js ! test/script/basic/NASHORN-184.js ! test/script/basic/NASHORN-185.js ! test/script/basic/NASHORN-187.js ! test/script/basic/NASHORN-188.js ! test/script/basic/NASHORN-19.js ! test/script/basic/NASHORN-190.js ! test/script/basic/NASHORN-192.js ! test/script/basic/NASHORN-194.js ! test/script/basic/NASHORN-196.js ! test/script/basic/NASHORN-198.js ! test/script/basic/NASHORN-20.js ! test/script/basic/NASHORN-201.js ! test/script/basic/NASHORN-202.js ! test/script/basic/NASHORN-203.js ! test/script/basic/NASHORN-204.js ! test/script/basic/NASHORN-205.js ! test/script/basic/NASHORN-206.js ! test/script/basic/NASHORN-207.js ! test/script/basic/NASHORN-207_2.js ! test/script/basic/NASHORN-208.js ! test/script/basic/NASHORN-209.js ! test/script/basic/NASHORN-21.js ! test/script/basic/NASHORN-211.js ! test/script/basic/NASHORN-212.js ! test/script/basic/NASHORN-213.js ! test/script/basic/NASHORN-215.js ! test/script/basic/NASHORN-216.js ! test/script/basic/NASHORN-217.js ! test/script/basic/NASHORN-219.js ! test/script/basic/NASHORN-22.js ! test/script/basic/NASHORN-221.js ! test/script/basic/NASHORN-222.js ! test/script/basic/NASHORN-223.js ! test/script/basic/NASHORN-225.js ! test/script/basic/NASHORN-226.js ! test/script/basic/NASHORN-227.js ! test/script/basic/NASHORN-228.js ! test/script/basic/NASHORN-229.js ! test/script/basic/NASHORN-229_subtest.js ! test/script/basic/NASHORN-23.js ! test/script/basic/NASHORN-232.js ! test/script/basic/NASHORN-234.js ! test/script/basic/NASHORN-235.js ! test/script/basic/NASHORN-236.js ! test/script/basic/NASHORN-237.js ! test/script/basic/NASHORN-239.js ! test/script/basic/NASHORN-24.js ! test/script/basic/NASHORN-241.js ! test/script/basic/NASHORN-242.js ! test/script/basic/NASHORN-245.js ! test/script/basic/NASHORN-247.js ! test/script/basic/NASHORN-25.js ! test/script/basic/NASHORN-251.js ! test/script/basic/NASHORN-252.js ! test/script/basic/NASHORN-253.js ! test/script/basic/NASHORN-256.js ! test/script/basic/NASHORN-258.js ! test/script/basic/NASHORN-26.js ! test/script/basic/NASHORN-260.js ! test/script/basic/NASHORN-261.js ! test/script/basic/NASHORN-262.js ! test/script/basic/NASHORN-263.js ! test/script/basic/NASHORN-264.js ! test/script/basic/NASHORN-265.js ! test/script/basic/NASHORN-266.js ! test/script/basic/NASHORN-269.js ! test/script/basic/NASHORN-27.js ! test/script/basic/NASHORN-270.js ! test/script/basic/NASHORN-271.js ! test/script/basic/NASHORN-275.js ! test/script/basic/NASHORN-276.js ! test/script/basic/NASHORN-277.js ! test/script/basic/NASHORN-278.js ! test/script/basic/NASHORN-28.js ! test/script/basic/NASHORN-281.js ! test/script/basic/NASHORN-284.js ! test/script/basic/NASHORN-285.js ! test/script/basic/NASHORN-288.js ! test/script/basic/NASHORN-29.js ! test/script/basic/NASHORN-293.js ! test/script/basic/NASHORN-294.js ! test/script/basic/NASHORN-296.js ! test/script/basic/NASHORN-297.js ! test/script/basic/NASHORN-30.js ! test/script/basic/NASHORN-300.js ! test/script/basic/NASHORN-301.js ! test/script/basic/NASHORN-304.js ! test/script/basic/NASHORN-310.js ! test/script/basic/NASHORN-318.js ! test/script/basic/NASHORN-32.js ! test/script/basic/NASHORN-321.js ! test/script/basic/NASHORN-323.js ! test/script/basic/NASHORN-324.js ! test/script/basic/NASHORN-33.js ! test/script/basic/NASHORN-331.js ! test/script/basic/NASHORN-337.js ! test/script/basic/NASHORN-34.js ! test/script/basic/NASHORN-340.js ! test/script/basic/NASHORN-349.js ! test/script/basic/NASHORN-354.js ! test/script/basic/NASHORN-355.js ! test/script/basic/NASHORN-36.js ! test/script/basic/NASHORN-365.js ! test/script/basic/NASHORN-366.js ! test/script/basic/NASHORN-368.js ! test/script/basic/NASHORN-37.js ! test/script/basic/NASHORN-375.js ! test/script/basic/NASHORN-376.js ! test/script/basic/NASHORN-377.js ! test/script/basic/NASHORN-378.js ! test/script/basic/NASHORN-38.js ! test/script/basic/NASHORN-380.js ! test/script/basic/NASHORN-381.js ! test/script/basic/NASHORN-382.js ! test/script/basic/NASHORN-383.js ! test/script/basic/NASHORN-384.js ! test/script/basic/NASHORN-385.js ! test/script/basic/NASHORN-389.js ! test/script/basic/NASHORN-393.js ! test/script/basic/NASHORN-394.js ! test/script/basic/NASHORN-396.js ! test/script/basic/NASHORN-397.js ! test/script/basic/NASHORN-398.js ! test/script/basic/NASHORN-40.js ! test/script/basic/NASHORN-400.js ! test/script/basic/NASHORN-401.js ! test/script/basic/NASHORN-402.js ! test/script/basic/NASHORN-404.js ! test/script/basic/NASHORN-405.js ! test/script/basic/NASHORN-406.js ! test/script/basic/NASHORN-408.js ! test/script/basic/NASHORN-415.js ! test/script/basic/NASHORN-416.js ! test/script/basic/NASHORN-417.js ! test/script/basic/NASHORN-418.js ! test/script/basic/NASHORN-420.js ! test/script/basic/NASHORN-421.js ! test/script/basic/NASHORN-423.js ! test/script/basic/NASHORN-423a.js ! test/script/basic/NASHORN-424.js ! test/script/basic/NASHORN-425.js ! test/script/basic/NASHORN-426.js ! test/script/basic/NASHORN-427.js ! test/script/basic/NASHORN-428.js ! test/script/basic/NASHORN-429.js ! test/script/basic/NASHORN-432.js ! test/script/basic/NASHORN-433.js ! test/script/basic/NASHORN-434.js ! test/script/basic/NASHORN-435.js ! test/script/basic/NASHORN-437.js ! test/script/basic/NASHORN-44.js ! test/script/basic/NASHORN-441.js ! test/script/basic/NASHORN-442.js ! test/script/basic/NASHORN-443.js ! test/script/basic/NASHORN-444.js ! test/script/basic/NASHORN-445.js ! test/script/basic/NASHORN-446.js ! test/script/basic/NASHORN-447.js ! test/script/basic/NASHORN-448.js ! test/script/basic/NASHORN-449.js ! test/script/basic/NASHORN-45.js ! test/script/basic/NASHORN-450.js ! test/script/basic/NASHORN-452.js ! test/script/basic/NASHORN-459.js ! test/script/basic/NASHORN-46.js ! test/script/basic/NASHORN-462.js ! test/script/basic/NASHORN-463.js ! test/script/basic/NASHORN-468.js ! test/script/basic/NASHORN-47.js ! test/script/basic/NASHORN-473.js ! test/script/basic/NASHORN-474.js ! test/script/basic/NASHORN-478.js ! test/script/basic/NASHORN-48.js ! test/script/basic/NASHORN-481.js ! test/script/basic/NASHORN-482.js ! test/script/basic/NASHORN-484.js ! test/script/basic/NASHORN-486.js ! test/script/basic/NASHORN-487.js ! test/script/basic/NASHORN-488.js ! test/script/basic/NASHORN-49.js ! test/script/basic/NASHORN-490.js ! test/script/basic/NASHORN-494.js ! test/script/basic/NASHORN-497.js ! test/script/basic/NASHORN-498.js ! test/script/basic/NASHORN-499.js ! test/script/basic/NASHORN-50.js ! test/script/basic/NASHORN-500.js ! test/script/basic/NASHORN-503.js ! test/script/basic/NASHORN-51.js ! test/script/basic/NASHORN-511.js ! test/script/basic/NASHORN-515.js ! test/script/basic/NASHORN-516.js ! test/script/basic/NASHORN-52.js ! test/script/basic/NASHORN-534.js ! test/script/basic/NASHORN-535.js ! test/script/basic/NASHORN-544.js ! test/script/basic/NASHORN-55.js ! test/script/basic/NASHORN-554.js ! test/script/basic/NASHORN-556.js ! test/script/basic/NASHORN-56.js ! test/script/basic/NASHORN-562.js ! test/script/basic/NASHORN-565.js ! test/script/basic/NASHORN-575.js ! test/script/basic/NASHORN-58.js ! test/script/basic/NASHORN-59.js ! test/script/basic/NASHORN-592.js ! test/script/basic/NASHORN-597.js ! test/script/basic/NASHORN-60.js ! test/script/basic/NASHORN-609.js ! test/script/basic/NASHORN-61.js ! test/script/basic/NASHORN-62.js ! test/script/basic/NASHORN-620.js ! test/script/basic/NASHORN-623.js ! test/script/basic/NASHORN-627.js ! test/script/basic/NASHORN-63.js ! test/script/basic/NASHORN-637.js ! test/script/basic/NASHORN-638.js ! test/script/basic/NASHORN-639.js ! test/script/basic/NASHORN-64.js ! test/script/basic/NASHORN-642.js ! test/script/basic/NASHORN-646.js ! test/script/basic/NASHORN-653.js ! test/script/basic/NASHORN-658.js ! test/script/basic/NASHORN-659.js ! test/script/basic/NASHORN-66.js ! test/script/basic/NASHORN-664.js ! test/script/basic/NASHORN-665.js ! test/script/basic/NASHORN-67.js ! test/script/basic/NASHORN-678.js ! test/script/basic/NASHORN-68.js ! test/script/basic/NASHORN-689.js ! test/script/basic/NASHORN-69.js ! test/script/basic/NASHORN-691.js ! test/script/basic/NASHORN-694.js ! test/script/basic/NASHORN-697.js ! test/script/basic/NASHORN-703.js ! test/script/basic/NASHORN-703a.js ! test/script/basic/NASHORN-705.js ! test/script/basic/NASHORN-71.js ! test/script/basic/NASHORN-710.js ! test/script/basic/NASHORN-711.js ! test/script/basic/NASHORN-72.js ! test/script/basic/NASHORN-722.js ! test/script/basic/NASHORN-73.js ! test/script/basic/NASHORN-737.js ! test/script/basic/NASHORN-74.js ! test/script/basic/NASHORN-740.js ! test/script/basic/NASHORN-75.js ! test/script/basic/NASHORN-758.js ! test/script/basic/NASHORN-759.js ! test/script/basic/NASHORN-760.js ! test/script/basic/NASHORN-768.js ! test/script/basic/NASHORN-778.js ! test/script/basic/NASHORN-78.js ! test/script/basic/NASHORN-79.js ! test/script/basic/NASHORN-792.js ! test/script/basic/NASHORN-80.js ! test/script/basic/NASHORN-81.js ! test/script/basic/NASHORN-833.js ! test/script/basic/NASHORN-85.js ! test/script/basic/NASHORN-86.js ! test/script/basic/NASHORN-87.js ! test/script/basic/NASHORN-89.js ! test/script/basic/NASHORN-90.js ! test/script/basic/NASHORN-91.js ! test/script/basic/NASHORN-92.js ! test/script/basic/NASHORN-93.js ! test/script/basic/NASHORN-95.js ! test/script/basic/NASHORN-96.js ! test/script/basic/NASHORN-97.js ! test/script/basic/NASHORN-98.js ! test/script/basic/NASHORN-99.js ! test/script/basic/addition.js ! test/script/basic/allgettersetters.js ! test/script/basic/andor.js ! test/script/basic/anonrecur.js ! test/script/basic/applycall.js ! test/script/basic/args.js ! test/script/basic/arity.js ! test/script/basic/arrayprotoclass.js ! test/script/basic/arrays.js ! test/script/basic/arrays2.js ! test/script/basic/arraysIntKey.js ! test/script/basic/arrayset.js ! test/script/basic/arrayundefined.js ! test/script/basic/assign.js ! test/script/basic/bitwise_and.js ! test/script/basic/booleangetter.js ! test/script/basic/builtin.js ! test/script/basic/builtin_assign.js ! test/script/basic/builtinchain.js ! test/script/basic/calllink.js ! test/script/basic/closure.js ! test/script/basic/commandargs.js ! test/script/basic/compile-octane.js ! test/script/basic/condassign.js ! test/script/basic/construct.js ! test/script/basic/constructorname.js ! test/script/basic/date.js ! test/script/basic/dateparse.js ! test/script/basic/decinc.js ! test/script/basic/delete.js ! test/script/basic/delete2.js ! test/script/basic/dotpropname.js ! test/script/basic/doublecache.js ! test/script/basic/enumeration.js ! test/script/basic/errors.js ! test/script/basic/errorstack.js ! test/script/basic/eval.js ! test/script/basic/evalreturn.js ! test/script/basic/exprclosure.js ! test/script/basic/extensibility.js ! test/script/basic/fileline.js ! test/script/basic/finally-catchalls.js ! test/script/basic/finallyreturn.js ! test/script/basic/forin.js ! test/script/basic/forin2.js ! test/script/basic/funcarray.js ! test/script/basic/funcbind.js ! test/script/basic/funcconstructor.js ! test/script/basic/getclassname.js ! test/script/basic/getenv.js ! test/script/basic/getter_callsite.js ! test/script/basic/gettercalls.js ! test/script/basic/getterfunc.js ! test/script/basic/gettersetter.js ! test/script/basic/globalaccess.js ! test/script/basic/globals.js ! test/script/basic/globalscope.js ! test/script/basic/hello.js ! test/script/basic/herestr_operator.js ! test/script/basic/illegaljavaname.js ! test/script/basic/incheck.js ! test/script/basic/indexedcall.js ! test/script/basic/info.js ! test/script/basic/inherited_nonwritable.js ! test/script/basic/instanceof.js ! test/script/basic/instanceof2.js ! test/script/basic/interfaces.js ! test/script/basic/iterator.js ! test/script/basic/java.js ! test/script/basic/javaarray.js ! test/script/basic/javaarrayconversion.js ! test/script/basic/javaexceptions.js ! test/script/basic/javaimporter.js ! test/script/basic/javainnerclasses.js ! test/script/basic/javasigcall.js ! test/script/basic/jquery.js ! test/script/basic/jsadapter.js ! test/script/basic/jsadapterlink.js ! test/script/basic/json.js ! test/script/basic/list.js ! test/script/basic/literal.js ! test/script/basic/load.js ! test/script/basic/loadedfile.js ! test/script/basic/localundef.js ! test/script/basic/map.js ! test/script/basic/math.js ! test/script/basic/minuszero.js ! test/script/basic/module.js ! test/script/basic/moduleload.js ! test/script/basic/nashorn2.js ! test/script/basic/natives.js ! test/script/basic/new.js ! test/script/basic/newexpr.js ! test/script/basic/newnew.js ! test/script/basic/nonconstructors.js ! test/script/basic/nosuchmethod.js ! test/script/basic/nosuchproperty.js ! test/script/basic/number.js ! test/script/basic/numberstring.js ! test/script/basic/objectprops.js ! test/script/basic/objects.js ! test/script/basic/options.js ! test/script/basic/propchange.js ! test/script/basic/propertycheck.js ! test/script/basic/prototype.js ! test/script/basic/pushpull.js ! test/script/basic/regex.js ! test/script/basic/regexp_flags.js ! test/script/basic/run-octane.js ! test/script/basic/runsunspider.js ! test/script/basic/samfunc.js ! test/script/basic/scripting.js ! test/script/basic/scripting.js.EXPECTED ! test/script/basic/sealfreeze.js ! test/script/basic/setlength.js ! test/script/basic/stdin.js ! test/script/basic/strings.js ! test/script/basic/throws.js ! test/script/basic/tosource.js ! test/script/basic/tostring.js ! test/script/basic/try.js ! test/script/basic/trybreakcont.js ! test/script/basic/trycatch.js ! test/script/basic/trycatchfor.js ! test/script/basic/tryfinallyreturn.js ! test/script/basic/tryforbreak.js ! test/script/basic/typechange.js ! test/script/basic/typeof.js ! test/script/basic/typeof2.js ! test/script/basic/undefined.js ! test/script/basic/underscore.js ! test/script/basic/varargs.js ! test/script/basic/void.js ! test/script/basic/with.js ! test/script/basic/withprimitive.js ! test/script/basic/writable_relink.js ! test/script/basic/xorassign.js ! test/script/basic/yui.js ! test/script/error/NASHORN-154/function_mult_params_in_strict.js ! test/script/error/NASHORN-154/improper_return_break_continue.js ! test/script/error/NASHORN-154/invalid_lvalue.js ! test/script/error/NASHORN-154/literal_data_and_accessor.js ! test/script/error/NASHORN-154/literal_mult_getters.js ! test/script/error/NASHORN-154/literal_mult_prop_in_strict.js ! test/script/error/NASHORN-154/with_in_strict.js ! test/script/error/NASHORN-214.js ! test/script/error/NASHORN-35.js ! test/script/error/NASHORN-39.js ! test/script/error/NASHORN-568.js ! test/script/error/NASHORN-57.js ! test/script/error/NASHORN-668.js ! test/script/error/quotemissing.js ! test/script/error/strictmode.js ! test/script/representations/NASHORN-592a.js ! test/script/sandbox/NASHORN-525.js ! test/script/sandbox/classloader.js ! test/script/sandbox/doprivileged.js ! test/script/sandbox/exit.js ! test/script/sandbox/file.js ! test/script/sandbox/javaextend.js ! test/script/sandbox/loadLibrary.js ! test/script/sandbox/net.js ! test/script/sandbox/property.js ! test/script/sandbox/reflection.js ! test/script/sandbox/runnable.js ! test/script/sandbox/unsafe.js ! test/script/test262.js ! test/script/test262_single.js ! test/src/UnnamedPackageTestCallback.java ! test/src/jdk/nashorn/api/scripting/MultipleEngineTest.java ! test/src/jdk/nashorn/api/scripting/ScriptEngineTest.java ! test/src/jdk/nashorn/api/scripting/Window.java ! test/src/jdk/nashorn/api/scripting/WindowEventHandler.java ! test/src/jdk/nashorn/internal/access/BooleanAccessTest.java ! test/src/jdk/nashorn/internal/access/MethodAccessTest.java ! test/src/jdk/nashorn/internal/access/NumberAccessTest.java ! test/src/jdk/nashorn/internal/access/NumberBoxingTest.java ! test/src/jdk/nashorn/internal/access/ObjectAccessTest.java ! test/src/jdk/nashorn/internal/access/Person.java ! test/src/jdk/nashorn/internal/access/SharedObject.java ! test/src/jdk/nashorn/internal/access/StringAccessTest.java ! test/src/jdk/nashorn/internal/codegen/CompilerTest.java ! test/src/jdk/nashorn/internal/parser/ParserTest.java ! test/src/jdk/nashorn/internal/performance/AuroraWrapper.java ! test/src/jdk/nashorn/internal/performance/OctaneTest.java ! test/src/jdk/nashorn/internal/performance/PerformanceWrapper.java ! test/src/jdk/nashorn/internal/performance/SplayTest.java ! test/src/jdk/nashorn/internal/runtime/ContextTest.java ! test/src/jdk/nashorn/internal/runtime/JSTypeTest.java ! test/src/jdk/nashorn/internal/runtime/Nashorn401TestSubject.java ! test/src/jdk/nashorn/internal/test/framework/AbstractScriptRunnable.java ! test/src/jdk/nashorn/internal/test/framework/JSJUnitReportReporter.java ! test/src/jdk/nashorn/internal/test/framework/OrphanTestFinder.java ! test/src/jdk/nashorn/internal/test/framework/ParallelTestRunner.java ! test/src/jdk/nashorn/internal/test/framework/ScriptEvaluator.java ! test/src/jdk/nashorn/internal/test/framework/ScriptRunnable.java ! test/src/jdk/nashorn/internal/test/framework/ScriptTest.java ! test/src/jdk/nashorn/internal/test/framework/SeparateContextEvaluator.java ! test/src/jdk/nashorn/internal/test/framework/SharedContextEvaluator.java ! test/src/jdk/nashorn/internal/test/framework/TestConfig.java ! test/src/jdk/nashorn/internal/test/framework/TestFinder.java ! test/src/jdk/nashorn/internal/test/framework/TestHelper.java ! test/src/jdk/nashorn/internal/test/framework/TestReorderInterceptor.java ! test/src/jdk/nashorn/internal/test/models/ConstructorWithArgument.java ! test/src/jdk/nashorn/internal/test/models/FinalClass.java ! test/src/jdk/nashorn/internal/test/models/NoAccessibleConstructorClass.java ! test/src/jdk/nashorn/internal/test/models/NonPublicClass.java ! test/src/jdk/nashorn/internal/test/models/OuterClass.java ! test/src/jdk/nashorn/internal/test/models/OverloadedSam.java ! test/src/jdk/nashorn/internal/test/models/OverrideObject.java Changeset: 1e3f411f47bf Author: lagergren Date: 2013-01-07 19:31 +0100 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/1e3f411f47bf 8005789: Forgot to document -Dnashorn.unstable.relink.threshold Summary: Added documentation to DEVELOPER_README, fixed code convention warnings Reviewed-by: attila ! docs/DEVELOPER_README ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/codegen/Splitter.java ! src/jdk/nashorn/internal/runtime/PropertyMap.java ! src/jdk/nashorn/internal/runtime/options/Options.java Changeset: 41c7093477ae Author: jlaskey Date: 2013-01-07 14:41 -0400 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/41c7093477ae 8005703: Offsets miscalculated for blocks Reviewed-by: lagergren Contributed-by: petr.hejl at oracle.com ! src/jdk/nashorn/internal/ir/Block.java ! src/jdk/nashorn/internal/parser/AbstractParser.java ! src/jdk/nashorn/internal/parser/Parser.java Changeset: d14da0d0c577 Author: sundar Date: 2013-01-08 08:51 +0530 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/d14da0d0c577 8005782: get rid of javadoc errors, warnings in nashorn build Reviewed-by: lagergren ! make/build.xml ! make/project.properties ! src/jdk/nashorn/internal/codegen/MethodEmitter.java ! src/jdk/nashorn/internal/runtime/ECMAErrors.java ! src/jdk/nashorn/internal/runtime/PropertyMap.java Changeset: 0e7da548ef6a Author: lagergren Date: 2013-01-08 09:59 +0100 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/0e7da548ef6a 8005788: Loggers and their corresponding system properties not working correctly Summary: 1-1 mapping now maintained. Used Context err instead of System.err in several places (after bootstrapping Context). Problematic closing of err stream replaced by @SuppressWarnings("resource") Reviewed-by: jlaskey, sundar ! src/jdk/nashorn/internal/ir/Symbol.java ! src/jdk/nashorn/internal/objects/NativeDebug.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/DebugLogger.java ! src/jdk/nashorn/internal/runtime/ECMAException.java ! src/jdk/nashorn/internal/runtime/ErrorManager.java ! src/jdk/nashorn/internal/runtime/Logging.java ! src/jdk/nashorn/internal/runtime/linker/LinkerCallSite.java ! src/jdk/nashorn/internal/runtime/linker/MethodHandleFactory.java ! src/jdk/nashorn/internal/runtime/options/Options.java ! src/jdk/nashorn/tools/Shell.java Changeset: 5f2db2d8a7fa Author: sundar Date: 2013-01-08 15:02 +0530 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/5f2db2d8a7fa 8005835: NASHORN-668 output fails to compare with the corresponding .EXPECTED file Reviewed-by: lagergren, hannesw ! test/script/error/NASHORN-668.js.EXPECTED Changeset: d8e4d66f1a06 Author: lagergren Date: 2013-01-08 10:52 +0100 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/d8e4d66f1a06 8005843: refSymbols lookup of unbound variable could cause NullPointerException in Lower Reviewed-by: hannesw, attila ! src/jdk/nashorn/internal/codegen/Lower.java + test/script/basic/NASHORN-837.js Changeset: c5a321205f49 Author: attila Date: 2013-01-08 13:50 +0100 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/c5a321205f49 8005846: Remove Mangler in favor of Dynalink's NameCodec Reviewed-by: jlaskey, sundar ! src/jdk/nashorn/internal/codegen/Compiler.java Changeset: 4620ac94e7dc Author: attila Date: 2013-01-08 14:14 +0100 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/4620ac94e7dc 8005801: Refactor findSetMethod Summary: findSetMethod() was a very large single method, very unreadable and unmaintainable. It was broken into easy-to-understand pieces. The refactoring required introduction of a comand-object like entity, SetMethodCreator, to contain the nontrivial transient state of the algorithm that made the original big method so resistant to refactoring in the first place. Reviewed-by: lagergren, sundar ! src/jdk/nashorn/internal/runtime/ScriptObject.java + src/jdk/nashorn/internal/runtime/SetMethodCreator.java ! src/jdk/nashorn/internal/runtime/SpillProperty.java - src/jdk/nashorn/internal/runtime/linker/Mangler.java Changeset: 69a4f0363d0f Author: lagergren Date: 2013-01-08 15:20 +0100 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/69a4f0363d0f 8005842: Loops in ASTWriter. Corrected @Reference and @Ignore node annotation for IR nodes Reviewed-by: hannesw, sundar ! src/jdk/nashorn/internal/ir/Block.java ! src/jdk/nashorn/internal/ir/FunctionNode.java ! src/jdk/nashorn/internal/ir/LabelNode.java ! src/jdk/nashorn/internal/ir/LabeledNode.java ! src/jdk/nashorn/internal/ir/ObjectNode.java ! src/jdk/nashorn/internal/ir/ReferenceNode.java ! src/jdk/nashorn/internal/ir/ReturnNode.java ! src/jdk/nashorn/internal/ir/SplitNode.java ! src/jdk/nashorn/internal/ir/SwitchNode.java ! src/jdk/nashorn/internal/ir/ThrowNode.java ! src/jdk/nashorn/internal/ir/TryNode.java ! src/jdk/nashorn/internal/ir/debug/ASTWriter.java Changeset: 548587cfb065 Author: sundar Date: 2013-01-08 21:16 +0530 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/548587cfb065 8005848: assigning to global toString variable affects Object.prototype.toString Reviewed-by: jlaskey, lagergren ! src/jdk/nashorn/internal/runtime/ScriptObject.java + test/script/basic/JDK_8005848.js Changeset: 812b9963b1c7 Author: attila Date: 2013-01-09 15:02 +0100 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/812b9963b1c7 8005777: Bug in the FacetIntrospector of Dynalink - non-public class should search super Reviewed-by: lagergren, sundar ! make/project.properties Changeset: 4cd65798ec70 Author: sundar Date: 2013-01-09 22:32 +0530 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/4cd65798ec70 8005940: provide ant targets to get and update external test scripts Reviewed-by: jlaskey, lagergren ! bin/verbose_octane.bat ! bin/verbose_octane.sh ! make/Makefile ! make/build-benchmark.xml ! make/build.xml ! make/project.properties ! test/script/basic/run-octane.js ! test/script/basic/runsunspider.js ! test/src/jdk/nashorn/internal/codegen/CompilerTest.java ! test/src/jdk/nashorn/internal/parser/ParserTest.java Changeset: 9f59ba5090f2 Author: lagergren Date: 2013-01-10 10:28 +0100 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/9f59ba5090f2 8005971: runsunspider.js should check results of benchmarks Reviewed-by: attila, hannesw ! test/script/basic/runsunspider.js Changeset: a7f177d6639c Author: sundar Date: 2013-01-10 19:03 +0530 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/a7f177d6639c 8005987: ant octane tries to run non-benchmark scripts Reviewed-by: lagergren, attila, jlaskey ! make/build-benchmark.xml ! make/project.properties Changeset: 0362d36d3dd6 Author: sundar Date: 2013-01-10 19:55 +0530 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/0362d36d3dd6 8005982: NASHORN-71.js failing in nightlys Reviewed-by: attila, lagergren, jlaskey ! test/script/basic/NASHORN-71.js - test/script/basic/NASHORN-71.js.EXPECTED Changeset: 2a5c2258827b Author: attila Date: 2013-01-10 15:28 +0100 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/2a5c2258827b 8005983: JavaAdapterFactory generated proxy classes should take extra constructor arguments at the end Reviewed-by: lagergren, sundar ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterFactory.java ! src/jdk/nashorn/internal/runtime/linker/NashornLinker.java ! test/script/sandbox/javaextend.js ! test/script/sandbox/javaextend.js.EXPECTED Changeset: 2a4769fcd13f Author: lagergren Date: 2013-01-11 10:40 +0100 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/2a4769fcd13f 8005976: Break out AccessSpecializer into one pass before CodeGenerator instead of iterative applications from CodeGenerator Summary: Now scope and slot information is guaranteed to be fixed AND NOT CHANGE before CodeGeneration. We want to keep it that way to build future type specializations and bring all type work out of CodeGenerator. Reviewed-by: attila, hannesw + bin/dump_octane_code.sh ! bin/verbose_octane.sh ! docs/DEVELOPER_README ! src/jdk/nashorn/internal/codegen/AccessSpecializer.java ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/codegen/Compiler.java ! src/jdk/nashorn/internal/codegen/Lower.java ! src/jdk/nashorn/internal/codegen/Splitter.java - src/jdk/nashorn/internal/codegen/Transform.java ! src/jdk/nashorn/internal/ir/Block.java ! src/jdk/nashorn/internal/ir/FunctionNode.java ! src/jdk/nashorn/internal/ir/Symbol.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java Changeset: f67bf56495ca Author: sundar Date: 2013-01-11 18:26 +0530 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/f67bf56495ca 8006082: Provide option to run octane benchmarks in separate processes Reviewed-by: lagergren, jlaskey ! make/build-benchmark.xml ! make/project.properties Changeset: 8a5922638ff0 Author: sundar Date: 2013-01-11 20:34 +0530 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/8a5922638ff0 8006093: Add a makefile target to run all tests (test, test262, perf tests) Reviewed-by: attila, hannesw ! make/Makefile ! make/build.xml Changeset: eda69555239a Author: attila Date: 2013-01-14 16:00 +0100 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/eda69555239a 8006168: ability to generate multi-type Java adapters Reviewed-by: lagergren, jlaskey ! src/jdk/nashorn/internal/objects/NativeJava.java ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterFactory.java ! src/jdk/nashorn/internal/runtime/linker/NashornPrimitiveLinker.java ! src/jdk/nashorn/internal/runtime/resources/Messages.properties ! test/script/sandbox/javaextend.js ! test/script/sandbox/javaextend.js.EXPECTED + test/src/jdk/nashorn/internal/test/models/DessertTopping.java + test/src/jdk/nashorn/internal/test/models/DessertToppingFloorWaxDriver.java + test/src/jdk/nashorn/internal/test/models/FloorWax.java + test/src/jdk/nashorn/internal/test/models/Toothpaste.java Changeset: 3c6db5ea0ecc Author: sundar Date: 2013-01-14 21:30 +0530 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/3c6db5ea0ecc 8006181: nashorn script engine does not run jrunscript's initialization script Reviewed-by: lagergren, jlaskey Contributed-by: rieberandreas at gmail.com + src/jdk/nashorn/api/scripting/Formatter.java ! src/jdk/nashorn/api/scripting/NashornScriptEngine.java ! src/jdk/nashorn/api/scripting/resources/engine.js + src/jdk/nashorn/api/scripting/resources/init.js Changeset: 1d0307c2bb4c Author: attila Date: 2013-01-15 13:10 +0100 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/1d0307c2bb4c 8006293: Reduce ScriptObject.findCallMethodMethod Reviewed-by: lagergren, jlaskey ! src/jdk/nashorn/internal/runtime/ScriptFunction.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/WithObject.java ! src/jdk/nashorn/internal/runtime/linker/Bootstrap.java ! src/jdk/nashorn/internal/runtime/linker/MethodHandleFactory.java ! src/jdk/nashorn/internal/runtime/linker/MethodHandleFunctionality.java Changeset: ee73d7378e3e Author: attila Date: 2013-01-15 17:09 +0100 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/ee73d7378e3e 8005958: invoking a function through INVOKESTATIC with more arguments than it declares resulted in malformed bytecode being generated Reviewed-by: lagergren, jlaskey ! src/jdk/nashorn/internal/codegen/CodeGenerator.java + test/script/basic/JDK-8005958.js Changeset: 9088170e68df Author: attila Date: 2013-01-15 18:08 +0100 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/9088170e68df 8006337: Discarded arguments for INVOKESTATIC must still be evaluated for side effects Reviewed-by: hannesw, jlaskey, sundar ! src/jdk/nashorn/internal/codegen/CodeGenerator.java + test/script/basic/JDK-8006337.js + test/script/basic/JDK-8006337.js.EXPECTED Changeset: 617313881c55 Author: jlaskey Date: 2013-01-16 07:06 -0400 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/617313881c55 8006304: Remove pre-population of maps for constructor produced maps Reviewed-by: sundar Contributed-by: james.laskey at oracle.com ! .hgignore ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/codegen/objects/FunctionObjectCreator.java + test/script/basic/JDK-8006304.js + test/script/basic/JDK-8006304.js.EXPECTED Changeset: 80447df16322 Author: sundar Date: 2013-01-16 17:58 +0530 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/80447df16322 8006412: Improve toString method of ScriptObjectMirror class Reviewed-by: jlaskey, lagergren ! src/jdk/nashorn/api/scripting/ScriptObjectMirror.java ! test/src/jdk/nashorn/api/scripting/ScriptEngineTest.java Changeset: cd5b684ce7b2 Author: sundar Date: 2013-01-16 21:26 +0530 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/cd5b684ce7b2 8006424: Passing null or undefined to adapter class constructors results in NPE or ClassCastException Reviewed-by: attila, hannesw, jlaskey ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterFactory.java + test/script/basic/JDK-8006424.js Changeset: 4acebfe9e504 Author: jlaskey Date: 2013-01-17 10:33 -0400 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/4acebfe9e504 8006517: PropertyHashMap.Element.equals() compares to Property Reviewed-by: sundar Contributed-by: james.laskey at oracle.com ! src/jdk/nashorn/internal/runtime/PropertyHashMap.java Changeset: f8136c060914 Author: sundar Date: 2013-01-18 08:45 +0530 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/f8136c060914 8006527: nashorn jsr223 engine does not work in sandbox Reviewed-by: jlaskey, attila, lagergren + bin/nashornsecure + bin/nashornsecure.bat ! src/jdk/nashorn/api/scripting/NashornScriptEngine.java ! src/jdk/nashorn/api/scripting/resources/init.js ! src/jdk/nashorn/internal/objects/NativeJSAdapter.java + test/script/sandbox/engine.js + test/script/sandbox/engine.js.EXPECTED + test/script/sandbox/jsadapter.js Changeset: 4361e8cd6a02 Author: sundar Date: 2013-01-18 17:55 +0530 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/4361e8cd6a02 8006562: findOwnMH in nashorn "objects" package should be cleaned up Reviewed-by: jlaskey, lagergren ! make/project.properties ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeArguments.java ! src/jdk/nashorn/internal/objects/NativeBoolean.java ! src/jdk/nashorn/internal/objects/NativeError.java ! src/jdk/nashorn/internal/objects/NativeJSAdapter.java ! src/jdk/nashorn/internal/objects/NativeNumber.java ! src/jdk/nashorn/internal/objects/NativeStrictArguments.java ! src/jdk/nashorn/internal/objects/NativeString.java ! src/jdk/nashorn/internal/objects/PrototypeObject.java ! src/jdk/nashorn/internal/objects/ScriptFunctionImpl.java Changeset: c887baec012a Author: sundar Date: 2013-01-19 09:14 +0530 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/c887baec012a 8006584: improve variable handling in NashornScriptEngine Reviewed-by: jlaskey, hannesw ! src/jdk/nashorn/api/scripting/NashornScriptEngine.java ! src/jdk/nashorn/api/scripting/ScriptObjectMirror.java ! test/src/jdk/nashorn/api/scripting/ScriptEngineTest.java Changeset: a8966074d4e9 Author: sundar Date: 2013-01-19 22:35 +0530 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/a8966074d4e9 8006557: JDK8/Lambda build clashes on Map.replace() Reviewed-by: jlaskey ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! test/src/jdk/nashorn/internal/runtime/ContextTest.java Changeset: 0cee498b330d Author: attila Date: 2013-01-21 11:03 +0100 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/0cee498b330d 8006525: Give StaticClass objects their own linker Reviewed-by: hannesw, lagergren ! src/jdk/nashorn/internal/runtime/linker/Bootstrap.java ! src/jdk/nashorn/internal/runtime/linker/NashornPrimitiveLinker.java + src/jdk/nashorn/internal/runtime/linker/NashornStaticClassLinker.java Changeset: 8b3cc4ad1810 Author: sundar Date: 2013-01-21 21:17 +0530 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/8b3cc4ad1810 8006635: Reduce access levels as much as possible Reviewed-by: jlaskey, lagergren, attila ! src/jdk/nashorn/api/scripting/NashornScriptEngine.java ! src/jdk/nashorn/api/scripting/ScriptObjectMirror.java ! src/jdk/nashorn/internal/codegen/Compiler.java ! src/jdk/nashorn/internal/ir/Symbol.java ! src/jdk/nashorn/internal/ir/debug/JSONWriter.java ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeArray.java ! src/jdk/nashorn/internal/objects/NativeDebug.java ! src/jdk/nashorn/internal/objects/NativeJava.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/DebugLogger.java ! src/jdk/nashorn/internal/runtime/ECMAException.java + src/jdk/nashorn/internal/runtime/OptionsObject.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/StructureLoader.java ! src/jdk/nashorn/internal/runtime/arrays/ArrayIterator.java ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterFactory.java ! src/jdk/nashorn/internal/runtime/linker/LinkerCallSite.java ! src/jdk/nashorn/tools/Shell.java ! test/src/jdk/nashorn/internal/access/BooleanAccessTest.java ! test/src/jdk/nashorn/internal/codegen/CompilerTest.java ! test/src/jdk/nashorn/internal/parser/ParserTest.java ! test/src/jdk/nashorn/internal/runtime/ContextTest.java ! test/src/jdk/nashorn/internal/runtime/JSTypeTest.java ! test/src/jdk/nashorn/internal/test/framework/SharedContextEvaluator.java Changeset: 935dcec38e9a Author: hannesw Date: 2013-01-22 14:14 +0100 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/935dcec38e9a 8006570: This-value for non-strict functions should be converted to object Reviewed-by: jlaskey, lagergren, attila ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeBoolean.java ! src/jdk/nashorn/internal/objects/NativeFunction.java ! src/jdk/nashorn/internal/objects/NativeNumber.java ! src/jdk/nashorn/internal/objects/NativeString.java ! src/jdk/nashorn/internal/runtime/GlobalObject.java ! src/jdk/nashorn/internal/runtime/ScriptFunction.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/SetMethodCreator.java ! src/jdk/nashorn/internal/runtime/linker/NashornGuardedInvocation.java ! src/jdk/nashorn/internal/runtime/linker/NashornLinker.java ! src/jdk/nashorn/internal/runtime/linker/PrimitiveLookup.java + test/script/basic/JDK-8006570.js + test/script/basic/JDK-8006570.js.EXPECTED Changeset: e43d1013d871 Author: attila Date: 2013-01-22 14:36 +0100 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/e43d1013d871 8006677: Remove unused FunctionNode flags Reviewed-by: hannesw, jlaskey ! src/jdk/nashorn/internal/codegen/Lower.java ! src/jdk/nashorn/internal/ir/FunctionNode.java ! src/jdk/nashorn/internal/parser/Parser.java Changeset: e62dba3ce52b Author: sundar Date: 2013-01-22 22:07 +0530 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/e62dba3ce52b 8006678: Avoid too many Context.getGlobal() calls Reviewed-by: lagergren, jlaskey ! make/project.properties ! src/jdk/nashorn/api/scripting/NashornScriptEngine.java ! src/jdk/nashorn/api/scripting/ScriptObjectMirror.java ! src/jdk/nashorn/internal/codegen/Lower.java ! src/jdk/nashorn/internal/ir/debug/JSONWriter.java ! src/jdk/nashorn/internal/objects/AccessorPropertyDescriptor.java ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeArguments.java ! src/jdk/nashorn/internal/objects/NativeArray.java ! src/jdk/nashorn/internal/objects/NativeBoolean.java ! src/jdk/nashorn/internal/objects/NativeDate.java ! src/jdk/nashorn/internal/objects/NativeFunction.java ! src/jdk/nashorn/internal/objects/NativeJSAdapter.java ! src/jdk/nashorn/internal/objects/NativeJSON.java ! src/jdk/nashorn/internal/objects/NativeJava.java ! src/jdk/nashorn/internal/objects/NativeNumber.java ! src/jdk/nashorn/internal/objects/NativeObject.java ! src/jdk/nashorn/internal/objects/NativeRegExp.java ! src/jdk/nashorn/internal/objects/NativeString.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/ECMAErrors.java ! src/jdk/nashorn/internal/runtime/ErrorManager.java ! src/jdk/nashorn/internal/runtime/JSType.java ! src/jdk/nashorn/internal/runtime/ParserException.java ! src/jdk/nashorn/internal/runtime/ScriptFunction.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/ScriptRuntime.java ! src/jdk/nashorn/internal/runtime/ScriptingFunctions.java ! src/jdk/nashorn/internal/runtime/SetMethodCreator.java ! src/jdk/nashorn/internal/runtime/URIUtils.java ! src/jdk/nashorn/internal/runtime/Undefined.java ! src/jdk/nashorn/internal/runtime/arrays/ArrayLikeIterator.java ! src/jdk/nashorn/internal/runtime/arrays/FrozenArrayFilter.java ! src/jdk/nashorn/internal/runtime/arrays/IteratorAction.java ! src/jdk/nashorn/internal/runtime/arrays/SealedArrayFilter.java ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterFactory.java ! src/jdk/nashorn/internal/runtime/linker/JavaArgumentConverters.java ! src/jdk/nashorn/internal/runtime/linker/Lookup.java ! src/jdk/nashorn/internal/runtime/linker/NashornBottomLinker.java ! src/jdk/nashorn/internal/runtime/linker/NashornStaticClassLinker.java Changeset: 0dbcb7350595 Author: sundar Date: 2013-01-23 17:04 +0530 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/0dbcb7350595 8006736: nashorn script engine should support the usage multiple global objects with same engine instance Reviewed-by: lagergren, jlaskey, hannesw ! src/jdk/nashorn/api/scripting/NashornScriptEngine.java ! src/jdk/nashorn/api/scripting/ScriptObjectMirror.java ! test/src/jdk/nashorn/api/scripting/ScriptEngineTest.java Changeset: d4a968ca8953 Author: sundar Date: 2013-01-24 16:21 +0530 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/d4a968ca8953 8006575: Error in codegen for element access on primitive value Reviewed-by: hannesw, lagergren ! src/jdk/nashorn/internal/codegen/CodeGenerator.java + test/script/basic/JDK-8006575.js Changeset: 3f528769aee1 Author: sundar Date: 2013-01-24 17:49 +0530 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/3f528769aee1 8006755: Functions inside with statements dont get correct scope Reviewed-by: lagergren, attila ! src/jdk/nashorn/internal/parser/Parser.java + test/script/basic/JDK-8006755.js Changeset: edfa73d9fde7 Author: hannesw Date: 2013-01-24 14:55 +0100 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/edfa73d9fde7 8006408: Clean up and specialize NativeString Reviewed-by: jlaskey, lagergren ! src/jdk/nashorn/internal/objects/NativeString.java + test/examples/string-micro.js Changeset: f336aee22e85 Author: jlaskey Date: 2013-01-24 12:15 -0400 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/f336aee22e85 8006852: Move tests from JIRA for prepopulated map failures Reviewed-by: sundar Contributed-by: james.laskey at oracle.com + test/script/basic/JDK-8006852a.js + test/script/basic/JDK-8006852a.js.EXPECTED + test/script/basic/JDK-8006852b.js Changeset: bff7087396d7 Author: sundar Date: 2013-01-24 22:38 +0530 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/bff7087396d7 8006857: ClassCastException when interface implementing function uses arguments object Reviewed-by: jlaskey, lagergren ! src/jdk/nashorn/internal/runtime/ScriptObject.java + test/script/basic/JDK-8006857.js + test/script/basic/JDK-8006857.js.EXPECTED Changeset: f52d7294536f Author: hannesw Date: 2013-01-25 17:35 +0100 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/f52d7294536f 8006766: Array-like access to characters of a string is slow Reviewed-by: lagergren, attila ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeBoolean.java ! src/jdk/nashorn/internal/objects/NativeJSAdapter.java ! src/jdk/nashorn/internal/objects/NativeJavaImporter.java ! src/jdk/nashorn/internal/objects/NativeNumber.java ! src/jdk/nashorn/internal/objects/NativeString.java ! src/jdk/nashorn/internal/runtime/GlobalObject.java ! src/jdk/nashorn/internal/runtime/NativeJavaPackage.java ! src/jdk/nashorn/internal/runtime/ScriptFunction.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/WithObject.java ! src/jdk/nashorn/internal/runtime/linker/NashornLinker.java ! src/jdk/nashorn/internal/runtime/linker/NashornPrimitiveLinker.java ! src/jdk/nashorn/internal/runtime/linker/PrimitiveLookup.java Changeset: 8f7a86f82376 Author: sundar Date: 2013-01-28 18:10 +0530 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/8f7a86f82376 8006983: Introduce a command line option to switch off syntactic extensions of nashorn Reviewed-by: lagergren, attila ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/parser/Parser.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/ScriptingFunctions.java ! src/jdk/nashorn/internal/runtime/resources/Options.properties + test/script/basic/JDK-8006983.js ! test/script/basic/scripting.js ! test/script/basic/scripting.js.EXPECTED Changeset: 265c46dbcf43 Author: sundar Date: 2013-01-28 21:29 +0530 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/265c46dbcf43 8007004: nashorn script engine should not use thread context class loader as script 'application loader' Reviewed-by: attila, hannesw ! src/jdk/nashorn/api/scripting/NashornScriptEngine.java ! src/jdk/nashorn/api/scripting/NashornScriptEngineFactory.java Changeset: b6c69beebde6 Author: jlaskey Date: 2013-01-28 16:22 -0400 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/b6c69beebde6 8006676: Integrate Nashorn into new build system Reviewed-by: jlaskey Contributed-by: james.laskey at oracle.com ! make/Makefile + makefiles/BuildNashorn.gmk + makefiles/Makefile Changeset: 333748665588 Author: sundar Date: 2013-01-29 19:57 +0530 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/333748665588 8007091: Provide private API to pass application class loader for nashorn script engine Reviewed-by: jlaskey, lagergren ! src/jdk/nashorn/api/scripting/NashornScriptEngineFactory.java ! test/src/jdk/nashorn/api/scripting/ScriptEngineTest.java Changeset: 755404d7d189 Author: jlaskey Date: 2013-01-29 14:25 -0400 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/755404d7d189 8007094: Apply version to nashorn.jar manifest Reviewed-by: sundar Contributed-by: james.laskey at oracle.com ! makefiles/BuildNashorn.gmk Changeset: 59970b70ebb5 Author: lagergren Date: 2013-01-30 12:26 +0100 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/59970b70ebb5 8007062: Split Lower up into Lower/Attr/FinalizeTypes. Integrate AccessSpecalizer into FinalizeTypes. Summary: Lower suffered from being a "God class" trying to do everything at once. As Nashorn code generation has grown, so has Lower. It does several post processing passes, tries to do several things at once even though all type information isn't in place, adjusting state afterwards and so on. It also performs control flow analysis, type attribution and constant folding, and everything else code generation related before byte code emission. I have now separated the compilation process into Lower (create low level nodes from high level ones, copy code such as finally block inlining etc), Attr (assign types and symbols to all nodes - freeze slot and scope information) and FinalizeTypes (insert explicit casts, specialize invoke dynamic types for scope accesses). I've removed the kludgy AccessSpecializer, as this now integrates naturally with typing. Everything is now much easier to read and each module performs only one thing. I have added separate loggers for the separate ti ers. In the process I have also fixed: (1) problems with type coercion (see test/script/basic/typecoercion.js, basically our coercion was too late and our symbol inference was erroneous. This only manifested itself in very rare occasions where toNumber coercion has side effects, such as for example when valueOf is overridden) (2) copying literal nodes (literal copy did not use the superclass copy, which made all the Node specific fields not to be copied (3) erroneous literal tokenization (literals shouldn't always just inherit token information from whatever node that creates them) (4) splitter weighnodes - unary nodes were considered weightless (4) removed the hateful and kludgy "VarNode.shouldAppend", which really isn't needed when we have an attribution phase that determines self reference symbols (the only thing it was used for) (5) duplicate line number issues in the parser (6) convert bug in CodeGenerator for intermediate results of scope accesses (see test/script/b asic/access-specializer.js) ... Several of these things just stopped being problems with the new architecture "can't happen anymore" and are not bug fixes per se. All tests run. No performance regressions exist that I've been able to measure. Some increases in performance were measured, but in the statistical margin of error (which is very wide as HotSpot currently has warmup issues with LambdaForms/invoke dynamic). Compile speed has not measurably increased. Reviewed-by: jlaskey, attila ! docs/DEVELOPER_README ! src/jdk/nashorn/api/scripting/Formatter.java ! src/jdk/nashorn/api/scripting/NashornScriptEngine.java - src/jdk/nashorn/internal/codegen/AccessSpecializer.java + src/jdk/nashorn/internal/codegen/Attr.java ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/codegen/Compiler.java + src/jdk/nashorn/internal/codegen/FinalizeTypes.java + src/jdk/nashorn/internal/codegen/FoldConstants.java ! src/jdk/nashorn/internal/codegen/Lower.java ! src/jdk/nashorn/internal/codegen/MethodEmitter.java ! src/jdk/nashorn/internal/codegen/SharedScopeCall.java ! src/jdk/nashorn/internal/codegen/WeighNodes.java ! src/jdk/nashorn/internal/codegen/objects/FunctionObjectCreator.java ! src/jdk/nashorn/internal/ir/Block.java ! src/jdk/nashorn/internal/ir/CallNode.java ! src/jdk/nashorn/internal/ir/CatchNode.java ! src/jdk/nashorn/internal/ir/ExecuteNode.java ! src/jdk/nashorn/internal/ir/FunctionNode.java ! src/jdk/nashorn/internal/ir/LiteralNode.java ! src/jdk/nashorn/internal/ir/Node.java ! src/jdk/nashorn/internal/ir/RuntimeNode.java ! src/jdk/nashorn/internal/ir/Symbol.java ! src/jdk/nashorn/internal/ir/TryNode.java ! src/jdk/nashorn/internal/ir/VarNode.java ! src/jdk/nashorn/internal/ir/debug/ASTWriter.java ! src/jdk/nashorn/internal/objects/NativeJSON.java ! src/jdk/nashorn/internal/objects/NativeString.java ! src/jdk/nashorn/internal/parser/AbstractParser.java ! src/jdk/nashorn/internal/parser/Parser.java ! src/jdk/nashorn/internal/parser/TokenType.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/DebugLogger.java ! src/jdk/nashorn/internal/runtime/OptionsObject.java ! src/jdk/nashorn/internal/runtime/PropertyMap.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/ScriptingFunctions.java ! src/jdk/nashorn/internal/runtime/arrays/ArrayIterator.java ! src/jdk/nashorn/internal/runtime/arrays/ArrayLikeIterator.java ! src/jdk/nashorn/internal/runtime/arrays/FrozenArrayFilter.java ! src/jdk/nashorn/internal/runtime/arrays/SealedArrayFilter.java ! src/jdk/nashorn/internal/runtime/linker/LinkerCallSite.java ! src/jdk/nashorn/internal/runtime/options/Options.java ! src/jdk/nashorn/tools/Shell.java + test/script/basic/access-specializer.js ! test/script/basic/compile-octane.js.EXPECTED ! test/script/basic/run-octane.js + test/script/basic/typecoerce.js + test/script/basic/typecoerce.js.EXPECTED Changeset: ca6d5e4b8170 Author: sundar Date: 2013-01-30 17:52 +0530 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/ca6d5e4b8170 8007132: Java objects returned from constructor functions are lost Reviewed-by: hannesw, lagergren, attila ! src/jdk/nashorn/internal/runtime/ScriptFunction.java + test/script/basic/JDK-8007132.js Changeset: 9f913c1843c8 Author: hannesw Date: 2013-01-30 14:57 +0100 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/9f913c1843c8 8007109: Regression: String(ConsString) does not flatten argument to String Reviewed-by: sundar, lagergren ! src/jdk/nashorn/internal/objects/NativeString.java + test/script/basic/consstring.js + test/src/jdk/nashorn/internal/test/models/StringArgs.java Changeset: c04f54d5b672 Author: sundar Date: 2013-01-30 21:15 +0530 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/c04f54d5b672 8007140: Java.extend crashes when attempting to extend java.lang.Object Reviewed-by: lagergren, hannesw ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterFactory.java ! test/script/basic/JDK-8006424.js + test/script/basic/JDK-8007140.js Changeset: 9c1e7ae975db Author: sundar Date: 2013-01-31 20:07 +0530 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/9c1e7ae975db 8007286: Add JavaAdapter and importPackage to compatibility script Reviewed-by: lagergren, jlaskey ! src/jdk/nashorn/api/scripting/NashornException.java ! src/jdk/nashorn/api/scripting/NashornScriptEngine.java ! src/jdk/nashorn/api/scripting/resources/engine.js ! src/jdk/nashorn/internal/parser/TokenLookup.java ! src/jdk/nashorn/internal/parser/TokenType.java ! src/jdk/nashorn/internal/runtime/ECMAException.java ! src/jdk/nashorn/internal/runtime/PropertyHashMap.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/resources/mozilla_compat.js + test/script/basic/importpackage.js + test/script/basic/javaadapter.js Changeset: f7825c1a11d3 Author: attila Date: 2013-01-31 18:34 +0100 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/f7825c1a11d3 8006529: Methods always get callee - it should be conditional Summary: This commit streamlines the bytecode function signatures, prologue, local variable use, scope creation, and invocation. It started out quite innocently when we noticed that we always emit __callee__ parameters for all functions even when they are not needed, but it turned out to be quite a deep rabbit hole. In the end, I identified exact conditions when functions need to have a callee parameter, when they need to receive parent scope, when they need to create their own scope, when they need to have variable arity signature, and when they need to have an "arguments" object, and made sure that callee parameters in signatures only show up when they are needed, that parent function's scope is only passed to a child function when it is needed, that the function only creates its own scope when it is needed. In crypto.js, the number of scopes dropped from 446 to 244, and the number of callees dropped from 315 to 145. Reviewed-by: jlaskey, lagergren ! src/jdk/nashorn/internal/codegen/Attr.java ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/codegen/Compiler.java ! src/jdk/nashorn/internal/codegen/FinalizeTypes.java ! src/jdk/nashorn/internal/codegen/Lower.java ! src/jdk/nashorn/internal/codegen/MethodEmitter.java ! src/jdk/nashorn/internal/codegen/objects/FieldObjectCreator.java ! src/jdk/nashorn/internal/codegen/objects/FunctionObjectCreator.java ! src/jdk/nashorn/internal/codegen/types/Type.java ! src/jdk/nashorn/internal/ir/Block.java ! src/jdk/nashorn/internal/ir/FunctionNode.java ! src/jdk/nashorn/internal/ir/Symbol.java ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeArguments.java ! src/jdk/nashorn/internal/objects/ScriptFunctionImpl.java ! src/jdk/nashorn/internal/parser/Parser.java + src/jdk/nashorn/internal/runtime/ArgumentSetter.java ! src/jdk/nashorn/internal/runtime/ScriptFunction.java ! src/jdk/nashorn/internal/runtime/ScriptRuntime.java + test/script/basic/JDK-8006529-b.js + test/script/basic/JDK-8006529-b.js.EXPECTED + test/script/basic/JDK-8006529.js + test/src/jdk/nashorn/internal/codegen/CompilerAccess.java Changeset: 697f700d90c0 Author: hannesw Date: 2013-02-01 02:24 +0100 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/697f700d90c0 8007060: Primitive wrap filter throws ClassCastException in test262parallel Reviewed-by: sundar, jlaskey, lagergren ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeFunction.java ! src/jdk/nashorn/internal/objects/ScriptFunctionImpl.java ! src/jdk/nashorn/internal/runtime/GlobalObject.java ! src/jdk/nashorn/internal/runtime/ScriptFunction.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/SetMethodCreator.java - src/jdk/nashorn/internal/runtime/linker/NashornGuardedInvocation.java ! src/jdk/nashorn/internal/runtime/linker/NashornGuards.java ! src/jdk/nashorn/internal/runtime/linker/PrimitiveLookup.java + test/script/basic/JDK-8007060.js + test/script/basic/JDK-8007060.js.EXPECTED Changeset: a704700470fb Author: jlaskey Date: 2013-02-04 08:13 -0400 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/a704700470fb 8007455: Extraneous $(ECHO) in make/Makefile Reviewed-by: sundar Contributed-by: james.laskey at oracle.com ! make/Makefile Changeset: bb86bf840f9f Author: attila Date: 2013-02-04 15:59 +0100 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/bb86bf840f9f 8007460: var assignment to a parameter in a varargs method causes compilation error Reviewed-by: jlaskey, lagergren ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/codegen/MethodEmitter.java + test/script/basic/JDK-8007460.js + test/script/basic/JDK-8007460.js.EXPECTED Changeset: bee7c8a45a04 Author: lagergren Date: 2013-02-04 16:20 +0100 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/bee7c8a45a04 8007215: Varargs broken for the case of passing more than the arg limit arguments. Reviewed-by: jlaskey, attila ! src/jdk/nashorn/api/scripting/NashornException.java ! src/jdk/nashorn/api/scripting/NashornScriptEngine.java ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/codegen/FunctionSignature.java ! src/jdk/nashorn/internal/codegen/MethodEmitter.java ! src/jdk/nashorn/internal/codegen/RuntimeCallSite.java ! src/jdk/nashorn/internal/codegen/SharedScopeCall.java ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/runtime/ECMAException.java ! src/jdk/nashorn/internal/runtime/ScriptFunction.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java + test/script/basic/JDK-8007215.js + test/script/basic/JDK-8007215.js.EXPECTED Changeset: 6f58c28c4faa Author: jlaskey Date: 2013-02-04 14:48 -0400 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/6f58c28c4faa 8006191: `cmd` -> exec("cmd") in script mode Reviewed-by: sundar, lagergren, hannesw Contributed-by: james.laskey at oracle.com ! src/jdk/nashorn/api/scripting/NashornScriptEngine.java ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/parser/Lexer.java ! src/jdk/nashorn/internal/parser/Parser.java ! src/jdk/nashorn/internal/parser/TokenType.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/OptionsObject.java ! src/jdk/nashorn/internal/runtime/ScriptingFunctions.java ! src/jdk/nashorn/internal/runtime/resources/Messages.properties + test/script/basic/JDK-8006191.js + test/script/basic/JDK-8006191.js.EXPECTED Changeset: 5c2ed5d89524 Author: sundar Date: 2013-02-05 09:11 +0530 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/5c2ed5d89524 8007452: add scripting programmers doc changes for nashorn Reviewed-by: jlaskey, hannesw + docs/JavaScriptingProgrammersGuide.html + docs/source/EvalFile.java + docs/source/EvalScript.java + docs/source/InvokeScriptFunction.java + docs/source/InvokeScriptMethod.java + docs/source/MultiScopes.java + docs/source/RunnableImpl.java + docs/source/RunnableImplObject.java + docs/source/ScriptVars.java + docs/source/importpackageclass.js + docs/source/javaarray.js + docs/source/javaextend.js + docs/source/javaimporter.js + docs/source/javatypes.js + docs/source/overload.js + docs/source/runnable.js + docs/source/samfunc.js + docs/source/test.js ! src/jdk/nashorn/internal/objects/NativeJava.java Changeset: c48e8a28da90 Author: sundar Date: 2013-02-05 18:44 +0530 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/c48e8a28da90 8007521: $ENV should be undefined when security manager is present Reviewed-by: hannesw, jlaskey ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/runtime/ScriptingFunctions.java - test/script/basic/JDK-8006191.js - test/script/basic/JDK-8006191.js.EXPECTED + test/script/currently-failing/JDK-8006191.js + test/script/currently-failing/JDK-8006191.js.EXPECTED + test/script/sandbox/env.js + test/script/sandbox/exec.js Changeset: 819b5485949d Author: sundar Date: 2013-02-05 21:00 +0530 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/819b5485949d 8007522: IllegalStateException thrown from String.prototype.search function Reviewed-by: jlaskey ! src/jdk/nashorn/internal/objects/NativeRegExp.java + test/script/basic/JDK-8007522.js Changeset: f05d4dae30f7 Author: sundar Date: 2013-02-05 22:07 +0530 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/f05d4dae30f7 8007523: VerifyError on script that uses regular expression literals with ternary operator Reviewed-by: lagergren ! src/jdk/nashorn/internal/ir/LiteralNode.java ! test/script/basic/JDK-8007522.js + test/script/basic/JDK-8007523.js Changeset: f6fae6de6f4f Author: hannesw Date: 2013-02-06 10:31 +0100 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/f6fae6de6f4f 8007273: Creation of ScriptFunctions can be refactored Reviewed-by: lagergren, attila ! src/jdk/nashorn/internal/codegen/objects/FunctionObjectCreator.java ! src/jdk/nashorn/internal/codegen/objects/ObjectCreator.java ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/ScriptFunctionImpl.java ! src/jdk/nashorn/internal/runtime/PropertyMap.java ! src/jdk/nashorn/internal/runtime/ScriptFunction.java + src/jdk/nashorn/internal/runtime/ScriptFunctionData.java Changeset: fcf541418304 Author: sundar Date: 2013-02-06 17:56 +0530 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/fcf541418304 8007619: Add support for deprecated properties of RegExp constructor Reviewed-by: lagergren, hannesw ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeRegExp.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java + test/script/basic/JDK-8007619.js + test/script/basic/JDK-8007619.js.EXPECTED Changeset: ec4d59c9b8d2 Author: jlaskey Date: 2013-02-06 08:42 -0400 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/ec4d59c9b8d2 8007545: jjs input evalinput need to be NOT_ENUMERABLE Reviewed-by: sundar, lagergren Contributed-by: james.laskey at oracle.com ! src/jdk/nashorn/tools/resources/shell.js Changeset: 2ca25bf25d0c Author: jlaskey Date: 2013-02-06 11:57 -0400 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/2ca25bf25d0c 8007629: Remove extraneous quit from shell.js Reviewed-by: sundar, hannesw Contributed-by: james.laskey at oracle.com ! src/jdk/nashorn/api/scripting/resources/init.js ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/runtime/ScriptingFunctions.java ! src/jdk/nashorn/tools/resources/shell.js Changeset: 02f810c26ff9 Author: jlaskey Date: 2013-02-06 12:51 -0400 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/02f810c26ff9 8007643: Add testing for quit and exit Reviewed-by: sundar Contributed-by: james.laskey at oracle.com ! test/script/sandbox/exit.js ! test/script/sandbox/exit.js.EXPECTED Changeset: d7e83be6e7aa Author: sundar Date: 2013-02-07 17:17 +0530 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/d7e83be6e7aa 8007715: Make sure that not all tests run with AllPermission Reviewed-by: lagergren, attila ! make/build.xml ! make/project.properties ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterFactory.java + test/script/README - test/script/basic/JDK-8006424.js - test/script/basic/JDK-8006529.js - test/script/basic/NASHORN-638.js - test/script/basic/NASHORN-638.js.EXPECTED - test/script/basic/NASHORN-653.js ! test/script/basic/NASHORN-758.js - test/script/basic/getenv.js - test/script/basic/getenv.js.EXPECTED ! test/script/basic/javaexceptions.js ! test/script/basic/newexpr.js + test/script/sandbox/interfaceimpl.js + test/script/sandbox/loadcompat.js + test/script/trusted/JDK-8006424.js + test/script/trusted/JDK-8006529.js + test/script/trusted/NASHORN-638.js + test/script/trusted/NASHORN-638.js.EXPECTED + test/script/trusted/NASHORN-653.js + test/script/trusted/README + test/script/trusted/getenv.js + test/script/trusted/getenv.js.EXPECTED ! test/src/jdk/nashorn/api/scripting/ScriptEngineTest.java ! test/src/jdk/nashorn/internal/runtime/ContextTest.java Changeset: bca3a64a4a82 Author: hannesw Date: 2013-02-07 14:58 +0100 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/bca3a64a4a82 8007627: Support @Getter annotation on constructor Reviewed-by: attila, lagergren ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/ConstructorGenerator.java ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/PrototypeGenerator.java Changeset: d5130a5803d1 Author: hannesw Date: 2013-02-07 15:33 +0100 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/d5130a5803d1 8007718: Make static RegExp properties fully compatible to other engines Reviewed-by: lagergren, sundar ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeRegExp.java ! src/jdk/nashorn/internal/runtime/RegExpMatch.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java + test/script/basic/JDK-8007718.js + test/script/basic/JDK-8007718.js.EXPECTED Changeset: 8742be332c8a Author: jlaskey Date: 2013-02-08 09:19 -0400 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/8742be332c8a 8006222: Move slot from SpillProperty to Property Reviewed-by: hannesw, lagergren Contributed-by: james.laskey at oracle.com ! src/jdk/nashorn/internal/codegen/objects/FieldObjectCreator.java ! src/jdk/nashorn/internal/codegen/objects/MapCreator.java ! src/jdk/nashorn/internal/codegen/objects/ObjectCreator.java ! src/jdk/nashorn/internal/objects/ScriptFunctionImpl.java ! src/jdk/nashorn/internal/runtime/AccessorProperty.java ! src/jdk/nashorn/internal/runtime/FindProperty.java ! src/jdk/nashorn/internal/runtime/Property.java ! src/jdk/nashorn/internal/runtime/PropertyMap.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/SpillProperty.java ! src/jdk/nashorn/internal/runtime/UserAccessorProperty.java ! src/jdk/nashorn/internal/runtime/linker/Lookup.java Changeset: 5ead5333fa59 Author: attila Date: 2013-02-09 16:58 +0100 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/5ead5333fa59 8006943: Fix order of function method arguments to be (callee, thisObject) Reviewed-by: jlaskey, lagergren ! src/jdk/nashorn/internal/codegen/Attr.java ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/codegen/CompilerConstants.java ! src/jdk/nashorn/internal/codegen/FunctionSignature.java ! src/jdk/nashorn/internal/codegen/MethodEmitter.java ! src/jdk/nashorn/internal/codegen/objects/ObjectClassGenerator.java ! src/jdk/nashorn/internal/codegen/types/ObjectType.java ! src/jdk/nashorn/internal/objects/ScriptFunctionImpl.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/ScriptFunction.java ! src/jdk/nashorn/internal/runtime/ScriptFunctionData.java Changeset: abea4ba28901 Author: sundar Date: 2013-02-11 21:26 +0530 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/abea4ba28901 8007915: Nashorn IR, codegen, parser packages and Context instance should be inaccessible to user code Reviewed-by: lagergren, jlaskey, attila ! bin/jjssecure ! bin/jjssecure.bat ! bin/nashornsecure ! bin/nashornsecure.bat ! make/Makefile ! make/build.xml + make/java.security.override ! make/project.properties ! src/jdk/nashorn/internal/codegen/Attr.java ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/codegen/Compiler.java ! src/jdk/nashorn/internal/codegen/RuntimeCallSite.java ! src/jdk/nashorn/internal/ir/Symbol.java ! src/jdk/nashorn/internal/ir/debug/JSONWriter.java ! src/jdk/nashorn/internal/objects/AccessorPropertyDescriptor.java ! src/jdk/nashorn/internal/objects/DataPropertyDescriptor.java ! src/jdk/nashorn/internal/objects/GenericPropertyDescriptor.java ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeArray.java ! src/jdk/nashorn/internal/objects/NativeArrayBuffer.java ! src/jdk/nashorn/internal/objects/NativeDebug.java ! src/jdk/nashorn/internal/objects/NativeError.java ! src/jdk/nashorn/internal/objects/NativeEvalError.java ! src/jdk/nashorn/internal/objects/NativeFloat32Array.java ! src/jdk/nashorn/internal/objects/NativeFloat64Array.java ! src/jdk/nashorn/internal/objects/NativeFunction.java ! src/jdk/nashorn/internal/objects/NativeInt16Array.java ! src/jdk/nashorn/internal/objects/NativeInt32Array.java ! src/jdk/nashorn/internal/objects/NativeInt8Array.java ! src/jdk/nashorn/internal/objects/NativeJSAdapter.java ! src/jdk/nashorn/internal/objects/NativeJSON.java ! src/jdk/nashorn/internal/objects/NativeJava.java ! src/jdk/nashorn/internal/objects/NativeJavaImporter.java ! src/jdk/nashorn/internal/objects/NativeRangeError.java ! src/jdk/nashorn/internal/objects/NativeReferenceError.java ! src/jdk/nashorn/internal/objects/NativeRegExp.java ! src/jdk/nashorn/internal/objects/NativeRegExpExecResult.java ! src/jdk/nashorn/internal/objects/NativeString.java ! src/jdk/nashorn/internal/objects/NativeSyntaxError.java ! src/jdk/nashorn/internal/objects/NativeTypeError.java ! src/jdk/nashorn/internal/objects/NativeURIError.java ! src/jdk/nashorn/internal/objects/NativeUint16Array.java ! src/jdk/nashorn/internal/objects/NativeUint32Array.java ! src/jdk/nashorn/internal/objects/NativeUint8Array.java ! src/jdk/nashorn/internal/objects/NativeUint8ClampedArray.java ! src/jdk/nashorn/internal/objects/ScriptFunctionImpl.java ! src/jdk/nashorn/internal/parser/AbstractParser.java ! src/jdk/nashorn/internal/parser/Lexer.java - src/jdk/nashorn/internal/parser/RegExp.java - src/jdk/nashorn/internal/parser/RegExpScanner.java ! src/jdk/nashorn/internal/runtime/ArgumentSetter.java ! src/jdk/nashorn/internal/runtime/BitVector.java ! src/jdk/nashorn/internal/runtime/ConsString.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/Debug.java ! src/jdk/nashorn/internal/runtime/DebugLogger.java ! src/jdk/nashorn/internal/runtime/GlobalFunctions.java + src/jdk/nashorn/internal/runtime/JSONFunctions.java ! src/jdk/nashorn/internal/runtime/Logging.java ! src/jdk/nashorn/internal/runtime/NashornLoader.java ! src/jdk/nashorn/internal/runtime/NativeJavaPackage.java + src/jdk/nashorn/internal/runtime/RegExp.java + src/jdk/nashorn/internal/runtime/RegExpScanner.java ! src/jdk/nashorn/internal/runtime/ScriptFunction.java ! src/jdk/nashorn/internal/runtime/ScriptFunctionData.java ! src/jdk/nashorn/internal/runtime/ScriptLoader.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/ScriptRuntime.java ! src/jdk/nashorn/internal/runtime/ScriptingFunctions.java ! src/jdk/nashorn/internal/runtime/SetMethodCreator.java ! src/jdk/nashorn/internal/runtime/StructureLoader.java ! src/jdk/nashorn/internal/runtime/WithObject.java ! src/jdk/nashorn/internal/runtime/arrays/EmptyArrayLikeIterator.java ! src/jdk/nashorn/internal/runtime/arrays/MapIterator.java ! src/jdk/nashorn/internal/runtime/linker/Bootstrap.java ! src/jdk/nashorn/internal/runtime/resources/parser.js + test/script/sandbox/nashorninternals.js ! test/script/trusted/JDK-8006529.js + test/src/jdk/nashorn/api/javaaccess/BooleanAccessTest.java + test/src/jdk/nashorn/api/javaaccess/MethodAccessTest.java + test/src/jdk/nashorn/api/javaaccess/NumberAccessTest.java + test/src/jdk/nashorn/api/javaaccess/NumberBoxingTest.java + test/src/jdk/nashorn/api/javaaccess/ObjectAccessTest.java + test/src/jdk/nashorn/api/javaaccess/Person.java + test/src/jdk/nashorn/api/javaaccess/SharedObject.java + test/src/jdk/nashorn/api/javaaccess/StringAccessTest.java - test/src/jdk/nashorn/internal/access/BooleanAccessTest.java - test/src/jdk/nashorn/internal/access/MethodAccessTest.java - test/src/jdk/nashorn/internal/access/NumberAccessTest.java - test/src/jdk/nashorn/internal/access/NumberBoxingTest.java - test/src/jdk/nashorn/internal/access/ObjectAccessTest.java - test/src/jdk/nashorn/internal/access/Person.java - test/src/jdk/nashorn/internal/access/SharedObject.java - test/src/jdk/nashorn/internal/access/StringAccessTest.java - test/src/jdk/nashorn/internal/codegen/CompilerAccess.java Changeset: 774a0f349cc0 Author: hannesw Date: 2013-02-12 13:55 +0100 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/774a0f349cc0 8007956: Wrong or obsolete system properties in docs/DEVELOPER_README Reviewed-by: attila, jlaskey ! docs/DEVELOPER_README Changeset: d50e1752f59b Author: attila Date: 2013-02-12 12:47 +0100 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/d50e1752f59b 8007900: Function binding is inefficient Reviewed-by: jlaskey, lagergren + src/jdk/nashorn/internal/objects/BoundScriptFunctionImpl.java ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeStrictArguments.java ! src/jdk/nashorn/internal/objects/ScriptFunctionImpl.java ! src/jdk/nashorn/internal/runtime/ArgumentSetter.java ! src/jdk/nashorn/internal/runtime/PropertyMap.java ! src/jdk/nashorn/internal/runtime/ScriptFunction.java ! src/jdk/nashorn/internal/runtime/ScriptFunctionData.java ! src/jdk/nashorn/internal/runtime/ScriptRuntime.java + src/jdk/nashorn/internal/runtime/SpecializedMethodChooser.java + test/script/basic/funcbind2.js + test/script/basic/funcbind2.js.EXPECTED + test/script/basic/funcbind3.js + test/script/basic/funcbind3.js.EXPECTED Changeset: a3dc1b180ce7 Author: hannesw Date: 2013-02-13 13:30 +0100 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/a3dc1b180ce7 8008096: TokenStream buffer should grow exponentially Reviewed-by: attila, lagergren, sundar ! src/jdk/nashorn/internal/parser/TokenStream.java Changeset: 38c44687e4bd Author: sundar Date: 2013-02-13 19:59 +0530 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/38c44687e4bd 8008103: Source object should maintain URL of the script source as a private field Reviewed-by: lagergren, jlaskey ! src/jdk/nashorn/api/scripting/NashornScriptEngine.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/Source.java ! src/jdk/nashorn/tools/Shell.java ! test/src/jdk/nashorn/internal/codegen/CompilerTest.java ! test/src/jdk/nashorn/internal/runtime/ContextTest.java ! test/src/jdk/nashorn/internal/test/framework/SharedContextEvaluator.java Changeset: 222b9f32b674 Author: sundar Date: 2013-02-14 09:14 +0530 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/222b9f32b674 8008193: test262 tests should be run with security manager enabled Reviewed-by: jlaskey ! make/build.xml Changeset: 8c72a2bec1be Author: sundar Date: 2013-02-14 14:16 +0530 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/8c72a2bec1be 8008197: Cross script engine function calls do not work as expected Reviewed-by: lagergren, hannesw ! src/jdk/nashorn/api/scripting/NashornScriptEngine.java ! src/jdk/nashorn/api/scripting/ScriptObjectMirror.java ! src/jdk/nashorn/internal/runtime/ScriptFunction.java ! src/jdk/nashorn/internal/runtime/ScriptRuntime.java + test/script/basic/JDK-8008197.js ! test/script/basic/jquery.js Changeset: 43e32b36153c Author: lagergren Date: 2013-02-14 13:01 +0100 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/43e32b36153c 8008199: Lazy compilation and trampoline implementation Summary: The code pipeline now supports lazy compilation, which can be used to only compile certain FunctionNodes and leave others be, saving startup time. When these uncompiled nodes are hit, a trampoline will force them to be recompiled. This can also be used to specialize compilation fixing parameter types and return types to a callsite specific compilation. This will give performance. Reviewed-by: attila, sundar ! src/jdk/nashorn/internal/codegen/Attr.java ! src/jdk/nashorn/internal/codegen/ClassEmitter.java ! src/jdk/nashorn/internal/codegen/CodeGenerator.java + src/jdk/nashorn/internal/codegen/CompilationPhase.java ! src/jdk/nashorn/internal/codegen/CompileUnit.java ! src/jdk/nashorn/internal/codegen/Compiler.java ! src/jdk/nashorn/internal/codegen/ConstantData.java ! src/jdk/nashorn/internal/codegen/FinalizeTypes.java ! src/jdk/nashorn/internal/codegen/FoldConstants.java ! src/jdk/nashorn/internal/codegen/FunctionSignature.java ! src/jdk/nashorn/internal/codegen/Lower.java ! src/jdk/nashorn/internal/codegen/SharedScopeCall.java ! src/jdk/nashorn/internal/codegen/Splitter.java ! src/jdk/nashorn/internal/codegen/WeighNodes.java - src/jdk/nashorn/internal/codegen/objects/FunctionObjectCreator.java ! src/jdk/nashorn/internal/codegen/objects/ObjectClassGenerator.java ! src/jdk/nashorn/internal/ir/FunctionNode.java ! src/jdk/nashorn/internal/ir/debug/JSONWriter.java ! src/jdk/nashorn/internal/ir/visitor/NodeVisitor.java ! src/jdk/nashorn/internal/objects/BoundScriptFunctionImpl.java ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeJava.java ! src/jdk/nashorn/internal/objects/ScriptFunctionImpl.java + src/jdk/nashorn/internal/objects/ScriptFunctionTrampolineImpl.java ! src/jdk/nashorn/internal/parser/Lexer.java ! src/jdk/nashorn/internal/parser/Parser.java ! src/jdk/nashorn/internal/runtime/CodeInstaller.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/DebugLogger.java ! src/jdk/nashorn/internal/runtime/FindProperty.java ! src/jdk/nashorn/internal/runtime/ScriptFunction.java ! src/jdk/nashorn/internal/runtime/ScriptFunctionData.java ! src/jdk/nashorn/internal/runtime/ScriptingFunctions.java ! src/jdk/nashorn/tools/Shell.java ! test/script/trusted/JDK-8006529.js ! test/src/jdk/nashorn/internal/parser/ParserTest.java ! test/src/jdk/nashorn/internal/test/framework/SharedContextEvaluator.java Changeset: 5a820fb11814 Author: attila Date: 2013-02-14 13:22 +0100 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/5a820fb11814 8008085: Integrate Dynalink source code into Nashorn codebase Reviewed-by: jlaskey, lagergren, sundar ! THIRD_PARTY_README ! make/build.xml ! make/nbproject/project.xml ! make/project.properties + src/jdk/internal/dynalink/CallSiteDescriptor.java + src/jdk/internal/dynalink/ChainedCallSite.java + src/jdk/internal/dynalink/DefaultBootstrapper.java + src/jdk/internal/dynalink/DynamicLinker.java + src/jdk/internal/dynalink/DynamicLinkerFactory.java + src/jdk/internal/dynalink/MonomorphicCallSite.java + src/jdk/internal/dynalink/NoSuchDynamicMethodException.java + src/jdk/internal/dynalink/RelinkableCallSite.java + src/jdk/internal/dynalink/beans/AbstractJavaLinker.java + src/jdk/internal/dynalink/beans/AccessibleMembersLookup.java + src/jdk/internal/dynalink/beans/ApplicableOverloadedMethods.java + src/jdk/internal/dynalink/beans/BeanIntrospector.java + src/jdk/internal/dynalink/beans/BeanLinker.java + src/jdk/internal/dynalink/beans/BeansLinker.java + src/jdk/internal/dynalink/beans/CheckRestrictedPackage.java + src/jdk/internal/dynalink/beans/CheckRestrictedPackageInternal.java + src/jdk/internal/dynalink/beans/ClassLinker.java + src/jdk/internal/dynalink/beans/ClassString.java + src/jdk/internal/dynalink/beans/DynamicMethod.java + src/jdk/internal/dynalink/beans/DynamicMethodLinker.java + src/jdk/internal/dynalink/beans/FacetIntrospector.java + src/jdk/internal/dynalink/beans/GuardedInvocationComponent.java + src/jdk/internal/dynalink/beans/MaximallySpecific.java + src/jdk/internal/dynalink/beans/OverloadedDynamicMethod.java + src/jdk/internal/dynalink/beans/OverloadedMethod.java + src/jdk/internal/dynalink/beans/RestrictedPackageTester.java + src/jdk/internal/dynalink/beans/SimpleDynamicMethod.java + src/jdk/internal/dynalink/beans/StaticClass.java + src/jdk/internal/dynalink/beans/StaticClassIntrospector.java + src/jdk/internal/dynalink/beans/StaticClassLinker.java + src/jdk/internal/dynalink/beans/messages.properties + src/jdk/internal/dynalink/beans/package.html + src/jdk/internal/dynalink/linker/ConversionComparator.java + src/jdk/internal/dynalink/linker/GuardedInvocation.java + src/jdk/internal/dynalink/linker/GuardingDynamicLinker.java + src/jdk/internal/dynalink/linker/GuardingTypeConverterFactory.java + src/jdk/internal/dynalink/linker/LinkRequest.java + src/jdk/internal/dynalink/linker/LinkerServices.java + src/jdk/internal/dynalink/linker/TypeBasedGuardingDynamicLinker.java + src/jdk/internal/dynalink/linker/package.html + src/jdk/internal/dynalink/package.html + src/jdk/internal/dynalink/support/AbstractCallSiteDescriptor.java + src/jdk/internal/dynalink/support/AbstractRelinkableCallSite.java + src/jdk/internal/dynalink/support/AutoDiscovery.java + src/jdk/internal/dynalink/support/Backport.java + src/jdk/internal/dynalink/support/BottomGuardingDynamicLinker.java + src/jdk/internal/dynalink/support/CallSiteDescriptorFactory.java + src/jdk/internal/dynalink/support/ClassMap.java + src/jdk/internal/dynalink/support/CompositeGuardingDynamicLinker.java + src/jdk/internal/dynalink/support/CompositeTypeBasedGuardingDynamicLinker.java + src/jdk/internal/dynalink/support/DefaultCallSiteDescriptor.java + src/jdk/internal/dynalink/support/Guards.java + src/jdk/internal/dynalink/support/LinkRequestImpl.java + src/jdk/internal/dynalink/support/LinkerServicesImpl.java + src/jdk/internal/dynalink/support/Lookup.java + src/jdk/internal/dynalink/support/LookupCallSiteDescriptor.java + src/jdk/internal/dynalink/support/NameCodec.java + src/jdk/internal/dynalink/support/NamedDynCallSiteDescriptor.java + src/jdk/internal/dynalink/support/RuntimeContextLinkRequestImpl.java + src/jdk/internal/dynalink/support/TypeConverterFactory.java + src/jdk/internal/dynalink/support/TypeUtilities.java + src/jdk/internal/dynalink/support/UnnamedDynCallSiteDescriptor.java + src/jdk/internal/dynalink/support/messages.properties + src/jdk/internal/dynalink/support/package.html ! src/jdk/nashorn/internal/codegen/Compiler.java ! src/jdk/nashorn/internal/codegen/MethodEmitter.java ! src/jdk/nashorn/internal/codegen/WeighNodes.java ! src/jdk/nashorn/internal/ir/Block.java ! src/jdk/nashorn/internal/ir/CallNode.java ! src/jdk/nashorn/internal/ir/Node.java ! src/jdk/nashorn/internal/ir/Symbol.java ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeBoolean.java ! src/jdk/nashorn/internal/objects/NativeJSAdapter.java ! src/jdk/nashorn/internal/objects/NativeJava.java ! src/jdk/nashorn/internal/objects/NativeJavaImporter.java ! src/jdk/nashorn/internal/objects/NativeNumber.java ! src/jdk/nashorn/internal/objects/NativeString.java ! src/jdk/nashorn/internal/parser/Lexer.java ! src/jdk/nashorn/internal/runtime/GlobalObject.java ! src/jdk/nashorn/internal/runtime/JSType.java ! src/jdk/nashorn/internal/runtime/NativeJavaPackage.java ! src/jdk/nashorn/internal/runtime/ScriptFunction.java ! src/jdk/nashorn/internal/runtime/ScriptLoader.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/ScriptRuntime.java ! src/jdk/nashorn/internal/runtime/SetMethodCreator.java ! src/jdk/nashorn/internal/runtime/StructureLoader.java ! src/jdk/nashorn/internal/runtime/Undefined.java ! src/jdk/nashorn/internal/runtime/WithObject.java ! src/jdk/nashorn/internal/runtime/linker/Bootstrap.java ! src/jdk/nashorn/internal/runtime/linker/JSObjectLinker.java ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterFactory.java ! src/jdk/nashorn/internal/runtime/linker/JavaArgumentConverters.java ! src/jdk/nashorn/internal/runtime/linker/LinkerCallSite.java ! src/jdk/nashorn/internal/runtime/linker/NashornBottomLinker.java ! src/jdk/nashorn/internal/runtime/linker/NashornCallSiteDescriptor.java ! src/jdk/nashorn/internal/runtime/linker/NashornLinker.java ! src/jdk/nashorn/internal/runtime/linker/NashornPrimitiveLinker.java ! src/jdk/nashorn/internal/runtime/linker/NashornStaticClassLinker.java ! src/jdk/nashorn/internal/runtime/linker/PrimitiveLookup.java ! src/jdk/nashorn/internal/runtime/options/Options.java ! test/script/sandbox/nashorninternals.js ! test/src/jdk/nashorn/api/scripting/ScriptEngineTest.java ! test/src/jdk/nashorn/internal/runtime/ContextTest.java ! test/src/jdk/nashorn/internal/runtime/JSTypeTest.java Changeset: d086c3eead6b Author: lagergren Date: 2013-02-14 13:52 +0100 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/d086c3eead6b 8008206: The allInteger case for SwitchNode generation in CodeGenerator assumes integer LITERALS only. Reviewed-by: sundar, jlaskey ! src/jdk/nashorn/internal/codegen/Attr.java ! src/jdk/nashorn/internal/codegen/CodeGenerator.java + test/script/basic/JDK-8008206.js + test/script/basic/JDK-8008206.js.EXPECTED Changeset: 3df0a0d62d60 Author: attila Date: 2013-02-14 13:51 +0100 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/3df0a0d62d60 8007990: No access to interface methods on a restricted class Reviewed-by: jlaskey, lagergren, sundar ! make/build.xml + test/script/basic/JDK-8007990.js + test/script/basic/JDK-8007990.js.EXPECTED Changeset: d1ce4e09e4ba Author: hannesw Date: 2013-02-14 14:07 +0100 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/d1ce4e09e4ba 8008198: java.lang.AssertionError: Invalid break target class jdk.nashorn.internal.ir.TryNode Reviewed-by: attila, jlaskey ! src/jdk/nashorn/internal/ir/LabelNode.java ! src/jdk/nashorn/internal/parser/Parser.java + test/script/basic/JDK-8008198.js + test/script/basic/JDK-8008198.js.EXPECTED Changeset: d41d7cf9ab8b Author: jlaskey Date: 2013-02-14 11:32 -0400 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/d41d7cf9ab8b 8008231: Fix build system to accommodate integration of dynalink Reviewed-by: jlaskey Contributed-by: james.laskey at oracle.com ! makefiles/BuildNashorn.gmk Changeset: 36065e5ea3d1 Author: hannesw Date: 2013-02-15 09:18 +0100 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/36065e5ea3d1 8008215: break in catch clause causes java.lang.VerifyError: Inconsistent stackmap Reviewed-by: jlaskey, lagergren ! src/jdk/nashorn/internal/parser/Parser.java + test/script/basic/JDK-8008215.js + test/script/basic/JDK-8008215.js.EXPECTED Changeset: e478708faa22 Author: lagergren Date: 2013-02-15 09:44 +0100 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/e478708faa22 8008239: Unpublicized parts of the code generator package that were only package internal. Reviewed-by: hannesw, attila ! src/jdk/nashorn/internal/codegen/BranchOptimizer.java ! src/jdk/nashorn/internal/codegen/ClassEmitter.java ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/codegen/CompilationPhase.java ! src/jdk/nashorn/internal/codegen/CompilerConstants.java + src/jdk/nashorn/internal/codegen/Condition.java + src/jdk/nashorn/internal/codegen/FieldObjectCreator.java ! src/jdk/nashorn/internal/codegen/FunctionSignature.java + src/jdk/nashorn/internal/codegen/Label.java + src/jdk/nashorn/internal/codegen/MapCreator.java ! src/jdk/nashorn/internal/codegen/MethodEmitter.java + src/jdk/nashorn/internal/codegen/ObjectClassGenerator.java + src/jdk/nashorn/internal/codegen/ObjectCreator.java ! src/jdk/nashorn/internal/codegen/SharedScopeCall.java ! src/jdk/nashorn/internal/codegen/Splitter.java - src/jdk/nashorn/internal/codegen/objects/FieldObjectCreator.java - src/jdk/nashorn/internal/codegen/objects/MapCreator.java - src/jdk/nashorn/internal/codegen/objects/ObjectClassGenerator.java - src/jdk/nashorn/internal/codegen/objects/ObjectCreator.java - src/jdk/nashorn/internal/codegen/objects/ObjectMapCreator.java ! src/jdk/nashorn/internal/codegen/types/BooleanType.java ! src/jdk/nashorn/internal/codegen/types/IntType.java ! src/jdk/nashorn/internal/codegen/types/LongType.java ! src/jdk/nashorn/internal/codegen/types/NumberType.java ! src/jdk/nashorn/internal/ir/AccessNode.java ! src/jdk/nashorn/internal/ir/BaseNode.java ! src/jdk/nashorn/internal/ir/Block.java ! src/jdk/nashorn/internal/ir/BreakNode.java ! src/jdk/nashorn/internal/ir/BreakableNode.java ! src/jdk/nashorn/internal/ir/CallNode.java ! src/jdk/nashorn/internal/ir/CaseNode.java ! src/jdk/nashorn/internal/ir/CatchNode.java ! src/jdk/nashorn/internal/ir/ContinueNode.java ! src/jdk/nashorn/internal/ir/IdentNode.java ! src/jdk/nashorn/internal/ir/IndexNode.java ! src/jdk/nashorn/internal/ir/LabelNode.java ! src/jdk/nashorn/internal/ir/LineNumberNode.java ! src/jdk/nashorn/internal/ir/ObjectNode.java ! src/jdk/nashorn/internal/ir/ReturnNode.java ! src/jdk/nashorn/internal/ir/SplitNode.java ! src/jdk/nashorn/internal/ir/SwitchNode.java ! src/jdk/nashorn/internal/ir/ThrowNode.java ! src/jdk/nashorn/internal/ir/TryNode.java ! src/jdk/nashorn/internal/ir/UnaryNode.java ! src/jdk/nashorn/internal/ir/WhileNode.java ! src/jdk/nashorn/internal/ir/WithNode.java ! src/jdk/nashorn/internal/objects/NativeRegExp.java ! src/jdk/nashorn/internal/objects/ScriptFunctionImpl.java ! src/jdk/nashorn/internal/runtime/AccessorProperty.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/ECMAException.java ! src/jdk/nashorn/internal/runtime/FindProperty.java ! src/jdk/nashorn/internal/runtime/Property.java ! src/jdk/nashorn/internal/runtime/Scope.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/ScriptRuntime.java ! src/jdk/nashorn/internal/runtime/SetMethodCreator.java ! src/jdk/nashorn/internal/runtime/StructureLoader.java Changeset: 757a49aaad02 Author: sundar Date: 2013-02-15 18:30 +0530 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/757a49aaad02 8008291: Add more tests for better coverage of objects, scripting and parser packages Reviewed-by: lagergren, jlaskey ! src/jdk/nashorn/internal/parser/AbstractParser.java ! src/jdk/nashorn/internal/parser/Scanner.java ! src/jdk/nashorn/internal/runtime/BitVector.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/QuotedStringTokenizer.java ! src/jdk/nashorn/internal/runtime/RegExpScanner.java ! src/jdk/nashorn/internal/runtime/Source.java ! src/jdk/nashorn/tools/Shell.java ! test/script/basic/NASHORN-401.js ! test/script/basic/NASHORN-401.js.EXPECTED + test/script/basic/assign_builtin_func_props.js + test/script/basic/debugger.js + test/script/basic/yield.js ! test/src/jdk/nashorn/api/scripting/MultipleEngineTest.java ! test/src/jdk/nashorn/api/scripting/ScriptEngineTest.java ! test/src/jdk/nashorn/api/scripting/Window.java ! test/src/jdk/nashorn/internal/parser/ParserTest.java Changeset: 5851c5dac260 Author: sundar Date: 2013-02-15 20:40 +0530 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/5851c5dac260 8008298: Add tests to cover specialized versions of Math functions. Reviewed-by: jlaskey, lagergren + test/script/basic/JDK-8008298.js Changeset: d5f74bd2dc20 Author: sundar Date: 2013-02-18 14:41 +0530 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/d5f74bd2dc20 8008305: ScriptEngine.eval should offer the ability to provide a codebase Reviewed-by: lagergren, hannesw, attila ! src/jdk/nashorn/api/scripting/NashornScriptEngine.java + src/jdk/nashorn/api/scripting/URLReader.java + test/script/trusted/JDK-8008305.js + test/script/trusted/JDK-8008305_subtest.js + test/script/trusted/urlreader.js Changeset: 3245e174fe3a Author: hannesw Date: 2013-02-18 10:36 +0100 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/3245e174fe3a 8008351: Avoid using String.replace(String, String) in codegen Reviewed-by: sundar, attila ! src/jdk/nashorn/internal/codegen/Condition.java ! src/jdk/nashorn/internal/codegen/RuntimeCallSite.java ! src/jdk/nashorn/internal/ir/RuntimeNode.java Changeset: f8221ce53c2e Author: attila Date: 2013-02-18 16:00 +0100 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/f8221ce53c2e 8008371: Fix Dynalink compiler warnings and whitespace Reviewed-by: jlaskey, sundar ! src/jdk/internal/dynalink/CallSiteDescriptor.java ! src/jdk/internal/dynalink/ChainedCallSite.java ! src/jdk/internal/dynalink/DefaultBootstrapper.java ! src/jdk/internal/dynalink/DynamicLinker.java ! src/jdk/internal/dynalink/DynamicLinkerFactory.java ! src/jdk/internal/dynalink/MonomorphicCallSite.java ! src/jdk/internal/dynalink/NoSuchDynamicMethodException.java ! src/jdk/internal/dynalink/RelinkableCallSite.java ! src/jdk/internal/dynalink/beans/AbstractJavaLinker.java ! src/jdk/internal/dynalink/beans/ApplicableOverloadedMethods.java ! src/jdk/internal/dynalink/beans/BeanLinker.java ! src/jdk/internal/dynalink/beans/BeansLinker.java ! src/jdk/internal/dynalink/beans/CheckRestrictedPackageInternal.java ! src/jdk/internal/dynalink/beans/ClassLinker.java ! src/jdk/internal/dynalink/beans/ClassString.java ! src/jdk/internal/dynalink/beans/DynamicMethod.java ! src/jdk/internal/dynalink/beans/DynamicMethodLinker.java ! src/jdk/internal/dynalink/beans/FacetIntrospector.java ! src/jdk/internal/dynalink/beans/GuardedInvocationComponent.java ! src/jdk/internal/dynalink/beans/MaximallySpecific.java ! src/jdk/internal/dynalink/beans/OverloadedDynamicMethod.java ! src/jdk/internal/dynalink/beans/OverloadedMethod.java ! src/jdk/internal/dynalink/beans/SimpleDynamicMethod.java ! src/jdk/internal/dynalink/beans/StaticClass.java ! src/jdk/internal/dynalink/beans/StaticClassLinker.java ! src/jdk/internal/dynalink/linker/GuardedInvocation.java ! src/jdk/internal/dynalink/linker/GuardingDynamicLinker.java ! src/jdk/internal/dynalink/linker/GuardingTypeConverterFactory.java ! src/jdk/internal/dynalink/linker/LinkRequest.java ! src/jdk/internal/dynalink/linker/LinkerServices.java ! src/jdk/internal/dynalink/support/AbstractCallSiteDescriptor.java ! src/jdk/internal/dynalink/support/AbstractRelinkableCallSite.java ! src/jdk/internal/dynalink/support/AutoDiscovery.java ! src/jdk/internal/dynalink/support/BottomGuardingDynamicLinker.java ! src/jdk/internal/dynalink/support/CallSiteDescriptorFactory.java ! src/jdk/internal/dynalink/support/CompositeGuardingDynamicLinker.java ! src/jdk/internal/dynalink/support/CompositeTypeBasedGuardingDynamicLinker.java ! src/jdk/internal/dynalink/support/DefaultCallSiteDescriptor.java ! src/jdk/internal/dynalink/support/Guards.java ! src/jdk/internal/dynalink/support/LinkRequestImpl.java ! src/jdk/internal/dynalink/support/LinkerServicesImpl.java ! src/jdk/internal/dynalink/support/Lookup.java ! src/jdk/internal/dynalink/support/LookupCallSiteDescriptor.java ! src/jdk/internal/dynalink/support/NamedDynCallSiteDescriptor.java ! src/jdk/internal/dynalink/support/RuntimeContextLinkRequestImpl.java ! src/jdk/internal/dynalink/support/TypeConverterFactory.java ! src/jdk/internal/dynalink/support/TypeUtilities.java ! src/jdk/internal/dynalink/support/UnnamedDynCallSiteDescriptor.java ! src/jdk/nashorn/internal/codegen/CompilationPhase.java ! src/jdk/nashorn/internal/codegen/FunctionSignature.java ! src/jdk/nashorn/internal/ir/FunctionNode.java ! src/jdk/nashorn/internal/objects/ScriptFunctionImpl.java ! src/jdk/nashorn/internal/objects/ScriptFunctionTrampolineImpl.java ! src/jdk/nashorn/internal/parser/Parser.java ! src/jdk/nashorn/internal/runtime/Context.java Changeset: 4738de1bd57f Author: sundar Date: 2013-02-18 20:41 +0530 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/4738de1bd57f 8008387: Improve code coverage tests for JSObjectLinker and NashornBottomLinker Reviewed-by: lagergren, jlaskey, hannesw ! src/jdk/internal/dynalink/beans/BeansLinker.java ! src/jdk/nashorn/internal/runtime/linker/NashornBottomLinker.java + test/script/basic/javamethodcallerrors.js + test/script/basic/jsobject.js Changeset: b6798a83dbd4 Author: jlaskey Date: 2013-02-19 09:46 -0400 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/b6798a83dbd4 8008420: Tweaks to make all NEWBUILD=false round 2 Reviewed-by: jjh Contributed-by: james.laskey at oracle.com ! make/Makefile Changeset: b228e3cdbfc3 Author: jlaskey Date: 2013-02-19 09:47 -0400 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/b228e3cdbfc3 Merge Changeset: b632446ba138 Author: sundar Date: 2013-02-19 20:33 +0530 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/b632446ba138 8008448: Add coverage test for jdk.nashorn.internal.ir.debug.JSONWriter Reviewed-by: jlaskey, attila ! src/jdk/nashorn/internal/ir/debug/JSONWriter.java + test/script/basic/JDK-8008448.js Changeset: 58eea0e8f369 Author: sundar Date: 2013-02-20 17:08 +0530 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/58eea0e8f369 8008207: Make constants array and source fields private Reviewed-by: hannesw, lagergren ! src/jdk/nashorn/internal/codegen/ClassEmitter.java ! src/jdk/nashorn/internal/codegen/Compiler.java Changeset: 671852e35ced Author: lagergren Date: 2013-02-20 16:43 +0100 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/671852e35ced 8008166: URL handling was broken on windows, causing "load" to malfunction Reviewed-by: attila, jlaskey Contributed-by: klara.ward at oracle.com ! make/build.xml ! src/jdk/nashorn/internal/runtime/Context.java Changeset: a971adb68f38 Author: lagergren Date: 2013-02-21 16:57 +0100 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/a971adb68f38 8008648: Lazy JIT scope and callee semantics bugfixes. Broke out wallclock timer. Reviewed-by: attila, hannesw ! src/jdk/internal/dynalink/beans/BeansLinker.java ! src/jdk/nashorn/internal/codegen/CodeGenerator.java + src/jdk/nashorn/internal/codegen/CompilationException.java ! src/jdk/nashorn/internal/codegen/CompilationPhase.java ! src/jdk/nashorn/internal/codegen/Compiler.java ! src/jdk/nashorn/internal/codegen/FinalizeTypes.java ! src/jdk/nashorn/internal/codegen/Lower.java ! src/jdk/nashorn/internal/codegen/MethodEmitter.java ! src/jdk/nashorn/internal/codegen/Splitter.java ! src/jdk/nashorn/internal/ir/FunctionNode.java ! src/jdk/nashorn/internal/ir/TernaryNode.java ! src/jdk/nashorn/internal/objects/ScriptFunctionTrampolineImpl.java ! src/jdk/nashorn/internal/parser/Parser.java ! src/jdk/nashorn/internal/runtime/NashornLoader.java ! src/jdk/nashorn/internal/runtime/ScriptingFunctions.java + src/jdk/nashorn/internal/runtime/Timing.java ! test/script/trusted/JDK-8006529.js Changeset: ae1c9716685b Author: jlaskey Date: 2013-02-21 15:24 -0400 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/ae1c9716685b 8008447: Tweaks to make all NEWBUILD=false round 3 Reviewed-by: jjh, sundar Contributed-by: james.laskey at oracle.com ! make/Makefile Changeset: 678da59a29b3 Author: lagergren Date: 2013-02-22 08:57 +0100 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/678da59a29b3 8008554: load was broken for URLs Reviewed-by: attila, sundar ! src/jdk/nashorn/internal/runtime/Context.java + test/script/basic/JDK-8008554.js Changeset: 230a711062c1 Author: lagergren Date: 2013-02-22 11:27 +0100 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/230a711062c1 8008575: Re-integrate code coverage Reviewed-by: attila, hannesw Contributed-by: eugene.drobitko at oracle.com, ilya.dergalin at oracle.com ! make/build.xml + make/code_coverage.xml ! make/project.properties Changeset: 267cc4c85160 Author: lagergren Date: 2013-02-22 12:22 +0100 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/267cc4c85160 8007002: Replace implicit exception throwing methods with explicit throws - simplify control flow and remove useless code Reviewed-by: attila, hannesw ! src/jdk/nashorn/api/scripting/NashornException.java ! src/jdk/nashorn/api/scripting/NashornScriptEngine.java ! src/jdk/nashorn/api/scripting/URLReader.java ! src/jdk/nashorn/internal/objects/AccessorPropertyDescriptor.java ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeArguments.java ! src/jdk/nashorn/internal/objects/NativeArray.java ! src/jdk/nashorn/internal/objects/NativeBoolean.java ! src/jdk/nashorn/internal/objects/NativeDate.java ! src/jdk/nashorn/internal/objects/NativeError.java ! src/jdk/nashorn/internal/objects/NativeFunction.java ! src/jdk/nashorn/internal/objects/NativeJSAdapter.java ! src/jdk/nashorn/internal/objects/NativeJSON.java ! src/jdk/nashorn/internal/objects/NativeJava.java ! src/jdk/nashorn/internal/objects/NativeNumber.java ! src/jdk/nashorn/internal/objects/NativeObject.java ! src/jdk/nashorn/internal/objects/NativeRegExp.java ! src/jdk/nashorn/internal/objects/NativeString.java ! src/jdk/nashorn/internal/parser/AbstractParser.java ! src/jdk/nashorn/internal/parser/Lexer.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/ECMAErrors.java ! src/jdk/nashorn/internal/runtime/ECMAException.java ! src/jdk/nashorn/internal/runtime/ErrorManager.java ! src/jdk/nashorn/internal/runtime/JSONFunctions.java ! src/jdk/nashorn/internal/runtime/JSType.java ! src/jdk/nashorn/internal/runtime/ParserException.java ! src/jdk/nashorn/internal/runtime/ScriptFunction.java ! src/jdk/nashorn/internal/runtime/ScriptFunctionData.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/ScriptRuntime.java ! src/jdk/nashorn/internal/runtime/ScriptingFunctions.java ! src/jdk/nashorn/internal/runtime/SetMethodCreator.java ! src/jdk/nashorn/internal/runtime/URIUtils.java ! src/jdk/nashorn/internal/runtime/Undefined.java ! src/jdk/nashorn/internal/runtime/arrays/FrozenArrayFilter.java ! src/jdk/nashorn/internal/runtime/arrays/IteratorAction.java ! src/jdk/nashorn/internal/runtime/arrays/SealedArrayFilter.java ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterFactory.java ! src/jdk/nashorn/internal/runtime/linker/JavaArgumentConverters.java ! src/jdk/nashorn/internal/runtime/linker/Lookup.java ! src/jdk/nashorn/internal/runtime/linker/NashornBottomLinker.java ! src/jdk/nashorn/internal/runtime/linker/NashornStaticClassLinker.java Changeset: 3f0ff84aaf36 Author: jlaskey Date: 2013-02-22 10:39 -0400 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/3f0ff84aaf36 8008721: Tweaks to make all NEWBUILD=false round 4 Reviewed-by: jjh Contributed-by: james.laskey at oracle.com ! makefiles/BuildNashorn.gmk Changeset: 508da3c7fc3a Author: hannesw Date: 2013-02-22 16:31 +0100 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/508da3c7fc3a 8008093: Make RegExp engine pluggable Reviewed-by: lagergren, attila ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeRegExp.java ! src/jdk/nashorn/internal/objects/NativeRegExpExecResult.java ! src/jdk/nashorn/internal/objects/NativeString.java ! src/jdk/nashorn/internal/parser/AbstractParser.java - src/jdk/nashorn/internal/runtime/RegExp.java - src/jdk/nashorn/internal/runtime/RegExpMatch.java - src/jdk/nashorn/internal/runtime/RegExpScanner.java + src/jdk/nashorn/internal/runtime/regexp/DefaultRegExp.java + src/jdk/nashorn/internal/runtime/regexp/RegExp.java + src/jdk/nashorn/internal/runtime/regexp/RegExpFactory.java + src/jdk/nashorn/internal/runtime/regexp/RegExpMatcher.java + src/jdk/nashorn/internal/runtime/regexp/RegExpResult.java + src/jdk/nashorn/internal/runtime/regexp/RegExpScanner.java Changeset: e42fd1640ff9 Author: hannesw Date: 2013-02-22 17:00 +0100 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/e42fd1640ff9 8006028: Integrate Joni regexp engine with Nashorn Reviewed-by: lagergren, attila ! THIRD_PARTY_README ! docs/DEVELOPER_README + src/jdk/nashorn/internal/runtime/regexp/JoniRegExp.java ! src/jdk/nashorn/internal/runtime/regexp/RegExpFactory.java + src/jdk/nashorn/internal/runtime/regexp/joni/Analyser.java + src/jdk/nashorn/internal/runtime/regexp/joni/ApplyCaseFold.java + src/jdk/nashorn/internal/runtime/regexp/joni/ApplyCaseFoldArg.java + src/jdk/nashorn/internal/runtime/regexp/joni/ArrayCompiler.java + src/jdk/nashorn/internal/runtime/regexp/joni/AsmCompiler.java + src/jdk/nashorn/internal/runtime/regexp/joni/AsmCompilerSupport.java + src/jdk/nashorn/internal/runtime/regexp/joni/BitSet.java + src/jdk/nashorn/internal/runtime/regexp/joni/BitStatus.java + src/jdk/nashorn/internal/runtime/regexp/joni/ByteCodeMachine.java + src/jdk/nashorn/internal/runtime/regexp/joni/ByteCodePrinter.java + src/jdk/nashorn/internal/runtime/regexp/joni/CaptureTreeNode.java + src/jdk/nashorn/internal/runtime/regexp/joni/CodeRangeBuffer.java + src/jdk/nashorn/internal/runtime/regexp/joni/Compiler.java + src/jdk/nashorn/internal/runtime/regexp/joni/Config.java + src/jdk/nashorn/internal/runtime/regexp/joni/EncodingHelper.java + src/jdk/nashorn/internal/runtime/regexp/joni/Lexer.java + src/jdk/nashorn/internal/runtime/regexp/joni/Matcher.java + src/jdk/nashorn/internal/runtime/regexp/joni/MatcherFactory.java + src/jdk/nashorn/internal/runtime/regexp/joni/MinMaxLen.java + src/jdk/nashorn/internal/runtime/regexp/joni/NameEntry.java + src/jdk/nashorn/internal/runtime/regexp/joni/NativeMachine.java + src/jdk/nashorn/internal/runtime/regexp/joni/NodeOptInfo.java + src/jdk/nashorn/internal/runtime/regexp/joni/OptAnchorInfo.java + src/jdk/nashorn/internal/runtime/regexp/joni/OptEnvironment.java + src/jdk/nashorn/internal/runtime/regexp/joni/OptExactInfo.java + src/jdk/nashorn/internal/runtime/regexp/joni/OptMapInfo.java + src/jdk/nashorn/internal/runtime/regexp/joni/Option.java + src/jdk/nashorn/internal/runtime/regexp/joni/Parser.java + src/jdk/nashorn/internal/runtime/regexp/joni/Regex.java + src/jdk/nashorn/internal/runtime/regexp/joni/Region.java + src/jdk/nashorn/internal/runtime/regexp/joni/ScanEnvironment.java + src/jdk/nashorn/internal/runtime/regexp/joni/ScannerSupport.java + src/jdk/nashorn/internal/runtime/regexp/joni/SearchAlgorithm.java + src/jdk/nashorn/internal/runtime/regexp/joni/StackEntry.java + src/jdk/nashorn/internal/runtime/regexp/joni/StackMachine.java + src/jdk/nashorn/internal/runtime/regexp/joni/Syntax.java + src/jdk/nashorn/internal/runtime/regexp/joni/Token.java + src/jdk/nashorn/internal/runtime/regexp/joni/UnsetAddrList.java + src/jdk/nashorn/internal/runtime/regexp/joni/WarnCallback.java + src/jdk/nashorn/internal/runtime/regexp/joni/Warnings.java + src/jdk/nashorn/internal/runtime/regexp/joni/ast/AnchorNode.java + src/jdk/nashorn/internal/runtime/regexp/joni/ast/AnyCharNode.java + src/jdk/nashorn/internal/runtime/regexp/joni/ast/BackRefNode.java + src/jdk/nashorn/internal/runtime/regexp/joni/ast/CClassNode.java + src/jdk/nashorn/internal/runtime/regexp/joni/ast/CTypeNode.java + src/jdk/nashorn/internal/runtime/regexp/joni/ast/CallNode.java + src/jdk/nashorn/internal/runtime/regexp/joni/ast/ConsAltNode.java + src/jdk/nashorn/internal/runtime/regexp/joni/ast/EncloseNode.java + src/jdk/nashorn/internal/runtime/regexp/joni/ast/Node.java + src/jdk/nashorn/internal/runtime/regexp/joni/ast/QuantifierNode.java + src/jdk/nashorn/internal/runtime/regexp/joni/ast/StateNode.java + src/jdk/nashorn/internal/runtime/regexp/joni/ast/StringNode.java + src/jdk/nashorn/internal/runtime/regexp/joni/bench/AbstractBench.java + src/jdk/nashorn/internal/runtime/regexp/joni/bench/BenchGreedyBacktrack.java + src/jdk/nashorn/internal/runtime/regexp/joni/bench/BenchRailsRegs.java + src/jdk/nashorn/internal/runtime/regexp/joni/bench/BenchSeveralRegexps.java + src/jdk/nashorn/internal/runtime/regexp/joni/constants/AnchorType.java + src/jdk/nashorn/internal/runtime/regexp/joni/constants/Arguments.java + src/jdk/nashorn/internal/runtime/regexp/joni/constants/AsmConstants.java + src/jdk/nashorn/internal/runtime/regexp/joni/constants/CCSTATE.java + src/jdk/nashorn/internal/runtime/regexp/joni/constants/CCVALTYPE.java + src/jdk/nashorn/internal/runtime/regexp/joni/constants/EncloseType.java + src/jdk/nashorn/internal/runtime/regexp/joni/constants/MetaChar.java + src/jdk/nashorn/internal/runtime/regexp/joni/constants/NodeStatus.java + src/jdk/nashorn/internal/runtime/regexp/joni/constants/NodeType.java + src/jdk/nashorn/internal/runtime/regexp/joni/constants/OPCode.java + src/jdk/nashorn/internal/runtime/regexp/joni/constants/OPSize.java + src/jdk/nashorn/internal/runtime/regexp/joni/constants/Reduce.java + src/jdk/nashorn/internal/runtime/regexp/joni/constants/RegexState.java + src/jdk/nashorn/internal/runtime/regexp/joni/constants/StackPopLevel.java + src/jdk/nashorn/internal/runtime/regexp/joni/constants/StackType.java + src/jdk/nashorn/internal/runtime/regexp/joni/constants/StringType.java + src/jdk/nashorn/internal/runtime/regexp/joni/constants/SyntaxProperties.java + src/jdk/nashorn/internal/runtime/regexp/joni/constants/TargetInfo.java + src/jdk/nashorn/internal/runtime/regexp/joni/constants/TokenType.java + src/jdk/nashorn/internal/runtime/regexp/joni/constants/Traverse.java + src/jdk/nashorn/internal/runtime/regexp/joni/encoding/AsciiTables.java + src/jdk/nashorn/internal/runtime/regexp/joni/encoding/CharacterType.java + src/jdk/nashorn/internal/runtime/regexp/joni/encoding/IntHolder.java + src/jdk/nashorn/internal/runtime/regexp/joni/encoding/ObjPtr.java + src/jdk/nashorn/internal/runtime/regexp/joni/encoding/PosixBracket.java + src/jdk/nashorn/internal/runtime/regexp/joni/encoding/Ptr.java + src/jdk/nashorn/internal/runtime/regexp/joni/exception/ErrorMessages.java + src/jdk/nashorn/internal/runtime/regexp/joni/exception/InternalException.java + src/jdk/nashorn/internal/runtime/regexp/joni/exception/JOniException.java + src/jdk/nashorn/internal/runtime/regexp/joni/exception/SyntaxException.java + src/jdk/nashorn/internal/runtime/regexp/joni/exception/ValueException.java Changeset: 7f5b7c6859d7 Author: sundar Date: 2013-02-22 22:39 +0530 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/7f5b7c6859d7 8008729: Make sure that we can run basic jsr223 tests using jtreg Reviewed-by: jlaskey, hannesw, lagergren + test/TEST.ROOT ! test/src/jdk/nashorn/api/scripting/MultipleEngineTest.java + test/src/jdk/nashorn/api/scripting/ScriptEngineSecurityTest.java ! test/src/jdk/nashorn/api/scripting/ScriptEngineTest.java Changeset: 5452f82eb2ce Author: jlaskey Date: 2013-02-22 23:33 -0400 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/5452f82eb2ce 8008776: Revise BuildNashorn.gmk for changes in new build system Reviewed-by: jjh Contributed-by: james.laskey at oracle.com ! makefiles/BuildNashorn.gmk Changeset: 927fba6785b0 Author: sundar Date: 2013-02-25 16:58 +0530 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/927fba6785b0 8008731: Separate configuration environment (options, error/output writer etc.) from Context Reviewed-by: hannesw, lagergren ! src/jdk/nashorn/internal/codegen/Attr.java ! src/jdk/nashorn/internal/codegen/ClassEmitter.java ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/codegen/CompilationPhase.java ! src/jdk/nashorn/internal/codegen/Compiler.java ! src/jdk/nashorn/internal/codegen/MethodEmitter.java ! src/jdk/nashorn/internal/codegen/ObjectClassGenerator.java ! src/jdk/nashorn/internal/ir/debug/JSONWriter.java ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeDate.java ! src/jdk/nashorn/internal/objects/NativeString.java ! src/jdk/nashorn/internal/objects/ScriptFunctionTrampolineImpl.java ! src/jdk/nashorn/internal/parser/Parser.java ! src/jdk/nashorn/internal/runtime/CodeInstaller.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/JSONFunctions.java - src/jdk/nashorn/internal/runtime/OptionsObject.java + src/jdk/nashorn/internal/runtime/ScriptEnvironment.java ! src/jdk/nashorn/internal/runtime/ScriptRuntime.java ! src/jdk/nashorn/tools/Shell.java ! test/script/trusted/JDK-8006529.js ! test/src/jdk/nashorn/internal/parser/ParserTest.java ! test/src/jdk/nashorn/internal/test/framework/SharedContextEvaluator.java Changeset: 5610ac25d8ff Author: sundar Date: 2013-02-25 18:13 +0530 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/5610ac25d8ff 8008789: Enable java access and nashorn runtime tests for jtreg Reviewed-by: lagergren, jlaskey, hannesw ! make/build.xml ! test/TEST.ROOT ! test/src/jdk/nashorn/api/javaaccess/BooleanAccessTest.java ! test/src/jdk/nashorn/api/javaaccess/MethodAccessTest.java ! test/src/jdk/nashorn/api/javaaccess/NumberAccessTest.java ! test/src/jdk/nashorn/api/javaaccess/NumberBoxingTest.java ! test/src/jdk/nashorn/api/javaaccess/ObjectAccessTest.java ! test/src/jdk/nashorn/api/javaaccess/StringAccessTest.java ! test/src/jdk/nashorn/internal/runtime/ContextTest.java ! test/src/jdk/nashorn/internal/runtime/JSTypeTest.java + test/src/jdk/nashorn/internal/runtime/TrustedScriptEngineTest.java Changeset: 1654918e0612 Author: attila Date: 2013-02-25 16:51 +0100 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/1654918e0612 8006984: Introducing local into a function inside with statement confuses its scope Reviewed-by: jlaskey, lagergren, sundar ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/WithObject.java + test/script/basic/JDK-8006984.js + test/script/basic/JDK-8006984.js.EXPECTED Changeset: a90094ae5be3 Author: sundar Date: 2013-02-26 22:57 +0530 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/a90094ae5be3 8009021: nasgen should be run on boot jdk rather than currenly built jdk Reviewed-by: jlaskey ! makefiles/BuildNashorn.gmk Changeset: 1d3dca059b3e Author: alanb Date: 2013-02-27 14:12 +0000 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/1d3dca059b3e 8008950: jdk8/tl failing with SetupJavaCompilation BUILD_NASGEN contains missing directory -c on Windows Reviewed-by: chegar, sundar ! makefiles/BuildNashorn.gmk Changeset: 071e859b371e Author: attila Date: 2013-02-27 15:20 +0100 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/071e859b371e 8009143: Eliminate Dynalink dependency on java.beans Reviewed-by: jlaskey, lagergren, sundar ! src/jdk/internal/dynalink/beans/AbstractJavaLinker.java ! src/jdk/internal/dynalink/beans/BeansLinker.java Changeset: 928ea3d8faf0 Author: attila Date: 2013-02-27 15:49 +0100 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/928ea3d8faf0 8009146: Eliminate some dead code in preparation for immutable AST Reviewed-by: hannesw, lagergren ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/ir/Assignment.java ! src/jdk/nashorn/internal/ir/UnaryNode.java ! src/jdk/nashorn/internal/ir/VarNode.java ! src/jdk/nashorn/internal/runtime/linker/NashornCallSiteDescriptor.java Changeset: 1da9e37697f6 Author: attila Date: 2013-02-27 16:25 +0100 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/1da9e37697f6 8009150: Previous dead code elimination was incomplete Reviewed-by: hannesw, lagergren ! src/jdk/nashorn/internal/ir/BinaryNode.java Changeset: 1e03be240534 Author: sundar Date: 2013-02-28 20:31 +0530 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/1e03be240534 8009229: ant makefile default target should be "test" Reviewed-by: lagergren, jlaskey ! make/build.xml Changeset: 037e1de7ab1a Author: hannesw Date: 2013-02-28 22:59 +0100 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/037e1de7ab1a 8009240: RegExpScanner code is inefficient and too complex Reviewed-by: jlaskey, lagergren ! src/jdk/nashorn/internal/runtime/regexp/JoniRegExp.java ! src/jdk/nashorn/internal/runtime/regexp/RegExpFactory.java ! src/jdk/nashorn/internal/runtime/regexp/RegExpScanner.java Changeset: 7e9fbe621d87 Author: sundar Date: 2013-03-01 15:58 +0530 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/7e9fbe621d87 8009263: Fix all javadoc errors in nashorn code Reviewed-by: hannesw, lagergren ! make/project.properties ! src/jdk/nashorn/internal/codegen/ClassEmitter.java ! src/jdk/nashorn/internal/codegen/ObjectClassGenerator.java ! src/jdk/nashorn/internal/codegen/RuntimeCallSite.java ! src/jdk/nashorn/internal/ir/RuntimeNode.java ! src/jdk/nashorn/internal/ir/visitor/NodeOperatorVisitor.java ! src/jdk/nashorn/internal/objects/DateParser.java ! src/jdk/nashorn/internal/objects/NativeJSAdapter.java ! src/jdk/nashorn/internal/objects/NativeJava.java ! src/jdk/nashorn/internal/runtime/CodeInstaller.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/ScriptRuntime.java ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterFactory.java ! src/jdk/nashorn/internal/runtime/linker/NashornCallSiteDescriptor.java ! src/jdk/nashorn/internal/runtime/options/Options.java ! src/jdk/nashorn/internal/runtime/regexp/joni/EncodingHelper.java Changeset: 3b222c90b7de Author: jlaskey Date: 2013-03-02 11:26 -0400 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/3b222c90b7de Merge Changeset: f90810d79b57 Author: hannesw Date: 2013-03-04 11:44 +0100 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/f90810d79b57 8008370: coffee script compiler doesn't work with Nashorn Reviewed-by: lagergren, attila ! src/jdk/nashorn/internal/runtime/regexp/RegExpScanner.java + test/script/basic/JDK-8008370.js + test/script/basic/JDK-8008370.js.EXPECTED Changeset: fe5211fc3114 Author: jlaskey Date: 2013-03-04 11:01 -0400 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/fe5211fc3114 8009379: Remove $ from generated class names Reviewed-by: attila, lagergren Contributed-by: james.laskey at oracle.com ! src/jdk/nashorn/internal/codegen/ClassEmitter.java ! src/jdk/nashorn/internal/codegen/Compiler.java ! src/jdk/nashorn/internal/codegen/CompilerConstants.java ! src/jdk/nashorn/internal/codegen/MapCreator.java ! src/jdk/nashorn/internal/codegen/ObjectCreator.java ! src/jdk/nashorn/internal/ir/Symbol.java ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeJSAdapter.java ! src/jdk/nashorn/internal/runtime/AccessorProperty.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/ECMAErrors.java ! src/jdk/nashorn/internal/runtime/PropertyMap.java - src/jdk/nashorn/internal/scripts/JO$.java + src/jdk/nashorn/internal/scripts/JO.java - src/jdk/nashorn/internal/scripts/JS$.java + src/jdk/nashorn/internal/scripts/JS.java Changeset: 3d57f57acd9c Author: sundar Date: 2013-03-06 22:38 +0530 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/3d57f57acd9c 8009553: Object.create(Array.prototype) doesn't respect reset length Reviewed-by: jlaskey, lagergren ! src/jdk/nashorn/internal/objects/Global.java + test/script/basic/JDK-8009553.js Changeset: 5759f600fcf7 Author: sundar Date: 2013-03-09 21:49 +0530 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/5759f600fcf7 8009559: clean up method handle lookup code. Reviewed-by: ahgross, jlaskey, attila, sundar ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/StringConstants.java ! make/java.security.override ! src/jdk/internal/dynalink/beans/CheckRestrictedPackage.java - src/jdk/internal/dynalink/beans/CheckRestrictedPackageInternal.java ! src/jdk/internal/dynalink/beans/FacetIntrospector.java - src/jdk/internal/dynalink/beans/RestrictedPackageTester.java + src/jdk/internal/dynalink/beans/SafeUnreflector.java + src/jdk/internal/dynalink/beans/SafeUnreflectorImpl.java + src/jdk/internal/dynalink/beans/SandboxClassLoader.java ! src/jdk/internal/dynalink/beans/StaticClassLinker.java + src/jdk/internal/dynalink/beans/sandbox/Unreflector.java ! src/jdk/nashorn/internal/codegen/CompilerConstants.java ! src/jdk/nashorn/internal/codegen/FunctionSignature.java ! src/jdk/nashorn/internal/codegen/ObjectClassGenerator.java ! src/jdk/nashorn/internal/codegen/RuntimeCallSite.java + src/jdk/nashorn/internal/lookup/Lookup.java + src/jdk/nashorn/internal/lookup/MethodHandleFactory.java + src/jdk/nashorn/internal/lookup/MethodHandleFunctionality.java ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeArguments.java ! src/jdk/nashorn/internal/objects/NativeBoolean.java ! src/jdk/nashorn/internal/objects/NativeError.java ! src/jdk/nashorn/internal/objects/NativeJSAdapter.java ! src/jdk/nashorn/internal/objects/NativeNumber.java ! src/jdk/nashorn/internal/objects/NativeStrictArguments.java ! src/jdk/nashorn/internal/objects/NativeString.java ! src/jdk/nashorn/internal/objects/PrototypeObject.java ! src/jdk/nashorn/internal/objects/ScriptFunctionImpl.java ! src/jdk/nashorn/internal/objects/ScriptFunctionTrampolineImpl.java ! src/jdk/nashorn/internal/runtime/AccessorProperty.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/FindProperty.java ! src/jdk/nashorn/internal/runtime/GlobalFunctions.java ! src/jdk/nashorn/internal/runtime/ScriptFunction.java ! src/jdk/nashorn/internal/runtime/ScriptFunctionData.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/ScriptingFunctions.java ! src/jdk/nashorn/internal/runtime/SetMethodCreator.java ! src/jdk/nashorn/internal/runtime/SpillProperty.java ! src/jdk/nashorn/internal/runtime/Undefined.java ! src/jdk/nashorn/internal/runtime/UserAccessorProperty.java ! src/jdk/nashorn/internal/runtime/WithObject.java ! src/jdk/nashorn/internal/runtime/linker/JSObjectLinker.java ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterFactory.java ! src/jdk/nashorn/internal/runtime/linker/JavaArgumentConverters.java ! src/jdk/nashorn/internal/runtime/linker/LinkerCallSite.java - src/jdk/nashorn/internal/runtime/linker/Lookup.java - src/jdk/nashorn/internal/runtime/linker/MethodHandleFactory.java - src/jdk/nashorn/internal/runtime/linker/MethodHandleFunctionality.java ! src/jdk/nashorn/internal/runtime/linker/NashornBottomLinker.java ! src/jdk/nashorn/internal/runtime/linker/NashornGuards.java ! src/jdk/nashorn/internal/runtime/linker/NashornLinker.java ! src/jdk/nashorn/internal/runtime/linker/NashornPrimitiveLinker.java ! src/jdk/nashorn/internal/runtime/linker/NashornStaticClassLinker.java ! src/jdk/nashorn/internal/runtime/linker/PrimitiveLookup.java + test/script/currently-failing/JDK-8006529.js - test/script/trusted/JDK-8006529.js From david.katleman at oracle.com Mon Mar 18 19:03:03 2013 From: david.katleman at oracle.com (David Katleman) Date: Mon, 18 Mar 2013 12:03:03 -0700 Subject: Empty jdk8/build/nashorn repository In-Reply-To: <243914179.20464042.1363629261446.JavaMail.root@redhat.com> References: <243914179.20464042.1363629261446.JavaMail.root@redhat.com> Message-ID: <514764E7.1010107@oracle.com> On 3/18/2013 10:54 AM, Andrew Hughes wrote: > ----- Original Message ----- >> Hi, >> >> The repository at http://hg.openjdk.java.net/jdk8/build/nashorn is >> empty >> with no changesets. Now the build fails (on 'make all') with an >> error: >> >> ## Starting nashorn >> /bin/sh: line 0: cd: /home/omajid/devel/jdk8-build/nashorn/makefiles: >> No >> such file or directory >> make: *** [nashorn-only] Error 1 >> >> Is this expected? >> > Yes & no: > > http://mail.openjdk.java.net/pipermail/jdk8-dev/2013-February/002065.html > *Jim Laskey (Oracle)* james.laskey at oracle.com > > > It is our intent to merge the nashorn forest into TL by EOB Friday Feb 22, 2013. This will allow nashorn to be promoted to master on March 5. If the nashorn repo is missing from your forest the build should still work correctly. No new tools or libraries are required. Nashorn is pure Java, all sources in house. Apparently it's not entirely true that if nashorn is missing the build should still work. I've sync'd up the nashorn changes into the build forest. Try again. Dave From david.holmes at oracle.com Mon Mar 18 19:59:25 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 19 Mar 2013 05:59:25 +1000 Subject: RFR: 8009426 "profiles" target fails due to nashorn if "images" is not built first Message-ID: <5147721D.8040309@oracle.com> Very simple fix/cleanup. webrev: http://cr.openjdk.java.net/~dholmes/8009426/webrev/ nashorn.jar was being added to the set of JARS targets regardless of what was being built, but nashorn is not a dependency for profiles target. JARS is not used the way it used to be now we have profiles and all jar files should simply be listed in the appropriate entry in profiles-includes.txt. There was a couple of other misplaced items too: makefiles/CreateJars.gmk Removed nashorn and tzdb setting of JARS makefiles/Profiles.gmk Removed redundant listing of cldrdata.jar makefiles/profile-includes.txt Add nashorn to full JRE lists Thanks, David From gnu.andrew at redhat.com Mon Mar 18 19:42:01 2013 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Mon, 18 Mar 2013 15:42:01 -0400 (EDT) Subject: New official README-builds.html In-Reply-To: Message-ID: <748388175.20529364.1363635721554.JavaMail.root@redhat.com> ----- Original Message ----- > 2013/3/18 Andrew Hughes : > > > > > Depends how many distros you intend to support. > > Well, I guess that if somebody doesn't use one between > rhel/fedora/suse/ubuntu/mint/debian than most likely will figure out > the exact commands anyway, I think those are still good suggestions > to > keep around. > I don't believe I ever suggested getting rid of them. I was just pointing out that their utility was limited. The fact configure doesn't fail with Xrender.h is missing is more problematic. > Cheers, > Mario > > -- > pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF > Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF > > IcedRobot: www.icedrobot.org > Proud GNU Classpath developer: http://www.classpath.org/ > Read About us at: http://planet.classpath.org > OpenJDK: http://openjdk.java.net/projects/caciocavallo/ > > Please, support open standards: > http://endsoftpatents.org/ > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From omajid at redhat.com Mon Mar 18 20:39:18 2013 From: omajid at redhat.com (Omair Majid) Date: Mon, 18 Mar 2013 16:39:18 -0400 Subject: Fix x11 header check (was: Re: New official README-builds.html) In-Reply-To: <51437CA8.20406@redhat.com> References: <1889117016.19471000.1363370700860.JavaMail.root@redhat.com> <51437CA8.20406@redhat.com> Message-ID: <51477B76.6030605@redhat.com> On 03/15/2013 03:55 PM, Omair Majid wrote: > In file included from > /builddir/build/BUILD/java-1.8.0-openjdk/jdk8/build/jdk8.build/jdk/gensrc_x11wrappers/sizer.64.c:11:0: > /builddir/build/BUILD/java-1.8.0-openjdk/jdk8/jdk/src/solaris/native/sun/awt/awt_p.h:51:36: > fatal error: X11/extensions/Xrender.h: No such file or directory > #include So this one turns out to be a bug in how we use AC_CHECK_HEADERS. If I remove the package that provides this header file on my machine, configure tells me that the header is missing but does not indicate an error: checking for IceConnectionNumber in -lICE... yes checking for X11/extensions/shape.h... yes checking for X11/extensions/Xrender.h... no checking for X11/extensions/XTest.h... yes checking cups/cups.h usability... yes checking cups/cups.h presence... yes The documentation for AC_CHECK_HEADERS [1] states: """ If action-if-found is given, it is additional shell code to execute when one of the header files is found """ So what happens is that as long as the last header in the list [X11/extensions/shape.h X11/extensions/Xrender.h X11/extensions/XTest.h] is found, X11_A_OK is set to "yes", and the build continues. A one-line fix is: http://cr.openjdk.java.net/~omajid/webrevs/x11-header-check/00/ Thanks, Omair [1] http://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.69/html_node/Generic-Headers.html -- PGP Key: 66484681 (http://pgp.mit.edu/) Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 From bradford.wetmore at oracle.com Tue Mar 19 01:29:45 2013 From: bradford.wetmore at oracle.com (Brad Wetmore) Date: Mon, 18 Mar 2013 18:29:45 -0700 Subject: RFR 8009517: Disable fatal compiler warning in the old build In-Reply-To: <513AEEBB.2080900@oracle.com> References: <5139E680.6000606@oracle.com> <513A0A96.7080508@oracle.com> <513A8194.9040002@oracle.com> <513AEEBB.2080900@oracle.com> Message-ID: <5147BF89.7000602@oracle.com> Sorry for the delay in response, I've been pulled in yet another direction, and this has come back up in priority. On 3/9/2013 12:11 AM, Chris Hegarty wrote: >> I agree about warning creeping problems. This is a temporary solution, >> we should soon be fixing the underlying hashcode/equals problems...but... > > Your temporary solution, -overrides, is just that. It will enable the > old build to complete today, but it could fail at any point in the > future, as the code changes. Correct. As it stands today, a recent change now requires *BOTH* overrides/deprecation in order to get a complete MASTER build using the old build system. [brwetmor at flicker-vm1] 222 >hg diff common/shared/Defs-java.gmk diff --git a/make/common/shared/Defs-java.gmk b/make/common/shared/Defs-java.gmk --- a/make/common/shared/Defs-java.gmk +++ b/make/common/shared/Defs-java.gmk @@ -127,7 +127,7 @@ endif # TODO: Workaround for CR 7063027. Remove -path eventually. -JAVAC_LINT_OPTIONS += -Xlint:-path +JAVAC_LINT_OPTIONS += -Xlint:-path,-overrides,-deprecation JAVACFLAGS += $(JAVAC_LINT_OPTIONS) > For example, java.net is currently warning free, in the old it compiles > with fatal warnings enabled. Lets say, in a moment of madness, I add a > dependency from java.net.Socket to say java.awt.RenderingHints.Key ( or > any class that produces warnings when compiled. I run the new build, all > is fine. Push the changes. Now someone else sync's up, but need to build > using the old build. If the new dependent class is not already compiled > before java.net.Socket gets compiled, it will be compiled implicitly. > It's warnings will cause the compile to fail, and the old build will > fail. Or much simpler, anyone could write sloppy code with warnings, the > new build will suppress them, and they won't notice. Push this code, and > the old build will fail if is explicitly, or implicitly, compiles this > code with -Werror enabled. Exactly. Our formerly clean code now requires disabling of two Lint options, but the new build is happy just to report the warning. The old build crashes on the warning. Our options for the old build system are: 1. disable the warning for overrides/deprecation, keep -Werror (my preferred since these are minor warnings.) 2. Somehow disable -Werror on these new directories that are now failing. (more work to figure out, but also acceptable) 3. Fix the warnings. (I don't have cycles to drive a rewrite of use of deprecated code and/or add missing equals/hashcode that the recent javac changes exposed.) >> We >> spent a lot of time cleaning up many directories, seems a shame to start >> allowing non-fatal warnings to come back into previously clean code >> because people aren't taking the time to fix new warnings as they are >> introduced. > > I personally spent several weeks over the past number of years fixing > warnings and reviewing warning cleanup webrevs from others. I took much > pride in keeping certain areas warnings free. > > It is with great regret that I propose to disable fatal warnings in the > old build, but I felt this the best/safest option. I heard much > annoyance and frustration from others about hitting seemingly random > errors with the old build recently. This is the only sure way to avoid > that. > >> The new builds will still warn, but the >> old builds will still fail for all but these override problems. Yes, >> you lose the warnings in the old, but seems better than completely >> shutting off erroring. > > I'm ok with that, if others are. To clarify, I think you are suggesting > that we keep the old build as it, with -overrides, and now ",-deprecation" :( > and use it > periodically as a way of tracking new warnings being introduced into > areas that were warning free. That would be a side-effect, as someone would occasionally need to figure out what's changed. The main issue we're hitting right now is that RE has to make several source code changes in order to build JCE jar files without errors. I was able to change the individual LINT options globally and reduce it down to one change, but that's still one change that RE has to make. I feel that RE should not be making any changes, but that ship has already sailed and we're stuck with the results now. That is, if the old build fails because of > a fatal warning, so be it. File a bug and fix the source code. Then the > old build will work again. This means that at any point in time the old > build cannot be guaranteed to be buildable. > > Everyone seems to agree, a solution needs to be found to allow us to > keep certain areas warning free. This issue is too important, and too > much time was spent, to allow it to regress to the state it was in a few > years ago. It's already started. Brad > -Chris. > >> >> (Ideally it would be nice to warn but not fail on just this one lint >> option, but don't see how that's possible.) >> >> Brad >> >> >> >> >> >>> -Chris. >>> >>>> >>>> Mike >>>> >>>> On Mar 8 2013, at 05:24 , Chris Hegarty wrote: >>>> >>>>> Since the new build does not enable -Werror when compiling any java >>>>> code, and disables quite a few lint options, new changes my >>>>> inadvertently introduce warnings without even realizing. This can >>>>> cause problems when building with the old build as many areas do >>>>> compile with -Werror set. Since the old build is on life support, >>>>> probably best to just completely disable -Werror, so anyone still >>>>> needing to use it can. >>>>> >>>>> diff -r 48b7295f02f8 make/common/shared/Defs-java.gmk >>>>> --- a/make/common/shared/Defs-java.gmk Thu Mar 07 10:07:13 2013 +0000 >>>>> +++ b/make/common/shared/Defs-java.gmk Thu Mar 07 11:10:37 2013 +0000 >>>>> @@ -122,9 +122,10 @@ ifeq ($(JAVAC_MAX_WARNINGS), true) >>>>> ifeq ($(JAVAC_MAX_WARNINGS), true) >>>>> JAVAC_LINT_OPTIONS += -Xlint:all >>>>> endif >>>>> -ifeq ($(JAVAC_WARNINGS_FATAL), true) >>>>> - JAVACFLAGS += -Werror >>>>> -endif >>>>> +# Disable fatal warnings, 8009517 >>>>> +#ifeq ($(JAVAC_WARNINGS_FATAL), true) >>>>> +# JAVACFLAGS += -Werror >>>>> +#endif >>>>> >>>>> # TODO: Workaround for CR 7063027. Remove -path eventually. >>>>> JAVAC_LINT_OPTIONS += -Xlint:-path >>>>> >>>>> -Chris. >>>> From mike.duigou at oracle.com Tue Mar 19 05:48:08 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Mon, 18 Mar 2013 22:48:08 -0700 Subject: RFR JDK-8010267 & JDK-8010268 : Makefile maintenance for test targets Message-ID: A two small changes to review: If approved I will commit to TL (or someone else can commit to build for me) Mike JDK-8010267 : Add test-clean for cleaning of testoutput directory from output directory. diff --git a/common/makefiles/Main.gmk b/common/makefiles/Main.gmk --- a/common/makefiles/Main.gmk +++ b/common/makefiles/Main.gmk @@ -191,7 +191,7 @@ source-tips: $(OUTPUT_ROOT)/source_tips # Remove everything, except the output from configure. -clean: clean-langtools clean-corba clean-jaxp clean-jaxws clean-hotspot clean-jdk clean-images clean-overlay-images clean-bootcycle-build clean-docs +clean: clean-langtools clean-corba clean-jaxp clean-jaxws clean-hotspot clean-jdk clean-images clean-overlay-images clean-bootcycle-build clean-docs clean-test @($(CD) $(OUTPUT_ROOT) && $(RM) -r tmp source_tips build.log* build-trace*.log*) @$(ECHO) Cleaned all build artifacts. @@ -230,6 +230,8 @@ clean-bootcycle-build: clean-docs: $(call CleanComponent,docs) $(call CleanComponent,docstemp) +clean-test: + $(call CleanComponent,testoutput) .PHONY: langtools corba jaxp jaxws hotspot jdk images overlay-images install .PHONY: langtools-only corba-only jaxp-only jaxws-only hotspot-only jdk-only images-only overlay-images-only install-only JDK-8010268 : Remove dependence upon clean target from jdk/test/Makefile prep target None of the current users seem to depend upon the clean behaviour of "prep" diff --git a/test/Makefile b/test/Makefile --- a/test/Makefile +++ b/test/Makefile @@ -336,7 +336,7 @@ all: jdk_default @$(ECHO) "Testing completed successfully" # Prep for output -prep: clean +prep: @$(MKDIR) -p $(ABS_TEST_OUTPUT_DIR) @$(MKDIR) -p `$(DIRNAME) $(ARCHIVE_BUNDLE)` From Alan.Bateman at oracle.com Tue Mar 19 07:44:58 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 19 Mar 2013 07:44:58 +0000 Subject: RFR: 8009426 "profiles" target fails due to nashorn if "images" is not built first In-Reply-To: <5147721D.8040309@oracle.com> References: <5147721D.8040309@oracle.com> Message-ID: <5148177A.5070200@oracle.com> On 18/03/2013 19:59, David Holmes wrote: > Very simple fix/cleanup. > > webrev: http://cr.openjdk.java.net/~dholmes/8009426/webrev/ > > nashorn.jar was being added to the set of JARS targets regardless of > what was being built, but nashorn is not a dependency for profiles > target. JARS is not used the way it used to be now we have profiles > and all jar files should simply be listed in the appropriate entry in > profiles-includes.txt. There was a couple of other misplaced items too: > > makefiles/CreateJars.gmk > > Removed nashorn and tzdb setting of JARS > > makefiles/Profiles.gmk > > Removed redundant listing of cldrdata.jar > > makefiles/profile-includes.txt > > Add nashorn to full JRE lists This looks okay to me for now but as javax.script is in compact3 then we should be looking to include that in the compact3 builds. The other clean-ups looks okay to me too. I remember suggesting to Sherman to add tzdb.jar to JARS but that was prior to the merge with profiles (pre-dated profiles-includes.txt). -Alan. From david.holmes at oracle.com Tue Mar 19 09:10:17 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 19 Mar 2013 19:10:17 +1000 Subject: RFR: 8009426 "profiles" target fails due to nashorn if "images" is not built first In-Reply-To: <5148177A.5070200@oracle.com> References: <5147721D.8040309@oracle.com> <5148177A.5070200@oracle.com> Message-ID: <51482B79.9020304@oracle.com> Hi Alan, On 19/03/2013 5:44 PM, Alan Bateman wrote: > On 18/03/2013 19:59, David Holmes wrote: >> Very simple fix/cleanup. >> >> webrev: http://cr.openjdk.java.net/~dholmes/8009426/webrev/ >> >> nashorn.jar was being added to the set of JARS targets regardless of >> what was being built, but nashorn is not a dependency for profiles >> target. JARS is not used the way it used to be now we have profiles >> and all jar files should simply be listed in the appropriate entry in >> profiles-includes.txt. There was a couple of other misplaced items too: >> >> makefiles/CreateJars.gmk >> >> Removed nashorn and tzdb setting of JARS >> >> makefiles/Profiles.gmk >> >> Removed redundant listing of cldrdata.jar >> >> makefiles/profile-includes.txt >> >> Add nashorn to full JRE lists > This looks okay to me for now but as javax.script is in compact3 then we > should be looking to include that in the compact3 builds. If we are definitely going to add nashorn.jar to compact3 then I will revise this to do so, and add the missing dependency to ensure nashorn is built. If this decision still has to be confirmed then I will push what I have now and we can deal with the change later. Thanks, David > The other clean-ups looks okay to me too. I remember suggesting to > Sherman to add tzdb.jar to JARS but that was prior to the merge with > profiles (pre-dated profiles-includes.txt). > > -Alan. From Alan.Bateman at oracle.com Tue Mar 19 09:18:28 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 19 Mar 2013 09:18:28 +0000 Subject: RFR: 8009426 "profiles" target fails due to nashorn if "images" is not built first In-Reply-To: <51482B79.9020304@oracle.com> References: <5147721D.8040309@oracle.com> <5148177A.5070200@oracle.com> <51482B79.9020304@oracle.com> Message-ID: <51482D64.3080001@oracle.com> On 19/03/2013 09:10, David Holmes wrote: > > If we are definitely going to add nashorn.jar to compact3 then I will > revise this to do so, and add the missing dependency to ensure nashorn > is built. If this decision still has to be confirmed then I will push > what I have now and we can deal with the change later. I think we should assume nashorn.jar can be optionally included in a compact3 build (and for Oracle builds, dropping Rhino). It's fine to push what you have now as there will be other changes required to fully digest Nashorn. -Alan From erik.joelsson at oracle.com Tue Mar 19 09:19:56 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 19 Mar 2013 10:19:56 +0100 Subject: Fix x11 header check In-Reply-To: <51477B76.6030605@redhat.com> References: <1889117016.19471000.1363370700860.JavaMail.root@redhat.com> <51437CA8.20406@redhat.com> <51477B76.6030605@redhat.com> Message-ID: <51482DBC.8030600@oracle.com> On 2013-03-18 21:39, Omair Majid wrote: > On 03/15/2013 03:55 PM, Omair Majid wrote: >> In file included from >> /builddir/build/BUILD/java-1.8.0-openjdk/jdk8/build/jdk8.build/jdk/gensrc_x11wrappers/sizer.64.c:11:0: >> /builddir/build/BUILD/java-1.8.0-openjdk/jdk8/jdk/src/solaris/native/sun/awt/awt_p.h:51:36: >> fatal error: X11/extensions/Xrender.h: No such file or directory >> #include > So this one turns out to be a bug in how we use AC_CHECK_HEADERS. If I > remove the package that provides this header file on my machine, > configure tells me that the header is missing but does not indicate an > error: > > checking for IceConnectionNumber in -lICE... yes > checking for X11/extensions/shape.h... yes > checking for X11/extensions/Xrender.h... no > checking for X11/extensions/XTest.h... yes > checking cups/cups.h usability... yes > checking cups/cups.h presence... yes > > The documentation for AC_CHECK_HEADERS [1] states: > > """ > If action-if-found is given, it is additional shell code to execute when > one of the header files is found > """ > > So what happens is that as long as the last header in the list > [X11/extensions/shape.h X11/extensions/Xrender.h X11/extensions/XTest.h] > is found, X11_A_OK is set to "yes", and the build continues. > > A one-line fix is: > http://cr.openjdk.java.net/~omajid/webrevs/x11-header-check/00/ > Nice find and simple fix. The "break" is even mentioned in the documentation as a recommended way of solving this. I created: 8010277: Configure doesn't fail when Xrender.h is missing /Erik > Thanks, > Omair > > [1] > http://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.69/html_node/Generic-Headers.html From chris.hegarty at oracle.com Tue Mar 19 09:37:17 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 19 Mar 2013 09:37:17 +0000 Subject: RFR 8009517: Disable fatal compiler warning in the old build In-Reply-To: <5147BF89.7000602@oracle.com> References: <5139E680.6000606@oracle.com> <513A0A96.7080508@oracle.com> <513A8194.9040002@oracle.com> <513AEEBB.2080900@oracle.com> <5147BF89.7000602@oracle.com> Message-ID: <514831CD.9030409@oracle.com> Brad, I do not build using the old build anymore. This is clearly a blocker for your work. If you want to suppress the warnings for overrides/deprecation, then please push the change ( your patch ). We can revisit this in the future, when it is necessary. -Chris. On 03/19/2013 01:29 AM, Brad Wetmore wrote: > Sorry for the delay in response, I've been pulled in yet another > direction, and this has come back up in priority. > > On 3/9/2013 12:11 AM, Chris Hegarty wrote: >>> I agree about warning creeping problems. This is a temporary solution, >>> we should soon be fixing the underlying hashcode/equals >>> problems...but... >> >> Your temporary solution, -overrides, is just that. It will enable the >> old build to complete today, but it could fail at any point in the >> future, as the code changes. > > Correct. As it stands today, a recent change now requires *BOTH* > overrides/deprecation in order to get a complete MASTER build using the > old build system. > > [brwetmor at flicker-vm1] 222 >hg diff common/shared/Defs-java.gmk > diff --git a/make/common/shared/Defs-java.gmk > b/make/common/shared/Defs-java.gmk > --- a/make/common/shared/Defs-java.gmk > +++ b/make/common/shared/Defs-java.gmk > @@ -127,7 +127,7 @@ > endif > > # TODO: Workaround for CR 7063027. Remove -path eventually. > -JAVAC_LINT_OPTIONS += -Xlint:-path > +JAVAC_LINT_OPTIONS += -Xlint:-path,-overrides,-deprecation > > JAVACFLAGS += $(JAVAC_LINT_OPTIONS) > >> For example, java.net is currently warning free, in the old it compiles >> with fatal warnings enabled. Lets say, in a moment of madness, I add a >> dependency from java.net.Socket to say java.awt.RenderingHints.Key ( or >> any class that produces warnings when compiled. I run the new build, all >> is fine. Push the changes. Now someone else sync's up, but need to build >> using the old build. If the new dependent class is not already compiled >> before java.net.Socket gets compiled, it will be compiled implicitly. >> It's warnings will cause the compile to fail, and the old build will >> fail. Or much simpler, anyone could write sloppy code with warnings, the >> new build will suppress them, and they won't notice. Push this code, and >> the old build will fail if is explicitly, or implicitly, compiles this >> code with -Werror enabled. > > Exactly. Our formerly clean code now requires disabling of two Lint > options, but the new build is happy just to report the warning. The old > build crashes on the warning. > > Our options for the old build system are: > > 1. disable the warning for overrides/deprecation, keep -Werror (my > preferred since these are minor warnings.) > 2. Somehow disable -Werror on these new directories that are now > failing. (more work to figure out, but also acceptable) > 3. Fix the warnings. (I don't have cycles to drive a rewrite of use of > deprecated code and/or add missing equals/hashcode that the recent javac > changes exposed.) > >>> We >>> spent a lot of time cleaning up many directories, seems a shame to start >>> allowing non-fatal warnings to come back into previously clean code >>> because people aren't taking the time to fix new warnings as they are >>> introduced. >> >> I personally spent several weeks over the past number of years fixing >> warnings and reviewing warning cleanup webrevs from others. I took much >> pride in keeping certain areas warnings free. >> >> It is with great regret that I propose to disable fatal warnings in the >> old build, but I felt this the best/safest option. I heard much >> annoyance and frustration from others about hitting seemingly random >> errors with the old build recently. This is the only sure way to avoid >> that. >> >>> The new builds will still warn, but the >>> old builds will still fail for all but these override problems. Yes, >>> you lose the warnings in the old, but seems better than completely >>> shutting off erroring. >> >> I'm ok with that, if others are. To clarify, I think you are suggesting >> that we keep the old build as it, with -overrides, > > and now ",-deprecation" :( > >> and use it >> periodically as a way of tracking new warnings being introduced into >> areas that were warning free. > > That would be a side-effect, as someone would occasionally need to > figure out what's changed. > > The main issue we're hitting right now is that RE has to make several > source code changes in order to build JCE jar files without errors. I > was able to change the individual LINT options globally and reduce it > down to one change, but that's still one change that RE has to make. I > feel that RE should not be making any changes, but that ship has already > sailed and we're stuck with the results now. > > That is, if the old build fails because of >> a fatal warning, so be it. File a bug and fix the source code. Then the >> old build will work again. This means that at any point in time the old >> build cannot be guaranteed to be buildable. >> >> Everyone seems to agree, a solution needs to be found to allow us to >> keep certain areas warning free. This issue is too important, and too >> much time was spent, to allow it to regress to the state it was in a few >> years ago. > > It's already started. > > Brad > > >> -Chris. >> >>> >>> (Ideally it would be nice to warn but not fail on just this one lint >>> option, but don't see how that's possible.) >>> >>> Brad >>> >>> >>> >>> >>> >>>> -Chris. >>>> >>>>> >>>>> Mike >>>>> >>>>> On Mar 8 2013, at 05:24 , Chris Hegarty wrote: >>>>> >>>>>> Since the new build does not enable -Werror when compiling any java >>>>>> code, and disables quite a few lint options, new changes my >>>>>> inadvertently introduce warnings without even realizing. This can >>>>>> cause problems when building with the old build as many areas do >>>>>> compile with -Werror set. Since the old build is on life support, >>>>>> probably best to just completely disable -Werror, so anyone still >>>>>> needing to use it can. >>>>>> >>>>>> diff -r 48b7295f02f8 make/common/shared/Defs-java.gmk >>>>>> --- a/make/common/shared/Defs-java.gmk Thu Mar 07 10:07:13 2013 >>>>>> +0000 >>>>>> +++ b/make/common/shared/Defs-java.gmk Thu Mar 07 11:10:37 2013 >>>>>> +0000 >>>>>> @@ -122,9 +122,10 @@ ifeq ($(JAVAC_MAX_WARNINGS), true) >>>>>> ifeq ($(JAVAC_MAX_WARNINGS), true) >>>>>> JAVAC_LINT_OPTIONS += -Xlint:all >>>>>> endif >>>>>> -ifeq ($(JAVAC_WARNINGS_FATAL), true) >>>>>> - JAVACFLAGS += -Werror >>>>>> -endif >>>>>> +# Disable fatal warnings, 8009517 >>>>>> +#ifeq ($(JAVAC_WARNINGS_FATAL), true) >>>>>> +# JAVACFLAGS += -Werror >>>>>> +#endif >>>>>> >>>>>> # TODO: Workaround for CR 7063027. Remove -path eventually. >>>>>> JAVAC_LINT_OPTIONS += -Xlint:-path >>>>>> >>>>>> -Chris. >>>>> From gnu.andrew at redhat.com Tue Mar 19 14:47:39 2013 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Tue, 19 Mar 2013 10:47:39 -0400 (EDT) Subject: Fix x11 header check (was: Re: New official README-builds.html) In-Reply-To: <51477B76.6030605@redhat.com> Message-ID: <1372058647.21057443.1363704459796.JavaMail.root@redhat.com> ----- Original Message ----- > On 03/15/2013 03:55 PM, Omair Majid wrote: > > In file included from > > /builddir/build/BUILD/java-1.8.0-openjdk/jdk8/build/jdk8.build/jdk/gensrc_x11wrappers/sizer.64.c:11:0: > > /builddir/build/BUILD/java-1.8.0-openjdk/jdk8/jdk/src/solaris/native/sun/awt/awt_p.h:51:36: > > fatal error: X11/extensions/Xrender.h: No such file or directory > > #include > > So this one turns out to be a bug in how we use AC_CHECK_HEADERS. If > I > remove the package that provides this header file on my machine, > configure tells me that the header is missing but does not indicate > an > error: > > checking for IceConnectionNumber in -lICE... yes > checking for X11/extensions/shape.h... yes > checking for X11/extensions/Xrender.h... no > checking for X11/extensions/XTest.h... yes > checking cups/cups.h usability... yes > checking cups/cups.h presence... yes > > The documentation for AC_CHECK_HEADERS [1] states: > > """ > If action-if-found is given, it is additional shell code to execute > when > one of the header files is found > """ > > So what happens is that as long as the last header in the list > [X11/extensions/shape.h X11/extensions/Xrender.h > X11/extensions/XTest.h] > is found, X11_A_OK is set to "yes", and the build continues. > > A one-line fix is: > http://cr.openjdk.java.net/~omajid/webrevs/x11-header-check/00/ > > Thanks, > Omair > > [1] > http://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.69/html_node/Generic-Headers.html > -- > PGP Key: 66484681 (http://pgp.mit.edu/) > Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 > Looks good to me. Needs a bug ID... sigh. -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From omajid at redhat.com Tue Mar 19 15:26:59 2013 From: omajid at redhat.com (omajid at redhat.com) Date: Tue, 19 Mar 2013 15:26:59 +0000 Subject: hg: jdk8/build: 8010277: Configure doesn't fail when Xrender.h is missing Message-ID: <20130319152659.F01E548251@hg.openjdk.java.net> Changeset: 29153d0df68f Author: omajid Date: 2013-03-19 11:25 -0400 URL: http://hg.openjdk.java.net/jdk8/build/rev/29153d0df68f 8010277: Configure doesn't fail when Xrender.h is missing Reviewed-by: andrew ! common/autoconf/generated-configure.sh ! common/autoconf/libraries.m4 From omajid at redhat.com Tue Mar 19 15:28:50 2013 From: omajid at redhat.com (Omair Majid) Date: Tue, 19 Mar 2013 11:28:50 -0400 Subject: Fix x11 header check In-Reply-To: <51482DBC.8030600@oracle.com> References: <1889117016.19471000.1363370700860.JavaMail.root@redhat.com> <51437CA8.20406@redhat.com> <51477B76.6030605@redhat.com> <51482DBC.8030600@oracle.com> Message-ID: <51488432.9010208@redhat.com> Hi Erik, On 03/19/2013 05:19 AM, Erik Joelsson wrote: > On 2013-03-18 21:39, Omair Majid wrote: >> A one-line fix is: >> http://cr.openjdk.java.net/~omajid/webrevs/x11-header-check/00/ >> > Nice find and simple fix. The "break" is even mentioned in the > documentation as a recommended way of solving this. I created: > > 8010277: Configure doesn't fail when Xrender.h is missing > Thanks for the review. I have pushed the changeset: http://hg.openjdk.java.net/jdk8/build/rev/29153d0df68f Thanks, Omair -- PGP Key: 66484681 (http://pgp.mit.edu/) Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 From david.r.chase at oracle.com Tue Mar 19 15:57:23 2013 From: david.r.chase at oracle.com (David Chase) Date: Tue, 19 Mar 2013 11:57:23 -0400 Subject: Does README-builds.html need to mention Nashorn? Message-ID: <89ED8AC0-555B-4BA2-A2E3-7C1D03B75DE9@oracle.com> I was just browsing through, to be sure I was going to set the knobs right for some performance testing, and noticed no mention of the repository I had to clone last night. David From jen.dority at oracle.com Tue Mar 19 16:19:22 2013 From: jen.dority at oracle.com (Jen Dority) Date: Tue, 19 Mar 2013 12:19:22 -0400 Subject: RFR: 8006818: SunEC and SunPKCS11 providers should be in all profiles Message-ID: <5148900A.9020802@oracle.com> Please review http://cr.openjdk.java.net/~dholmes/8006818/webrev/. This resolves JDK-8006818 which calls for adding the SunEC and SunPKCS11 providers to the compact* profiles. Thanks, Jen From Alan.Bateman at oracle.com Tue Mar 19 19:49:43 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 19 Mar 2013 19:49:43 +0000 Subject: RFR: 8006818: SunEC and SunPKCS11 providers should be in all profiles In-Reply-To: <5148900A.9020802@oracle.com> References: <5148900A.9020802@oracle.com> Message-ID: <5148C157.2060706@oracle.com> On 19/03/2013 16:19, Jen Dority wrote: > Please review http://cr.openjdk.java.net/~dholmes/8006818/webrev/. > > This resolves JDK-8006818 which calls for adding the SunEC and > SunPKCS11 providers to the compact* profiles. > > Thanks, > Jen This looks okay to me although the SunPKCS11 provider isn't configured by default on Linux so that additional effort would be required to actually use it. -Alan From valerie.peng at oracle.com Tue Mar 19 20:12:28 2013 From: valerie.peng at oracle.com (Valerie (Yu-Ching) Peng) Date: Tue, 19 Mar 2013 13:12:28 -0700 Subject: RFR: 8006818: SunEC and SunPKCS11 providers should be in all profiles In-Reply-To: <5148C157.2060706@oracle.com> References: <5148900A.9020802@oracle.com> <5148C157.2060706@oracle.com> Message-ID: <5148C6AC.9070607@oracle.com> Also, for jdk7 and its update releases, SunPKCS11 provider isn't built for Windows 64-bit. Just FYI. Valerie On 03/19/13 12:49, Alan Bateman wrote: > On 19/03/2013 16:19, Jen Dority wrote: >> Please review http://cr.openjdk.java.net/~dholmes/8006818/webrev/. >> >> This resolves JDK-8006818 which calls for adding the SunEC and >> SunPKCS11 providers to the compact* profiles. >> >> Thanks, >> Jen > This looks okay to me although the SunPKCS11 provider isn't configured > by default on Linux so that additional effort would be required to > actually use it. > > -Alan From omajid at redhat.com Tue Mar 19 20:59:17 2013 From: omajid at redhat.com (Omair Majid) Date: Tue, 19 Mar 2013 16:59:17 -0400 Subject: Allow using a system-installed giflib In-Reply-To: <5142ECFC.1090402@oracle.com> References: <1350720224.19115736.1363317011803.JavaMail.root@redhat.com> <5142ECFC.1090402@oracle.com> Message-ID: <5148D1A5.8090606@redhat.com> On 03/15/2013 05:42 AM, Erik Joelsson wrote: >> On 2013-03-15 04:10, Andrew Hughes wrote: >>> On 03/08/2013 12:26 PM, Phil Race wrote: >>>> If I understand correctly, this removes the directory containing >>>> the JDK's copy of giflib sources from the set of locations to be >>>> compiled etc, and replaces it with just a link line pointer to use >>>> "libgif" which is then expected to be on the default linker path, >>>> ie in /usr/lib. >>>> >>>> I think this is fine except I would guard USE_EXTERNAL_LIBGIF >>>> with an expectation that this is at least "not" windows, since >>>> I'm pretty sure that option would always be a mistake there. >>> The updated webrev does that. I don't have a windows machine to test >>> this on, unfortunately. >>> >> This does cause some duplication. Is this really a major issue? It's >> not the default and, if I was someone on Windows trying to get system >> giflib working, this would just get in the way. We had to remove >> something >> similar in the zlib case that blocked it if not on Mac OS X. >> > This part is weird to me. Sure, trying to set --with-giflib=system on > windows is wrong, but that's why configure is verifying that it's > actually there and that the toolchain is able to compile and link > against it. I just tried the patch on windows, and configure fails at > finding giflib, even if it's installed in cygwin, as expected. I do not > think we should be hand holding to this extent in the makefiles. If we > really want to guard this on windows, do it in configure, with a helpful > error message, rather then silently ignoring the option in make. But as > pointed out, it's really not necessary. Okay, I have reverted the Makefile changes that checked for windows. Updated webrev at: http://cr.openjdk.java.net/~omajid/webrevs/system-giflib/02/ Thanks, Omair -- PGP Key: 66484681 (http://pgp.mit.edu/) Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 From bradford.wetmore at oracle.com Tue Mar 19 21:55:46 2013 From: bradford.wetmore at oracle.com (Brad Wetmore) Date: Tue, 19 Mar 2013 14:55:46 -0700 Subject: Does README-builds.html need to mention Nashorn? In-Reply-To: <89ED8AC0-555B-4BA2-A2E3-7C1D03B75DE9@oracle.com> References: <89ED8AC0-555B-4BA2-A2E3-7C1D03B75DE9@oracle.com> Message-ID: <5148DEE2.3040404@oracle.com> I noticed the same and filed JDK-8010258 yesterday. Tim Bell thinks it's probably just an oversight. Brad On 3/19/2013 8:57 AM, David Chase wrote: > I was just browsing through, to be sure I was going to set the knobs right for some performance testing, and noticed no mention of the repository I had to clone last night. > > David > From david.holmes at oracle.com Wed Mar 20 00:56:07 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 20 Mar 2013 10:56:07 +1000 Subject: RFR: 8006818: SunEC and SunPKCS11 providers should be in all profiles In-Reply-To: <5148C6AC.9070607@oracle.com> References: <5148900A.9020802@oracle.com> <5148C157.2060706@oracle.com> <5148C6AC.9070607@oracle.com> Message-ID: <51490927.6090805@oracle.com> On 20/03/2013 6:12 AM, Valerie (Yu-Ching) Peng wrote: > Also, for jdk7 and its update releases, SunPKCS11 provider isn't built > for Windows 64-bit. Just FYI. Thanks Valerie. This is 8 only and the Profiles RI is Linux only, so no issues in that regard. David > Valerie > > On 03/19/13 12:49, Alan Bateman wrote: >> On 19/03/2013 16:19, Jen Dority wrote: >>> Please review http://cr.openjdk.java.net/~dholmes/8006818/webrev/. >>> >>> This resolves JDK-8006818 which calls for adding the SunEC and >>> SunPKCS11 providers to the compact* profiles. >>> >>> Thanks, >>> Jen >> This looks okay to me although the SunPKCS11 provider isn't configured >> by default on Linux so that additional effort would be required to >> actually use it. >> >> -Alan > From david.holmes at oracle.com Wed Mar 20 00:57:19 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 20 Mar 2013 10:57:19 +1000 Subject: RFR: 8006818: SunEC and SunPKCS11 providers should be in all profiles In-Reply-To: <5148C157.2060706@oracle.com> References: <5148900A.9020802@oracle.com> <5148C157.2060706@oracle.com> Message-ID: <5149096F.2070603@oracle.com> Thanks Alan. Jen: I will push these changes for you into TL forest. David On 20/03/2013 5:49 AM, Alan Bateman wrote: > On 19/03/2013 16:19, Jen Dority wrote: >> Please review http://cr.openjdk.java.net/~dholmes/8006818/webrev/. >> >> This resolves JDK-8006818 which calls for adding the SunEC and >> SunPKCS11 providers to the compact* profiles. >> >> Thanks, >> Jen > This looks okay to me although the SunPKCS11 provider isn't configured > by default on Linux so that additional effort would be required to > actually use it. > > -Alan From christian.thalinger at oracle.com Wed Mar 20 01:16:14 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 19 Mar 2013 18:16:14 -0700 Subject: RFR (S): 8006965: test_gamma should run with import JDK In-Reply-To: References: <645283DC-655E-4FA7-A0EA-676D08559F5B@oracle.com> <8CF27CFE-174B-44BA-ABAE-52D3D931DFBF@oracle.com> <512A9A3F.4070402@oracle.com> <6FD71E10-9866-42F5-8201-60FB237AD988@oracle.com> <512C632B.3070206@oracle.com> Message-ID: <9C3E07EA-7709-466D-B938-A9542F33CBF5@oracle.com> On Mar 13, 2013, at 4:44 PM, Christian Thalinger wrote: > > On Feb 26, 2013, at 6:09 PM, Christian Thalinger wrote: > >> >> On Feb 25, 2013, at 11:24 PM, David Holmes wrote: >> >>> On 26/02/2013 4:42 AM, Christian Thalinger wrote: >>>> On Feb 24, 2013, at 2:54 PM, David Holmes wrote: >>>>> On 23/02/2013 1:55 PM, Christian Thalinger wrote: >>>>>> I talked to a lot of people about this today. What we really want is to not run tests when we build. Mikael and I were looking into how we could do that without gamma and there is a way: >>>>>> >>>>>> http://cr.openjdk.java.net/~twisti/8006965/ >>>>>> >>>>>> This would be the first of three fixes: >>>>>> >>>>>> Fix 1) The patch above removes test_gamma and uses some weirdness in the VM (-Dsun.java.launcher=gamma) to run it with an existing JDK; add test_{product,fastdebug,debug} targets >>>>> >>>>> This logic is not suitable: >>>>> >>>>> 541 # Testing the built JVM >>>>> 542 ifeq ($(JAVA_HOME),) >>>>> 543 RUN_JVM=JAVA_HOME=$(JDK_IMPORT_PATH) $(JDK_IMPORT_PATH)/bin/java -d$(ARCH_DATA_MODEL) -server -XXaltjvm=$(MISC_DIR)/$(VM_FLAVOR) -Dsun.java.launcher=gamma >>>>> 544 else >>>>> 545 RUN_JVM=$(JAVA_HOME)/bin/java -d$(ARCH_DATA_MODEL) -server -XXaltjvm=$(MISC_DIR)/$(VM_FLAVOR) -Dsun.java.launcher=gamma >>>>> 546 endif >>>>> >>>>> I have JAVA_HOME set in my environment for use by other tools/scripts and it points at JDK7. The existing logic does not use my environments JAVA_HOME setting so neither should the revised logic! >>>> >>>> That's not entirely correct. test_gamma uses your JAVA_HOME setting: >>> >>> This is so confusing. Our makefiles are an abomination! >> >> I couldn't agree more. >> >>> >>> So this all started because the makefile has: >>> >>> JAVA_HOME=$(ABS_BOOTDIR) >>> >>> which was flagged as wrong because gamma would run in the boot JDK. But now it seems the make variable JAVA_HOME is irrelevant anyway because the test_gamma script will use the JAVA_HOME environment variable. >>> >>> So how did the boot JDK come back into this??? >>> >>>> cthaling at sc14a501:/export/twisti/build/graal/build/linux_amd64_compiler2/product$ export JAVA_HOME=/java/re/jdk/8/latest/binaries/linux-x64 >>>> cthaling at sc14a501:/export/twisti/build/graal/build/linux_amd64_compiler2/product$ ./test_gamma >>>> Using java runtime at: /java/re/jdk/8/latest/binaries/linux-x64/jre >>>> >>>> cthaling at sc14a501:/export/twisti/build/graal/build/linux_amd64_compiler2/product$ export JAVA_HOME=/foo >>>> cthaling at sc14a501:/export/twisti/build/graal/build/linux_amd64_compiler2/product$ ./test_gamma >>>> JAVA_HOME must point to a 64-bit OpenJDK. >>>> >>>> And here comes this little snippet into play: >>>> >>>> -MAKE_ARGS += JAVA_HOME=$(ABS_BOOTDIR) >>>> +MAKE_ARGS += BOOTDIR=$(ABS_BOOTDIR) >>>> >>>> Only setting JAVA_HOME to ABS_BOOTDIR make test_gamma work even if you have a JAVA_HOME set. >>> >>> I still don't get this. What has BOOTDIR got to do with JAVA_HOME? Where is this BOOTDIR value being used? > > Ha! I can remember. It's used by jmvti.make (implicitly). The logic in rules.make is: > > ifdef ALT_BOOTDIR > > COMPILE.JAVAC = $(ALT_BOOTDIR)/bin/javac > > else > > ifdef BOOTDIR > > COMPILE.JAVAC = $(BOOTDIR)/bin/javac > > else > > ifdef JAVA_HOME > else > > endif > endif > endif > > BOOTDIR is not defined in rules.make and JAVA_HOME is picked up (which is set to ABS_BOOTDIR). Back to my favorite review these days :-) I put the BOOTDIR setting back because we need it. Any reviewers who approve or veto pushing this change? -- Chris > > This all sucks and needs to be replaced by something completely different. Soon. > > -- Chris > >>> There is no use of it in http://cr.openjdk.java.net/~twisti/8006965/8006965.patch and I don't see it pre-existing ?? >> >> I talked to John Coomes about that yesterday and we can remove that line. ABS_BOOTDIR is only used by Windows. >> >> -- Chris >> >>> >>> Thanks, >>> David >>> >>>> I have added this logic so that users can control what JDK is used when running the test. In fact they should use ALT_JDK_IMPORT_PATH if they want to control that. >>>> >>>>> >>>>> I also don't see why the above sets JAVA_HOME at #543 - what will read that environment variable? >>>> >>>> It's the odd logic in os::jvm_path guarded by Arguments::created_by_gamma_launcher(). A clean-up of that logic would be part of Fix 3. >>>> >>>>> >>>>> I still have concerns over what JDK_IMPORT_PATH will point to for different JDK builders. >>>> >>>> It's either JDK_IMPORT_PATH or JDK_IMAGE_DIR. Since most people don't want to export their libjvm into a JDK we have to use JDK_IMPORT_PATH. We could add some logic that checks if JDK_IMAGE_DIR exists and use that one. >>>> >>>> -- Chris >>>> >>>>> >>>>> And this addition still makes no sense to me: >>>>> >>>>> MAKE_ARGS += BOOTDIR=$(ABS_BOOTDIR) >>>>> >>>>> Why do you need to add BOOTDIR to the MAKE_ARGS? >>>>> >>>>> David >>>>> >>>>> >>>>>> Fix 2) Remove gamma and all the ugly code that comes with it (copies of the jdk launcher in hotspot and other pieces); make the hotspot script work like the test targets in Fix 1 >>>>>> >>>>>> Fix 3) Remove the -Dsun.java.launcher=gamma and possibly replace the existing -Dsun.boot.library.path weirdness by explicit command line options like -Xbootlibrarypath:{/p,/a} >>>>>> >>>>>> -- Chris >>>>>> >>>>>> On Feb 22, 2013, at 3:21 PM, Christian Thalinger wrote: >>>>>> >>>>>>> >>>>>>> On Feb 22, 2013, at 12:58 AM, Staffan Larsen wrote: >>>>>>> >>>>>>>> I'm not sure what the correct solution is, but when you do find out, the jdkpath.sh target should also be updated. >>>>>>> >>>>>>> How many are actually using the hotspot script? Would people be very sentimental if we would remove the gamma launcher altogether? >>>>>>> >>>>>>> Taking to people here it seems that most are copying their libjvm into a JDK and use java anyway. >>>>>>> >>>>>>> -- Chris >>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> /Staffan >>>>>>>> >>>>>>>> On 22 feb 2013, at 03:40, Christian Thalinger wrote: >>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~twisti/8006965 >>>>>>>>> >>>>>>>>> 8006965: test_gamma should run with import JDK >>>>>>>>> Reviewed-by: >>>>>>>>> >>>>>>>>> Right now test_gamma runs with the boot JDK which is JDK n-1 (where >>>>>>>>> JDK n is the version we are actually compiling for). This setup is >>>>>>>>> unsupported and thus should not be done during HotSpot builds. >>>>>>>>> >>>>>>>>> The fix is to always use JDK_IMPORT_PATH instead of JAVA_HOME when >>>>>>>>> running test_gamma. >>>>>>>>> >>>>>>>>> make/bsd/makefiles/buildtree.make >>>>>>>>> make/defs.make >>>>>>>>> make/linux/makefiles/buildtree.make >>>>>>>>> make/solaris/makefiles/buildtree.make >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>> >> > From erik.joelsson at oracle.com Wed Mar 20 07:49:04 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 20 Mar 2013 08:49:04 +0100 Subject: Allow using a system-installed giflib In-Reply-To: <5148D1A5.8090606@redhat.com> References: <1350720224.19115736.1363317011803.JavaMail.root@redhat.com> <5142ECFC.1090402@oracle.com> <5148D1A5.8090606@redhat.com> Message-ID: <514969F0.7060208@oracle.com> This looks good to me. Thanks! /Erik On 2013-03-19 21:59, Omair Majid wrote: > On 03/15/2013 05:42 AM, Erik Joelsson wrote: >>> On 2013-03-15 04:10, Andrew Hughes wrote: >>>> On 03/08/2013 12:26 PM, Phil Race wrote: >>>>> If I understand correctly, this removes the directory containing >>>>> the JDK's copy of giflib sources from the set of locations to be >>>>> compiled etc, and replaces it with just a link line pointer to use >>>>> "libgif" which is then expected to be on the default linker path, >>>>> ie in /usr/lib. >>>>> >>>>> I think this is fine except I would guard USE_EXTERNAL_LIBGIF >>>>> with an expectation that this is at least "not" windows, since >>>>> I'm pretty sure that option would always be a mistake there. >>>> The updated webrev does that. I don't have a windows machine to test >>>> this on, unfortunately. >>>> >>> This does cause some duplication. Is this really a major issue? It's >>> not the default and, if I was someone on Windows trying to get system >>> giflib working, this would just get in the way. We had to remove >>> something >>> similar in the zlib case that blocked it if not on Mac OS X. >>> >> This part is weird to me. Sure, trying to set --with-giflib=system on >> windows is wrong, but that's why configure is verifying that it's >> actually there and that the toolchain is able to compile and link >> against it. I just tried the patch on windows, and configure fails at >> finding giflib, even if it's installed in cygwin, as expected. I do not >> think we should be hand holding to this extent in the makefiles. If we >> really want to guard this on windows, do it in configure, with a helpful >> error message, rather then silently ignoring the option in make. But as >> pointed out, it's really not necessary. > Okay, I have reverted the Makefile changes that checked for windows. > Updated webrev at: > > http://cr.openjdk.java.net/~omajid/webrevs/system-giflib/02/ > > Thanks, > Omair > From mikhail.cherkasov at oracle.com Wed Mar 20 16:20:59 2013 From: mikhail.cherkasov at oracle.com (mikhail cherkasov) Date: Wed, 20 Mar 2013 20:20:59 +0400 Subject: Solaris jdk6 build. gcc version check fails Message-ID: <5149E1EB.4070406@oracle.com> Hi all, I have weird error: ERROR: The Solaris GCC compiler version must be 2.95.2. You are using the following compiler version: 2.95 The compiler was obtained from the following location: /java/devtools/i586/gnucc/bin/ Please change your compiler. it's weird because I have exactly the same version is required: -bash-3.2$ /java/devtools/i586/gnucc/bin/gcc --version 2.95.2 Any idea how to fix it? I use -bash-3.2$ gmake --version GNU Make 3.82 and trying to build 6u43. Thanks, Mikhail. From david.katleman at oracle.com Wed Mar 20 21:38:29 2013 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Wed, 20 Mar 2013 21:38:29 +0000 Subject: hg: jdk8/build/hotspot: 40 new changesets Message-ID: <20130320213956.438E2482B7@hg.openjdk.java.net> Changeset: 8196357e95b5 Author: amurillo Date: 2013-03-08 08:22 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/8196357e95b5 8009688: new hotspot build - hs25-b23 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 255c0a4cb4eb Author: sla Date: 2013-03-05 08:50 +0100 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/255c0a4cb4eb 8009287: [parfait] Uninitialised variable in hotspot/agent/src/os/linux/ps_core.c Reviewed-by: dholmes, kvn, mikael, morris ! agent/src/os/linux/ps_core.c Changeset: 9058789475af Author: iklam Date: 2013-03-05 13:55 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/9058789475af 7107135: Stack guard pages are no more protected after loading a shared library with executable stack Summary: Detect the execstack attribute of the loaded library and attempt to fix the stack guard using Safepoint op. Reviewed-by: dholmes, zgu Contributed-by: ioi.lam at oracle.com ! src/os/linux/vm/globals_linux.hpp ! src/os/linux/vm/os_linux.cpp ! src/os/linux/vm/os_linux.hpp ! src/os_cpu/linux_sparc/vm/os_linux_sparc.cpp ! src/os_cpu/linux_x86/vm/os_linux_x86.cpp ! src/share/vm/runtime/thread.hpp ! src/share/vm/runtime/vm_operations.hpp ! src/share/vm/utilities/elfFile.cpp ! src/share/vm/utilities/elfFile.hpp + test/runtime/7107135/Test.java + test/runtime/7107135/Test7107135.sh + test/runtime/7107135/TestMT.java + test/runtime/7107135/test.c Changeset: 6b803ba47588 Author: zgu Date: 2013-03-07 14:06 -0500 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/6b803ba47588 8008257: NMT: assert(new_rec->is_allocation_record()) failed when running with shared memory option Summary: Corrected virtual memory recording and tagging code when large pages are used Reviewed-by: coleenp, ccheung ! src/os/bsd/vm/os_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp Changeset: 3efdfd6ddbf2 Author: coleenp Date: 2013-03-08 11:47 -0500 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/3efdfd6ddbf2 8003553: NPG: metaspace objects should be zeroed in constructors Summary: Zero metadata in constructors, not in allocation (and some in constructors) Reviewed-by: jmasa, sspitsyn ! src/share/vm/interpreter/rewriter.cpp ! src/share/vm/memory/metablock.cpp ! src/share/vm/memory/metaspace.cpp ! src/share/vm/oops/constMethod.cpp ! src/share/vm/oops/cpCache.cpp ! src/share/vm/oops/cpCache.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/klass.cpp ! src/share/vm/oops/klass.hpp ! src/share/vm/oops/method.cpp ! src/share/vm/oops/methodData.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 252ad8d5f22b Author: dcubed Date: 2013-03-08 17:14 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/252ad8d5f22b Merge ! src/os/bsd/vm/os_bsd.cpp Changeset: 35ef86296a5d Author: dcubed Date: 2013-03-08 17:49 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/35ef86296a5d Merge ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp Changeset: 5939f5953b45 Author: coleenp Date: 2013-03-13 09:10 -0400 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/5939f5953b45 8009836: nsk/regression/b4222717 fails with empty stack trace Summary: Some zeroing was missed for bug 8003553, causing empty stack traces and Xcom crashes, add back zeroing to metablock Reviewed-by: dholmes, rbackman ! src/share/vm/memory/metablock.cpp ! src/share/vm/oops/constMethod.cpp ! src/share/vm/oops/method.cpp Changeset: 96480359523a Author: coleenp Date: 2013-03-11 14:00 -0400 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/96480359523a 8008965: @Contended fails with classes having static fields Summary: Disable @Contended support for static fields Reviewed-by: coleenp, kvn Contributed-by: Aleksey Shipilev ! src/share/vm/classfile/classFileParser.cpp + test/runtime/8003985/Test8003985.java Changeset: d6320e955c89 Author: coleenp Date: 2013-03-13 13:47 -0400 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/d6320e955c89 Merge Changeset: 0ede345ec7c9 Author: coleenp Date: 2013-03-13 15:15 -0400 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/0ede345ec7c9 8009829: CDS: JDK JPRT test fails crash in Symbol::equals() Summary: -Xshare:dump was creating a Symbol in C_heap. There's an assert there that jdk jprt wasn't hitting because it was only done in product Reviewed-by: dholmes, hseigel, iklam ! src/share/vm/classfile/symbolTable.cpp Changeset: c8b31b461e1a Author: coleenp Date: 2013-03-13 17:34 -0400 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/c8b31b461e1a 8003419: NPG: Clean up metadata created during class loading if failure Summary: Store metadata on ClassFileParser instance to be cleaned up by destructor. This enabled some refactoring of the enormous parseClassFile function. Reviewed-by: jmasa, acorn ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/oops/constMethod.cpp ! src/share/vm/oops/constMethod.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp Changeset: fad90b102190 Author: jprovino Date: 2013-03-06 13:38 -0500 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/fad90b102190 8008310: Some adjustments needed to minimal VM warnings and errors for unsupported command line options Summary: Changes to arguments.cpp for warnings vs. errors. Changes for CDS arguments. Reviewed-by: coleenp, cjplummer ! make/excludeSrc.make ! src/share/vm/memory/filemap.hpp ! src/share/vm/runtime/arguments.cpp Changeset: 47bc9800972c Author: jprovino Date: 2013-03-06 13:46 -0500 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/47bc9800972c 8006498: #if is wrong in the code. Summary: ASSERT and other symbols used incorrectly with #if are supposed to be defined or not. Reviewed-by: dholmes, mikael ! src/cpu/x86/vm/frame_x86.cpp ! src/cpu/x86/vm/frame_x86.hpp ! src/share/vm/c1/c1_LIR.hpp ! src/share/vm/ci/ciTypeFlow.cpp ! src/share/vm/code/compressedStream.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/prims/jvmtiImpl.cpp ! src/share/vm/prims/jvmtiTrace.hpp Changeset: 67342b960b47 Author: jprovino Date: 2013-03-06 13:50 -0500 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/67342b960b47 8008474: Add -Wundef to warning flags. Summary: Force use of undefined macros to be and error. Reviewed-by: dholmes, mikael ! make/bsd/makefiles/gcc.make ! make/linux/makefiles/gcc.make ! make/solaris/makefiles/gcc.make Changeset: cb75b67f04fb Author: jprovino Date: 2013-03-08 12:35 -0500 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/cb75b67f04fb Merge ! make/bsd/makefiles/gcc.make Changeset: 69ffa4ac9e53 Author: jprovino Date: 2013-03-12 00:02 -0400 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/69ffa4ac9e53 8009835: Only produce a warning when -Xshare:auto is explicitly requested Summary: The minimal JVM is printing a warning message for default settings when it should quitely ignore them. Reviewed-by: coleenp, dholmes ! src/share/vm/runtime/arguments.cpp Changeset: 9102c4111564 Author: jprovino Date: 2013-03-14 10:37 -0400 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/9102c4111564 Merge Changeset: ed53b50794d7 Author: vladidan Date: 2013-03-14 12:49 -0400 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/ed53b50794d7 Merge Changeset: 0094485b46c7 Author: roland Date: 2013-03-13 09:44 +0100 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/0094485b46c7 8009761: Deoptimization on sparc doesn't set Llast_SP correctly in the interpreter frames it creates Summary: deoptimization doesn't set up callee frames so that they restore caller frames correctly. Reviewed-by: kvn ! src/cpu/sparc/vm/cppInterpreter_sparc.cpp ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/x86/vm/cppInterpreter_x86.cpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/cpu/zero/vm/cppInterpreter_zero.cpp ! src/share/vm/interpreter/abstractInterpreter.hpp ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/runtime/vframeArray.cpp ! src/share/vm/runtime/vframeArray.hpp + test/compiler/8009761/Test8009761.java Changeset: 056ab43544a4 Author: neliasso Date: 2013-03-13 10:56 +0100 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/056ab43544a4 8009721: Make PhaseLive independent from regalloc Summary: Moved class definition of LRG_List from chaitin.hpp to live.hpp Reviewed-by: kvn, rbackman, roland Contributed-by: niclas.adlertz at oracle.com ! src/share/vm/opto/chaitin.hpp ! src/share/vm/opto/live.hpp Changeset: 6d98efabf3ba Author: neliasso Date: 2013-03-13 13:44 +0100 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/6d98efabf3ba Merge Changeset: b7c2c5b2572c Author: neliasso Date: 2013-02-13 10:25 +0100 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/b7c2c5b2572c 8005772: Stubs report compile id -1 in phase events Summary: Use 0 to indicate id is NA, -1 for error or uninitalized Reviewed-by: kvn, twisti ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/opto/compile.cpp Changeset: 71f13276159d Author: morris Date: 2013-03-14 07:44 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/71f13276159d 8008560: [parfait] Null pointer deference in hotspot/src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp Summary: add null pointer check in signal handler Reviewed-by: kvn ! src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp Changeset: fba788946616 Author: morris Date: 2013-03-14 16:16 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/fba788946616 Merge Changeset: 9def4075da6d Author: tamao Date: 2013-03-05 15:36 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/9def4075da6d 8008079: G1: Add nextObject routine to CMBitMapRO and replace nextWord Summary: Update the task local finger to the start of the next object when marking aborts, in order to avoid the redundant scanning of all 0's when the marking task restarts, if otherwise updating to the next word. In addition, reuse the routine nextObject() in routine iterate(). Reviewed-by: johnc, ysr Contributed-by: tamao ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/gc_implementation/g1/concurrentMark.inline.hpp Changeset: 209f8ba5020b Author: tamao Date: 2013-03-07 10:44 -0800 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/209f8ba5020b 8008368: Deprecate MaxGCMinorPauseMillis Summary: Deprecate MaxGCMinorPauseMillis and emit a warning if set by users Reviewed-by: brutisso, johnc Contributed-by: tamao ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/arguments.hpp Changeset: 1f3354851c91 Author: stefank Date: 2013-03-11 08:49 +0100 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/1f3354851c91 Merge Changeset: 167812fe00bb Author: kevinw Date: 2013-03-11 12:56 +0000 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/167812fe00bb 8009723: CMS logs "concurrent mode failure" twice when using (disabling) -XX:-UseCMSCompactAtFullCollection Reviewed-by: jwilhelm, ehelin, brutisso ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp Changeset: 71f619500f9b Author: kevinw Date: 2013-03-11 15:37 +0100 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/71f619500f9b Merge Changeset: 1c88b99a2b01 Author: mgerdin Date: 2013-03-12 09:42 +0100 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/1c88b99a2b01 8009282: Assertion "assert(used_and_free == capacity_bytes) failed: Accounting is wrong" failed with -XX:+Verbose -XX:+TraceMetadataChunkAllocation Summary: Assertion is only valid when at a safepoint, adjust accordingly. Reviewed-by: stefank, jmasa, tamao ! src/share/vm/memory/metaspace.cpp Changeset: ca9580859cf4 Author: stefank Date: 2013-03-11 02:24 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/ca9580859cf4 8004697: SIGSEGV on Solaris sparc with -XX:+UseNUMA Summary: Don't scan pages outside the given range. Reviewed-by: jwilhelm, jmasa ! src/os/solaris/vm/os_solaris.cpp ! src/share/vm/gc_implementation/shared/mutableNUMASpace.cpp Changeset: 62609ffa2fc6 Author: tschatzl Date: 2013-03-12 15:10 +0100 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/62609ffa2fc6 8008684: CMS: concurrent phase start markers should always be printed Summary: Print the concurrent phase start markers for CMS when PrintGCDetails is enabled, not only if both PrintGCDetails and PrintGCTimeStamps are. Reviewed-by: mgerdin, jmasa ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp Changeset: eac371996b44 Author: brutisso Date: 2013-03-12 08:33 +0100 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/eac371996b44 8001049: VM crashes when running with large -Xms and not specifying ObjectAlignmentInBytes Summary: Take the initial heap size into account when checking the heap size for compressed oops Reviewed-by: jmasa, kvn, hseigel, ctornqvi ! src/share/vm/memory/universe.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/arguments.hpp Changeset: 993d878108d9 Author: brutisso Date: 2013-03-13 05:14 +0100 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/993d878108d9 Merge Changeset: 82657b6a8cc0 Author: jmasa Date: 2013-03-12 11:00 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/82657b6a8cc0 6976528: PS: assert(!limit_exceeded || softrefs_clear) failed: Should have been cleared Reviewed-by: johnc ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.cpp ! src/share/vm/memory/collectorPolicy.cpp Changeset: 15401203db6b Author: stefank Date: 2013-03-15 08:57 +0100 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/15401203db6b Merge ! src/os/solaris/vm/os_solaris.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/memory/metaspace.cpp ! src/share/vm/runtime/arguments.cpp Changeset: a10dc1469c3f Author: stefank Date: 2013-03-15 04:39 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/a10dc1469c3f Merge Changeset: 0631ebcc45f0 Author: amurillo Date: 2013-03-15 11:18 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/0631ebcc45f0 Merge ! src/share/vm/runtime/arguments.cpp Changeset: 3db4ab0e12f4 Author: amurillo Date: 2013-03-15 11:18 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/3db4ab0e12f4 Added tag hs25-b23 for changeset 0631ebcc45f0 ! .hgtags From erik.joelsson at oracle.com Thu Mar 21 11:49:34 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 21 Mar 2013 12:49:34 +0100 Subject: RFR: 8010465: Can't enable sjavac when building in jprt. Message-ID: <514AF3CE.8020202@oracle.com> This patch makes it possible to enable sjavac in jprt runs. This is achieved by adding -buildenv ENABLE_SJAVAC=true to the jprt command line. http://cr.openjdk.java.net/~erikj/8010465/webrev.root.01/ Doing this uncovered another bug. Adding the keyword "nofile" to the LOG variable is done to disable logging build output to a file. JPRT does this on all build runs since it already saves the build output. The value of LOG is also sent to sjavac to help it filter its output, but sjavac does not accept "nofile" as input. The logic to remove "nofile" before sending it to sjavac didn't work and is also fixed in this patch. The sad news is that all the windows builds currently fail with sjavac enabled, but having this feature will help us harden sjavac to the point where we can make the switch. /Erik From bradford.wetmore at oracle.com Thu Mar 21 22:12:10 2013 From: bradford.wetmore at oracle.com (Brad Wetmore) Date: Thu, 21 Mar 2013 15:12:10 -0700 Subject: RFR 8009517: Disable fatal compiler warning in the old build In-Reply-To: <5147BF89.7000602@oracle.com> References: <5139E680.6000606@oracle.com> <513A0A96.7080508@oracle.com> <513A8194.9040002@oracle.com> <513AEEBB.2080900@oracle.com> <5147BF89.7000602@oracle.com> Message-ID: <514B85BA.5000302@oracle.com> David, Plugin's integration next week is now also impacted since they also have to use the old build environment, so it's time to resolve this. So here's an update/proposal/webrev. The original bug filed by David Katleman was: 8009517: build-infra: jdk8: -Werror not being applied to nio builds and I filed: 8010434: Old build environment no longer builds. I've closed mine, and will integrate against the former. In my partial (JDK) build using the old mechanism and the current TL JDK/langtools gate, only two changes are now necessary. I propose we disable -deprecation in jdk/makejavax/others, and -overrides in make/com/sun/org/apache/xml. The first *LIKELY* crept in due to a recent change in the Base64 code which no longer implicitly compiles sun/misc/CharacterDecoder.java without -Werror active. The original deprecation issue needs to be addressed sometime by the responsible team, but that will avoid RE having to hand edit to the Makefiles just to build JCE. The second change is due to the compiler change with hashCode/equals. The codereview is here: http://cr.openjdk.java.net/~wetmore/8009517/webrev.00/ I plan to push through the deploy gate, as they have an integration next week. Thomas Ng will do the push for us. Any objections, please speak now. Brad On 3/18/2013 6:29 PM, Brad Wetmore wrote: > Sorry for the delay in response, I've been pulled in yet another > direction, and this has come back up in priority. > > On 3/9/2013 12:11 AM, Chris Hegarty wrote: >>> I agree about warning creeping problems. This is a temporary solution, >>> we should soon be fixing the underlying hashcode/equals >>> problems...but... >> >> Your temporary solution, -overrides, is just that. It will enable the >> old build to complete today, but it could fail at any point in the >> future, as the code changes. > > Correct. As it stands today, a recent change now requires *BOTH* > overrides/deprecation in order to get a complete MASTER build using the > old build system. > > [brwetmor at flicker-vm1] 222 >hg diff common/shared/Defs-java.gmk > diff --git a/make/common/shared/Defs-java.gmk > b/make/common/shared/Defs-java.gmk > --- a/make/common/shared/Defs-java.gmk > +++ b/make/common/shared/Defs-java.gmk > @@ -127,7 +127,7 @@ > endif > > # TODO: Workaround for CR 7063027. Remove -path eventually. > -JAVAC_LINT_OPTIONS += -Xlint:-path > +JAVAC_LINT_OPTIONS += -Xlint:-path,-overrides,-deprecation > > JAVACFLAGS += $(JAVAC_LINT_OPTIONS) > >> For example, java.net is currently warning free, in the old it compiles >> with fatal warnings enabled. Lets say, in a moment of madness, I add a >> dependency from java.net.Socket to say java.awt.RenderingHints.Key ( or >> any class that produces warnings when compiled. I run the new build, all >> is fine. Push the changes. Now someone else sync's up, but need to build >> using the old build. If the new dependent class is not already compiled >> before java.net.Socket gets compiled, it will be compiled implicitly. >> It's warnings will cause the compile to fail, and the old build will >> fail. Or much simpler, anyone could write sloppy code with warnings, the >> new build will suppress them, and they won't notice. Push this code, and >> the old build will fail if is explicitly, or implicitly, compiles this >> code with -Werror enabled. > > Exactly. Our formerly clean code now requires disabling of two Lint > options, but the new build is happy just to report the warning. The old > build crashes on the warning. > > Our options for the old build system are: > > 1. disable the warning for overrides/deprecation, keep -Werror (my > preferred since these are minor warnings.) > 2. Somehow disable -Werror on these new directories that are now > failing. (more work to figure out, but also acceptable) > 3. Fix the warnings. (I don't have cycles to drive a rewrite of use of > deprecated code and/or add missing equals/hashcode that the recent javac > changes exposed.) > >>> We >>> spent a lot of time cleaning up many directories, seems a shame to start >>> allowing non-fatal warnings to come back into previously clean code >>> because people aren't taking the time to fix new warnings as they are >>> introduced. >> >> I personally spent several weeks over the past number of years fixing >> warnings and reviewing warning cleanup webrevs from others. I took much >> pride in keeping certain areas warnings free. >> >> It is with great regret that I propose to disable fatal warnings in the >> old build, but I felt this the best/safest option. I heard much >> annoyance and frustration from others about hitting seemingly random >> errors with the old build recently. This is the only sure way to avoid >> that. >> >>> The new builds will still warn, but the >>> old builds will still fail for all but these override problems. Yes, >>> you lose the warnings in the old, but seems better than completely >>> shutting off erroring. >> >> I'm ok with that, if others are. To clarify, I think you are suggesting >> that we keep the old build as it, with -overrides, > > and now ",-deprecation" :( > >> and use it >> periodically as a way of tracking new warnings being introduced into >> areas that were warning free. > > That would be a side-effect, as someone would occasionally need to > figure out what's changed. > > The main issue we're hitting right now is that RE has to make several > source code changes in order to build JCE jar files without errors. I > was able to change the individual LINT options globally and reduce it > down to one change, but that's still one change that RE has to make. I > feel that RE should not be making any changes, but that ship has already > sailed and we're stuck with the results now. > > That is, if the old build fails because of >> a fatal warning, so be it. File a bug and fix the source code. Then the >> old build will work again. This means that at any point in time the old >> build cannot be guaranteed to be buildable. >> >> Everyone seems to agree, a solution needs to be found to allow us to >> keep certain areas warning free. This issue is too important, and too >> much time was spent, to allow it to regress to the state it was in a few >> years ago. > > It's already started. > > Brad > > >> -Chris. >> >>> >>> (Ideally it would be nice to warn but not fail on just this one lint >>> option, but don't see how that's possible.) >>> >>> Brad >>> >>> >>> >>> >>> >>>> -Chris. >>>> >>>>> >>>>> Mike >>>>> >>>>> On Mar 8 2013, at 05:24 , Chris Hegarty wrote: >>>>> >>>>>> Since the new build does not enable -Werror when compiling any java >>>>>> code, and disables quite a few lint options, new changes my >>>>>> inadvertently introduce warnings without even realizing. This can >>>>>> cause problems when building with the old build as many areas do >>>>>> compile with -Werror set. Since the old build is on life support, >>>>>> probably best to just completely disable -Werror, so anyone still >>>>>> needing to use it can. >>>>>> >>>>>> diff -r 48b7295f02f8 make/common/shared/Defs-java.gmk >>>>>> --- a/make/common/shared/Defs-java.gmk Thu Mar 07 10:07:13 2013 >>>>>> +0000 >>>>>> +++ b/make/common/shared/Defs-java.gmk Thu Mar 07 11:10:37 2013 >>>>>> +0000 >>>>>> @@ -122,9 +122,10 @@ ifeq ($(JAVAC_MAX_WARNINGS), true) >>>>>> ifeq ($(JAVAC_MAX_WARNINGS), true) >>>>>> JAVAC_LINT_OPTIONS += -Xlint:all >>>>>> endif >>>>>> -ifeq ($(JAVAC_WARNINGS_FATAL), true) >>>>>> - JAVACFLAGS += -Werror >>>>>> -endif >>>>>> +# Disable fatal warnings, 8009517 >>>>>> +#ifeq ($(JAVAC_WARNINGS_FATAL), true) >>>>>> +# JAVACFLAGS += -Werror >>>>>> +#endif >>>>>> >>>>>> # TODO: Workaround for CR 7063027. Remove -path eventually. >>>>>> JAVAC_LINT_OPTIONS += -Xlint:-path >>>>>> >>>>>> -Chris. >>>>> From mike.duigou at oracle.com Thu Mar 21 22:28:56 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Thu, 21 Mar 2013 15:28:56 -0700 Subject: RFR 8009517: Disable fatal compiler warning in the old build In-Reply-To: <514B85BA.5000302@oracle.com> References: <5139E680.6000606@oracle.com> <513A0A96.7080508@oracle.com> <513A8194.9040002@oracle.com> <513AEEBB.2080900@oracle.com> <5147BF89.7000602@oracle.com> <514B85BA.5000302@oracle.com> Message-ID: <52EFE005-18D9-4FD6-9218-21AFFEBFD5B0@oracle.com> This looks fine. Get it in before something else changes! Mike On Mar 21 2013, at 15:12 , Brad Wetmore wrote: > David, > > Plugin's integration next week is now also impacted since they also have to use the old build environment, so it's time to resolve this. So here's an update/proposal/webrev. > > The original bug filed by David Katleman was: > > 8009517: build-infra: jdk8: -Werror not being applied to nio builds > > and I filed: > > 8010434: Old build environment no longer builds. > > I've closed mine, and will integrate against the former. > > In my partial (JDK) build using the old mechanism and the current TL JDK/langtools gate, only two changes are now necessary. > > I propose we disable -deprecation in jdk/makejavax/others, and -overrides in make/com/sun/org/apache/xml. > > The first *LIKELY* crept in due to a recent change in the Base64 code which no longer implicitly compiles sun/misc/CharacterDecoder.java without -Werror active. The original deprecation issue needs to be addressed sometime by the responsible team, but that will avoid RE having to hand edit to the Makefiles just to build JCE. > > The second change is due to the compiler change with hashCode/equals. > > The codereview is here: > > http://cr.openjdk.java.net/~wetmore/8009517/webrev.00/ > > I plan to push through the deploy gate, as they have an integration next week. Thomas Ng will do the push for us. > > Any objections, please speak now. > > Brad > > > > On 3/18/2013 6:29 PM, Brad Wetmore wrote: >> Sorry for the delay in response, I've been pulled in yet another >> direction, and this has come back up in priority. >> >> On 3/9/2013 12:11 AM, Chris Hegarty wrote: >>>> I agree about warning creeping problems. This is a temporary solution, >>>> we should soon be fixing the underlying hashcode/equals >>>> problems...but... >>> >>> Your temporary solution, -overrides, is just that. It will enable the >>> old build to complete today, but it could fail at any point in the >>> future, as the code changes. >> >> Correct. As it stands today, a recent change now requires *BOTH* >> overrides/deprecation in order to get a complete MASTER build using the >> old build system. >> >> [brwetmor at flicker-vm1] 222 >hg diff common/shared/Defs-java.gmk >> diff --git a/make/common/shared/Defs-java.gmk >> b/make/common/shared/Defs-java.gmk >> --- a/make/common/shared/Defs-java.gmk >> +++ b/make/common/shared/Defs-java.gmk >> @@ -127,7 +127,7 @@ >> endif >> >> # TODO: Workaround for CR 7063027. Remove -path eventually. >> -JAVAC_LINT_OPTIONS += -Xlint:-path >> +JAVAC_LINT_OPTIONS += -Xlint:-path,-overrides,-deprecation >> >> JAVACFLAGS += $(JAVAC_LINT_OPTIONS) >> >>> For example, java.net is currently warning free, in the old it compiles >>> with fatal warnings enabled. Lets say, in a moment of madness, I add a >>> dependency from java.net.Socket to say java.awt.RenderingHints.Key ( or >>> any class that produces warnings when compiled. I run the new build, all >>> is fine. Push the changes. Now someone else sync's up, but need to build >>> using the old build. If the new dependent class is not already compiled >>> before java.net.Socket gets compiled, it will be compiled implicitly. >>> It's warnings will cause the compile to fail, and the old build will >>> fail. Or much simpler, anyone could write sloppy code with warnings, the >>> new build will suppress them, and they won't notice. Push this code, and >>> the old build will fail if is explicitly, or implicitly, compiles this >>> code with -Werror enabled. >> >> Exactly. Our formerly clean code now requires disabling of two Lint >> options, but the new build is happy just to report the warning. The old >> build crashes on the warning. >> >> Our options for the old build system are: >> >> 1. disable the warning for overrides/deprecation, keep -Werror (my >> preferred since these are minor warnings.) >> 2. Somehow disable -Werror on these new directories that are now >> failing. (more work to figure out, but also acceptable) >> 3. Fix the warnings. (I don't have cycles to drive a rewrite of use of >> deprecated code and/or add missing equals/hashcode that the recent javac >> changes exposed.) >> >>>> We >>>> spent a lot of time cleaning up many directories, seems a shame to start >>>> allowing non-fatal warnings to come back into previously clean code >>>> because people aren't taking the time to fix new warnings as they are >>>> introduced. >>> >>> I personally spent several weeks over the past number of years fixing >>> warnings and reviewing warning cleanup webrevs from others. I took much >>> pride in keeping certain areas warnings free. >>> >>> It is with great regret that I propose to disable fatal warnings in the >>> old build, but I felt this the best/safest option. I heard much >>> annoyance and frustration from others about hitting seemingly random >>> errors with the old build recently. This is the only sure way to avoid >>> that. >>> >>>> The new builds will still warn, but the >>>> old builds will still fail for all but these override problems. Yes, >>>> you lose the warnings in the old, but seems better than completely >>>> shutting off erroring. >>> >>> I'm ok with that, if others are. To clarify, I think you are suggesting >>> that we keep the old build as it, with -overrides, >> >> and now ",-deprecation" :( >> >>> and use it >>> periodically as a way of tracking new warnings being introduced into >>> areas that were warning free. >> >> That would be a side-effect, as someone would occasionally need to >> figure out what's changed. >> >> The main issue we're hitting right now is that RE has to make several >> source code changes in order to build JCE jar files without errors. I >> was able to change the individual LINT options globally and reduce it >> down to one change, but that's still one change that RE has to make. I >> feel that RE should not be making any changes, but that ship has already >> sailed and we're stuck with the results now. >> >> That is, if the old build fails because of >>> a fatal warning, so be it. File a bug and fix the source code. Then the >>> old build will work again. This means that at any point in time the old >>> build cannot be guaranteed to be buildable. >>> >>> Everyone seems to agree, a solution needs to be found to allow us to >>> keep certain areas warning free. This issue is too important, and too >>> much time was spent, to allow it to regress to the state it was in a few >>> years ago. >> >> It's already started. >> >> Brad >> >> >>> -Chris. >>> >>>> >>>> (Ideally it would be nice to warn but not fail on just this one lint >>>> option, but don't see how that's possible.) >>>> >>>> Brad >>>> >>>> >>>> >>>> >>>> >>>>> -Chris. >>>>> >>>>>> >>>>>> Mike >>>>>> >>>>>> On Mar 8 2013, at 05:24 , Chris Hegarty wrote: >>>>>> >>>>>>> Since the new build does not enable -Werror when compiling any java >>>>>>> code, and disables quite a few lint options, new changes my >>>>>>> inadvertently introduce warnings without even realizing. This can >>>>>>> cause problems when building with the old build as many areas do >>>>>>> compile with -Werror set. Since the old build is on life support, >>>>>>> probably best to just completely disable -Werror, so anyone still >>>>>>> needing to use it can. >>>>>>> >>>>>>> diff -r 48b7295f02f8 make/common/shared/Defs-java.gmk >>>>>>> --- a/make/common/shared/Defs-java.gmk Thu Mar 07 10:07:13 2013 >>>>>>> +0000 >>>>>>> +++ b/make/common/shared/Defs-java.gmk Thu Mar 07 11:10:37 2013 >>>>>>> +0000 >>>>>>> @@ -122,9 +122,10 @@ ifeq ($(JAVAC_MAX_WARNINGS), true) >>>>>>> ifeq ($(JAVAC_MAX_WARNINGS), true) >>>>>>> JAVAC_LINT_OPTIONS += -Xlint:all >>>>>>> endif >>>>>>> -ifeq ($(JAVAC_WARNINGS_FATAL), true) >>>>>>> - JAVACFLAGS += -Werror >>>>>>> -endif >>>>>>> +# Disable fatal warnings, 8009517 >>>>>>> +#ifeq ($(JAVAC_WARNINGS_FATAL), true) >>>>>>> +# JAVACFLAGS += -Werror >>>>>>> +#endif >>>>>>> >>>>>>> # TODO: Workaround for CR 7063027. Remove -path eventually. >>>>>>> JAVAC_LINT_OPTIONS += -Xlint:-path >>>>>>> >>>>>>> -Chris. >>>>>> From Alan.Bateman at oracle.com Fri Mar 22 08:34:23 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 22 Mar 2013 08:34:23 +0000 Subject: RFR 8009517: Disable fatal compiler warning in the old build In-Reply-To: <514B85BA.5000302@oracle.com> References: <5139E680.6000606@oracle.com> <513A0A96.7080508@oracle.com> <513A8194.9040002@oracle.com> <513AEEBB.2080900@oracle.com> <5147BF89.7000602@oracle.com> <514B85BA.5000302@oracle.com> Message-ID: <514C178F.4000401@oracle.com> On 21/03/2013 22:12, Brad Wetmore wrote: > : > > The codereview is here: > > http://cr.openjdk.java.net/~wetmore/8009517/webrev.00/ > > I plan to push through the deploy gate, as they have an integration > next week. Thomas Ng will do the push for us. > > Any objections, please speak now. No objection here but just to mention that since you need to set NEWBUILD=false then it might not be too much extra to also set JAVAC_WARNINGS_FATAL=false. In any case, I think it would be desirable if there was a retirement date set for the old build so that the remaining users (I assume very few at this point) have something to aim for. -Alan. From bradford.wetmore at oracle.com Fri Mar 22 19:10:46 2013 From: bradford.wetmore at oracle.com (Brad Wetmore) Date: Fri, 22 Mar 2013 12:10:46 -0700 Subject: RFR 8009517: Disable fatal compiler warning in the old build In-Reply-To: <514C178F.4000401@oracle.com> References: <5139E680.6000606@oracle.com> <513A0A96.7080508@oracle.com> <513A8194.9040002@oracle.com> <513AEEBB.2080900@oracle.com> <5147BF89.7000602@oracle.com> <514B85BA.5000302@oracle.com> <514C178F.4000401@oracle.com> Message-ID: <514CACB6.6060106@oracle.com> On 3/22/2013 1:34 AM, Alan Bateman wrote: > On 21/03/2013 22:12, Brad Wetmore wrote: >> : >> >> The codereview is here: >> >> http://cr.openjdk.java.net/~wetmore/8009517/webrev.00/ >> >> I plan to push through the deploy gate, as they have an integration >> next week. Thomas Ng will do the push for us. >> >> Any objections, please speak now. > No objection here but just to mention that since you need to set > NEWBUILD=false then it might not be too much extra to also set > JAVAC_WARNINGS_FATAL=false. At least for me, I'm not using the new build environment at all. (I think RE is doing the same when building the JCE jar files): % cd jdk/make % make381 all That is, NEWBUILD doesn't exist in this build hierarchy. As for adding JAVAC_WARNINGS_FATAL=false, I thought we were keeping warnings fatal here to so that folks running builds in this environment can the developers know they are introducing warnings/crud into their code? > In any case, I think it would be desirable if there was a retirement > date set for the old build so that the remaining users (I assume very > few at this point) have something to aim for. Erik is now more aware of our JCE build problems, so hopefully we won't be far behind. I was surprised to hear deploy still has the dependency. Brad From daniel.fuchs at oracle.com Mon Mar 25 11:45:30 2013 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Mon, 25 Mar 2013 12:45:30 +0100 Subject: JDK-8010495: Update JAXP NetBeans project - add support for generating javadoc Message-ID: <515038DA.3010802@oracle.com> Hi guys, I'd like to propose a small change to jaxp/build.xml and jaxp/nbproject/project.xml - in order to allow editing JAXP sources in NetBeans, as well as generating the JAXP javadoc for previewing purposes. I actually stole the javadoc target from jdk/make/netbeans/common/shared.xml The changes are small & targeted at developers. There should be no impact on the build process. Here is the webrev: http://cr.openjdk.java.net/~dfuchs/JDK-8010495/jdk8/webrev.00/ best regards, -- daniel From huizhe.wang at oracle.com Mon Mar 25 16:20:22 2013 From: huizhe.wang at oracle.com (huizhe wang) Date: Mon, 25 Mar 2013 09:20:22 -0700 Subject: JDK-8010495: Update JAXP NetBeans project - add support for generating javadoc In-Reply-To: <515038DA.3010802@oracle.com> References: <515038DA.3010802@oracle.com> Message-ID: <51507946.6050400@oracle.com> Hi Daniel, Thanks for doing this. JAXP doesn't have these packages: "java/", "org/ietf/jgss/", and "org/omg/". Since this is the jaxp repo, it would be fine if only 'javax/' and 'org/' are included, or 'com/' be excluded. Regards, Joe On 3/25/2013 4:45 AM, Daniel Fuchs wrote: > Hi guys, > > I'd like to propose a small change to jaxp/build.xml and > jaxp/nbproject/project.xml - in order to allow editing > JAXP sources in NetBeans, as well as generating the JAXP > javadoc for previewing purposes. > > I actually stole the javadoc target from > jdk/make/netbeans/common/shared.xml > > The changes are small & targeted at developers. > There should be no impact on the build process. > > Here is the webrev: > > http://cr.openjdk.java.net/~dfuchs/JDK-8010495/jdk8/webrev.00/ > > best regards, > > -- daniel From daniel.fuchs at oracle.com Mon Mar 25 16:35:08 2013 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Mon, 25 Mar 2013 17:35:08 +0100 Subject: JDK-8010495: Update JAXP NetBeans project - add support for generating javadoc In-Reply-To: <51507946.6050400@oracle.com> References: <515038DA.3010802@oracle.com> <51507946.6050400@oracle.com> Message-ID: <51507CBC.1070904@oracle.com> On 3/25/13 5:20 PM, huizhe wang wrote: > Hi Daniel, > > Thanks for doing this. > > JAXP doesn't have these packages: "java/", "org/ietf/jgss/", and > "org/omg/". Since this is the jaxp repo, it would be fine if only > 'javax/' and 'org/' are included, or 'com/' be excluded. OK - I just copied the pattern shared by all jdk/make/netbeans projects - but I guess I can safely restrict the list to what is actually present in JAXP. That would make it: 203 204 205 206 207 208 209 210 211 -- daniel > > Regards, > Joe > > On 3/25/2013 4:45 AM, Daniel Fuchs wrote: >> Hi guys, >> >> I'd like to propose a small change to jaxp/build.xml and >> jaxp/nbproject/project.xml - in order to allow editing >> JAXP sources in NetBeans, as well as generating the JAXP >> javadoc for previewing purposes. >> >> I actually stole the javadoc target from >> jdk/make/netbeans/common/shared.xml >> >> The changes are small & targeted at developers. >> There should be no impact on the build process. >> >> Here is the webrev: >> >> http://cr.openjdk.java.net/~dfuchs/JDK-8010495/jdk8/webrev.00/ >> >> best regards, >> >> -- daniel > From huizhe.wang at oracle.com Mon Mar 25 16:52:10 2013 From: huizhe.wang at oracle.com (huizhe wang) Date: Mon, 25 Mar 2013 09:52:10 -0700 Subject: JDK-8010495: Update JAXP NetBeans project - add support for generating javadoc In-Reply-To: <51507CBC.1070904@oracle.com> References: <515038DA.3010802@oracle.com> <51507946.6050400@oracle.com> <51507CBC.1070904@oracle.com> Message-ID: <515080BA.3090000@oracle.com> On 3/25/2013 9:35 AM, Daniel Fuchs wrote: > On 3/25/13 5:20 PM, huizhe wang wrote: >> Hi Daniel, >> >> Thanks for doing this. >> >> JAXP doesn't have these packages: "java/", "org/ietf/jgss/", and >> "org/omg/". Since this is the jaxp repo, it would be fine if only >> 'javax/' and 'org/' are included, or 'com/' be excluded. > > OK - I just copied the pattern shared by all > jdk/make/netbeans projects - but I guess I can safely restrict > the list to what is actually present in JAXP. > > That would make it: > > 203 includes="${includes}" excludes="${excludes}"> > 204 > 205 > 206 > 207 > 208 > 209 > 210 > 211 I'm not familiar with this usage. Does the 'includes' attribute take precedence over the package names in tags? Will they be ignored since 'includes' includes all packages. -Joe > > > -- daniel > >> >> Regards, >> Joe >> >> On 3/25/2013 4:45 AM, Daniel Fuchs wrote: >>> Hi guys, >>> >>> I'd like to propose a small change to jaxp/build.xml and >>> jaxp/nbproject/project.xml - in order to allow editing >>> JAXP sources in NetBeans, as well as generating the JAXP >>> javadoc for previewing purposes. >>> >>> I actually stole the javadoc target from >>> jdk/make/netbeans/common/shared.xml >>> >>> The changes are small & targeted at developers. >>> There should be no impact on the build process. >>> >>> Here is the webrev: >>> >>> http://cr.openjdk.java.net/~dfuchs/JDK-8010495/jdk8/webrev.00/ >>> >>> best regards, >>> >>> -- daniel >> > From gnu.andrew at redhat.com Mon Mar 25 19:49:57 2013 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Mon, 25 Mar 2013 15:49:57 -0400 (EDT) Subject: PING: Re: Code Review Request: Simple new build system fix In-Reply-To: <514088B0.3080702@oracle.com> Message-ID: <704523776.23634640.1364240997123.JavaMail.root@redhat.com> ----- Original Message ----- > > > On 2013-03-13 15:01, Andrew Hughes wrote: > > ----- Original Message ----- > >> Hello, > >> > >> I created a bug for you: > >> > >> 8009988: build-infra: Fix configure output for zip debuginfo check > >> > >> As David says, we haven't decided on 2.67, but I would guess that > >> a > >> majority of the commits have been with that version. This change > >> is a > >> first step towards enforcing a specific version and I'm ok with > >> that. > > Yes, I've been out of the loop a bit on this new build system. > > When I saw the huge diff my first attempt generated, I just assumed > > I should be using the same version that had been used previously. > > > >> The actual fix looks good to. You will still need a JDK reviewer > >> to > >> ok > >> it. Also, please notify me when you push this so that the closed > >> version > >> of the configure script may also be regenerated. > >> > > Ok, no problem. I await a review from someone like David or Kelly. > > > > Is there a preferred tree to push to? I spotted this when just > > trying > > to build so it's against jdk8 at the moment (which I obviously > > can't push > > to). Perhaps build? > > > Please use jdk8/build. > > /Erik > >> /Erik > >> > >> On 2013-03-13 13:18, Andrew Hughes wrote: > >>> I've finally found time to look at the new build system (well, > >>> there seems to no longer be any choice ;) > >>> and so thought I start out with a simple fix. > >>> > >>> http://cr.openjdk.java.net/~andrew/build/zip_debug_info/webrev.01/ > >>> > >>> At the moment, if disable-zip-debug-info is not specified, the > >>> configure output is: > >>> > >>> checking if we should zip debug-info files... > >>> > >>> with no result as $enable_zip_debug_info is unset. > >>> > >>> This simple patch makes the option use the more standard > >>> AC_ARG_ENABLE form used elsewhere and will > >>> print the default ('yes') when the option is unspecified: > >>> > >>> checking if we should zip debug-info files... yes > >>> > >>> What actually took longer than the fix was updating the generated > >>> files. We seem to have already settled > >>> on autoconf 2.67 for generating the configure script, so my > >>> initial > >>> attempt threw up a huge number of changes > >>> as the system install is 2.69. I was able to get it down to > >>> something closer to what is expected by installing > >>> a local copy of 2.67 but it's still not perfect. I don't know > >>> why. > >>> I've never been a fan of including generated > >>> files for this reason. > >>> > >>> So this script also updates autogen.sh to see if there is an > >>> autoconf-2.67 available and use that in preference > >>> to autoconf if it is. I also added a little debug output so we > >>> can > >>> see which autoconf is being used in autogen.sh. > >>> > >>> If this is ok, can you please allocate it a bug ID and let me > >>> know > >>> which tree to commit it to. > >>> > >>> Thanks, > Any progress on this? Still needs a reviewer. -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From Lance.Andersen at oracle.com Mon Mar 25 20:25:38 2013 From: Lance.Andersen at oracle.com (Lance Andersen) Date: Mon, 25 Mar 2013 16:25:38 -0400 Subject: netbeans and openjdk Message-ID: <63D9462D-2B6B-4BD3-89EA-8B93728DEDC3@oracle.com> Hi all, I am trying to set up a netbeans project for JDBC within openjdk leveraging the existing projects that are already in jdk/make/netbeans I have getting the following error and not sure why so wondered if anyone has encountered this before: ------------------------------------------------------ ant -f /Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/make/netbeans/jdbc clean build Deleting directory /Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/build/windows-x86_64/depcache shared.clean: clean: /Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/make/netbeans/common/shared.xml:128: warning: 'includeantruntime' was not set, defaulting to build.sysclasspath=last; set to false for repeatable builds Compiling 96 source files to /Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/build/windows-x86_64/classes warning: [options] bootstrap class path not set in conjunction with -source 1.5 /Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/src/share/classes/javax/sql/rowset/serial/SerialClob.java:148: error: try-with-resources is not supported in -source 1.5 try (Reader charStream = clob.getCharacterStream()) { (use -source 7 or higher to enable try-with-resources) /Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/src/share/classes/javax/sql/rowset/spi/SyncFactory.java:370: error: try-with-resources is not supported in -source 1.5 try (FileInputStream fis = new FileInputStream(ROWSET_PROPERTIES)) { (use -source 7 or higher to enable try-with-resources) 2 errors 1 warning /Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/make/netbeans/common/shared.xml:170: The following error occurred while executing this line: /Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/make/netbeans/common/shared.xml:155: The following error occurred while executing this line: /Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/make/netbeans/common/shared.xml:128: Compile failed; see the compiler error output for details. BUILD FAILED (total time: 2 seconds) ---------------------------------------- If I open the project properties in netbeans, it shows 1.7 source. This is with netbeans 7.3 Best Lance Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From huizhe.wang at oracle.com Mon Mar 25 21:12:55 2013 From: huizhe.wang at oracle.com (huizhe wang) Date: Mon, 25 Mar 2013 14:12:55 -0700 Subject: netbeans and openjdk In-Reply-To: <63D9462D-2B6B-4BD3-89EA-8B93728DEDC3@oracle.com> References: <63D9462D-2B6B-4BD3-89EA-8B93728DEDC3@oracle.com> Message-ID: <5150BDD7.6060804@oracle.com> Hi Lance, Are you setting it up as a free-form project? In a free-form project, the custom build script is separate from those generated by the IDE. Although you can map targets from the custom build script to project actions, you won't see properties such as source in the script reflected in the IDE. Your ide may be configured so that you may right-click and compile selected file using IDE generated scripts, but when you 'build' the whole project, you're using the target in your customer script. In this case, your build script must have defined to compile to source 1.5 that seems to be in the shared.xml. -Joe On 3/25/2013 1:25 PM, Lance Andersen wrote: > Hi all, > > I am trying to set up a netbeans project for JDBC within openjdk leveraging the existing projects that are already in jdk/make/netbeans > > I have getting the following error and not sure why so wondered if anyone has encountered this before: > > ------------------------------------------------------ > > > ant -f /Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/make/netbeans/jdbc clean build > Deleting directory /Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/build/windows-x86_64/depcache > shared.clean: > clean: > /Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/make/netbeans/common/shared.xml:128: warning: 'includeantruntime' was not set, defaulting to build.sysclasspath=last; set to false for repeatable builds > Compiling 96 source files to /Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/build/windows-x86_64/classes > warning: [options] bootstrap class path not set in conjunction with -source 1.5 > /Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/src/share/classes/javax/sql/rowset/serial/SerialClob.java:148: error: try-with-resources is not supported in -source 1.5 > try (Reader charStream = clob.getCharacterStream()) { > (use -source 7 or higher to enable try-with-resources) > /Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/src/share/classes/javax/sql/rowset/spi/SyncFactory.java:370: error: try-with-resources is not supported in -source 1.5 > try (FileInputStream fis = new FileInputStream(ROWSET_PROPERTIES)) { > (use -source 7 or higher to enable try-with-resources) > 2 errors > 1 warning > /Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/make/netbeans/common/shared.xml:170: The following error occurred while executing this line: > /Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/make/netbeans/common/shared.xml:155: The following error occurred while executing this line: > /Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/make/netbeans/common/shared.xml:128: Compile failed; see the compiler error output for details. > BUILD FAILED (total time: 2 seconds) > > ---------------------------------------- > > If I open the project properties in netbeans, it shows 1.7 source. This is with netbeans 7.3 > > Best > Lance > > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > > > > From Lance.Andersen at oracle.com Mon Mar 25 21:28:05 2013 From: Lance.Andersen at oracle.com (Lance Andersen) Date: Mon, 25 Mar 2013 17:28:05 -0400 Subject: netbeans and openjdk In-Reply-To: <5150BDD7.6060804@oracle.com> References: <63D9462D-2B6B-4BD3-89EA-8B93728DEDC3@oracle.com> <5150BDD7.6060804@oracle.com> Message-ID: <9A7DF021-1EE6-49B9-81B4-AC2922712313@oracle.com> Hi Joe, On Mar 25, 2013, at 5:12 PM, huizhe wang wrote: > Hi Lance, > > Are you setting it up as a free-form project? In a free-form project, the custom build script is separate from those generated by the IDE. Although you can map targets from the custom build script to project actions, you won't see properties such as source in the script reflected in the IDE. Your ide may be configured so that you may right-click and compile selected file using IDE generated scripts, but when you 'build' the whole project, you're using the target in your customer script. In this case, your build script must have defined to compile to source 1.5 that seems to be in the shared.xml. Yes, I was looking at shared.xml and it has the following So this seems to be the issue. So I changed the values above just now from 1.5 and 1.6 to both be 1.7 Which worked much better. This works in a jdk7 repository. It looks like shared.xml was changed for jdk8 so it does not have the values above. Also, do you know why if this is on osx it is building in Copying 3 files to /Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/build/windows-x86_64/classes Building jar: /Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/dist/lib/jdb42.jar Thank you for your time Joe Best Lance > -Joe > > On 3/25/2013 1:25 PM, Lance Andersen wrote: >> Hi all, >> >> I am trying to set up a netbeans project for JDBC within openjdk leveraging the existing projects that are already in jdk/make/netbeans >> >> I have getting the following error and not sure why so wondered if anyone has encountered this before: >> >> ------------------------------------------------------ >> >> >> ant -f /Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/make/netbeans/jdbc clean build >> Deleting directory /Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/build/windows-x86_64/depcache >> shared.clean: >> clean: >> /Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/make/netbeans/common/shared.xml:128: warning: 'includeantruntime' was not set, defaulting to build.sysclasspath=last; set to false for repeatable builds >> Compiling 96 source files to /Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/build/windows-x86_64/classes >> warning: [options] bootstrap class path not set in conjunction with -source 1.5 >> /Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/src/share/classes/javax/sql/rowset/serial/SerialClob.java:148: error: try-with-resources is not supported in -source 1.5 >> try (Reader charStream = clob.getCharacterStream()) { >> (use -source 7 or higher to enable try-with-resources) >> /Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/src/share/classes/javax/sql/rowset/spi/SyncFactory.java:370: error: try-with-resources is not supported in -source 1.5 >> try (FileInputStream fis = new FileInputStream(ROWSET_PROPERTIES)) { >> (use -source 7 or higher to enable try-with-resources) >> 2 errors >> 1 warning >> /Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/make/netbeans/common/shared.xml:170: The following error occurred while executing this line: >> /Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/make/netbeans/common/shared.xml:155: The following error occurred while executing this line: >> /Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/make/netbeans/common/shared.xml:128: Compile failed; see the compiler error output for details. >> BUILD FAILED (total time: 2 seconds) >> >> ---------------------------------------- >> >> If I open the project properties in netbeans, it shows 1.7 source. This is with netbeans 7.3 >> >> Best >> Lance >> >> >> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 >> Oracle Java Engineering >> 1 Network Drive >> Burlington, MA 01803 >> Lance.Andersen at oracle.com >> >> >> >> > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From huizhe.wang at oracle.com Mon Mar 25 21:45:54 2013 From: huizhe.wang at oracle.com (huizhe wang) Date: Mon, 25 Mar 2013 14:45:54 -0700 Subject: netbeans and openjdk In-Reply-To: <9A7DF021-1EE6-49B9-81B4-AC2922712313@oracle.com> References: <63D9462D-2B6B-4BD3-89EA-8B93728DEDC3@oracle.com> <5150BDD7.6060804@oracle.com> <9A7DF021-1EE6-49B9-81B4-AC2922712313@oracle.com> Message-ID: <5150C592.5050200@oracle.com> Hi Lance, On 3/25/2013 2:28 PM, Lance Andersen wrote: > Hi Joe, > > On Mar 25, 2013, at 5:12 PM, huizhe wang > wrote: > >> Hi Lance, >> >> Are you setting it up as a free-form project? In a free-form >> project, the custom build script is separate from those generated by >> the IDE. Although you can map targets from the custom build script >> to project actions, you won't see properties such as source in the >> script reflected in the IDE. Your ide may be configured so that you >> may right-click and compile selected file using IDE generated >> scripts, but when you 'build' the whole project, you're using the >> target in your customer script. In this case, your build script must >> have defined to compile to source 1.5 that seems to be in the shared.xml. > > Yes, I was looking at shared.xml and it has the following > > > > > > > > > excludes="@{excludes}" sourcepath="" > destdir="@{classesdir}" fork="true" > executable="${bootstrap.javac}" > debug="${javac.debug}" > debuglevel="${javac.debuglevel}"> > > > > > > > > > > > So this seems to be the issue. > > So I changed the values above just now from 1.5 and 1.6 to both be 1.7 > > Which worked much better. > > > This works in a jdk7 repository. > > It looks like shared.xml was changed for jdk8 so it does not have the > values above. That makes sense. I mean we specify source/target levels for the standalone, endorsed technologies so that they may be used in older JDKs. But for scripts doing that inside the JDK, that's kind of interesting :-) > > > Also, do you know why if this is on osx it is building in > > Copying 3 files to > /Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/build/windows-x86_64/classes > Building jar: > /Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/dist/lib/jdb42.jar I'm not familiar with the script. But it seems to me there's no support for OSX in the script that you're using. Was windows-x86_64 the default value? > > > Thank you for your time Joe You're very welcome. Best, Joe > > Best > Lance >> -Joe >> >> On 3/25/2013 1:25 PM, Lance Andersen wrote: >>> Hi all, >>> >>> I am trying to set up a netbeans project for JDBC within openjdk >>> leveraging the existing projects that are already in jdk/make/netbeans >>> >>> I have getting the following error and not sure why so wondered if >>> anyone has encountered this before: >>> >>> ------------------------------------------------------ >>> >>> >>> ant -f >>> /Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/make/netbeans/jdbc >>> clean build >>> Deleting directory >>> /Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/build/windows-x86_64/depcache >>> shared.clean: >>> clean: >>> /Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/make/netbeans/common/shared.xml:128: >>> warning: 'includeantruntime' was not set, defaulting to >>> build.sysclasspath=last; set to false for repeatable builds >>> Compiling 96 source files to >>> /Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/build/windows-x86_64/classes >>> warning: [options] bootstrap class path not set in conjunction with >>> -source 1.5 >>> /Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/src/share/classes/javax/sql/rowset/serial/SerialClob.java:148: >>> error: try-with-resources is not supported in -source 1.5 >>> try (Reader charStream = clob.getCharacterStream()) { >>> (use -source 7 or higher to enable try-with-resources) >>> /Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/src/share/classes/javax/sql/rowset/spi/SyncFactory.java:370: >>> error: try-with-resources is not supported in -source 1.5 >>> try (FileInputStream fis = new >>> FileInputStream(ROWSET_PROPERTIES)) { >>> (use -source 7 or higher to enable try-with-resources) >>> 2 errors >>> 1 warning >>> /Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/make/netbeans/common/shared.xml:170: >>> The following error occurred while executing this line: >>> /Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/make/netbeans/common/shared.xml:155: >>> The following error occurred while executing this line: >>> /Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/make/netbeans/common/shared.xml:128: >>> Compile failed; see the compiler error output for details. >>> BUILD FAILED (total time: 2 seconds) >>> >>> ---------------------------------------- >>> >>> If I open the project properties in netbeans, it shows 1.7 source. >>> This is with netbeans 7.3 >>> >>> Best >>> Lance >>> >>> >>> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 >>> Oracle Java Engineering >>> 1 Network Drive >>> Burlington, MA 01803 >>> Lance.Andersen at oracle.com >>> >>> >>> >>> >> > > > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > > > > > From Lance.Andersen at oracle.com Mon Mar 25 21:53:13 2013 From: Lance.Andersen at oracle.com (Lance Andersen) Date: Mon, 25 Mar 2013 17:53:13 -0400 Subject: netbeans and openjdk In-Reply-To: <9A7DF021-1EE6-49B9-81B4-AC2922712313@oracle.com> References: <63D9462D-2B6B-4BD3-89EA-8B93728DEDC3@oracle.com> <5150BDD7.6060804@oracle.com> <9A7DF021-1EE6-49B9-81B4-AC2922712313@oracle.com> Message-ID: On Mar 25, 2013, at 5:28 PM, Lance Andersen wrote: > Hi Joe, > > On Mar 25, 2013, at 5:12 PM, huizhe wang wrote: > >> Hi Lance, >> >> Are you setting it up as a free-form project? In a free-form project, the custom build script is separate from those generated by the IDE. Although you can map targets from the custom build script to project actions, you won't see properties such as source in the script reflected in the IDE. Your ide may be configured so that you may right-click and compile selected file using IDE generated scripts, but when you 'build' the whole project, you're using the target in your customer script. In this case, your build script must have defined to compile to source 1.5 that seems to be in the shared.xml. > > Yes, I was looking at shared.xml and it has the following > > > > > > > > > destdir="@{classesdir}" fork="true" executable="${bootstrap.javac}" > debug="${javac.debug}" debuglevel="${javac.debuglevel}"> > > > > > > > > > > > So this seems to be the issue. > > So I changed the values above just now from 1.5 and 1.6 to both be 1.7 > > Which worked much better. > > > This works in a jdk7 repository. > > It looks like shared.xml was changed for jdk8 so it does not have the values above. > > > Also, do you know why if this is on osx it is building in > > Copying 3 files to /Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/build/windows-x86_64/classes > Building jar: /Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/dist/lib/jdb42.jar > This appears due to the following error which you see with verbose on for ant Unable to find property file: /Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/make/netbeans/common/architectures/name-Mac OS X.properties The actual file name the jdk make/netbeans/architectures is name-Macosx.properties The culprit seems to be the -project-init target in shared.xml Now perhaps this is a difference between OSX versions? I will have to try on my work machine as this is my home system which is Mountain Lion and my work is Snow Leopard Best Lance > > Thank you for your time Joe > > Best > Lance >> -Joe >> >> On 3/25/2013 1:25 PM, Lance Andersen wrote: >>> Hi all, >>> >>> I am trying to set up a netbeans project for JDBC within openjdk leveraging the existing projects that are already in jdk/make/netbeans >>> >>> I have getting the following error and not sure why so wondered if anyone has encountered this before: >>> >>> ------------------------------------------------------ >>> >>> >>> ant -f /Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/make/netbeans/jdbc clean build >>> Deleting directory /Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/build/windows-x86_64/depcache >>> shared.clean: >>> clean: >>> /Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/make/netbeans/common/shared.xml:128: warning: 'includeantruntime' was not set, defaulting to build.sysclasspath=last; set to false for repeatable builds >>> Compiling 96 source files to /Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/build/windows-x86_64/classes >>> warning: [options] bootstrap class path not set in conjunction with -source 1.5 >>> /Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/src/share/classes/javax/sql/rowset/serial/SerialClob.java:148: error: try-with-resources is not supported in -source 1.5 >>> try (Reader charStream = clob.getCharacterStream()) { >>> (use -source 7 or higher to enable try-with-resources) >>> /Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/src/share/classes/javax/sql/rowset/spi/SyncFactory.java:370: error: try-with-resources is not supported in -source 1.5 >>> try (FileInputStream fis = new FileInputStream(ROWSET_PROPERTIES)) { >>> (use -source 7 or higher to enable try-with-resources) >>> 2 errors >>> 1 warning >>> /Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/make/netbeans/common/shared.xml:170: The following error occurred while executing this line: >>> /Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/make/netbeans/common/shared.xml:155: The following error occurred while executing this line: >>> /Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/make/netbeans/common/shared.xml:128: Compile failed; see the compiler error output for details. >>> BUILD FAILED (total time: 2 seconds) >>> >>> ---------------------------------------- >>> >>> If I open the project properties in netbeans, it shows 1.7 source. This is with netbeans 7.3 >>> >>> Best >>> Lance >>> >>> >>> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 >>> Oracle Java Engineering >>> 1 Network Drive >>> Burlington, MA 01803 >>> Lance.Andersen at oracle.com >>> >>> >>> >>> >> > > > > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > > > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From mike.duigou at oracle.com Mon Mar 25 21:54:52 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Mon, 25 Mar 2013 14:54:52 -0700 Subject: netbeans and openjdk In-Reply-To: <9A7DF021-1EE6-49B9-81B4-AC2922712313@oracle.com> References: <63D9462D-2B6B-4BD3-89EA-8B93728DEDC3@oracle.com> <5150BDD7.6060804@oracle.com> <9A7DF021-1EE6-49B9-81B4-AC2922712313@oracle.com> Message-ID: <04560500-13BB-43C6-9BA3-F080894E54E5@oracle.com> On Mar 25 2013, at 14:28 , Lance Andersen wrote: > > So I changed the values above just now from 1.5 and 1.6 to both be 1.7 > > Which worked much better. > > > This works in a jdk7 repository. > > It looks like shared.xml was changed for jdk8 so it does not have the values above. I made this change in the jdk8 repo. I never thought to backport it to jdk1.7. If you make a patch or webrev I will be happy to review it. > > > Also, do you know why if this is on osx it is building in > > Copying 3 files to /Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/build/windows-x86_64/classes > Building jar: /Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/dist/lib/jdb42.jar The problem is that there is no macos platform or architecture recognition in the common/architectures folder. I tried creating these files in the jdk8 repo but ran into a problem with Ant offering inconsistent environment (depending on whether the boot jdk was Apple's 6 or Oracle's 7). I haven't tried to resolve these problems in jdk8. Mike > > Thank you for your time Joe > > Best > Lance >> -Joe >> >> On 3/25/2013 1:25 PM, Lance Andersen wrote: >>> Hi all, >>> >>> I am trying to set up a netbeans project for JDBC within openjdk leveraging the existing projects that are already in jdk/make/netbeans >>> >>> I have getting the following error and not sure why so wondered if anyone has encountered this before: >>> >>> ------------------------------------------------------ >>> >>> >>> ant -f /Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/make/netbeans/jdbc clean build >>> Deleting directory /Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/build/windows-x86_64/depcache >>> shared.clean: >>> clean: >>> /Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/make/netbeans/common/shared.xml:128: warning: 'includeantruntime' was not set, defaulting to build.sysclasspath=last; set to false for repeatable builds >>> Compiling 96 source files to /Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/build/windows-x86_64/classes >>> warning: [options] bootstrap class path not set in conjunction with -source 1.5 >>> /Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/src/share/classes/javax/sql/rowset/serial/SerialClob.java:148: error: try-with-resources is not supported in -source 1.5 >>> try (Reader charStream = clob.getCharacterStream()) { >>> (use -source 7 or higher to enable try-with-resources) >>> /Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/src/share/classes/javax/sql/rowset/spi/SyncFactory.java:370: error: try-with-resources is not supported in -source 1.5 >>> try (FileInputStream fis = new FileInputStream(ROWSET_PROPERTIES)) { >>> (use -source 7 or higher to enable try-with-resources) >>> 2 errors >>> 1 warning >>> /Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/make/netbeans/common/shared.xml:170: The following error occurred while executing this line: >>> /Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/make/netbeans/common/shared.xml:155: The following error occurred while executing this line: >>> /Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/make/netbeans/common/shared.xml:128: Compile failed; see the compiler error output for details. >>> BUILD FAILED (total time: 2 seconds) >>> >>> ---------------------------------------- >>> >>> If I open the project properties in netbeans, it shows 1.7 source. This is with netbeans 7.3 >>> >>> Best >>> Lance >>> >>> >>> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 >>> Oracle Java Engineering >>> 1 Network Drive >>> Burlington, MA 01803 >>> Lance.Andersen at oracle.com >>> >>> >>> >>> >> > > > > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > > > > From lance.andersen at oracle.com Mon Mar 25 22:04:46 2013 From: lance.andersen at oracle.com (Lance Andersen) Date: Mon, 25 Mar 2013 18:04:46 -0400 Subject: netbeans and openjdk In-Reply-To: <04560500-13BB-43C6-9BA3-F080894E54E5@oracle.com> References: <63D9462D-2B6B-4BD3-89EA-8B93728DEDC3@oracle.com> <5150BDD7.6060804@oracle.com> <9A7DF021-1EE6-49B9-81B4-AC2922712313@oracle.com> <04560500-13BB-43C6-9BA3-F080894E54E5@oracle.com> Message-ID: <9A4255D1-A05A-4116-9EC3-25EED03BDDA2@oracle.com> On Mar 25, 2013, at 5:54 PM, Mike Duigou wrote: > > On Mar 25 2013, at 14:28 , Lance Andersen wrote: >> >> So I changed the values above just now from 1.5 and 1.6 to both be 1.7 >> >> Which worked much better. >> >> >> This works in a jdk7 repository. >> >> It looks like shared.xml was changed for jdk8 so it does not have the values above. > > I made this change in the jdk8 repo. I never thought to backport it to jdk1.7. If you make a patch or webrev I will be happy to review it. Thank you Mike. I will look to make this change and send it for a review > >> >> >> Also, do you know why if this is on osx it is building in >> >> Copying 3 files to /Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/build/windows-x86_64/classes >> Building jar: /Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/dist/lib/jdb42.jar > > The problem is that there is no macos platform or architecture recognition in the common/architectures folder. I tried creating these files in the jdk8 repo but ran into a problem with Ant offering inconsistent environment (depending on whether the boot jdk was Apple's 6 or Oracle's 7). I haven't tried to resolve these problems in jdk8. Thanks for the explanation. I might try to take a look at this after i make the above change best lance > > Mike > > >> >> Thank you for your time Joe >> >> Best >> Lance >>> -Joe >>> >>> On 3/25/2013 1:25 PM, Lance Andersen wrote: >>>> Hi all, >>>> >>>> I am trying to set up a netbeans project for JDBC within openjdk leveraging the existing projects that are already in jdk/make/netbeans >>>> >>>> I have getting the following error and not sure why so wondered if anyone has encountered this before: >>>> >>>> ------------------------------------------------------ >>>> >>>> >>>> ant -f /Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/make/netbeans/jdbc clean build >>>> Deleting directory /Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/build/windows-x86_64/depcache >>>> shared.clean: >>>> clean: >>>> /Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/make/netbeans/common/shared.xml:128: warning: 'includeantruntime' was not set, defaulting to build.sysclasspath=last; set to false for repeatable builds >>>> Compiling 96 source files to /Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/build/windows-x86_64/classes >>>> warning: [options] bootstrap class path not set in conjunction with -source 1.5 >>>> /Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/src/share/classes/javax/sql/rowset/serial/SerialClob.java:148: error: try-with-resources is not supported in -source 1.5 >>>> try (Reader charStream = clob.getCharacterStream()) { >>>> (use -source 7 or higher to enable try-with-resources) >>>> /Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/src/share/classes/javax/sql/rowset/spi/SyncFactory.java:370: error: try-with-resources is not supported in -source 1.5 >>>> try (FileInputStream fis = new FileInputStream(ROWSET_PROPERTIES)) { >>>> (use -source 7 or higher to enable try-with-resources) >>>> 2 errors >>>> 1 warning >>>> /Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/make/netbeans/common/shared.xml:170: The following error occurred while executing this line: >>>> /Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/make/netbeans/common/shared.xml:155: The following error occurred while executing this line: >>>> /Users/lance/Documents/hg-workspaces/jdk7/jdk7u-dev/jdk/make/netbeans/common/shared.xml:128: Compile failed; see the compiler error output for details. >>>> BUILD FAILED (total time: 2 seconds) >>>> >>>> ---------------------------------------- >>>> >>>> If I open the project properties in netbeans, it shows 1.7 source. This is with netbeans 7.3 >>>> >>>> Best >>>> Lance >>>> >>>> >>>> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 >>>> Oracle Java Engineering >>>> 1 Network Drive >>>> Burlington, MA 01803 >>>> Lance.Andersen at oracle.com >>>> >>>> >>>> >>>> >>> >> >> >> >> >> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 >> Oracle Java Engineering >> 1 Network Drive >> Burlington, MA 01803 >> Lance.Andersen at oracle.com >> >> >> >> > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From daniel.fuchs at oracle.com Tue Mar 26 09:04:18 2013 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 26 Mar 2013 10:04:18 +0100 Subject: JDK-8010495: Update JAXP NetBeans project - add support for generating javadoc In-Reply-To: <515080BA.3090000@oracle.com> References: <515038DA.3010802@oracle.com> <51507946.6050400@oracle.com> <51507CBC.1070904@oracle.com> <515080BA.3090000@oracle.com> Message-ID: <51516492.6090401@oracle.com> Hi Joe, On 3/25/13 5:52 PM, huizhe wang wrote: > > On 3/25/2013 9:35 AM, Daniel Fuchs wrote: >> On 3/25/13 5:20 PM, huizhe wang wrote: >>> Hi Daniel, >>> >>> Thanks for doing this. >>> >>> JAXP doesn't have these packages: "java/", "org/ietf/jgss/", and >>> "org/omg/". Since this is the jaxp repo, it would be fine if only >>> 'javax/' and 'org/' are included, or 'com/' be excluded. >> >> OK - I just copied the pattern shared by all >> jdk/make/netbeans projects - but I guess I can safely restrict >> the list to what is actually present in JAXP. >> >> That would make it: >> >> 203 > includes="${includes}" excludes="${excludes}"> >> 204 >> 205 >> 206 >> 207 >> 208 >> 209 >> 210 >> 211 > > I'm not familiar with this usage. Does the 'includes' attribute take > precedence over the package names in tags? Will they be ignored > since 'includes' includes all packages. In other free form projects defined for JDK, 'includes' and 'excludes' are global properties defined in the project's properties file. They control which subset of the sources are considered part of the project - and are used by the compile target, the javadoc target, and also to select which files will be seen in NetBeans, etc... As far as I understand the selector in packageset in the javadoc target defines the subset of the subset of the sources for which javadoc should be generated. So it's a way to scope the sources defined by includes/excludes down to the set of public packages for which api documentation is desired. I think we should keep it like that in JAXP - even though the javadoc target is currently the only target that would be affected by the definition of includes/excludes in jaxp/build.properties. -- daniel > > -Joe > >> >> >> -- daniel >> >>> >>> Regards, >>> Joe >>> >>> On 3/25/2013 4:45 AM, Daniel Fuchs wrote: >>>> Hi guys, >>>> >>>> I'd like to propose a small change to jaxp/build.xml and >>>> jaxp/nbproject/project.xml - in order to allow editing >>>> JAXP sources in NetBeans, as well as generating the JAXP >>>> javadoc for previewing purposes. >>>> >>>> I actually stole the javadoc target from >>>> jdk/make/netbeans/common/shared.xml >>>> >>>> The changes are small & targeted at developers. >>>> There should be no impact on the build process. >>>> >>>> Here is the webrev: >>>> >>>> http://cr.openjdk.java.net/~dfuchs/JDK-8010495/jdk8/webrev.00/ >>>> >>>> best regards, >>>> >>>> -- daniel >>> >> > From joel.franck at oracle.com Tue Mar 26 10:32:59 2013 From: joel.franck at oracle.com (=?ISO-8859-1?Q?Joel_Borggr=E9n-Franck?=) Date: Tue, 26 Mar 2013 11:32:59 +0100 Subject: RFR 8009382: Add JVM_Get{Field|Method}TypeAnnotations In-Reply-To: <51506A98.70103@oracle.com> References: <514C67A9.1060106@oracle.com> <51506A98.70103@oracle.com> Message-ID: <5151795B.7080109@oracle.com> Hi, Also including build-dev since this touches some makefiles. Thanks Dan! see inline, also new webrev: http://cr.openjdk.java.net/~jfranck/8009382/hotspot/webrev.02/ On 03/25/2013 04:17 PM, Daniel D. Daugherty wrote: > On 3/22/13 8:16 AM, Joel Borggr?n-Franck wrote: > make/bsd/makefiles/mapfile-vers-debug > make/linux/makefiles/mapfile-vers-debug > make/linux/makefiles/mapfile-vers-product > make/solaris/makefiles/mapfile-vers > It looks like the other entries are in alpha order so these > two new entries should also be added in alpha order. > Fixed. I also noticed I forgot to update one of the bsd makefiles. > src/share/vm/prims/jvm.cpp > line 1510: return NULL; > nit: indent should be two spaces > > line 1529: assert(false, "cannot find method"); > line 1530: return NULL; // robustness > Normally "robustness" comments flag logic after an assert() > to indicate what we do in product mode to deal with the "bad" > situation without crashing. In this case, we don't try to use > 'm' after discovering that it is NULL so this could be simpler: > > Method* m = InstanceKlass::cast(k)->method_with_idnum(slot); > assert(m != NULL, "cannot find method"); > return m; // caller has to deal with NULL in product mode > > Yes, I realize you only touched the comment here, but it > served to point out the messiness of the existing code. > Good suggestion. Fixed. > line 1551: return NULL; > line 1565: return NULL; > line 1579: return NULL; > nit: indent should be two spaces > > line 1632: return NULL; > line 1613: return NULL; > nit: indent should be two spaces Fixed all indent nits. >> >> A prototype of the jdk changes can be found here: >> http://cr.openjdk.java.net/~jfranck/8009382/jdk/webrev.00/ > > You should use a separate bug ID for the jdk repo changes. This will > prevent confusion between when HSX with these changes is integrated > into JDK8 and when the jdk repo changes are integrated into JDK8. > The JDK changes have a separate bug, sorry if this was unclear. The jdk changes shown are just a proof of concept, intended to highlight that my HotSpot changes have actually been run. I will send out a separate review request in the future for the JDK changes. cheers /Joel From daniel.daugherty at oracle.com Tue Mar 26 13:05:43 2013 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 26 Mar 2013 07:05:43 -0600 Subject: RFR 8009382: Add JVM_Get{Field|Method}TypeAnnotations In-Reply-To: <5151795B.7080109@oracle.com> References: <514C67A9.1060106@oracle.com> <51506A98.70103@oracle.com> <5151795B.7080109@oracle.com> Message-ID: <51519D27.2090900@oracle.com> Thumbs up on the re-review. Dan On 3/26/13 4:32 AM, Joel Borggr?n-Franck wrote: > Hi, > > Also including build-dev since this touches some makefiles. > > Thanks Dan! see inline, also new webrev: > > http://cr.openjdk.java.net/~jfranck/8009382/hotspot/webrev.02/ > > On 03/25/2013 04:17 PM, Daniel D. Daugherty wrote: >> On 3/22/13 8:16 AM, Joel Borggr?n-Franck wrote: > >> make/bsd/makefiles/mapfile-vers-debug >> make/linux/makefiles/mapfile-vers-debug >> make/linux/makefiles/mapfile-vers-product >> make/solaris/makefiles/mapfile-vers >> It looks like the other entries are in alpha order so these >> two new entries should also be added in alpha order. >> > > Fixed. I also noticed I forgot to update one of the bsd makefiles. > >> src/share/vm/prims/jvm.cpp >> line 1510: return NULL; >> nit: indent should be two spaces >> >> line 1529: assert(false, "cannot find method"); >> line 1530: return NULL; // robustness >> Normally "robustness" comments flag logic after an assert() >> to indicate what we do in product mode to deal with the "bad" >> situation without crashing. In this case, we don't try to use >> 'm' after discovering that it is NULL so this could be simpler: >> >> Method* m = >> InstanceKlass::cast(k)->method_with_idnum(slot); >> assert(m != NULL, "cannot find method"); >> return m; // caller has to deal with NULL in product mode >> >> Yes, I realize you only touched the comment here, but it >> served to point out the messiness of the existing code. >> > > Good suggestion. Fixed. > >> line 1551: return NULL; >> line 1565: return NULL; >> line 1579: return NULL; >> nit: indent should be two spaces >> >> line 1632: return NULL; >> line 1613: return NULL; >> nit: indent should be two spaces > > Fixed all indent nits. > >>> >>> A prototype of the jdk changes can be found here: >>> http://cr.openjdk.java.net/~jfranck/8009382/jdk/webrev.00/ >> >> You should use a separate bug ID for the jdk repo changes. This will >> prevent confusion between when HSX with these changes is integrated >> into JDK8 and when the jdk repo changes are integrated into JDK8. >> > > The JDK changes have a separate bug, sorry if this was unclear. The > jdk changes shown are just a proof of concept, intended to highlight > that my HotSpot changes have actually been run. I will send out a > separate review request in the future for the JDK changes. > > cheers > /Joel From rickard.backman at oracle.com Tue Mar 26 13:33:20 2013 From: rickard.backman at oracle.com (=?iso-8859-1?Q?Rickard_B=E4ckman?=) Date: Tue, 26 Mar 2013 14:33:20 +0100 Subject: RFR 8009382: Add JVM_Get{Field|Method}TypeAnnotations In-Reply-To: <5151795B.7080109@oracle.com> References: <514C67A9.1060106@oracle.com> <51506A98.70103@oracle.com> <5151795B.7080109@oracle.com> Message-ID: <4A335290-E3B1-4F03-8A02-AB0C097D39F7@oracle.com> Joel, the change looks good. /R On Mar 26, 2013, at 11:32 AM, Joel Borggr?n-Franck wrote: > Hi, > > Also including build-dev since this touches some makefiles. > > Thanks Dan! see inline, also new webrev: > > http://cr.openjdk.java.net/~jfranck/8009382/hotspot/webrev.02/ > > On 03/25/2013 04:17 PM, Daniel D. Daugherty wrote: >> On 3/22/13 8:16 AM, Joel Borggr?n-Franck wrote: > >> make/bsd/makefiles/mapfile-vers-debug >> make/linux/makefiles/mapfile-vers-debug >> make/linux/makefiles/mapfile-vers-product >> make/solaris/makefiles/mapfile-vers >> It looks like the other entries are in alpha order so these >> two new entries should also be added in alpha order. >> > > Fixed. I also noticed I forgot to update one of the bsd makefiles. > >> src/share/vm/prims/jvm.cpp >> line 1510: return NULL; >> nit: indent should be two spaces >> >> line 1529: assert(false, "cannot find method"); >> line 1530: return NULL; // robustness >> Normally "robustness" comments flag logic after an assert() >> to indicate what we do in product mode to deal with the "bad" >> situation without crashing. In this case, we don't try to use >> 'm' after discovering that it is NULL so this could be simpler: >> >> Method* m = InstanceKlass::cast(k)->method_with_idnum(slot); >> assert(m != NULL, "cannot find method"); >> return m; // caller has to deal with NULL in product mode >> >> Yes, I realize you only touched the comment here, but it >> served to point out the messiness of the existing code. >> > > Good suggestion. Fixed. > >> line 1551: return NULL; >> line 1565: return NULL; >> line 1579: return NULL; >> nit: indent should be two spaces >> >> line 1632: return NULL; >> line 1613: return NULL; >> nit: indent should be two spaces > > Fixed all indent nits. > >>> >>> A prototype of the jdk changes can be found here: >>> http://cr.openjdk.java.net/~jfranck/8009382/jdk/webrev.00/ >> >> You should use a separate bug ID for the jdk repo changes. This will >> prevent confusion between when HSX with these changes is integrated >> into JDK8 and when the jdk repo changes are integrated into JDK8. >> > > The JDK changes have a separate bug, sorry if this was unclear. The jdk changes shown are just a proof of concept, intended to highlight that my HotSpot changes have actually been run. I will send out a separate review request in the future for the JDK changes. > > cheers > /Joel From erik.joelsson at oracle.com Tue Mar 26 15:00:39 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 26 Mar 2013 16:00:39 +0100 Subject: RFR 8009382: Add JVM_Get{Field|Method}TypeAnnotations In-Reply-To: <5151795B.7080109@oracle.com> References: <514C67A9.1060106@oracle.com> <51506A98.70103@oracle.com> <5151795B.7080109@oracle.com> Message-ID: <5151B817.30205@oracle.com> Joel, Looks good from the build group. /Erik On 2013-03-26 11:32, Joel Borggr?n-Franck wrote: > Hi, > > Also including build-dev since this touches some makefiles. > > Thanks Dan! see inline, also new webrev: > > http://cr.openjdk.java.net/~jfranck/8009382/hotspot/webrev.02/ > > On 03/25/2013 04:17 PM, Daniel D. Daugherty wrote: >> On 3/22/13 8:16 AM, Joel Borggr?n-Franck wrote: > >> make/bsd/makefiles/mapfile-vers-debug >> make/linux/makefiles/mapfile-vers-debug >> make/linux/makefiles/mapfile-vers-product >> make/solaris/makefiles/mapfile-vers >> It looks like the other entries are in alpha order so these >> two new entries should also be added in alpha order. >> > > Fixed. I also noticed I forgot to update one of the bsd makefiles. > >> src/share/vm/prims/jvm.cpp >> line 1510: return NULL; >> nit: indent should be two spaces >> >> line 1529: assert(false, "cannot find method"); >> line 1530: return NULL; // robustness >> Normally "robustness" comments flag logic after an assert() >> to indicate what we do in product mode to deal with the "bad" >> situation without crashing. In this case, we don't try to use >> 'm' after discovering that it is NULL so this could be simpler: >> >> Method* m = >> InstanceKlass::cast(k)->method_with_idnum(slot); >> assert(m != NULL, "cannot find method"); >> return m; // caller has to deal with NULL in product mode >> >> Yes, I realize you only touched the comment here, but it >> served to point out the messiness of the existing code. >> > > Good suggestion. Fixed. > >> line 1551: return NULL; >> line 1565: return NULL; >> line 1579: return NULL; >> nit: indent should be two spaces >> >> line 1632: return NULL; >> line 1613: return NULL; >> nit: indent should be two spaces > > Fixed all indent nits. > >>> >>> A prototype of the jdk changes can be found here: >>> http://cr.openjdk.java.net/~jfranck/8009382/jdk/webrev.00/ >> >> You should use a separate bug ID for the jdk repo changes. This will >> prevent confusion between when HSX with these changes is integrated >> into JDK8 and when the jdk repo changes are integrated into JDK8. >> > > The JDK changes have a separate bug, sorry if this was unclear. The > jdk changes shown are just a proof of concept, intended to highlight > that my HotSpot changes have actually been run. I will send out a > separate review request in the future for the JDK changes. > > cheers > /Joel From david.r.chase at oracle.com Tue Mar 26 16:33:15 2013 From: david.r.chase at oracle.com (David Chase) Date: Tue, 26 Mar 2013 12:33:15 -0400 Subject: New build, gobjcopy failure, any clues? Message-ID: <5C655765-3638-4C33-8FF9-32D048A898F0@oracle.com> I think I'm doing a vanilla new-build, but obviously I'm not, because it fails. What should I be looking for? the failure: Linking vm... ld: warning: symbol '__JvmOffsets' has differing types: (file JvmOffsets.o type=OBJT; file dtrace.o type=FUNC); ld: warning: symbol 'CodeCache::_heap' has differing types: (file codeCache.o type=OBJT; file dtrace.o type=FUNC); ld: warning: symbol 'Universe::_collectedHeap' has differing types: (file adaptiveSizePolicy.o type=OBJT; file dtrace.o type=FUNC); ld: warning: symbol 'BufferBlob::__vtbl' has differing types: (file codeBlob.o type=OBJT; file dtrace.o type=FUNC); ld: warning: symbol 'Method::__vtbl' has differing types: (file dtrace.o type=FUNC; file method.o type=OBJT); ld: warning: symbol 'nmethod::__vtbl' has differing types: (file dtrace.o type=FUNC; file nmethod.o type=OBJT); Opening 'libjvm.so' for update No SHF_ALLOC flags needed to be cleared. Done with 'libjvm.so' /usr/ccs/bin/gobjcopy:libjvm.so: File format not recognized ... the offending file: file ./hotspot/solaris_sparcv9_compiler2/product/libjvm.so ./hotspot/solaris_sparcv9_compiler2/product/libjvm.so: ELF 64-bit MSB dynamic lib SPARCV9 Version 1, dynamically linked, not stripped configuration summary: Configuration summary: * Debug level: release * JDK variant: normal * JVM variants: server * OpenJDK target: OS: solaris, CPU architecture: sparc, address length: 64 Tools summary: * Boot JDK: java version "1.8.0-ea" Java(TM) SE Runtime Environment (build 1.8.0-ea-b82) Java HotSpot(TM) Server VM (build 25.0-b23, mixed mode) (at /export/drchase/jdk8) * C Compiler: Sun Studio version 5.10 (at /java/devtools/sparc/SUNWspro/SS12u1/prod/bin/cc) * C++ Compiler: Sun Studio version 5.10 (at /java/devtools/sparc/SUNWspro/SS12u1/prod/bin/CC) From volker.simonis at gmail.com Tue Mar 26 16:49:24 2013 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 26 Mar 2013 17:49:24 +0100 Subject: New build, gobjcopy failure, any clues? In-Reply-To: <5C655765-3638-4C33-8FF9-32D048A898F0@oracle.com> References: <5C655765-3638-4C33-8FF9-32D048A898F0@oracle.com> Message-ID: Hi David, I think you have to use /usr/sfw/bin/gobjcopy but I have no idea why you have '/usr/ccs/bin/gobjcopy' and what kind of 'objcopy' it is. I don't have '/usr/ccs/bin/gobjcopy' on my Solaris10 box. Regards, Volker On Tue, Mar 26, 2013 at 5:33 PM, David Chase wrote: > I think I'm doing a vanilla new-build, but obviously I'm not, because it > fails. > What should I be looking for? > > the failure: > > Linking vm... > ld: warning: symbol '__JvmOffsets' has differing types: > (file JvmOffsets.o type=OBJT; file dtrace.o type=FUNC); > ld: warning: symbol 'CodeCache::_heap' has differing types: > (file codeCache.o type=OBJT; file dtrace.o type=FUNC); > ld: warning: symbol 'Universe::_collectedHeap' has differing types: > (file adaptiveSizePolicy.o type=OBJT; file dtrace.o type=FUNC); > ld: warning: symbol 'BufferBlob::__vtbl' has differing types: > (file codeBlob.o type=OBJT; file dtrace.o type=FUNC); > ld: warning: symbol 'Method::__vtbl' has differing types: > (file dtrace.o type=FUNC; file method.o type=OBJT); > ld: warning: symbol 'nmethod::__vtbl' has differing types: > (file dtrace.o type=FUNC; file nmethod.o type=OBJT); > Opening 'libjvm.so' for update > No SHF_ALLOC flags needed to be cleared. > Done with 'libjvm.so' > /usr/ccs/bin/gobjcopy:libjvm.so: File format not recognized > ... > > the offending file: > > file ./hotspot/solaris_sparcv9_compiler2/product/libjvm.so > ./hotspot/solaris_sparcv9_compiler2/product/libjvm.so: ELF 64-bit MSB > dynamic lib SPARCV9 Version 1, dynamically linked, not stripped > > > configuration summary: > > Configuration summary: > * Debug level: release > * JDK variant: normal > * JVM variants: server > * OpenJDK target: OS: solaris, CPU architecture: sparc, address length: 64 > > Tools summary: > * Boot JDK: java version "1.8.0-ea" Java(TM) SE Runtime Environment > (build 1.8.0-ea-b82) Java HotSpot(TM) Server VM (build 25.0-b23, mixed > mode) (at /export/drchase/jdk8) > * C Compiler: Sun Studio version 5.10 (at > /java/devtools/sparc/SUNWspro/SS12u1/prod/bin/cc) > * C++ Compiler: Sun Studio version 5.10 (at > /java/devtools/sparc/SUNWspro/SS12u1/prod/bin/CC) > > > From huizhe.wang at oracle.com Tue Mar 26 17:42:52 2013 From: huizhe.wang at oracle.com (huizhe wang) Date: Tue, 26 Mar 2013 10:42:52 -0700 Subject: JDK-8010495: Update JAXP NetBeans project - add support for generating javadoc In-Reply-To: <51516492.6090401@oracle.com> References: <515038DA.3010802@oracle.com> <51507946.6050400@oracle.com> <51507CBC.1070904@oracle.com> <515080BA.3090000@oracle.com> <51516492.6090401@oracle.com> Message-ID: <5151DE1C.9000905@oracle.com> On 3/26/2013 2:04 AM, Daniel Fuchs wrote: > Hi Joe, > > On 3/25/13 5:52 PM, huizhe wang wrote: >> >> On 3/25/2013 9:35 AM, Daniel Fuchs wrote: >>> On 3/25/13 5:20 PM, huizhe wang wrote: >>>> Hi Daniel, >>>> >>>> Thanks for doing this. >>>> >>>> JAXP doesn't have these packages: "java/", "org/ietf/jgss/", and >>>> "org/omg/". Since this is the jaxp repo, it would be fine if only >>>> 'javax/' and 'org/' are included, or 'com/' be excluded. >>> >>> OK - I just copied the pattern shared by all >>> jdk/make/netbeans projects - but I guess I can safely restrict >>> the list to what is actually present in JAXP. >>> >>> That would make it: >>> >>> 203 >> includes="${includes}" excludes="${excludes}"> >>> 204 >>> 205 >>> 206 >>> 207 >>> 208 >>> 209 >>> 210 >>> 211 >> >> I'm not familiar with this usage. Does the 'includes' attribute take >> precedence over the package names in tags? Will they be ignored >> since 'includes' includes all packages. > > In other free form projects defined for JDK, 'includes' and 'excludes' > are global properties defined in the project's properties file. > They control which subset of the sources are considered part of the > project - and are used by the compile target, the javadoc target, > and also to select which files will be seen in NetBeans, etc... Yeh, there may be dependencies among different JDK projects. We don't have that for now. But I'm ok. > > As far as I understand the selector in packageset in the javadoc > target defines the subset of the subset of the sources for > which javadoc should be generated. So it's a way to scope the > sources defined by includes/excludes down to the set of public > packages for which api documentation is desired. > > I think we should keep it like that in JAXP - even though the javadoc > target is currently the only target that would be affected by the > definition of includes/excludes in jaxp/build.properties. I see. gives impression that the packages selected within the selector only take effect when includes/excludes is not defined, which was why I was asking. Thanks, Joe > > -- daniel > >> >> -Joe >> >>> >>> >>> -- daniel >>> >>>> >>>> Regards, >>>> Joe >>>> >>>> On 3/25/2013 4:45 AM, Daniel Fuchs wrote: >>>>> Hi guys, >>>>> >>>>> I'd like to propose a small change to jaxp/build.xml and >>>>> jaxp/nbproject/project.xml - in order to allow editing >>>>> JAXP sources in NetBeans, as well as generating the JAXP >>>>> javadoc for previewing purposes. >>>>> >>>>> I actually stole the javadoc target from >>>>> jdk/make/netbeans/common/shared.xml >>>>> >>>>> The changes are small & targeted at developers. >>>>> There should be no impact on the build process. >>>>> >>>>> Here is the webrev: >>>>> >>>>> http://cr.openjdk.java.net/~dfuchs/JDK-8010495/jdk8/webrev.00/ >>>>> >>>>> best regards, >>>>> >>>>> -- daniel >>>> >>> >> > From david.r.chase at oracle.com Tue Mar 26 17:43:48 2013 From: david.r.chase at oracle.com (David Chase) Date: Tue, 26 Mar 2013 13:43:48 -0400 Subject: New build, gobjcopy failure, any clues? In-Reply-To: References: <5C655765-3638-4C33-8FF9-32D048A898F0@oracle.com> Message-ID: This is Solaris 11, not sure if that matters (configure didn't seem to think it was important enough to mention it). cmp says /usr/{sfw,ccs}/bin/gobjcopy are equal. ls says they are the same inode. Just for grins, I tried putting /usr/sfw/bin earlier in my path, and trying again (reconfiguring), but had the same result. Is it possible that this is some sort of a concurrency bug? I tried gmake JOBS=1 and it failed slightly differently. I am cleaning, starting fresh with JOBS=1, I expect you will not hear from me for a while :-). From jim.gish at oracle.com Tue Mar 26 17:50:14 2013 From: jim.gish at oracle.com (Jim Gish) Date: Tue, 26 Mar 2013 13:50:14 -0400 Subject: RFR: 8009824: webrev.ksh generated jdk.patch files do not handle renames, copies, and shouldn't be applied Message-ID: <5151DFD6.8090001@oracle.com> Please review http://cr.openjdk.java.net/~jgish/Bug8009824-UpdateWebrevToUseHgExport/ This change to webrev.ksh replaces the current method for generating a patch with one that uses hg export -g, preserving copy, move and rename operations. The current method results in a patch which does not properly account for these file operations and cannot be safely applied. As a result of this change, a valid changeset is generated that can be safely applied by a committer (reducing the burden on and decreasing the chance of mistakes by non-committers when preparing webrevs and subsequent changesets to be sent to committers for pushing). Note that the new method can only be used when there are committed changes. If webrev is used against uncommitted changes in a users workspace, the old method of generating the patch is still used. (Another bug, another day :-)) Thanks, Jim -- Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304 Oracle Java Platform Group | Core Libraries Team 35 Network Drive Burlington, MA 01803 jim.gish at oracle.com From volker.simonis at gmail.com Tue Mar 26 18:00:29 2013 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 26 Mar 2013 19:00:29 +0100 Subject: New build, gobjcopy failure, any clues? In-Reply-To: References: <5C655765-3638-4C33-8FF9-32D048A898F0@oracle.com> Message-ID: On Tue, Mar 26, 2013 at 6:43 PM, David Chase wrote: > > This is Solaris 11, not sure if that matters (configure didn't seem to think it was important enough to mention it). > > cmp says /usr/{sfw,ccs}/bin/gobjcopy are equal. > ls says they are the same inode. > > Just for grins, I tried putting /usr/sfw/bin earlier in my path, and trying again (reconfiguring), but had the same result. > > Is it possible that this is some sort of a concurrency bug? I don't think so but if it should really be only a concurrency bug you should be able to manually do: gobjcopy --only-keep-debug libjvm.so /tmp/libjvm.debuginfo > I tried gmake JOBS=1 and it failed slightly differently. > I am cleaning, starting fresh with JOBS=1, I expect you will not hear from me for a while :-). > by the way, for my 'gobjcopy --info' prints: BFD header file version 2.15 elf32-sparc (header big endian, data big endian) sparc elf64-sparc (header big endian, data big endian) sparc a.out-sunos-big (header big endian, data big endian) sparc elf64-little (header little endian, data little endian) sparc elf64-big (header big endian, data big endian) sparc elf32-little (header little endian, data little endian) sparc elf32-big (header big endian, data big endian) sparc srec (header endianness unknown, data endianness unknown) sparc symbolsrec (header endianness unknown, data endianness unknown) sparc tekhex (header endianness unknown, data endianness unknown) sparc binary (header endianness unknown, data endianness unknown) sparc ihex (header endianness unknown, data endianness unknown) sparc elf32-sparc elf64-sparc a.out-sunos-big elf64-little elf64-big sparc elf32-sparc elf64-sparc a.out-sunos-big elf64-little elf64-big elf32-little elf32-big srec symbolsrec tekhex binary ihex sparc elf32-little elf32-big srec symbolsrec tekhex binary ihex From david.r.chase at oracle.com Tue Mar 26 18:24:11 2013 From: david.r.chase at oracle.com (David Chase) Date: Tue, 26 Mar 2013 14:24:11 -0400 Subject: New build, gobjcopy failure, any clues? In-Reply-To: References: <5C655765-3638-4C33-8FF9-32D048A898F0@oracle.com> Message-ID: Well, it's not a concurrency bug, and my objcopy is 2.19 but otherwise provides identical info, and the failure recurs by hand: gobjcopy --only-keep-debug libjvm.so /tmp/libjvm.debuginfo gobjcopy:libjvm.so: File format not recognized libjvm.so: ELF 64-bit MSB dynamic lib SPARCV9 Version 1, dynamically linked, not stripped What sort of "file" is your libjvm.so? David On 2013-03-26, at 2:00 PM, Volker Simonis wrote: > On Tue, Mar 26, 2013 at 6:43 PM, David Chase wrote: >> >> This is Solaris 11, not sure if that matters (configure didn't seem to think it was important enough to mention it). >> >> cmp says /usr/{sfw,ccs}/bin/gobjcopy are equal. >> ls says they are the same inode. >> >> Just for grins, I tried putting /usr/sfw/bin earlier in my path, and trying again (reconfiguring), but had the same result. >> >> Is it possible that this is some sort of a concurrency bug? > > I don't think so but if it should really be only a concurrency bug you > should be able to manually do: > > gobjcopy --only-keep-debug libjvm.so /tmp/libjvm.debuginfo > >> I tried gmake JOBS=1 and it failed slightly differently. >> I am cleaning, starting fresh with JOBS=1, I expect you will not hear from me for a while :-). >> > > by the way, for my 'gobjcopy --info' prints: > > BFD header file version 2.15 > elf32-sparc > (header big endian, data big endian) > sparc > elf64-sparc > (header big endian, data big endian) > sparc > a.out-sunos-big > (header big endian, data big endian) > sparc > elf64-little > (header little endian, data little endian) > sparc > elf64-big > (header big endian, data big endian) > sparc > elf32-little > (header little endian, data little endian) > sparc > elf32-big > (header big endian, data big endian) > sparc > srec > (header endianness unknown, data endianness unknown) > sparc > symbolsrec > (header endianness unknown, data endianness unknown) > sparc > tekhex > (header endianness unknown, data endianness unknown) > sparc > binary > (header endianness unknown, data endianness unknown) > sparc > ihex > (header endianness unknown, data endianness unknown) > sparc > > elf32-sparc elf64-sparc a.out-sunos-big elf64-little elf64-big > sparc elf32-sparc elf64-sparc a.out-sunos-big elf64-little elf64-big > > elf32-little elf32-big srec symbolsrec tekhex binary ihex > sparc elf32-little elf32-big srec symbolsrec tekhex binary ihex From volker.simonis at gmail.com Tue Mar 26 18:45:27 2013 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 26 Mar 2013 19:45:27 +0100 Subject: New build, gobjcopy failure, any clues? In-Reply-To: References: <5C655765-3638-4C33-8FF9-32D048A898F0@oracle.com> Message-ID: It's exactly the same! On Tue, Mar 26, 2013 at 7:24 PM, David Chase wrote: > Well, it's not a concurrency bug, and my objcopy is 2.19 but otherwise provides identical info, > and the failure recurs by hand: > > gobjcopy --only-keep-debug libjvm.so /tmp/libjvm.debuginfo > gobjcopy:libjvm.so: File format not recognized > > libjvm.so: ELF 64-bit MSB dynamic lib SPARCV9 Version 1, dynamically linked, not stripped > > What sort of "file" is your libjvm.so? > > David > > On 2013-03-26, at 2:00 PM, Volker Simonis wrote: > >> On Tue, Mar 26, 2013 at 6:43 PM, David Chase wrote: >>> >>> This is Solaris 11, not sure if that matters (configure didn't seem to think it was important enough to mention it). >>> >>> cmp says /usr/{sfw,ccs}/bin/gobjcopy are equal. >>> ls says they are the same inode. >>> >>> Just for grins, I tried putting /usr/sfw/bin earlier in my path, and trying again (reconfiguring), but had the same result. >>> >>> Is it possible that this is some sort of a concurrency bug? >> >> I don't think so but if it should really be only a concurrency bug you >> should be able to manually do: >> >> gobjcopy --only-keep-debug libjvm.so /tmp/libjvm.debuginfo >> >>> I tried gmake JOBS=1 and it failed slightly differently. >>> I am cleaning, starting fresh with JOBS=1, I expect you will not hear from me for a while :-). >>> >> >> by the way, for my 'gobjcopy --info' prints: >> >> BFD header file version 2.15 >> elf32-sparc >> (header big endian, data big endian) >> sparc >> elf64-sparc >> (header big endian, data big endian) >> sparc >> a.out-sunos-big >> (header big endian, data big endian) >> sparc >> elf64-little >> (header little endian, data little endian) >> sparc >> elf64-big >> (header big endian, data big endian) >> sparc >> elf32-little >> (header little endian, data little endian) >> sparc >> elf32-big >> (header big endian, data big endian) >> sparc >> srec >> (header endianness unknown, data endianness unknown) >> sparc >> symbolsrec >> (header endianness unknown, data endianness unknown) >> sparc >> tekhex >> (header endianness unknown, data endianness unknown) >> sparc >> binary >> (header endianness unknown, data endianness unknown) >> sparc >> ihex >> (header endianness unknown, data endianness unknown) >> sparc >> >> elf32-sparc elf64-sparc a.out-sunos-big elf64-little elf64-big >> sparc elf32-sparc elf64-sparc a.out-sunos-big elf64-little elf64-big >> >> elf32-little elf32-big srec symbolsrec tekhex binary ihex >> sparc elf32-little elf32-big srec symbolsrec tekhex binary ihex > From volker.simonis at gmail.com Tue Mar 26 18:57:00 2013 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 26 Mar 2013 19:57:00 +0100 Subject: New build, gobjcopy failure, any clues? In-Reply-To: References: <5C655765-3638-4C33-8FF9-32D048A898F0@oracle.com> Message-ID: Can you try if 'gobjdump -x' doesn't work as well? And you can also try '/usr/ccs/bin/elfdump -e'. For me '/usr/ccs/bin/elfdump -e' gives: ELF Header ei_magic: { 0x7f, E, L, F } ei_class: ELFCLASS64 ei_data: ELFDATA2MSB e_machine: EM_SPARCV9 e_version: EV_CURRENT e_type: ET_DYN e_flags: [ EF_SPARCV9_TSO ] e_entry: 0xe8 e_ehsize: 64 e_shstrndx: 27 e_shoff: 0x2478b68 e_shentsize: 64 e_shnum: 29 e_phoff: 0x40 e_phentsize: 56 e_phnum: 3 And 'gobjdump -x' prints: /usr/work/openjdk/nb/sun_64/nightly/output-jdk7u-fastdebug/lib/sparcv9/server/libjvm.so: file format elf64-sparc /usr/work/openjdk/nb/sun_64/nightly/output-jdk7u-fastdebug/lib/sparcv9/server/libjvm.so architecture: sparc:v9, flags 0x00000150: HAS_SYMS, DYNAMIC, D_PAGED start address 0x00000000000000e8 Program Header: LOAD off 0x0000000000000000 vaddr 0x0000000000000000 paddr 0x0000000000000000 align 2**20 filesz 0x0000000001afe0bf memsz 0x0000000001afe0bf flags r-x LOAD off 0x0000000001afe0c0 vaddr 0x0000000001bfe0c0 paddr 0x0000000000000000 align 2**20 filesz 0x0000000000140c74 memsz 0x00000000001b8520 flags rwx DYNAMIC off 0x0000000001b05128 vaddr 0x0000000001c05128 paddr 0x0000000000000000 align 2**0 filesz 0x0000000000000210 memsz 0x0000000000000000 flags rwx Dynamic Section: NEEDED libsocket.so.1 NEEDED libsched.so.1 NEEDED libdl.so.1 NEEDED libm.so.1 NEEDED libCrun.so.1 NEEDED libthread.so.1 NEEDED libdoor.so.1 NEEDED libc.so.1 NEEDED libdemangle.so.1 NEEDED libkstat.so.1 INIT 0x139bb88 FINI 0x139be88 SONAME libjvm.so HASH 0xe8 STRTAB 0x19718 STRSZ 0x17071 SYMTAB 0x6680 SYMENT 0x18 CHECKSUM 0x53fa PLTRELSZ 0x14b8 PLTREL 0x7 JMPREL 0x22def0 RELA 0x30790 RELASZ 0x1fec18 RELAENT 0x18 0x70000001 0x8d4 0x70000001 0x8e5 0x70000001 0x811 FEATURE 0x1 FLAGS 0x0 FLAGS_1 0x0 PLTGOT 0x1c03500 Sections: Idx Name Size VMA LMA File off Algn 0 .hash 00006598 00000000000000e8 00000000000000e8 000000e8 2**3 CONTENTS, ALLOC, LOAD, READONLY, DATA 1 .dynsym 00013098 0000000000006680 0000000000006680 00006680 2**3 CONTENTS, ALLOC, LOAD, READONLY, DATA 2 .dynstr 00017071 0000000000019718 0000000000019718 00019718 2**0 CONTENTS, ALLOC, LOAD, READONLY, DATA 3 .rela.got 0000fb40 0000000000030790 0000000000030790 00030790 2**3 CONTENTS, ALLOC, LOAD, READONLY, DATA 4 .rela.ex_shared 000000c0 00000000000402d0 00000000000402d0 000402d0 2**3 CONTENTS, ALLOC, LOAD, READONLY, DATA 5 .rela.cpp_finidata 00000048 0000000000040390 0000000000040390 00040390 2**3 CONTENTS, ALLOC, LOAD, READONLY, DATA 6 .rela.data 001edb18 00000000000403d8 00000000000403d8 000403d8 2**3 CONTENTS, ALLOC, LOAD, READONLY, DATA 7 .rela.plt 000014b8 000000000022def0 000000000022def0 0022def0 2**3 CONTENTS, ALLOC, LOAD, READONLY, DATA 8 .text 0116c7c4 000000000022f3c0 000000000022f3c0 0022f3c0 2**5 CONTENTS, ALLOC, LOAD, READONLY, CODE 9 .init 00000300 000000000139bb88 000000000139bb88 0139bb88 2**3 CONTENTS, ALLOC, LOAD, READONLY, CODE 10 .fini 00000094 000000000139be88 000000000139be88 0139be88 2**3 CONTENTS, ALLOC, LOAD, READONLY, CODE 11 .exception_ranges 00000008 000000000139bf20 000000000139bf20 0139bf20 2**3 CONTENTS, ALLOC, LOAD, READONLY, DATA 12 .rodata 00703d55 000000000139bf28 000000000139bf28 0139bf28 2**3 CONTENTS, ALLOC, LOAD, READONLY, DATA 13 .rodata1 0003b3b3 0000000001a9fc7d 0000000001a9fc7d 01a9fc7d 2**0 CONTENTS, ALLOC, LOAD, READONLY, DATA 14 .got 000053c8 0000000001bfe0c0 0000000001bfe0c0 01afe0c0 2**3 CONTENTS, ALLOC, LOAD, DATA 15 .plt 00001c24 0000000001c03500 0000000001c03500 01b03500 2**8 CONTENTS, ALLOC, LOAD, CODE 16 .dynamic 00000210 0000000001c05128 0000000001c05128 01b05128 2**3 CONTENTS, ALLOC, LOAD, DATA 17 .ex_shared 00000070 0000000001c05338 0000000001c05338 01b05338 2**3 CONTENTS, ALLOC, LOAD, DATA 18 .cpp_finidata 00000018 0000000001c053a8 0000000001c053a8 01b053a8 2**3 CONTENTS, ALLOC, LOAD, DATA 19 .data 00139974 0000000001c053c0 0000000001c053c0 01b053c0 2**3 CONTENTS, ALLOC, LOAD, DATA 20 .picdata 00000000 0000000001d3ed34 0000000001d3ed34 01c3ed34 2**0 CONTENTS, ALLOC, LOAD, DATA 21 .bss 000778a8 0000000001d3ed38 0000000001d3ed38 01c3ed38 2**3 ALLOC 22 .comment 000018d3 0000000000000000 0000000000000000 02477133 2**0 CONTENTS, READONLY 23 .gnu_debuglink 00000018 0000000000000000 0000000000000000 02478b4b 2**0 CONTENTS, READONLY On Tue, Mar 26, 2013 at 7:24 PM, David Chase wrote: > Well, it's not a concurrency bug, and my objcopy is 2.19 but otherwise provides identical info, > and the failure recurs by hand: > > gobjcopy --only-keep-debug libjvm.so /tmp/libjvm.debuginfo > gobjcopy:libjvm.so: File format not recognized > > libjvm.so: ELF 64-bit MSB dynamic lib SPARCV9 Version 1, dynamically linked, not stripped > > What sort of "file" is your libjvm.so? > > David > > On 2013-03-26, at 2:00 PM, Volker Simonis wrote: > >> On Tue, Mar 26, 2013 at 6:43 PM, David Chase wrote: >>> >>> This is Solaris 11, not sure if that matters (configure didn't seem to think it was important enough to mention it). >>> >>> cmp says /usr/{sfw,ccs}/bin/gobjcopy are equal. >>> ls says they are the same inode. >>> >>> Just for grins, I tried putting /usr/sfw/bin earlier in my path, and trying again (reconfiguring), but had the same result. >>> >>> Is it possible that this is some sort of a concurrency bug? >> >> I don't think so but if it should really be only a concurrency bug you >> should be able to manually do: >> >> gobjcopy --only-keep-debug libjvm.so /tmp/libjvm.debuginfo >> >>> I tried gmake JOBS=1 and it failed slightly differently. >>> I am cleaning, starting fresh with JOBS=1, I expect you will not hear from me for a while :-). >>> >> >> by the way, for my 'gobjcopy --info' prints: >> >> BFD header file version 2.15 >> elf32-sparc >> (header big endian, data big endian) >> sparc >> elf64-sparc >> (header big endian, data big endian) >> sparc >> a.out-sunos-big >> (header big endian, data big endian) >> sparc >> elf64-little >> (header little endian, data little endian) >> sparc >> elf64-big >> (header big endian, data big endian) >> sparc >> elf32-little >> (header little endian, data little endian) >> sparc >> elf32-big >> (header big endian, data big endian) >> sparc >> srec >> (header endianness unknown, data endianness unknown) >> sparc >> symbolsrec >> (header endianness unknown, data endianness unknown) >> sparc >> tekhex >> (header endianness unknown, data endianness unknown) >> sparc >> binary >> (header endianness unknown, data endianness unknown) >> sparc >> ihex >> (header endianness unknown, data endianness unknown) >> sparc >> >> elf32-sparc elf64-sparc a.out-sunos-big elf64-little elf64-big >> sparc elf32-sparc elf64-sparc a.out-sunos-big elf64-little elf64-big >> >> elf32-little elf32-big srec symbolsrec tekhex binary ihex >> sparc elf32-little elf32-big srec symbolsrec tekhex binary ihex > From david.r.chase at oracle.com Tue Mar 26 19:12:24 2013 From: david.r.chase at oracle.com (David Chase) Date: Tue, 26 Mar 2013 15:12:24 -0400 Subject: New build, gobjcopy failure, any clues? In-Reply-To: References: <5C655765-3638-4C33-8FF9-32D048A898F0@oracle.com> Message-ID: gobjdump -x fails in the same uninformative way. elfdump -e libjvm.so ELF Header ei_magic: { 0x7f, E, L, F } ei_class: ELFCLASS64 ei_data: ELFDATA2MSB ei_osabi: ELFOSABI_SOLARIS ei_abiversion: EAV_SUNW_CURRENT e_machine: EM_SPARCV9 e_version: EV_CURRENT e_type: ET_DYN e_flags: [ EF_SPARCV9_TSO ] e_entry: 0 e_ehsize: 64 e_shstrndx: 34 e_shoff: 0x27ce2658 e_shentsize: 64 e_shnum: 37 e_phoff: 0x40 e_phentsize: 56 e_phnum: 3 Very similar to yours, though different numbers. I wonder if e_entry=0 means anything. Other elfdump flags (-c, -d) provide similar reasonable-looking output. David On 2013-03-26, at 2:57 PM, Volker Simonis wrote: > Can you try if 'gobjdump -x' doesn't work as well? > And you can also try '/usr/ccs/bin/elfdump -e'. > > For me '/usr/ccs/bin/elfdump -e' gives: > > ELF Header > ei_magic: { 0x7f, E, L, F } > ei_class: ELFCLASS64 ei_data: ELFDATA2MSB > e_machine: EM_SPARCV9 e_version: EV_CURRENT > e_type: ET_DYN > e_flags: [ EF_SPARCV9_TSO ] > e_entry: 0xe8 e_ehsize: 64 e_shstrndx: 27 > e_shoff: 0x2478b68 e_shentsize: 64 e_shnum: 29 > e_phoff: 0x40 e_phentsize: 56 e_phnum: 3 > > > And 'gobjdump -x' prints: > > /usr/work/openjdk/nb/sun_64/nightly/output-jdk7u-fastdebug/lib/sparcv9/server/libjvm.so: > file format elf64-sparc > /usr/work/openjdk/nb/sun_64/nightly/output-jdk7u-fastdebug/lib/sparcv9/server/libjvm.so > architecture: sparc:v9, flags 0x00000150: > HAS_SYMS, DYNAMIC, D_PAGED > start address 0x00000000000000e8 > > Program Header: > LOAD off 0x0000000000000000 vaddr 0x0000000000000000 paddr > 0x0000000000000000 align 2**20 > filesz 0x0000000001afe0bf memsz 0x0000000001afe0bf flags r-x > LOAD off 0x0000000001afe0c0 vaddr 0x0000000001bfe0c0 paddr > 0x0000000000000000 align 2**20 > filesz 0x0000000000140c74 memsz 0x00000000001b8520 flags rwx > DYNAMIC off 0x0000000001b05128 vaddr 0x0000000001c05128 paddr > 0x0000000000000000 align 2**0 > filesz 0x0000000000000210 memsz 0x0000000000000000 flags rwx > > Dynamic Section: > NEEDED libsocket.so.1 > NEEDED libsched.so.1 > NEEDED libdl.so.1 > NEEDED libm.so.1 > NEEDED libCrun.so.1 > NEEDED libthread.so.1 > NEEDED libdoor.so.1 > NEEDED libc.so.1 > NEEDED libdemangle.so.1 > NEEDED libkstat.so.1 > INIT 0x139bb88 > FINI 0x139be88 > SONAME libjvm.so > HASH 0xe8 > STRTAB 0x19718 > STRSZ 0x17071 > SYMTAB 0x6680 > SYMENT 0x18 > CHECKSUM 0x53fa > PLTRELSZ 0x14b8 > PLTREL 0x7 > JMPREL 0x22def0 > RELA 0x30790 > RELASZ 0x1fec18 > RELAENT 0x18 > 0x70000001 0x8d4 > 0x70000001 0x8e5 > 0x70000001 0x811 > FEATURE 0x1 > FLAGS 0x0 > FLAGS_1 0x0 > PLTGOT 0x1c03500 > > Sections: > Idx Name Size VMA LMA File off Algn > 0 .hash 00006598 00000000000000e8 00000000000000e8 000000e8 2**3 > CONTENTS, ALLOC, LOAD, READONLY, DATA > 1 .dynsym 00013098 0000000000006680 0000000000006680 00006680 2**3 > CONTENTS, ALLOC, LOAD, READONLY, DATA > 2 .dynstr 00017071 0000000000019718 0000000000019718 00019718 2**0 > CONTENTS, ALLOC, LOAD, READONLY, DATA > 3 .rela.got 0000fb40 0000000000030790 0000000000030790 00030790 2**3 > CONTENTS, ALLOC, LOAD, READONLY, DATA > 4 .rela.ex_shared 000000c0 00000000000402d0 00000000000402d0 000402d0 2**3 > CONTENTS, ALLOC, LOAD, READONLY, DATA > 5 .rela.cpp_finidata 00000048 0000000000040390 0000000000040390 > 00040390 2**3 > CONTENTS, ALLOC, LOAD, READONLY, DATA > 6 .rela.data 001edb18 00000000000403d8 00000000000403d8 000403d8 2**3 > CONTENTS, ALLOC, LOAD, READONLY, DATA > 7 .rela.plt 000014b8 000000000022def0 000000000022def0 0022def0 2**3 > CONTENTS, ALLOC, LOAD, READONLY, DATA > 8 .text 0116c7c4 000000000022f3c0 000000000022f3c0 0022f3c0 2**5 > CONTENTS, ALLOC, LOAD, READONLY, CODE > 9 .init 00000300 000000000139bb88 000000000139bb88 0139bb88 2**3 > CONTENTS, ALLOC, LOAD, READONLY, CODE > 10 .fini 00000094 000000000139be88 000000000139be88 0139be88 2**3 > CONTENTS, ALLOC, LOAD, READONLY, CODE > 11 .exception_ranges 00000008 000000000139bf20 000000000139bf20 > 0139bf20 2**3 > CONTENTS, ALLOC, LOAD, READONLY, DATA > 12 .rodata 00703d55 000000000139bf28 000000000139bf28 0139bf28 2**3 > CONTENTS, ALLOC, LOAD, READONLY, DATA > 13 .rodata1 0003b3b3 0000000001a9fc7d 0000000001a9fc7d 01a9fc7d 2**0 > CONTENTS, ALLOC, LOAD, READONLY, DATA > 14 .got 000053c8 0000000001bfe0c0 0000000001bfe0c0 01afe0c0 2**3 > CONTENTS, ALLOC, LOAD, DATA > 15 .plt 00001c24 0000000001c03500 0000000001c03500 01b03500 2**8 > CONTENTS, ALLOC, LOAD, CODE > 16 .dynamic 00000210 0000000001c05128 0000000001c05128 01b05128 2**3 > CONTENTS, ALLOC, LOAD, DATA > 17 .ex_shared 00000070 0000000001c05338 0000000001c05338 01b05338 2**3 > CONTENTS, ALLOC, LOAD, DATA > 18 .cpp_finidata 00000018 0000000001c053a8 0000000001c053a8 01b053a8 2**3 > CONTENTS, ALLOC, LOAD, DATA > 19 .data 00139974 0000000001c053c0 0000000001c053c0 01b053c0 2**3 > CONTENTS, ALLOC, LOAD, DATA > 20 .picdata 00000000 0000000001d3ed34 0000000001d3ed34 01c3ed34 2**0 > CONTENTS, ALLOC, LOAD, DATA > 21 .bss 000778a8 0000000001d3ed38 0000000001d3ed38 01c3ed38 2**3 > ALLOC > 22 .comment 000018d3 0000000000000000 0000000000000000 02477133 2**0 > CONTENTS, READONLY > 23 .gnu_debuglink 00000018 0000000000000000 0000000000000000 02478b4b 2**0 > CONTENTS, READONLY > > > On Tue, Mar 26, 2013 at 7:24 PM, David Chase wrote: >> Well, it's not a concurrency bug, and my objcopy is 2.19 but otherwise provides identical info, >> and the failure recurs by hand: >> >> gobjcopy --only-keep-debug libjvm.so /tmp/libjvm.debuginfo >> gobjcopy:libjvm.so: File format not recognized >> >> libjvm.so: ELF 64-bit MSB dynamic lib SPARCV9 Version 1, dynamically linked, not stripped >> >> What sort of "file" is your libjvm.so? >> >> David >> >> On 2013-03-26, at 2:00 PM, Volker Simonis wrote: >> >>> On Tue, Mar 26, 2013 at 6:43 PM, David Chase wrote: >>>> >>>> This is Solaris 11, not sure if that matters (configure didn't seem to think it was important enough to mention it). >>>> >>>> cmp says /usr/{sfw,ccs}/bin/gobjcopy are equal. >>>> ls says they are the same inode. >>>> >>>> Just for grins, I tried putting /usr/sfw/bin earlier in my path, and trying again (reconfiguring), but had the same result. >>>> >>>> Is it possible that this is some sort of a concurrency bug? >>> >>> I don't think so but if it should really be only a concurrency bug you >>> should be able to manually do: >>> >>> gobjcopy --only-keep-debug libjvm.so /tmp/libjvm.debuginfo >>> >>>> I tried gmake JOBS=1 and it failed slightly differently. >>>> I am cleaning, starting fresh with JOBS=1, I expect you will not hear from me for a while :-). >>>> >>> >>> by the way, for my 'gobjcopy --info' prints: >>> >>> BFD header file version 2.15 >>> elf32-sparc >>> (header big endian, data big endian) >>> sparc >>> elf64-sparc >>> (header big endian, data big endian) >>> sparc >>> a.out-sunos-big >>> (header big endian, data big endian) >>> sparc >>> elf64-little >>> (header little endian, data little endian) >>> sparc >>> elf64-big >>> (header big endian, data big endian) >>> sparc >>> elf32-little >>> (header little endian, data little endian) >>> sparc >>> elf32-big >>> (header big endian, data big endian) >>> sparc >>> srec >>> (header endianness unknown, data endianness unknown) >>> sparc >>> symbolsrec >>> (header endianness unknown, data endianness unknown) >>> sparc >>> tekhex >>> (header endianness unknown, data endianness unknown) >>> sparc >>> binary >>> (header endianness unknown, data endianness unknown) >>> sparc >>> ihex >>> (header endianness unknown, data endianness unknown) >>> sparc >>> >>> elf32-sparc elf64-sparc a.out-sunos-big elf64-little elf64-big >>> sparc elf32-sparc elf64-sparc a.out-sunos-big elf64-little elf64-big >>> >>> elf32-little elf32-big srec symbolsrec tekhex binary ihex >>> sparc elf32-little elf32-big srec symbolsrec tekhex binary ihex >> From david.r.chase at oracle.com Tue Mar 26 19:23:13 2013 From: david.r.chase at oracle.com (David Chase) Date: Tue, 26 Mar 2013 15:23:13 -0400 Subject: New build, gobjcopy failure, any clues? In-Reply-To: References: <5C655765-3638-4C33-8FF9-32D048A898F0@oracle.com> Message-ID: <11254493-C5B4-4955-B219-A6923CD7EBB6@oracle.com> More non-clues. I did a make JOBS=1 LOG=debug, and then reproduced the creation step with cut and paste: /java/devtools/sparc/SUNWspro/SS12u1/prod/bin/CC -m64 -xarch=sparc -library=%none -mt -G -norunpath -z noversion -M mapfile_extended -h libjvm.so -o libjvm.so JvmOffsets.o (many lines omitted) ld whined about the following things, and produced a libjvm.so that was not understood by gobjcopy. ld: warning: symbol '__JvmOffsets' has differing types: (file JvmOffsets.o type=OBJT; file dtrace.o type=FUNC); ld: warning: symbol 'CodeCache::_heap' has differing types: (file codeCache.o type=OBJT; file dtrace.o type=FUNC); ld: warning: symbol 'Universe::_collectedHeap' has differing types: (file adaptiveSizePolicy.o type=OBJT; file dtrace.o type=FUNC); ld: warning: symbol 'BufferBlob::__vtbl' has differing types: (file codeBlob.o type=OBJT; file dtrace.o type=FUNC); ld: warning: symbol 'Method::__vtbl' has differing types: (file dtrace.o type=FUNC; file method.o type=OBJT); ld: warning: symbol 'nmethod::__vtbl' has differing types: (file dtrace.o type=FUNC; file nmethod.o type=OBJT); From martinrb at google.com Tue Mar 26 22:40:27 2013 From: martinrb at google.com (Martin Buchholz) Date: Tue, 26 Mar 2013 15:40:27 -0700 Subject: new build system doesn't notice modified C source files. Message-ID: I modified src/solaris/native/java/lang/UNIXProcess_md.c (on Linux) and did "make images" but no actual compilation happened. (I guess I currently need to do a clean rebuild? Which is a serious bug?) From martinrb at google.com Tue Mar 26 22:43:47 2013 From: martinrb at google.com (Martin Buchholz) Date: Tue, 26 Mar 2013 15:43:47 -0700 Subject: Too many java source files are recompiled when one changes. Message-ID: If I modify an ordinary JDK source file (like StringBuilder.java), then all files are recompiled, even those that don't have any compile-time dependency on StringBuilder. ## Starting jdk Compiling 9412 files for BUILD_JDK I'd like to see instead Compiling 103 files for BUILD_JDK From jonathan.gibbons at oracle.com Tue Mar 26 22:48:16 2013 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 26 Mar 2013 15:48:16 -0700 Subject: Too many java source files are recompiled when one changes. In-Reply-To: References: Message-ID: <515225B0.7080905@oracle.com> sh ./configure --enable-sjavac -- Jon On 03/26/2013 03:43 PM, Martin Buchholz wrote: > If I modify an ordinary JDK source file (like StringBuilder.java), then all > files are recompiled, even those that don't have any compile-time > dependency on StringBuilder. > > ## Starting jdk > Compiling 9412 files for BUILD_JDK > > I'd like to see instead > > Compiling 103 files for BUILD_JDK From omajid at redhat.com Tue Mar 26 23:43:06 2013 From: omajid at redhat.com (Omair Majid) Date: Tue, 26 Mar 2013 19:43:06 -0400 Subject: Support building zero with the new build Message-ID: <5152328A.9040608@redhat.com> Hi, I tried using the new build system to build zero and ran into a bunch of problems. The following webrev allows me to build zero successfully. http://cr.openjdk.java.net/~omajid/webrevs/zero-newbuild/00/ Any thoughts, comments or suggestions? Thanks, Omair -- PGP Key: 66484681 (http://pgp.mit.edu/) Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 From david.katleman at oracle.com Tue Mar 26 23:43:20 2013 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Tue, 26 Mar 2013 23:43:20 +0000 Subject: hg: jdk8/build/corba: Added tag jdk8-b82 for changeset 48e1bc77004d Message-ID: <20130326234321.F101F483F9@hg.openjdk.java.net> Changeset: a45bb25a67c7 Author: katleman Date: 2013-03-21 10:42 -0700 URL: http://hg.openjdk.java.net/jdk8/build/corba/rev/a45bb25a67c7 Added tag jdk8-b82 for changeset 48e1bc77004d ! .hgtags From david.katleman at oracle.com Tue Mar 26 23:43:15 2013 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Tue, 26 Mar 2013 23:43:15 +0000 Subject: hg: jdk8/build: Added tag jdk8-b82 for changeset 29153d0df68f Message-ID: <20130326234315.C5F3F483F8@hg.openjdk.java.net> Changeset: 466685ba01bf Author: katleman Date: 2013-03-21 10:42 -0700 URL: http://hg.openjdk.java.net/jdk8/build/rev/466685ba01bf Added tag jdk8-b82 for changeset 29153d0df68f ! .hgtags From david.katleman at oracle.com Tue Mar 26 23:45:03 2013 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Tue, 26 Mar 2013 23:45:03 +0000 Subject: hg: jdk8/build/hotspot: 52 new changesets Message-ID: <20130326234642.4C045483FA@hg.openjdk.java.net> Changeset: 4f7380dca47e Author: katleman Date: 2013-03-21 10:42 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/4f7380dca47e Added tag jdk8-b82 for changeset 3db4ab0e12f4 ! .hgtags Changeset: 7ae04e71af90 Author: amurillo Date: 2013-03-15 11:44 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/7ae04e71af90 8010105: new hotspot build - hs25-b24 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 39432a1cefdd Author: minqi Date: 2013-03-14 00:33 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/39432a1cefdd 8003348: SA can not read core file on OS Summary: Macosx uses Mach-O file format for binary files, not ELF format. Currently SA works on core files on other platforms, t his change enables SA work on core file generated on Darwin. Reviewed-by: sla, sspitsyn Contributed-by: yumin.qi at oracle.com ! agent/src/os/bsd/MacosxDebuggerLocal.m ! agent/src/os/bsd/Makefile ! agent/src/os/bsd/libproc.h ! agent/src/os/bsd/libproc_impl.c ! agent/src/os/bsd/libproc_impl.h ! agent/src/os/bsd/ps_core.c ! agent/src/os/bsd/symtab.c ! agent/src/os/bsd/symtab.h ! agent/src/share/classes/sun/jvm/hotspot/BsdVtblAccess.java ! agent/src/share/classes/sun/jvm/hotspot/CommandProcessor.java ! agent/src/share/classes/sun/jvm/hotspot/HotSpotAgent.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/BsdDebuggerLocal.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/BsdThread.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/JavaThread.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/Threads.java ! agent/src/share/classes/sun/jvm/hotspot/tools/PStack.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/PlatformInfo.java ! agent/src/share/native/sadis.c ! make/bsd/makefiles/saproc.make Changeset: 1fc4d4768b90 Author: coleenp Date: 2013-03-15 17:24 -0400 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/1fc4d4768b90 8007725: NPG: Klass::restore_unshareable_info() triggers assert(k->java_mirror() == NULL) Summary: Check for exception during SystemDictionary::resolve_instance_class_or_null() and clean up. Reviewed-by: coleenp, acorn, hseigel, minqi Contributed-by: ioi.lam at oracle.com ! src/share/vm/classfile/classLoaderData.cpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/oops/klass.cpp ! src/share/vm/oops/method.cpp Changeset: 82f49e8e2c28 Author: zgu Date: 2013-03-15 11:53 -0400 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/82f49e8e2c28 8009614: nsk/split_verifier/stress/ifelse/ifelse002_30 fails with 'assert((size & (granularity - 1)) == 0) failed: size not aligned to os::vm_allocation_granularity() Summary: Align up vm allocation size to os defined granularity Reviewed-by: dholmes, coleenp ! src/share/vm/memory/metaspace.cpp Changeset: 919a5f9f36a9 Author: zgu Date: 2013-03-15 17:12 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/919a5f9f36a9 Merge Changeset: 82ab039b9680 Author: dcubed Date: 2013-03-17 08:57 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/82ab039b9680 Merge ! src/share/vm/memory/metaspace.cpp Changeset: 117bb0519114 Author: sla Date: 2013-03-19 13:41 +0100 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/117bb0519114 8009456: SA: typeToVtbl of BasicTypeDataBase should not be static Reviewed-by: coleenp, sla Contributed-by: yunda.mly at taobao.com ! agent/src/share/classes/sun/jvm/hotspot/types/basic/BasicTypeDataBase.java Changeset: 686916dc0439 Author: sla Date: 2013-03-19 13:44 +0100 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/686916dc0439 8009457: SA: A small fix on "scanoops" command in CLHSDB Reviewed-by: sla, coleenp, kmo Contributed-by: yunda.mly at taobao.com ! agent/src/share/classes/sun/jvm/hotspot/CommandProcessor.java Changeset: 9960dce2024f Author: kmo Date: 2013-03-14 13:22 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/9960dce2024f 8010116: Abstract_VM_Version::internal_vm_info_string() should recognize VS2010 and VS2012 Summary: add cases for _MSC_VER == 1600 and 1700 Reviewed-by: zgu ! src/share/vm/runtime/vm_version.cpp Changeset: a40807924950 Author: kmo Date: 2013-03-14 16:17 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/a40807924950 Merge Changeset: f3d486462d36 Author: morris Date: 2013-03-15 18:44 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/f3d486462d36 Merge Changeset: 96ef09c26978 Author: morris Date: 2013-03-16 07:39 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/96ef09c26978 8009166: [parfait] Null pointer deference in hotspot/src/share/vm/opto/type.cpp Summary: add guarantee() to as_instance_type() Reviewed-by: kvn, twisti ! src/share/vm/opto/type.cpp Changeset: 8b4ce9870fd6 Author: morris Date: 2013-03-16 07:39 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/8b4ce9870fd6 8009156: [parfait] Null pointer deference in hotspot/src/share/vm/services/memoryService.cpp Summary: add guarantee() to add_generation_memory_pool() Reviewed-by: kvn, twisti ! src/share/vm/services/memoryService.cpp Changeset: 0a2deac0bbfb Author: morris Date: 2013-03-16 07:40 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/0a2deac0bbfb 8008328: [partfait] Null pointer defererence in hotspot/src/cpu/x86/vm/frame_x86.inline.hpp Summary: add guarantee() to oop_result inlines Reviewed-by: kvn, twisti ! src/cpu/x86/vm/frame_x86.inline.hpp Changeset: 9ef47379df20 Author: morris Date: 2013-03-16 07:41 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/9ef47379df20 8010144: [parfait] Null pointer deference in hotspot/src/os_cpu/linux_x86/vm/os_linux_x86.cpp Summary: add null check to signal handler Reviewed-by: dcubed ! src/os_cpu/linux_x86/vm/os_linux_x86.cpp Changeset: 8552f0992748 Author: kmo Date: 2013-03-15 22:07 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/8552f0992748 8008796: SA: Oop.iterateFields() should support CompressedKlassPointers again Summary: add a missing change from JDK-7054512 so that Oop.iterateFields() works with UseCompressedKlassPointers Reviewed-by: coleenp, roland Contributed-by: yunda.mly at taobao.com ! agent/src/share/classes/sun/jvm/hotspot/oops/Oop.java Changeset: 592f9722c72e Author: kmo Date: 2013-03-16 21:44 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/592f9722c72e Merge Changeset: 4efac99a998b Author: iignatyev Date: 2013-03-18 04:29 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/4efac99a998b 8008211: Some of WB tests on compiler fail Reviewed-by: kvn, vlivanov ! test/compiler/whitebox/CompilerWhiteBoxTest.java ! test/compiler/whitebox/DeoptimizeAllTest.java ! test/compiler/whitebox/DeoptimizeMethodTest.java ! test/compiler/whitebox/IsMethodCompilableTest.java ! test/compiler/whitebox/MakeMethodNotCompilableTest.java Changeset: a5de0cc2f91c Author: roland Date: 2013-03-18 13:19 +0100 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/a5de0cc2f91c 8008555: Debugging code in compiled method sometimes leaks memory Summary: support for strings that have same life-time as code that uses them. Reviewed-by: kvn, twisti ! src/cpu/sparc/vm/macroAssembler_sparc.cpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/share/vm/asm/assembler.cpp ! src/share/vm/asm/assembler.hpp ! src/share/vm/asm/codeBuffer.cpp ! src/share/vm/asm/codeBuffer.hpp ! src/share/vm/code/codeBlob.cpp ! src/share/vm/code/codeBlob.hpp ! src/share/vm/code/icBuffer.hpp ! src/share/vm/code/stubs.cpp ! src/share/vm/code/stubs.hpp ! src/share/vm/compiler/disassembler.cpp ! src/share/vm/compiler/disassembler.hpp ! src/share/vm/interpreter/interpreter.cpp ! src/share/vm/interpreter/interpreter.hpp ! src/share/vm/runtime/stubCodeGenerator.cpp Changeset: 578d9044c463 Author: roland Date: 2013-03-18 09:08 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/578d9044c463 Merge Changeset: be4d5c6c1f79 Author: neliasso Date: 2013-03-19 10:31 +0100 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/be4d5c6c1f79 8010121: Remove definition of ShouldNotReachHere2(msg) Reviewed-by: kvn, stefank, rbackman, twisti Contributed-by: niclas.adlertz at oracle.com ! src/share/vm/memory/sharedHeap.cpp ! src/share/vm/oops/fieldInfo.hpp ! src/share/vm/utilities/debug.cpp ! src/share/vm/utilities/debug.hpp Changeset: f15df3af32c5 Author: morris Date: 2013-03-19 07:20 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/f15df3af32c5 8009172: [parfait] Null pointer deference in hotspot/src/share/vm/opto/output.cpp Summary: add guarantee() to DoScheduling() Reviewed-by: twisti, kvn ! src/share/vm/opto/output.cpp Changeset: 75a28f465a12 Author: morris Date: 2013-03-19 07:23 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/75a28f465a12 8008663: [parfait] Null pointer deference in hotspot/src/share/vm/compiler/compileBroker.cpp Summary: add NULL checks for compiler name Reviewed-by: twisti, kvn ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/compiler/compileBroker.hpp Changeset: 80208f353616 Author: kvn Date: 2013-03-19 10:56 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/80208f353616 8010222: 8007439 disabled inlining of cold accessor methods Summary: added missing parenthesis Reviewed-by: jrose ! src/share/vm/opto/bytecodeInfo.cpp Changeset: 2eef6d34833b Author: morris Date: 2013-03-19 11:49 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/2eef6d34833b 8009022: [parfait] Null pointer deference in hotspot/src/share/vm/oops/generateOopMap.cpp Summary: add guarantee() checks to merge_state_into_bb() Reviewed-by: kvn ! src/share/vm/oops/generateOopMap.cpp Changeset: 3b9368710f08 Author: morris Date: 2013-03-19 12:15 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/3b9368710f08 8008811: [parfait] Null pointer deference in hotspot/src/share/vm/opto/loopopts.cpp Summary: add guarantee() checks Reviewed-by: kvn ! src/share/vm/opto/loopnode.hpp ! src/share/vm/opto/loopopts.cpp Changeset: 1275835a4ccc Author: morris Date: 2013-03-19 16:31 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/1275835a4ccc Merge Changeset: 41340544e182 Author: morris Date: 2013-03-20 06:32 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/41340544e182 8009248: [parfait] Null pointer deference in hotspot/src/share/vm/code/compiledIC.cpp Summary: add guarantee() to set_to_interpreted() Reviewed-by: kvn ! src/share/vm/code/compiledIC.cpp Changeset: 2dec1d9bfbe1 Author: morris Date: 2013-03-20 06:36 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/2dec1d9bfbe1 8009565: [partfait] Null pointer deference in hotspot/src/share/vm/ci/ciEnv.cpp Summary: add guarantee() to get_instance_klass_for_declared_method_holder() Reviewed-by: kvn ! src/share/vm/ci/ciEnv.cpp Changeset: 653d0346aa80 Author: morris Date: 2013-03-20 06:38 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/653d0346aa80 8009578: [parfait] Null pointer deference in hotspot/src/share/vm/classfile/defaultMethods.cpp Summary: add guarantee() to disqualify_method() Reviewed-by: kvn ! src/share/vm/classfile/defaultMethods.cpp Changeset: a59625d96f71 Author: morris Date: 2013-03-20 07:05 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/a59625d96f71 8009181: [parfait] Null pointer deference in hotspot/src/share/vm/opto/loopTransform.cpp Summary: add guarantee() to insert_pre_post_loops() Reviewed-by: kvn ! src/share/vm/opto/loopTransform.cpp Changeset: 98f3af397705 Author: twisti Date: 2013-03-20 17:04 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/98f3af397705 8006965: remove test_gamma and add dedicated test_* targets instead Reviewed-by: kvn, jcoomes ! make/Makefile ! make/bsd/Makefile ! make/bsd/makefiles/buildtree.make ! make/defs.make ! make/linux/Makefile ! make/linux/makefiles/buildtree.make ! make/solaris/Makefile ! make/solaris/makefiles/buildtree.make - make/test/Queens.java Changeset: 589aa23334ea Author: morris Date: 2013-03-21 10:11 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/589aa23334ea 8009584: [parfait] Null pointer deference in hotspot/src/cpu/x86/vm/relocInfo_x86.cpp Summary: added guarantee() to pd_address_in_code() Reviewed-by: kvn ! src/cpu/x86/vm/relocInfo_x86.cpp Changeset: c3c64a973559 Author: morris Date: 2013-03-21 10:13 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/c3c64a973559 8009593: [parfait] Null pointer deference in hotspot/src/share/vm/oops/constantPool.cpp Summary: added guarantee() to print_entry_on() Reviewed-by: kvn ! src/share/vm/oops/constantPool.cpp Changeset: 3536ea6bc4df Author: morris Date: 2013-03-21 21:48 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/3536ea6bc4df Merge - make/test/Queens.java Changeset: 79af1312fc2c Author: mgerdin Date: 2013-03-14 10:54 +0100 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/79af1312fc2c 8005602: NPG: classunloading does not happen while CMS GC with -XX:+CMSClassUnloadingEnabled is used Summary: Call purge() on CLDG after sweep(), reorder purge() call in GenCollectedHeap Reviewed-by: jmasa, stefank ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/metaspace.cpp Changeset: 3c226052f7dc Author: tschatzl Date: 2013-03-14 09:37 +0100 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/3c226052f7dc 6733980: par compact - TraceGen1Time always shows 0.0000 seconds Summary: Use the correct collector to retrieve accumulated gen1 trace time Reviewed-by: johnc, jmasa ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.cpp Changeset: 19f9fabd94cc Author: stefank Date: 2013-03-18 09:34 +0100 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/19f9fabd94cc Merge ! src/share/vm/memory/metaspace.cpp Changeset: fa08949fe0cb Author: johnc Date: 2013-03-18 11:05 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/fa08949fe0cb 8009536: G1: Apache Lucene hang during reference processing Summary: In CMTask::do_marking_step(), Skip offering termination and entering the first and second synchronization barriers if called from a serial context, i.e. the VM thread. Reviewed-by: brutisso, tschatzl ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp Changeset: e864cc14ca75 Author: johnc Date: 2013-03-19 00:57 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/e864cc14ca75 8009940: G1: assert(_finger == _heap_end) failed, concurrentMark.cpp:809 Summary: Skip reference processing if the global marking stack overflows during remark. Refactor and rename set_phase(); move code that sets the concurrency level into its own routine. Do not call set_phase() from within parallel reference processing; use the concurrency level routine instead. The marking state should only set reset by CMTask[0] during the concurrent phase of the marking cycle; if an overflow occurs at any stage during the remark, the marking state will be reset after reference processing. Reviewed-by: brutisso, jmasa ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp Changeset: 1179172e9ec9 Author: johnc Date: 2013-03-19 09:38 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/1179172e9ec9 8008301: G1: guarantee(satb_mq_set.completed_buffers_num() == 0) failure Summary: If the marking stack overflows while the marking tasks are draining the SATB buffers, remark will exit with some SATB buffers left unprocessed. Relax the guarantee to allow for overflow. Reviewed-by: jmasa, brutisso ! src/share/vm/gc_implementation/g1/concurrentMark.cpp Changeset: 7f0cb32dd233 Author: mgerdin Date: 2013-03-21 09:07 +0100 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/7f0cb32dd233 8004241: NPG: Metaspace occupies more memory than specified by -XX:MaxMetaspaceSize option Summary: Enforce MaxMetaspaceSize for both metaspace parts, check MaxMetaspaceSize against "reserved", not "capacity" Reviewed-by: jmasa, johnc ! src/share/vm/memory/metaspace.cpp Changeset: 47902e9acb3a Author: stefank Date: 2013-03-22 10:32 +0100 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/47902e9acb3a Merge ! src/share/vm/memory/metaspace.cpp Changeset: 5855e849c7e6 Author: stefank Date: 2013-03-22 12:32 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/5855e849c7e6 Merge Changeset: 499ccc15bbc8 Author: bpittore Date: 2013-03-15 15:20 -0400 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/499ccc15bbc8 8005716: Enhance JNI specification to allow support of static JNI libraries in Embedded JREs Reviewed-by: dlong, alanb, mduigou ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jni.h ! src/share/vm/runtime/thread.cpp Changeset: 9e62e72c59cc Author: bobv Date: 2013-03-17 06:30 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/9e62e72c59cc Merge Changeset: 3be6a41ad358 Author: dholmes Date: 2013-03-18 19:34 -0400 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/3be6a41ad358 8008783: Modifications needed to JPRT to allow for building hard float abi and new bundle changes Reviewed-by: twisti, collins, bobv, jwilhelm ! make/jprt.properties Changeset: 804663118c1f Author: jprovino Date: 2013-03-22 10:09 -0400 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/804663118c1f Merge Changeset: aca25026e2a4 Author: vladidan Date: 2013-03-22 17:23 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/aca25026e2a4 Merge Changeset: e3a41fc02348 Author: amurillo Date: 2013-03-23 01:47 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/e3a41fc02348 Merge - make/test/Queens.java Changeset: 1c8db54ee9f3 Author: amurillo Date: 2013-03-23 01:47 -0700 URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/1c8db54ee9f3 Added tag hs25-b24 for changeset e3a41fc02348 ! .hgtags From david.katleman at oracle.com Tue Mar 26 23:48:37 2013 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Tue, 26 Mar 2013 23:48:37 +0000 Subject: hg: jdk8/build/jdk: Added tag jdk8-b82 for changeset 624bcb480006 Message-ID: <20130326234858.6870F483FD@hg.openjdk.java.net> Changeset: cdcd4512c6f1 Author: katleman Date: 2013-03-21 10:43 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/cdcd4512c6f1 Added tag jdk8-b82 for changeset 624bcb480006 ! .hgtags From david.katleman at oracle.com Tue Mar 26 23:48:17 2013 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Tue, 26 Mar 2013 23:48:17 +0000 Subject: hg: jdk8/build/jaxp: Added tag jdk8-b82 for changeset d5a58291f09a Message-ID: <20130326234821.25C5C483FB@hg.openjdk.java.net> Changeset: a46d69a1a8ec Author: katleman Date: 2013-03-21 10:43 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jaxp/rev/a46d69a1a8ec Added tag jdk8-b82 for changeset d5a58291f09a ! .hgtags From david.katleman at oracle.com Tue Mar 26 23:48:26 2013 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Tue, 26 Mar 2013 23:48:26 +0000 Subject: hg: jdk8/build/jaxws: Added tag jdk8-b82 for changeset d8d8032d02d7 Message-ID: <20130326234829.77368483FC@hg.openjdk.java.net> Changeset: a1dcc0d83da1 Author: katleman Date: 2013-03-21 10:43 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jaxws/rev/a1dcc0d83da1 Added tag jdk8-b82 for changeset d8d8032d02d7 ! .hgtags From david.katleman at oracle.com Tue Mar 26 23:50:21 2013 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Tue, 26 Mar 2013 23:50:21 +0000 Subject: hg: jdk8/build/langtools: Added tag jdk8-b82 for changeset 825da6847791 Message-ID: <20130326235026.ADB78483FE@hg.openjdk.java.net> Changeset: 22ba3f92d4ae Author: katleman Date: 2013-03-21 10:43 -0700 URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/22ba3f92d4ae Added tag jdk8-b82 for changeset 825da6847791 ! .hgtags From david.katleman at oracle.com Tue Mar 26 23:50:32 2013 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Tue, 26 Mar 2013 23:50:32 +0000 Subject: hg: jdk8/build/nashorn: Added tag jdk8-b82 for changeset 5759f600fcf7 Message-ID: <20130326235033.A8D10483FF@hg.openjdk.java.net> Changeset: 053d7c55dc82 Author: katleman Date: 2013-03-21 10:43 -0700 URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/053d7c55dc82 Added tag jdk8-b82 for changeset 5759f600fcf7 ! .hgtags From martinrb at google.com Wed Mar 27 00:13:38 2013 From: martinrb at google.com (Martin Buchholz) Date: Tue, 26 Mar 2013 17:13:38 -0700 Subject: new build system doesn't notice modified C source files. In-Reply-To: References: Message-ID: Sorry, false alarm. The build proceeded so quietly and quickly, (and my modified code worked the first time!) that I assumed it must have not been built at all, but I was wrong. Congratulations to the build team! But a bit more verbosity to reassure me that a source file was compiled and a library was linked, please! On Tue, Mar 26, 2013 at 3:40 PM, Martin Buchholz wrote: > I modified src/solaris/native/java/lang/UNIXProcess_md.c (on Linux) and > did "make images" but no actual compilation happened. > (I guess I currently need to do a clean rebuild? Which is a serious bug?) > From bharadwaj.yadavalli at oracle.com Wed Mar 27 00:56:04 2013 From: bharadwaj.yadavalli at oracle.com (Bharadwaj Yadavalli) Date: Tue, 26 Mar 2013 20:56:04 -0400 Subject: configure using --disable-zip-debug-info In-Reply-To: <513936BB.2070404@oracle.com> References: <5138CF42.1040102@oracle.com> <513936BB.2070404@oracle.com> Message-ID: <515243A4.1080706@oracle.com> Hi David, Thanks for the suggestion. On 3/7/2013 7:54 PM, David Holmes wrote: > I think this is a bug in Images.gmk: > > ifneq ($(OPENJDK_TARGET_OS),windows) > ALL_BIN_LIST := $(filter-out %.debuginfo %.diz, $(ALL_BIN_LIST)) > else > > You can only have a single wildcard in a pattern so I don't think that > expands the way the author intended. > > Can you try editing jdk/makefiles/Images.gmk and changing the above to: > > ifneq ($(OPENJDK_TARGET_OS),windows) > ALL_BIN_LIST := $(filter-out %.debuginfo, $(ALL_BIN_LIST)) > ALL_BIN_LIST := $(filter-out %.diz, $(ALL_BIN_LIST)) > else > Sadly, that change did not help. I still get the same failure message while building jdk8/tl (or lambda repo). Regards, Bharadwaj > On 8/03/2013 3:32 AM, Bharadwaj Yadavalli wrote: >> I pulled down jdk/tl tree and configured it using the following command >> line: >> >> sh configure --with-debug-level=slowdebug >> --with-boot-jdk=/path/to/installed/jdk7 --disable-zip-debug-info >> >> and built by running >> >> make all >> >> I get the following build error >> >> Ignoring (other) javax.xml.ws.wsaddressing.package-info : >> ClassSymbol >> Creating images/lib/ct.sym >> gmake[2]: *** No rule to make target >> `/path/to/jdk8/workspace/build/linux-x86_64-normal-server-slowdebug/images/_strip_jre/bin/jarsigner.debuginfo.stripped', >> >> needed by `jre-image'. Stop. >> gmake[2]: *** Waiting for unfinished jobs.... >> gmake[1]: *** [images] Error 2 >> make: *** [images-only] Error 2 >> >> The build does not have any problems if I do not specify >> --disable-zip-debug-info >> >> Do I need to specify some other option along with >> --disable-zip-debug-info? >> >> Thanks for your help, >> >> Bharadwaj >> From david.holmes at oracle.com Wed Mar 27 02:40:10 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 27 Mar 2013 12:40:10 +1000 Subject: New build, gobjcopy failure, any clues? In-Reply-To: <5C655765-3638-4C33-8FF9-32D048A898F0@oracle.com> References: <5C655765-3638-4C33-8FF9-32D048A898F0@oracle.com> Message-ID: <51525C0A.6070801@oracle.com> On 27/03/2013 2:33 AM, David Chase wrote: > I think I'm doing a vanilla new-build, but obviously I'm not, because it fails. > What should I be looking for? Official build platform is Solaris 10 and we use gobjcopy version "GNU objcopy 2.15". Your 2.19 version may not have the right support built-in. What supported platforms does it report? 2.15 reports: gobjcopy: supported targets: elf32-sparc elf64-sparc a.out-sunos-big elf64-little elf64-big elf32-little elf32-big srec symbolsrec tekhex binary ihex David > the failure: > > Linking vm... > ld: warning: symbol '__JvmOffsets' has differing types: > (file JvmOffsets.o type=OBJT; file dtrace.o type=FUNC); > ld: warning: symbol 'CodeCache::_heap' has differing types: > (file codeCache.o type=OBJT; file dtrace.o type=FUNC); > ld: warning: symbol 'Universe::_collectedHeap' has differing types: > (file adaptiveSizePolicy.o type=OBJT; file dtrace.o type=FUNC); > ld: warning: symbol 'BufferBlob::__vtbl' has differing types: > (file codeBlob.o type=OBJT; file dtrace.o type=FUNC); > ld: warning: symbol 'Method::__vtbl' has differing types: > (file dtrace.o type=FUNC; file method.o type=OBJT); > ld: warning: symbol 'nmethod::__vtbl' has differing types: > (file dtrace.o type=FUNC; file nmethod.o type=OBJT); > Opening 'libjvm.so' for update > No SHF_ALLOC flags needed to be cleared. > Done with 'libjvm.so' > /usr/ccs/bin/gobjcopy:libjvm.so: File format not recognized > ... > > the offending file: > > file ./hotspot/solaris_sparcv9_compiler2/product/libjvm.so > ./hotspot/solaris_sparcv9_compiler2/product/libjvm.so: ELF 64-bit MSB dynamic lib SPARCV9 Version 1, dynamically linked, not stripped > > > configuration summary: > > Configuration summary: > * Debug level: release > * JDK variant: normal > * JVM variants: server > * OpenJDK target: OS: solaris, CPU architecture: sparc, address length: 64 > > Tools summary: > * Boot JDK: java version "1.8.0-ea" Java(TM) SE Runtime Environment (build 1.8.0-ea-b82) Java HotSpot(TM) Server VM (build 25.0-b23, mixed mode) (at /export/drchase/jdk8) > * C Compiler: Sun Studio version 5.10 (at /java/devtools/sparc/SUNWspro/SS12u1/prod/bin/cc) > * C++ Compiler: Sun Studio version 5.10 (at /java/devtools/sparc/SUNWspro/SS12u1/prod/bin/CC) > > From erik.joelsson at oracle.com Wed Mar 27 08:55:59 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 27 Mar 2013 09:55:59 +0100 Subject: Support building zero with the new build In-Reply-To: <5152328A.9040608@redhat.com> References: <5152328A.9040608@redhat.com> Message-ID: <5152B41F.3090207@oracle.com> Work on this was already initiated in this thread: http://mail.openjdk.java.net/pipermail/build-infra-dev/2013-February/003059.html Would be good if these efforts could be synchronized. I like that you define and translate these hotspot specific variables in hotspot-spec.gmk. I don't think we need to change any variables in hotspot for this to work as was done in the other thread. ZERO_ARCHDEF should maybe belong to platform.m4, not sure, but might as well be defined where you have it. However, checking for libraries would be better moved to libraries.m4 I think. /Erik On 2013-03-27 00:43, Omair Majid wrote: > Hi, > > I tried using the new build system to build zero and ran into a bunch of > problems. The following webrev allows me to build zero successfully. > > http://cr.openjdk.java.net/~omajid/webrevs/zero-newbuild/00/ > > Any thoughts, comments or suggestions? > > Thanks, > Omair > From erik.joelsson at oracle.com Wed Mar 27 08:57:43 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 27 Mar 2013 09:57:43 +0100 Subject: new build system doesn't notice modified C source files. In-Reply-To: References: Message-ID: <5152B487.1080003@oracle.com> On 2013-03-27 01:13, Martin Buchholz wrote: > Sorry, false alarm. > > The build proceeded so quietly and quickly, (and my modified code worked > the first time!) that I assumed it must have not been built at all, but I > was wrong. Congratulations to the build team! But a bit more verbosity to > reassure me that a source file was compiled and a library was linked, > please! > I have been fooled by this too, and would prefer a bit more verbosity. I think setting LOG=info increases it enough to notice this. /Erik > On Tue, Mar 26, 2013 at 3:40 PM, Martin Buchholzwrote: > >> I modified src/solaris/native/java/lang/UNIXProcess_md.c (on Linux) and >> did "make images" but no actual compilation happened. >> (I guess I currently need to do a clean rebuild? Which is a serious bug?) >> From david.holmes at oracle.com Wed Mar 27 09:08:10 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 27 Mar 2013 19:08:10 +1000 Subject: Support building zero with the new build In-Reply-To: <5152328A.9040608@redhat.com> References: <5152328A.9040608@redhat.com> Message-ID: <5152B6FA.7030705@oracle.com> On 27/03/2013 9:43 AM, Omair Majid wrote: > Hi, > > I tried using the new build system to build zero and ran into a bunch of > problems. The following webrev allows me to build zero successfully. > > http://cr.openjdk.java.net/~omajid/webrevs/zero-newbuild/00/ > > Any thoughts, comments or suggestions? The Profiles.gmk change for sa-jdi.jar should really be using a variable that says "I want the SA". The default would be false for zero. But that is a bigger RFE. David > Thanks, > Omair > From erik.joelsson at oracle.com Wed Mar 27 09:40:20 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 27 Mar 2013 10:40:20 +0100 Subject: Support building zero with the new build In-Reply-To: <1364376386.5998.2.camel@mercury> References: <5152328A.9040608@redhat.com> <5152B41F.3090207@oracle.com> <1364376386.5998.2.camel@mercury> Message-ID: <5152BE84.40709@oracle.com> On 2013-03-27 10:26, Roman Kennke wrote: > Am Mittwoch, den 27.03.2013, 09:55 +0100 schrieb Erik Joelsson: >> Work on this was already initiated in this thread: >> >> http://mail.openjdk.java.net/pipermail/build-infra-dev/2013-February/003059.html >> >> Would be good if these efforts could be synchronized. >> >> I like that you define and translate these hotspot specific variables in >> hotspot-spec.gmk. I don't think we need to change any variables in >> hotspot for this to work as was done in the other thread. ZERO_ARCHDEF >> should maybe belong to platform.m4, not sure, but might as well be >> defined where you have it. However, checking for libraries would be >> better moved to libraries.m4 I think. > Yeah, sorry that I did not follow up on 'my' thread. It kindof fizzled > out. What's blocking the patches from going in? > > http://cr.openjdk.java.net/~rkennke/zero_build_infra_hotspot/webrev.01/ I think it was the changes in hotspot that was blocking and those aren't really needed IMO. A simple translation from configure naming of variables to the hotspot naming in hotspot-spec.gmk.in should be enough and follows the current model, like in Omair's patch. > I think the JDK part needs to be revisited now that the way JARs are > built has changed, but this can be done independently: > > http://cr.openjdk.java.net/~rkennke/zero-build-infra-jdk/webrev.01/ > Omair's patch fixed this. I still prefer Roman's configure changes however. If all that could be combined, I would be happy. /Erik From erik.joelsson at oracle.com Wed Mar 27 10:12:38 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 27 Mar 2013 11:12:38 +0100 Subject: configure using --disable-zip-debug-info In-Reply-To: <515243A4.1080706@oracle.com> References: <5138CF42.1040102@oracle.com> <513936BB.2070404@oracle.com> <515243A4.1080706@oracle.com> Message-ID: <5152C616.5030401@oracle.com> I just tried this and the failure reproduces for me. Will investigate. /Erik On 2013-03-27 01:56, Bharadwaj Yadavalli wrote: > > Hi David, > > Thanks for the suggestion. > > On 3/7/2013 7:54 PM, David Holmes wrote: >> I think this is a bug in Images.gmk: >> >> ifneq ($(OPENJDK_TARGET_OS),windows) >> ALL_BIN_LIST := $(filter-out %.debuginfo %.diz, $(ALL_BIN_LIST)) >> else >> >> You can only have a single wildcard in a pattern so I don't think >> that expands the way the author intended. >> >> Can you try editing jdk/makefiles/Images.gmk and changing the above to: >> >> ifneq ($(OPENJDK_TARGET_OS),windows) >> ALL_BIN_LIST := $(filter-out %.debuginfo, $(ALL_BIN_LIST)) >> ALL_BIN_LIST := $(filter-out %.diz, $(ALL_BIN_LIST)) >> else >> > > Sadly, that change did not help. I still get the same failure message > while building jdk8/tl (or lambda repo). > > Regards, > > Bharadwaj > >> On 8/03/2013 3:32 AM, Bharadwaj Yadavalli wrote: >>> I pulled down jdk/tl tree and configured it using the following command >>> line: >>> >>> sh configure --with-debug-level=slowdebug >>> --with-boot-jdk=/path/to/installed/jdk7 --disable-zip-debug-info >>> >>> and built by running >>> >>> make all >>> >>> I get the following build error >>> >>> Ignoring (other) javax.xml.ws.wsaddressing.package-info : >>> ClassSymbol >>> Creating images/lib/ct.sym >>> gmake[2]: *** No rule to make target >>> `/path/to/jdk8/workspace/build/linux-x86_64-normal-server-slowdebug/images/_strip_jre/bin/jarsigner.debuginfo.stripped', >>> >>> needed by `jre-image'. Stop. >>> gmake[2]: *** Waiting for unfinished jobs.... >>> gmake[1]: *** [images] Error 2 >>> make: *** [images-only] Error 2 >>> >>> The build does not have any problems if I do not specify >>> --disable-zip-debug-info >>> >>> Do I need to specify some other option along with >>> --disable-zip-debug-info? >>> >>> Thanks for your help, >>> >>> Bharadwaj >>> > From erik.joelsson at oracle.com Wed Mar 27 10:59:57 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 27 Mar 2013 11:59:57 +0100 Subject: RFR: 8010908: Images target failes when configured with --disable-zip-debug-info In-Reply-To: <5152C616.5030401@oracle.com> References: <5138CF42.1040102@oracle.com> <513936BB.2070404@oracle.com> <515243A4.1080706@oracle.com> <5152C616.5030401@oracle.com> Message-ID: <5152D12D.5020804@oracle.com> I found the problem and fixed it: http://cr.openjdk.java.net/~erikj/8010908/webrev.jdk.01/ /Erik On 2013-03-27 11:12, Erik Joelsson wrote: > I just tried this and the failure reproduces for me. Will investigate. > > /Erik > > On 2013-03-27 01:56, Bharadwaj Yadavalli wrote: >> >> Hi David, >> >> Thanks for the suggestion. >> >> On 3/7/2013 7:54 PM, David Holmes wrote: >>> I think this is a bug in Images.gmk: >>> >>> ifneq ($(OPENJDK_TARGET_OS),windows) >>> ALL_BIN_LIST := $(filter-out %.debuginfo %.diz, $(ALL_BIN_LIST)) >>> else >>> >>> You can only have a single wildcard in a pattern so I don't think >>> that expands the way the author intended. >>> >>> Can you try editing jdk/makefiles/Images.gmk and changing the above to: >>> >>> ifneq ($(OPENJDK_TARGET_OS),windows) >>> ALL_BIN_LIST := $(filter-out %.debuginfo, $(ALL_BIN_LIST)) >>> ALL_BIN_LIST := $(filter-out %.diz, $(ALL_BIN_LIST)) >>> else >>> >> >> Sadly, that change did not help. I still get the same failure message >> while building jdk8/tl (or lambda repo). >> >> Regards, >> >> Bharadwaj >> >>> On 8/03/2013 3:32 AM, Bharadwaj Yadavalli wrote: >>>> I pulled down jdk/tl tree and configured it using the following >>>> command >>>> line: >>>> >>>> sh configure --with-debug-level=slowdebug >>>> --with-boot-jdk=/path/to/installed/jdk7 --disable-zip-debug-info >>>> >>>> and built by running >>>> >>>> make all >>>> >>>> I get the following build error >>>> >>>> Ignoring (other) javax.xml.ws.wsaddressing.package-info : >>>> ClassSymbol >>>> Creating images/lib/ct.sym >>>> gmake[2]: *** No rule to make target >>>> `/path/to/jdk8/workspace/build/linux-x86_64-normal-server-slowdebug/images/_strip_jre/bin/jarsigner.debuginfo.stripped', >>>> >>>> needed by `jre-image'. Stop. >>>> gmake[2]: *** Waiting for unfinished jobs.... >>>> gmake[1]: *** [images] Error 2 >>>> make: *** [images-only] Error 2 >>>> >>>> The build does not have any problems if I do not specify >>>> --disable-zip-debug-info >>>> >>>> Do I need to specify some other option along with >>>> --disable-zip-debug-info? >>>> >>>> Thanks for your help, >>>> >>>> Bharadwaj >>>> >> From david.holmes at oracle.com Wed Mar 27 12:20:11 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 27 Mar 2013 22:20:11 +1000 Subject: RFR: 8010908: Images target failes when configured with --disable-zip-debug-info In-Reply-To: <5152D12D.5020804@oracle.com> References: <5138CF42.1040102@oracle.com> <513936BB.2070404@oracle.com> <515243A4.1080706@oracle.com> <5152C616.5030401@oracle.com> <5152D12D.5020804@oracle.com> Message-ID: <5152E3FB.1020008@oracle.com> On 27/03/2013 8:59 PM, Erik Joelsson wrote: > I found the problem and fixed it: > > http://cr.openjdk.java.net/~erikj/8010908/webrev.jdk.01/ I don't understand - how did this: `$(FIND) $(JDK_OUTPUTDIR)/bin -type f -name \*$(EXE_SUFFIX)` match .debuginfo files but not .diz files (EXE_SUFFIX is empty) ??? David > /Erik > > On 2013-03-27 11:12, Erik Joelsson wrote: >> I just tried this and the failure reproduces for me. Will investigate. >> >> /Erik >> >> On 2013-03-27 01:56, Bharadwaj Yadavalli wrote: >>> >>> Hi David, >>> >>> Thanks for the suggestion. >>> >>> On 3/7/2013 7:54 PM, David Holmes wrote: >>>> I think this is a bug in Images.gmk: >>>> >>>> ifneq ($(OPENJDK_TARGET_OS),windows) >>>> ALL_BIN_LIST := $(filter-out %.debuginfo %.diz, $(ALL_BIN_LIST)) >>>> else >>>> >>>> You can only have a single wildcard in a pattern so I don't think >>>> that expands the way the author intended. >>>> >>>> Can you try editing jdk/makefiles/Images.gmk and changing the above to: >>>> >>>> ifneq ($(OPENJDK_TARGET_OS),windows) >>>> ALL_BIN_LIST := $(filter-out %.debuginfo, $(ALL_BIN_LIST)) >>>> ALL_BIN_LIST := $(filter-out %.diz, $(ALL_BIN_LIST)) >>>> else >>>> >>> >>> Sadly, that change did not help. I still get the same failure message >>> while building jdk8/tl (or lambda repo). >>> >>> Regards, >>> >>> Bharadwaj >>> >>>> On 8/03/2013 3:32 AM, Bharadwaj Yadavalli wrote: >>>>> I pulled down jdk/tl tree and configured it using the following >>>>> command >>>>> line: >>>>> >>>>> sh configure --with-debug-level=slowdebug >>>>> --with-boot-jdk=/path/to/installed/jdk7 --disable-zip-debug-info >>>>> >>>>> and built by running >>>>> >>>>> make all >>>>> >>>>> I get the following build error >>>>> >>>>> Ignoring (other) javax.xml.ws.wsaddressing.package-info : >>>>> ClassSymbol >>>>> Creating images/lib/ct.sym >>>>> gmake[2]: *** No rule to make target >>>>> `/path/to/jdk8/workspace/build/linux-x86_64-normal-server-slowdebug/images/_strip_jre/bin/jarsigner.debuginfo.stripped', >>>>> >>>>> needed by `jre-image'. Stop. >>>>> gmake[2]: *** Waiting for unfinished jobs.... >>>>> gmake[1]: *** [images] Error 2 >>>>> make: *** [images-only] Error 2 >>>>> >>>>> The build does not have any problems if I do not specify >>>>> --disable-zip-debug-info >>>>> >>>>> Do I need to specify some other option along with >>>>> --disable-zip-debug-info? >>>>> >>>>> Thanks for your help, >>>>> >>>>> Bharadwaj >>>>> >>> From erik.joelsson at oracle.com Wed Mar 27 12:58:25 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 27 Mar 2013 13:58:25 +0100 Subject: RFR: 8010908: Images target failes when configured with --disable-zip-debug-info In-Reply-To: <5152E3FB.1020008@oracle.com> References: <5138CF42.1040102@oracle.com> <513936BB.2070404@oracle.com> <515243A4.1080706@oracle.com> <5152C616.5030401@oracle.com> <5152D12D.5020804@oracle.com> <5152E3FB.1020008@oracle.com> Message-ID: <5152ECF1.8050008@oracle.com> On 2013-03-27 13:20, David Holmes wrote: > On 27/03/2013 8:59 PM, Erik Joelsson wrote: >> I found the problem and fixed it: >> >> http://cr.openjdk.java.net/~erikj/8010908/webrev.jdk.01/ > > I don't understand - how did this: > > `$(FIND) $(JDK_OUTPUTDIR)/bin -type f -name \*$(EXE_SUFFIX)` > > match .debuginfo files but not .diz files (EXE_SUFFIX is empty) ??? > It didn't, that was handled by the file command and grep. The problem is file output is more or less the same for the executable and the debuginfo file, but at least those can be separated by name. /Erik > David > >> /Erik >> >> On 2013-03-27 11:12, Erik Joelsson wrote: >>> I just tried this and the failure reproduces for me. Will investigate. >>> >>> /Erik >>> >>> On 2013-03-27 01:56, Bharadwaj Yadavalli wrote: >>>> >>>> Hi David, >>>> >>>> Thanks for the suggestion. >>>> >>>> On 3/7/2013 7:54 PM, David Holmes wrote: >>>>> I think this is a bug in Images.gmk: >>>>> >>>>> ifneq ($(OPENJDK_TARGET_OS),windows) >>>>> ALL_BIN_LIST := $(filter-out %.debuginfo %.diz, $(ALL_BIN_LIST)) >>>>> else >>>>> >>>>> You can only have a single wildcard in a pattern so I don't think >>>>> that expands the way the author intended. >>>>> >>>>> Can you try editing jdk/makefiles/Images.gmk and changing the >>>>> above to: >>>>> >>>>> ifneq ($(OPENJDK_TARGET_OS),windows) >>>>> ALL_BIN_LIST := $(filter-out %.debuginfo, $(ALL_BIN_LIST)) >>>>> ALL_BIN_LIST := $(filter-out %.diz, $(ALL_BIN_LIST)) >>>>> else >>>>> >>>> >>>> Sadly, that change did not help. I still get the same failure message >>>> while building jdk8/tl (or lambda repo). >>>> >>>> Regards, >>>> >>>> Bharadwaj >>>> >>>>> On 8/03/2013 3:32 AM, Bharadwaj Yadavalli wrote: >>>>>> I pulled down jdk/tl tree and configured it using the following >>>>>> command >>>>>> line: >>>>>> >>>>>> sh configure --with-debug-level=slowdebug >>>>>> --with-boot-jdk=/path/to/installed/jdk7 --disable-zip-debug-info >>>>>> >>>>>> and built by running >>>>>> >>>>>> make all >>>>>> >>>>>> I get the following build error >>>>>> >>>>>> Ignoring (other) javax.xml.ws.wsaddressing.package-info : >>>>>> ClassSymbol >>>>>> Creating images/lib/ct.sym >>>>>> gmake[2]: *** No rule to make target >>>>>> `/path/to/jdk8/workspace/build/linux-x86_64-normal-server-slowdebug/images/_strip_jre/bin/jarsigner.debuginfo.stripped', >>>>>> >>>>>> >>>>>> needed by `jre-image'. Stop. >>>>>> gmake[2]: *** Waiting for unfinished jobs.... >>>>>> gmake[1]: *** [images] Error 2 >>>>>> make: *** [images-only] Error 2 >>>>>> >>>>>> The build does not have any problems if I do not specify >>>>>> --disable-zip-debug-info >>>>>> >>>>>> Do I need to specify some other option along with >>>>>> --disable-zip-debug-info? >>>>>> >>>>>> Thanks for your help, >>>>>> >>>>>> Bharadwaj >>>>>> >>>> From david.r.chase at oracle.com Wed Mar 27 13:26:22 2013 From: david.r.chase at oracle.com (David Chase) Date: Wed, 27 Mar 2013 09:26:22 -0400 Subject: New build, gobjcopy failure, any clues? In-Reply-To: <51525C0A.6070801@oracle.com> References: <5C655765-3638-4C33-8FF9-32D048A898F0@oracle.com> <51525C0A.6070801@oracle.com> Message-ID: <82DDBE96-18ED-42A7-86BA-2FA3BD275413@oracle.com> It's not "my" version, it's whatever someone else installed on one of the ghostboxes (terminus). I was perhaps misled into using a 5.11 box by (1) seeing it listed as a box for our use; (2) my success building with Solaris 11 on Intel; (3) the fact that the exact OS version is not mentioned in the summary output of configure (so, probably not that important); (4) it does not whine about my choice (for example, if you use the latest Solaris compilers, it complains bitterly throughout the build, which is nonetheless successful). gobjcopy: supported targets: elf32-sparc elf64-sparc a.out-sunos-big elf64-little elf64-big elf32-little elf32-big srec symbolsrec tekhex binary ihex Isn't this information redundant with the output of "gobjcopy -info" (which appears earlier in this discussion)? It would have saved me a little time if you had mentioned that the output you desire was the result of typing "gobjcopy -v", because this is not implied by TFM, which I did in fact R yesterday. I've wasted quite a bit of time trying to do a detailed test of a code generation change and have been thwarted at every step by flaky tests, underdocumented test harnesses, and inexplicably buggy builds. It took some additional poking to discover the undocumented behavior of the "-v" flag: -v --verbose Verbose output: list all object files modified. In the case of archives, objcopy -V [sic] lists all members of the archive. David On 2013-03-26, at 10:40 PM, David Holmes wrote: > On 27/03/2013 2:33 AM, David Chase wrote: >> I think I'm doing a vanilla new-build, but obviously I'm not, because it fails. >> What should I be looking for? > > Official build platform is Solaris 10 and we use gobjcopy version "GNU objcopy 2.15". > > Your 2.19 version may not have the right support built-in. What supported platforms does it report? > > 2.15 reports: > > gobjcopy: supported targets: elf32-sparc elf64-sparc a.out-sunos-big elf64-little elf64-big elf32-little elf32-big srec symbolsrec tekhex binary ihex > > David > >> * OpenJDK target: OS: solaris, CPU architecture: sparc, address length: 64 >> >> Tools summary: >> * Boot JDK: java version "1.8.0-ea" Java(TM) SE Runtime Environment (build 1.8.0-ea-b82) Java HotSpot(TM) Server VM (build 25.0-b23, mixed mode) (at /export/drchase/jdk8) >> * C Compiler: Sun Studio version 5.10 (at /java/devtools/sparc/SUNWspro/SS12u1/prod/bin/cc) >> * C++ Compiler: Sun Studio version 5.10 (at /java/devtools/sparc/SUNWspro/SS12u1/prod/bin/CC) >> >> From omajid at redhat.com Wed Mar 27 13:42:56 2013 From: omajid at redhat.com (Omair Majid) Date: Wed, 27 Mar 2013 09:42:56 -0400 Subject: Support building zero with the new build In-Reply-To: <5152B41F.3090207@oracle.com> References: <5152328A.9040608@redhat.com> <5152B41F.3090207@oracle.com> Message-ID: <5152F760.4020201@redhat.com> Hi, On 03/27/2013 04:55 AM, Erik Joelsson wrote: > Work on this was already initiated in this thread: > > http://mail.openjdk.java.net/pipermail/build-infra-dev/2013-February/003059.html > Whoops. I was not aware of this. Thanks for pointing this out. > Would be good if these efforts could be synchronized. Yes, this would be great. I am happy to throw away all my changes and help improve Roman's patch. > I like that you define and translate these hotspot specific variables in > hotspot-spec.gmk. I had the feeling that my patch would become a lot less desirable if it started touching hotspot ;) > I don't think we need to change any variables in > hotspot for this to work as was done in the other thread. ZERO_ARCHDEF > should maybe belong to platform.m4, not sure, but might as well be > defined where you have it. However, checking for libraries would be > better moved to libraries.m4 I think. One thing worth pointing out is that my patch only addresses zero, while Roman's patch addresses both zero and shark. Roman, how do you want to proceed? Thanks, Omair -- PGP Key: 66484681 (http://pgp.mit.edu/) Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 From bharadwaj.yadavalli at oracle.com Wed Mar 27 14:36:32 2013 From: bharadwaj.yadavalli at oracle.com (Bharadwaj Yadavalli) Date: Wed, 27 Mar 2013 10:36:32 -0400 Subject: RFR: 8010908: Images target failes when configured with --disable-zip-debug-info In-Reply-To: <5152D12D.5020804@oracle.com> References: <5138CF42.1040102@oracle.com> <513936BB.2070404@oracle.com> <515243A4.1080706@oracle.com> <5152C616.5030401@oracle.com> <5152D12D.5020804@oracle.com> Message-ID: <515303F0.8030701@oracle.com> On 3/27/2013 6:59 AM, Erik Joelsson wrote: > I found the problem and fixed it: > > http://cr.openjdk.java.net/~erikj/8010908/webrev.jdk.01/ > Thanks for your quick response! Your proposed change worked for me. Bharadwaj From rkennke at redhat.com Wed Mar 27 09:26:26 2013 From: rkennke at redhat.com (Roman Kennke) Date: Wed, 27 Mar 2013 10:26:26 +0100 Subject: Support building zero with the new build In-Reply-To: <5152B41F.3090207@oracle.com> References: <5152328A.9040608@redhat.com> <5152B41F.3090207@oracle.com> Message-ID: <1364376386.5998.2.camel@mercury> Am Mittwoch, den 27.03.2013, 09:55 +0100 schrieb Erik Joelsson: > Work on this was already initiated in this thread: > > http://mail.openjdk.java.net/pipermail/build-infra-dev/2013-February/003059.html > > Would be good if these efforts could be synchronized. > > I like that you define and translate these hotspot specific variables in > hotspot-spec.gmk. I don't think we need to change any variables in > hotspot for this to work as was done in the other thread. ZERO_ARCHDEF > should maybe belong to platform.m4, not sure, but might as well be > defined where you have it. However, checking for libraries would be > better moved to libraries.m4 I think. Yeah, sorry that I did not follow up on 'my' thread. It kindof fizzled out. What's blocking the patches from going in? http://cr.openjdk.java.net/~rkennke/zero_build_infra_hotspot/webrev.01/ I think the JDK part needs to be revisited now that the way JARs are built has changed, but this can be done independently: http://cr.openjdk.java.net/~rkennke/zero-build-infra-jdk/webrev.01/ Roman From rkennke at redhat.com Wed Mar 27 14:05:32 2013 From: rkennke at redhat.com (Roman Kennke) Date: Wed, 27 Mar 2013 15:05:32 +0100 Subject: Support building zero with the new build In-Reply-To: <5152F760.4020201@redhat.com> References: <5152328A.9040608@redhat.com> <5152B41F.3090207@oracle.com> <5152F760.4020201@redhat.com> Message-ID: <1364393132.5998.9.camel@mercury> Am Mittwoch, den 27.03.2013, 09:42 -0400 schrieb Omair Majid: > Hi, > > On 03/27/2013 04:55 AM, Erik Joelsson wrote: > > Work on this was already initiated in this thread: > > > > http://mail.openjdk.java.net/pipermail/build-infra-dev/2013-February/003059.html > > > > Whoops. I was not aware of this. Thanks for pointing this out. > > > Would be good if these efforts could be synchronized. > > Yes, this would be great. I am happy to throw away all my changes and > help improve Roman's patch. > > > I like that you define and translate these hotspot specific variables in > > hotspot-spec.gmk. > > I had the feeling that my patch would become a lot less desirable if it > started touching hotspot ;) > > > I don't think we need to change any variables in > > hotspot for this to work as was done in the other thread. ZERO_ARCHDEF > > should maybe belong to platform.m4, not sure, but might as well be > > defined where you have it. However, checking for libraries would be > > better moved to libraries.m4 I think. > > One thing worth pointing out is that my patch only addresses zero, while > Roman's patch addresses both zero and shark. > > Roman, how do you want to proceed? I'd go with Erik's suggestion and keep your part for JDK changes, and mine for the rest, if that is ok with you? Roman From tim.bell at oracle.com Wed Mar 27 16:11:50 2013 From: tim.bell at oracle.com (Tim Bell) Date: Wed, 27 Mar 2013 09:11:50 -0700 Subject: RFR: 8010908: Images target failes when configured with --disable-zip-debug-info In-Reply-To: <5152D12D.5020804@oracle.com> References: <5138CF42.1040102@oracle.com> <513936BB.2070404@oracle.com> <515243A4.1080706@oracle.com> <5152C616.5030401@oracle.com> <5152D12D.5020804@oracle.com> Message-ID: <51531A46.5070907@oracle.com> Hi Erik: > I found the problem and fixed it: > > http://cr.openjdk.java.net/~erikj/8010908/webrev.jdk.01/ Looks good. > /Erik > > On 2013-03-27 11:12, Erik Joelsson wrote: >> I just tried this and the failure reproduces for me. Will investigate. >> >> /Erik >> >> On 2013-03-27 01:56, Bharadwaj Yadavalli wrote: >>> >>> Hi David, >>> >>> Thanks for the suggestion. >>> >>> On 3/7/2013 7:54 PM, David Holmes wrote: >>>> I think this is a bug in Images.gmk: >>>> >>>> ifneq ($(OPENJDK_TARGET_OS),windows) >>>> ALL_BIN_LIST := $(filter-out %.debuginfo %.diz, $(ALL_BIN_LIST)) >>>> else >>>> >>>> You can only have a single wildcard in a pattern so I don't think >>>> that expands the way the author intended. According to my reading of the doc: http://www.gnu.org/software/make/manual/make.html#index-filter-574 It is ok to have more than one % pattern before the , in a filter or a filter-out call. patsubst is the function where only the first % has a special meaning. Tim >>>> >>>> Can you try editing jdk/makefiles/Images.gmk and changing the above >>>> to: >>>> >>>> ifneq ($(OPENJDK_TARGET_OS),windows) >>>> ALL_BIN_LIST := $(filter-out %.debuginfo, $(ALL_BIN_LIST)) >>>> ALL_BIN_LIST := $(filter-out %.diz, $(ALL_BIN_LIST)) >>>> else >>>> >>> >>> Sadly, that change did not help. I still get the same failure >>> message while building jdk8/tl (or lambda repo). >>> >>> Regards, >>> >>> Bharadwaj >>> >>>> On 8/03/2013 3:32 AM, Bharadwaj Yadavalli wrote: >>>>> I pulled down jdk/tl tree and configured it using the following >>>>> command >>>>> line: >>>>> >>>>> sh configure --with-debug-level=slowdebug >>>>> --with-boot-jdk=/path/to/installed/jdk7 --disable-zip-debug-info >>>>> >>>>> and built by running >>>>> >>>>> make all >>>>> >>>>> I get the following build error >>>>> >>>>> Ignoring (other) javax.xml.ws.wsaddressing.package-info : >>>>> ClassSymbol >>>>> Creating images/lib/ct.sym >>>>> gmake[2]: *** No rule to make target >>>>> `/path/to/jdk8/workspace/build/linux-x86_64-normal-server-slowdebug/images/_strip_jre/bin/jarsigner.debuginfo.stripped', >>>>> >>>>> needed by `jre-image'. Stop. >>>>> gmake[2]: *** Waiting for unfinished jobs.... >>>>> gmake[1]: *** [images] Error 2 >>>>> make: *** [images-only] Error 2 >>>>> >>>>> The build does not have any problems if I do not specify >>>>> --disable-zip-debug-info >>>>> >>>>> Do I need to specify some other option along with >>>>> --disable-zip-debug-info? >>>>> >>>>> Thanks for your help, >>>>> >>>>> Bharadwaj >>>>> >>> From david.r.chase at oracle.com Wed Mar 27 16:21:17 2013 From: david.r.chase at oracle.com (David Chase) Date: Wed, 27 Mar 2013 12:21:17 -0400 Subject: I don't think this is intended behavior for LOG=trace Message-ID: <5454EDC2-3DCC-4A03-81C7-0129EBFC551C@oracle.com> PATH=/java/devtools/sparc/bin:/java/devtools/sparc/SUNWspro/SS12u1/bin/:/usr/sfw/bin:/usr/ccs/bin:/home/drchase/bin:/pkg/gnu/bin:/pkg/isv/bin:/pkg/usrdist/bin:/pkg/local/bin:/lab/tools/bin:/lab/east/bin:/usr/bin:/bin uname -a = SunOS dr-evil 5.10 Generic_142900-03 sun4v sparc SUNW,Sun-Fire-T1000 make381 LOG=trace /export/drchase/jdk8tl-full//common/makefiles/Main.gmk:43: Running shell command /usr/bin/time: illegal option -- f usage: time [-p] utility [argument...] /export/drchase/jdk8tl-full//common/makefiles/Main.gmk:44: Running shell command /usr/bin/time: illegal option -- f usage: time [-p] utility [argument...] /export/drchase/jdk8tl-full//common/makefiles/Main.gmk:48: Running shell command /usr/bin/time: illegal option -- f usage: time [-p] utility [argument...] /export/drchase/jdk8tl-full//common/makefiles/Main.gmk:57: Running shell command /usr/bin/time: illegal option -- f usage: time [-p] utility [argument...] /export/drchase/jdk8tl-full//common/makefiles/Main.gmk:83: Building start-make (from /export/drchase/jdk8tl-full/build/solaris-sparcv9-normal-server-release/spec.gmk) (/export/drchase/jdk8tl-full/build/solaris-sparcv9-normal-server-release/spec.gmk newer) /export/drchase/jdk8tl-full//common/makefiles/Main.gmk:83: Building start-make (from /export/drchase/jdk8tl-full/build/solaris-sparcv9-normal-server-release/spec.gmk) (/export/drchase/jdk8tl-full/build/solaris-sparcv9-normal-server-release/spec.gmk newer) /usr/bin/time: illegal option -- f usage: time [-p] utility [argument...] make381: *** [start-make] Error 1 From mike.duigou at oracle.com Wed Mar 27 16:27:57 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Wed, 27 Mar 2013 09:27:57 -0700 Subject: RFR JDK-8010267 & JDK-8010268 : Makefile maintenance for test targets In-Reply-To: References: Message-ID: <081944A1-4DBD-4E24-8C7C-355AFD37196B@oracle.com> I still need a review for both of these changes. Mike On Mar 18 2013, at 22:48 , Mike Duigou wrote: > A two small changes to review: > > If approved I will commit to TL (or someone else can commit to build for me) > > Mike > > JDK-8010267 : Add test-clean for cleaning of testoutput directory from output directory. > > diff --git a/common/makefiles/Main.gmk b/common/makefiles/Main.gmk > --- a/common/makefiles/Main.gmk > +++ b/common/makefiles/Main.gmk > @@ -191,7 +191,7 @@ source-tips: $(OUTPUT_ROOT)/source_tips > > > # Remove everything, except the output from configure. > -clean: clean-langtools clean-corba clean-jaxp clean-jaxws clean-hotspot clean-jdk clean-images clean-overlay-images clean-bootcycle-build clean-docs > +clean: clean-langtools clean-corba clean-jaxp clean-jaxws clean-hotspot clean-jdk clean-images clean-overlay-images clean-bootcycle-build clean-docs clean-test > @($(CD) $(OUTPUT_ROOT) && $(RM) -r tmp source_tips build.log* build-trace*.log*) > @$(ECHO) Cleaned all build artifacts. > > @@ -230,6 +230,8 @@ clean-bootcycle-build: > clean-docs: > $(call CleanComponent,docs) > $(call CleanComponent,docstemp) > +clean-test: > + $(call CleanComponent,testoutput) > > .PHONY: langtools corba jaxp jaxws hotspot jdk images overlay-images install > .PHONY: langtools-only corba-only jaxp-only jaxws-only hotspot-only jdk-only images-only overlay-images-only install-only > > > JDK-8010268 : Remove dependence upon clean target from jdk/test/Makefile prep target > > None of the current users seem to depend upon the clean behaviour of "prep" > > diff --git a/test/Makefile b/test/Makefile > --- a/test/Makefile > +++ b/test/Makefile > @@ -336,7 +336,7 @@ all: jdk_default > @$(ECHO) "Testing completed successfully" > > # Prep for output > -prep: clean > +prep: > @$(MKDIR) -p $(ABS_TEST_OUTPUT_DIR) > @$(MKDIR) -p `$(DIRNAME) $(ARCHIVE_BUNDLE)` > > From tim.bell at oracle.com Wed Mar 27 16:30:48 2013 From: tim.bell at oracle.com (Tim Bell) Date: Wed, 27 Mar 2013 09:30:48 -0700 Subject: I don't think this is intended behavior for LOG=trace In-Reply-To: <5454EDC2-3DCC-4A03-81C7-0129EBFC551C@oracle.com> References: <5454EDC2-3DCC-4A03-81C7-0129EBFC551C@oracle.com> Message-ID: <51531EB8.5030309@oracle.com> On 03/27/13 09:21, David Chase wrote: > PATH=/java/devtools/sparc/bin:/java/devtools/sparc/SUNWspro/SS12u1/bin/:/usr/sfw/bin:/usr/ccs/bin:/home/drchase/bin:/pkg/gnu/bin:/pkg/isv/bin:/pkg/usrdist/bin:/pkg/local/bin:/lab/tools/bin:/lab/east/bin:/usr/bin:/bin > uname -a = SunOS dr-evil 5.10 Generic_142900-03 sun4v sparc SUNW,Sun-Fire-T1000 > > make381 LOG=trace > /export/drchase/jdk8tl-full//common/makefiles/Main.gmk:43: Running shell command > /usr/bin/time: illegal option -- f Looks the same as this bug report: JDK-8010385 build with LOG=trace broken on mac An external view of the bug report is here: http://bugs.sun.com/view_bug.do?bug_id=8010385 It appears the Solaris /usr/bin/time rejects the 'f' flag, same as on a Mac. Tim From david.r.chase at oracle.com Wed Mar 27 16:34:59 2013 From: david.r.chase at oracle.com (David Chase) Date: Wed, 27 Mar 2013 12:34:59 -0400 Subject: Gnu mkdir version 3.16 considered harmful Message-ID: It led to an ugly failure (see below). I took it off my path, cleaned, configured, and the build (so far) went better. I checked the version it was picking up, and it was 3.16. So configure might want to check for this. (Why is this crap on my path? I no longer remember, it has been there for almost ten years, and whether pkg/gnu appears on any given machine is hit-or-miss.) ugly failure: make381[1]: Entering directory `/export/drchase/jdk8tl-full/langtools/makefiles' /pkg/gnu/bin/mkdir -p /export/drchase/jdk8tl-full/build/solaris-sparcv9-normal-server-release/langtools/classes/com/sun/tools/doclets/internal/toolkit/resources /pkg/gnu/bin/mkdir -p /export/drchase/jdk8tl-full/build/solaris-sparcv9-normal-server-release/langtools/classes/com/sun/tools/doclets/internal/toolkit/resources /pkg/gnu/bin/mkdir -p /export/drchase/jdk8tl-full/build/solaris-sparcv9-normal-server-release/langtools/classes/com/sun/tools/doclets/internal/toolkit/resources /pkg/gnu/bin/mkdir -p /export/drchase/jdk8tl-full/build/solaris-sparcv9-normal-server-release/langtools/classes/com/sun/tools/doclets/internal/toolkit/resources /pkg/gnu/bin/mkdir -p /export/drchase/jdk8tl-full/build/solaris-sparcv9-normal-server-release/langtools/classes/com/sun/tools/doclets/internal/toolkit/resources /pkg/gnu/bin/mkdir -p /export/drchase/jdk8tl-full/build/solaris-sparcv9-normal-server-release/langtools/classes/com/sun/tools/doclets/internal/toolkit/resources /pkg/gnu/bin/mkdir -p /export/drchase/jdk8tl-full/build/solaris-sparcv9-normal-server-release/langtools/classes/com/sun/tools/doclets/internal/toolkit/resources /pkg/gnu/bin/mkdir: cannot create directory `/export/drchase/jdk8tl-full/build/solaris-sparcv9-normal-server-release/langtools/classes/com/sun/tools'/pkg/gnu/bin/mkdir: cannot create directory `/export/drchase/jdk8tl-full/build/solaris-sparcv9-normal-server-release/langtools/classes/com/sun/tools/doclets': File exists /pkg/gnu/bin/mkdir: cannot create directory `/export/drchase/jdk8tl-full/build/solaris-sparcv9-normal-server-release/langtools/classes/com/sun/tools/doclets/internal': File exists make381[1]: *** [/export/drchase/jdk8tl-full/build/solaris-sparcv9-normal-server-release/langtools/classes/com/sun/tools/doclets/internal/toolkit/resources/activetitlebar_end.gif] Error 1 : File exists make381[1]: *** Waiting for unfinished jobs.... make381[1]: *** [/export/drchase/jdk8tl-full/build/solaris-sparcv9-normal-server-release/langtools/classes/com/sun/tools/doclets/internal/toolkit/resources/doclet.xml] Error 1 /pkg/gnu/bin/mkdir: cannot create directory `/export/drchase/jdk8tl-full/build/solaris-sparcv9-normal-server-release/langtools/classes/com/sun/tools/doclets/internal/toolkit/resources'make381[1]: *** [/export/drchase/jdk8tl-full/build/solaris-sparcv9-normal-server-release/langtools/classes/com/sun/tools/doclets/internal/toolkit/resources/script.js] Error 1 : File exists /pkg/gnu/bin/cp /export/drchase/jdk8tl-full/langtools/src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/background.gif /export/drchase/jdk8tl-full/build/solaris-sparcv9-normal-server-release/langtools/classes/com/sun/tools/doclets/internal/toolkit/resources/background.gif /pkg/gnu/bin/cp /export/drchase/jdk8tl-full/langtools/src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/tab.gif /export/drchase/jdk8tl-full/build/solaris-sparcv9-normal-server-release/langtools/classes/com/sun/tools/doclets/internal/toolkit/resources/tab.gif make381[1]: *** [/export/drchase/jdk8tl-full/build/solaris-sparcv9-normal-server-release/langtools/classes/com/sun/tools/doclets/internal/toolkit/resources/stylesheet.css] Error 1 /pkg/gnu/bin/chmod -f ug+w /export/drchase/jdk8tl-full/build/solaris-sparcv9-normal-server-release/langtools/classes/com/sun/tools/doclets/internal/toolkit/resources/tab.gif /pkg/gnu/bin/mkdir: cannot create directory `/export/drchase/jdk8tl-full/build/solaris-sparcv9-normal-server-release/langtools/classes/com/sun/tools': File exists make381[1]: *** [/export/drchase/jdk8tl-full/build/solaris-sparcv9-normal-server-release/langtools/classes/com/sun/tools/doclets/internal/toolkit/resources/activetitlebar.gif] Error 1 /pkg/gnu/bin/chmod -f ug+w /export/drchase/jdk8tl-full/build/solaris-sparcv9-normal-server-release/langtools/classes/com/sun/tools/doclets/internal/toolkit/resources/background.gif make381[1]: Leaving directory `/export/drchase/jdk8tl-full/langtools/makefiles' make381: *** [langtools-only] Error 2 From mike.duigou at oracle.com Wed Mar 27 17:02:59 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Wed, 27 Mar 2013 10:02:59 -0700 Subject: RFR: 8009824: webrev.ksh generated jdk.patch files do not handle renames, copies, and shouldn't be applied In-Reply-To: <5151DFD6.8090001@oracle.com> References: <5151DFD6.8090001@oracle.com> Message-ID: I've generated a couple of webrevs using your updated version. It's definitely an improvement. When I made my updates I didn't change the version number "23.18" but instead just added "+jbs". I do think we should decide what to do regarding versioning especially since webrev writes it's version to the output files. Time for "24.0"? Mike On Mar 26 2013, at 10:50 , Jim Gish wrote: > Please review http://cr.openjdk.java.net/~jgish/Bug8009824-UpdateWebrevToUseHgExport/ > > This change to webrev.ksh replaces the current method for generating a patch with one that uses hg export -g, preserving copy, move and rename operations. The current method results in a patch which does not properly account for these file operations and cannot be safely applied. > > As a result of this change, a valid changeset is generated that can be safely applied by a committer (reducing the burden on and decreasing the chance of mistakes by non-committers when preparing webrevs and subsequent changesets to be sent to committers for pushing). > > Note that the new method can only be used when there are committed changes. If webrev is used against uncommitted changes in a users workspace, the old method of generating the patch is still used. (Another bug, another day :-)) > > Thanks, > Jim From volker.simonis at gmail.com Wed Mar 27 17:08:38 2013 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 27 Mar 2013 18:08:38 +0100 Subject: New build, gobjcopy failure, any clues? In-Reply-To: <82DDBE96-18ED-42A7-86BA-2FA3BD275413@oracle.com> References: <5C655765-3638-4C33-8FF9-32D048A898F0@oracle.com> <51525C0A.6070801@oracle.com> <82DDBE96-18ED-42A7-86BA-2FA3BD275413@oracle.com> Message-ID: Hi David, I found a Solaris 11 box today and it seems that this is really a problem of binutils 2.19 on Solaris 11. Initially there was no gobjcopy on my Solaris machine at all so I did the following: - downloaded gnu-binutils.p5i from http://pkg.oracle.com/solaris/release/en/index.shtml - installed developer/gnu-binutils at 2.19-0.175.0.0.0.2.537 by doing '/usr/lib/pm-launch packagemanager gnu-binutils.p5i' Now I had /usr/ccs/bin/gobjcopy (version 2.19) but it miserably failed even on an libjvm.so from a jdk7u build that was done on Solaris 10 (and worked there): gobjcopy --only-keep-debug /usr/work/openjdk/nb/sun_64/nightly/output-jdk7u/j2sdk-image/jre/lib/sparcv9/server/libjvm.so /tmp/libjvm.debuginfo gobjcopy:/usr/work/openjdk/nb/sun_64/nightly/output-jdk7u/j2sdk-image/jre/lib/sparcv9/server/libjvm.so: File format not recognized You could try to compile binutils yourself and/or open a bug report against the binutils 2.19 package on Solaris 11 Regards, Volker On Wed, Mar 27, 2013 at 2:26 PM, David Chase wrote: > It's not "my" version, it's whatever someone else installed on one of the > ghostboxes (terminus). > > I was perhaps misled into using a 5.11 box by > (1) seeing it listed as a box for our use; > (2) my success building with Solaris 11 on Intel; > (3) the fact that the exact OS version is not mentioned in the summary > output of configure (so, probably not that important); > (4) it does not whine about my choice (for example, if you use the latest > Solaris compilers, it complains bitterly throughout the build, which is > nonetheless successful). > > gobjcopy: supported targets: elf32-sparc elf64-sparc a.out-sunos-big > elf64-little elf64-big elf32-little elf32-big srec symbolsrec tekhex binary > ihex > > Isn't this information redundant with the output of "gobjcopy -info" > (which appears earlier in this discussion)? > > It would have saved me a little time if you had mentioned that the output > you desire > was the result of typing "gobjcopy -v", because this is not implied by > TFM, which I did in fact R > yesterday. I've wasted quite a bit of time trying to do a detailed test > of a code generation change > and have been thwarted at every step by flaky tests, underdocumented test > harnesses, and > inexplicably buggy builds. It took some additional poking to discover the > undocumented > behavior of the "-v" flag: > > -v > --verbose > Verbose output: list all object files modified. In the > case of archives, objcopy -V [sic] lists all members of the > archive. > > David > > On 2013-03-26, at 10:40 PM, David Holmes wrote: > > > On 27/03/2013 2:33 AM, David Chase wrote: > >> I think I'm doing a vanilla new-build, but obviously I'm not, because > it fails. > >> What should I be looking for? > > > > Official build platform is Solaris 10 and we use gobjcopy version "GNU > objcopy 2.15". > > > > Your 2.19 version may not have the right support built-in. What > supported platforms does it report? > > > > 2.15 reports: > > > > gobjcopy: supported targets: elf32-sparc elf64-sparc a.out-sunos-big > elf64-little elf64-big elf32-little elf32-big srec symbolsrec tekhex binary > ihex > > > > David > > > >> * OpenJDK target: OS: solaris, CPU architecture: sparc, address length: > 64 > >> > >> Tools summary: > >> * Boot JDK: java version "1.8.0-ea" Java(TM) SE Runtime > Environment (build 1.8.0-ea-b82) Java HotSpot(TM) Server VM (build > 25.0-b23, mixed mode) (at /export/drchase/jdk8) > >> * C Compiler: Sun Studio version 5.10 (at > /java/devtools/sparc/SUNWspro/SS12u1/prod/bin/cc) > >> * C++ Compiler: Sun Studio version 5.10 (at > /java/devtools/sparc/SUNWspro/SS12u1/prod/bin/CC) > >> > >> > > From david.r.chase at oracle.com Wed Mar 27 17:17:02 2013 From: david.r.chase at oracle.com (David Chase) Date: Wed, 27 Mar 2013 13:17:02 -0400 Subject: New build, gobjcopy failure, any clues? In-Reply-To: References: <5C655765-3638-4C33-8FF9-32D048A898F0@oracle.com> <51525C0A.6070801@oracle.com> <82DDBE96-18ED-42A7-86BA-2FA3BD275413@oracle.com> Message-ID: On 2013-03-27, at 1:08 PM, Volker Simonis wrote: > Hi David, > > I found a Solaris 11 box today and it seems that this is really a problem of binutils 2.19 on Solaris 11. And vice-versa -- 10 minutes ago I tried gobjcopy 2.15 on the command line (on Solaris 11, with the same libjvm.so) and it worked. I'm testing a from-scratch build right now. Thanks very much for your help. Note that this appears to be a sparc-specific problem; I've been building on Intel Solaris 11 with no problems. Hmmm, differently busted, seems like I ought to install it properly instead of just copying over one binary, might want to update the rest of the binutils as well: Making signal interposition lib... Making libjvm_dtrace.so Opening 'libjsig.so' for update No SHF_ALLOC flags needed to be cleared. Done with 'libjsig.so' Opening 'libjvm_dtrace.so' for update No SHF_ALLOC flags needed to be cleared. Done with 'libjvm_dtrace.so' BFD: libjsig.debuginfo: Not enough room for program headers, try linking with -N /home/drchase/gobjcopy: libjsig.debuginfo: Bad value BFD: libjsig.debuginfo: Not enough room for program headers, try linking with -N /home/drchase/gobjcopy: libjsig.debuginfo: Bad value make381[6]: *** [libjsig.so] Error 1 make381[6]: *** Waiting for unfinished jobs.... BFD: libjvm_dtrace.debuginfo: Not enough room for program headers, try linking with -N /home/drchase/gobjcopy: libjvm_dtrace.debuginfo: Bad value BFD: libjvm_dtrace.debuginfo: Not enough room for program headers, try linking with -N /home/drchase/gobjcopy: libjvm_dtrace.debuginfo: Bad value David > Initially there was no gobjcopy on my Solaris machine at all so I did the following: > > - downloaded gnu-binutils.p5i from http://pkg.oracle.com/solaris/release/en/index.shtml > - installed developer/gnu-binutils at 2.19-0.175.0.0.0.2.537 by doing '/usr/lib/pm-launch packagemanager gnu-binutils.p5i' > > Now I had /usr/ccs/bin/gobjcopy (version 2.19) but it miserably failed even on an libjvm.so from a jdk7u build that was done on Solaris 10 (and worked there): > > gobjcopy --only-keep-debug /usr/work/openjdk/nb/sun_64/nightly/output-jdk7u/j2sdk-image/jre/lib/sparcv9/server/libjvm.so /tmp/libjvm.debuginfo > gobjcopy:/usr/work/openjdk/nb/sun_64/nightly/output-jdk7u/j2sdk-image/jre/lib/sparcv9/server/libjvm.so: File format not recognized > > You could try to compile binutils yourself and/or open a bug report against the binutils 2.19 package on Solaris 11 > > Regards, > Volker > From volker.simonis at gmail.com Wed Mar 27 17:26:19 2013 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 27 Mar 2013 18:26:19 +0100 Subject: New build, gobjcopy failure, any clues? In-Reply-To: References: <5C655765-3638-4C33-8FF9-32D048A898F0@oracle.com> <51525C0A.6070801@oracle.com> <82DDBE96-18ED-42A7-86BA-2FA3BD275413@oracle.com> Message-ID: I'm pretty sure this wouldn't have happened with "Open Solaris 11" :) On Wed, Mar 27, 2013 at 6:17 PM, David Chase wrote: > On 2013-03-27, at 1:08 PM, Volker Simonis > wrote: > > > Hi David, > > > > I found a Solaris 11 box today and it seems that this is really a > problem of binutils 2.19 on Solaris 11. > > And vice-versa -- 10 minutes ago I tried gobjcopy 2.15 on the command line > (on Solaris 11, with the same libjvm.so) and it worked. > > I'm testing a from-scratch build right now. > > Thanks very much for your help. > Note that this appears to be a sparc-specific problem; I've been building > on Intel Solaris 11 with no problems. > > Hmmm, differently busted, seems like I ought to install it properly > instead of just copying over one binary, > might want to update the rest of the binutils as well: > > Making signal interposition lib... > Making libjvm_dtrace.so > Opening 'libjsig.so' for update > No SHF_ALLOC flags needed to be cleared. > Done with 'libjsig.so' > Opening 'libjvm_dtrace.so' for update > No SHF_ALLOC flags needed to be cleared. > Done with 'libjvm_dtrace.so' > BFD: libjsig.debuginfo: Not enough room for program headers, try linking > with -N > /home/drchase/gobjcopy: libjsig.debuginfo: Bad value > BFD: libjsig.debuginfo: Not enough room for program headers, try linking > with -N > /home/drchase/gobjcopy: libjsig.debuginfo: Bad value > make381[6]: *** [libjsig.so] Error 1 > make381[6]: *** Waiting for unfinished jobs.... > BFD: libjvm_dtrace.debuginfo: Not enough room for program headers, try > linking with -N > /home/drchase/gobjcopy: libjvm_dtrace.debuginfo: Bad value > BFD: libjvm_dtrace.debuginfo: Not enough room for program headers, try > linking with -N > /home/drchase/gobjcopy: libjvm_dtrace.debuginfo: Bad value > > David > > > Initially there was no gobjcopy on my Solaris machine at all so I did > the following: > > > > - downloaded gnu-binutils.p5i from > http://pkg.oracle.com/solaris/release/en/index.shtml > > - installed developer/gnu-binutils at 2.19-0.175.0.0.0.2.537 by doing > '/usr/lib/pm-launch packagemanager gnu-binutils.p5i' > > > > Now I had /usr/ccs/bin/gobjcopy (version 2.19) but it miserably failed > even on an libjvm.so from a jdk7u build that was done on Solaris 10 (and > worked there): > > > > gobjcopy --only-keep-debug > /usr/work/openjdk/nb/sun_64/nightly/output-jdk7u/j2sdk-image/jre/lib/sparcv9/server/libjvm.so > /tmp/libjvm.debuginfo > > > gobjcopy:/usr/work/openjdk/nb/sun_64/nightly/output-jdk7u/j2sdk-image/jre/lib/sparcv9/server/libjvm.so: > File format not recognized > > > > You could try to compile binutils yourself and/or open a bug report > against the binutils 2.19 package on Solaris 11 > > > > Regards, > > Volker > > > From mark.susko at oracle.com Wed Mar 27 19:24:59 2013 From: mark.susko at oracle.com (Mark Susko) Date: Wed, 27 Mar 2013 15:24:59 -0400 Subject: 7152237 Linking with Java 7 libjvm.so on Linux reports unrecognized file format Message-ID: <5153478B.5010106@oracle.com> Hi all, http://monaco.sfbay.sun.com/detail.jsp?cr=7152237 I have a customer who is asking about the above bug. It seems they too have run into it. I explained about the public comment regarding fPIC that was in there and asked them to test different SLES builds. Their response is: It works on SLES11 but not 10 SP3. 6_33 works on both. When objdump is run manually on the .so files the error occurs, so I am wondering if there is some reference in the .so files that is not compatible with the older SLES 10 sp3 OS, ie maybe the library files were built on a newer system so that there are backword compatibility issues. Is there an explanation available? Thanks, Mark From volker.simonis at gmail.com Wed Mar 27 20:07:16 2013 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 27 Mar 2013 21:07:16 +0100 Subject: 7152237 Linking with Java 7 libjvm.so on Linux reports unrecognized file format In-Reply-To: <5153478B.5010106@oracle.com> References: <5153478B.5010106@oracle.com> Message-ID: Hi Mark, the next time you post to an OpenJDK mailing list please provide links which are visible from outside Oracle as well: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7152237 Thank you, Volker On Wed, Mar 27, 2013 at 8:24 PM, Mark Susko wrote: > Hi all, > > http://monaco.sfbay.sun.com/**detail.jsp?cr=7152237 > > I have a customer who is asking about the above bug. It seems they too > have run into it. > I explained about the public comment regarding fPIC that was in there and > asked them to test different SLES builds. > Their response is: > > It works on SLES11 but not 10 SP3. 6_33 works on both. When objdump is > run manually on the .so files the error occurs, so > I am wondering if there is some reference in the .so files that is not > compatible with the older SLES 10 sp3 OS, ie maybe the library files > were built on a newer system so that there are backword compatibility > issues. > > Is there an explanation available? > > Thanks, > Mark > > From david.r.chase at oracle.com Wed Mar 27 20:58:09 2013 From: david.r.chase at oracle.com (David Chase) Date: Wed, 27 Mar 2013 16:58:09 -0400 Subject: New build, gobjcopy failure, any clues? In-Reply-To: References: <5C655765-3638-4C33-8FF9-32D048A898F0@oracle.com> <51525C0A.6070801@oracle.com> <82DDBE96-18ED-42A7-86BA-2FA3BD275413@oracle.com> Message-ID: Getting to new build on Solaris11-sparc (not necessary for Solaris11-x86). Here's a recipe that works. It is biased towards modern releases of software. Note the use of undocumented flag-seting to configure and make at various steps, and the two out-of-band adjustments to binutils. 1) configure+make+install zlib-1.2.7 (e.g., --prefix=/export/drchase/newbuild) 2) configure binutils.23.2 (e.g., --prefix=/export/drchase/newbuild) 3) build binutils, referencing the new zlib DEFAULT_INCLUDES=-I/export/drchase/newbuild/include make381 -e 4) install symlink for gobjcopy cd /export/drchase/newbuild ; ln -s objcopy gobjcopy 5) configure new build, carefully avoiding as in binutils-23.2.2 AS=/usr/ccs/bin/as TOOLS_DIR=/export/drchase/newbuild/bin bash configure \ --with-cups=/java/devtools/share/cups --with-freetype=/java/devtools/sparc/freetype-sparcv9 Another choice here would be to remove "as" from the new binutils, a third choice would be to change the problematic invocation. ------- I tried not installing the symbolic link from gobjcopy to objcopy, and configure ignored it. The binutils build error that comes from a down-rev zlib is from a missing macro/declaration in older zlib.h: /bin/sh ./libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -DCP_ACP=1 -I. -I. -I./../include -DHAVE_bfd_elf32_sparc_sol2_vec -DHAVE_bfd_elf64_sparc_sol2_vec -DHAVE_sunos_big_vec -DHAVE_bfd_elf64_little_generic_vec -DHAVE_bfd_elf64_big_generic_vec -DHAVE_bfd_elf32_little_generic_vec -DHAVE_bfd_elf32_big_generic_vec -DBINDIR='"/export/dr2chase/newbuild/bin"' -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Werror -g -O2 -MT compress.lo -MD -MP -MF .deps/compress.Tpo -c -o compress.lo compress.c libtool: compile: gcc -DHAVE_CONFIG_H -I. -DCP_ACP=1 -I. -I. -I./../include -DHAVE_bfd_elf32_sparc_sol2_vec -DHAVE_bfd_elf64_sparc_sol2_vec -DHAVE_sunos_big_vec -DHAVE_bfd_elf64_little_generic_vec -DHAVE_bfd_elf64_big_generic_vec -DHAVE_bfd_elf32_little_generic_vec -DHAVE_bfd_elf32_big_generic_vec "-DBINDIR=\"/export/dr2chase/newbuild/bin\"" -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Werror -g -O2 -MT compress.lo -MD -MP -MF .deps/compress.Tpo -c compress.c -o compress.o cc1: warnings being treated as errors compress.c: In function ?bfd_compress_section_contents?: compress.c:99:3: error: implicit declaration of function ?compressBound? make381[4]: *** [compress.lo] Error 1 The error that comes from using the new as: /export/drchase/newbuild/bin/as: unrecognized option `-THIS_FILE="mlib_v_ImageCopy_blk.s"' make381[2]: *** [/export/drchase/jdk8tl-full/build/solaris-sparcv9-normal-server-release/jdk/objs/libawt/mlib_v_ImageCopy_blk.o] Error 1 make381[2]: *** Waiting for unfinished jobs.... make381[1]: *** [libs-only] Error 2 gmake: *** [jdk-only] Error 2 From volker.simonis at gmail.com Wed Mar 27 21:24:39 2013 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 27 Mar 2013 22:24:39 +0100 Subject: 7152237 Linking with Java 7 libjvm.so on Linux reports unrecognized file format In-Reply-To: <5153478B.5010106@oracle.com> References: <5153478B.5010106@oracle.com> Message-ID: This may be releated to the fact that on SLES 10 the default linker only supports anonymous version tags. As far as I know Oracle Java 7 libraries have named version tags (of the form `SUNWprivate_1.1') but are compiled on RedHat which doesn't has this problem. I don't have a link at hand but you can google for "Invalid version tag EXPORTED'. Only anonymous version tag is allowed in executable" to find more information. The only workaround I know would be to compile and use a custom version of binutils/ld on SLES 10 which doesn't suffer from this problem. Regards, Volker On Wed, Mar 27, 2013 at 8:24 PM, Mark Susko wrote: > Hi all, > > http://monaco.sfbay.sun.com/detail.jsp?cr=7152237 > > I have a customer who is asking about the above bug. It seems they too > have run into it. > I explained about the public comment regarding fPIC that was in there and > asked them to test different SLES builds. > Their response is: > > It works on SLES11 but not 10 SP3. 6_33 works on both. When objdump is run > manually on the .so files the error occurs, so > I am wondering if there is some reference in the .so files that is not > compatible with the older SLES 10 sp3 OS, ie maybe the library files > were built on a newer system so that there are backword compatibility > issues. > > Is there an explanation available? > > Thanks, > Mark > From david.katleman at oracle.com Wed Mar 27 21:33:39 2013 From: david.katleman at oracle.com (david.katleman at oracle.com) Date: Wed, 27 Mar 2013 21:33:39 +0000 Subject: hg: jdk8/build/jdk: 2 new changesets Message-ID: <20130327213414.E769448431@hg.openjdk.java.net> Changeset: 6782f2c46bca Author: wetmore Date: 2013-03-21 16:31 -0700 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/6782f2c46bca 8009517: new code changes causing errors in old build (-Werror) environment Reviewed-by: mduigou ! make/com/sun/org/apache/xml/Makefile ! make/javax/others/Makefile Changeset: ac519af51769 Author: dcherepanov Date: 2013-03-27 08:32 +0400 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/ac519af51769 Merge From kellyohair at gmail.com Thu Mar 28 02:47:25 2013 From: kellyohair at gmail.com (Kelly O'Hair) Date: Wed, 27 Mar 2013 19:47:25 -0700 Subject: New build, gobjcopy failure, any clues? In-Reply-To: <51525C0A.6070801@oracle.com> References: <5C655765-3638-4C33-8FF9-32D048A898F0@oracle.com> <51525C0A.6070801@oracle.com> Message-ID: There was a bug in the gobjcopy in Solaris 11.0 that was fixed in 11.1. Check with Dan -kto On Mar 26, 2013, at 7:40 PM, David Holmes wrote: > On 27/03/2013 2:33 AM, David Chase wrote: >> I think I'm doing a vanilla new-build, but obviously I'm not, because it fails. >> What should I be looking for? > > Official build platform is Solaris 10 and we use gobjcopy version "GNU objcopy 2.15". > > Your 2.19 version may not have the right support built-in. What supported platforms does it report? > > 2.15 reports: > > gobjcopy: supported targets: elf32-sparc elf64-sparc a.out-sunos-big elf64-little elf64-big elf32-little elf32-big srec symbolsrec tekhex binary ihex > > David > >> the failure: >> >> Linking vm... >> ld: warning: symbol '__JvmOffsets' has differing types: >> (file JvmOffsets.o type=OBJT; file dtrace.o type=FUNC); >> ld: warning: symbol 'CodeCache::_heap' has differing types: >> (file codeCache.o type=OBJT; file dtrace.o type=FUNC); >> ld: warning: symbol 'Universe::_collectedHeap' has differing types: >> (file adaptiveSizePolicy.o type=OBJT; file dtrace.o type=FUNC); >> ld: warning: symbol 'BufferBlob::__vtbl' has differing types: >> (file codeBlob.o type=OBJT; file dtrace.o type=FUNC); >> ld: warning: symbol 'Method::__vtbl' has differing types: >> (file dtrace.o type=FUNC; file method.o type=OBJT); >> ld: warning: symbol 'nmethod::__vtbl' has differing types: >> (file dtrace.o type=FUNC; file nmethod.o type=OBJT); >> Opening 'libjvm.so' for update >> No SHF_ALLOC flags needed to be cleared. >> Done with 'libjvm.so' >> /usr/ccs/bin/gobjcopy:libjvm.so: File format not recognized >> ... >> >> the offending file: >> >> file ./hotspot/solaris_sparcv9_compiler2/product/libjvm.so >> ./hotspot/solaris_sparcv9_compiler2/product/libjvm.so: ELF 64-bit MSB dynamic lib SPARCV9 Version 1, dynamically linked, not stripped >> >> >> configuration summary: >> >> Configuration summary: >> * Debug level: release >> * JDK variant: normal >> * JVM variants: server >> * OpenJDK target: OS: solaris, CPU architecture: sparc, address length: 64 >> >> Tools summary: >> * Boot JDK: java version "1.8.0-ea" Java(TM) SE Runtime Environment (build 1.8.0-ea-b82) Java HotSpot(TM) Server VM (build 25.0-b23, mixed mode) (at /export/drchase/jdk8) >> * C Compiler: Sun Studio version 5.10 (at /java/devtools/sparc/SUNWspro/SS12u1/prod/bin/cc) >> * C++ Compiler: Sun Studio version 5.10 (at /java/devtools/sparc/SUNWspro/SS12u1/prod/bin/CC) >> >> From david.holmes at oracle.com Thu Mar 28 03:41:31 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 28 Mar 2013 13:41:31 +1000 Subject: RFR: 8010908: Images target failes when configured with --disable-zip-debug-info In-Reply-To: <5152ECF1.8050008@oracle.com> References: <5138CF42.1040102@oracle.com> <513936BB.2070404@oracle.com> <515243A4.1080706@oracle.com> <5152C616.5030401@oracle.com> <5152D12D.5020804@oracle.com> <5152E3FB.1020008@oracle.com> <5152ECF1.8050008@oracle.com> Message-ID: <5153BBEB.5000504@oracle.com> On 27/03/2013 10:58 PM, Erik Joelsson wrote: > On 2013-03-27 13:20, David Holmes wrote: >> On 27/03/2013 8:59 PM, Erik Joelsson wrote: >>> I found the problem and fixed it: >>> >>> http://cr.openjdk.java.net/~erikj/8010908/webrev.jdk.01/ >> >> I don't understand - how did this: >> >> `$(FIND) $(JDK_OUTPUTDIR)/bin -type f -name \*$(EXE_SUFFIX)` >> >> match .debuginfo files but not .diz files (EXE_SUFFIX is empty) ??? >> > It didn't, that was handled by the file command and grep. The problem is > file output is more or less the same for the executable and the > debuginfo file, but at least those can be separated by name. Ah! Got it - thanks. So is this line buggy anyway: ALL_BIN_LIST := $(filter-out %.debuginfo %.diz, $(ALL_BIN_LIST)) I thought you could only have a single wildcard. David ----- > /Erik >> David >> >>> /Erik >>> >>> On 2013-03-27 11:12, Erik Joelsson wrote: >>>> I just tried this and the failure reproduces for me. Will investigate. >>>> >>>> /Erik >>>> >>>> On 2013-03-27 01:56, Bharadwaj Yadavalli wrote: >>>>> >>>>> Hi David, >>>>> >>>>> Thanks for the suggestion. >>>>> >>>>> On 3/7/2013 7:54 PM, David Holmes wrote: >>>>>> I think this is a bug in Images.gmk: >>>>>> >>>>>> ifneq ($(OPENJDK_TARGET_OS),windows) >>>>>> ALL_BIN_LIST := $(filter-out %.debuginfo %.diz, $(ALL_BIN_LIST)) >>>>>> else >>>>>> >>>>>> You can only have a single wildcard in a pattern so I don't think >>>>>> that expands the way the author intended. >>>>>> >>>>>> Can you try editing jdk/makefiles/Images.gmk and changing the >>>>>> above to: >>>>>> >>>>>> ifneq ($(OPENJDK_TARGET_OS),windows) >>>>>> ALL_BIN_LIST := $(filter-out %.debuginfo, $(ALL_BIN_LIST)) >>>>>> ALL_BIN_LIST := $(filter-out %.diz, $(ALL_BIN_LIST)) >>>>>> else >>>>>> >>>>> >>>>> Sadly, that change did not help. I still get the same failure message >>>>> while building jdk8/tl (or lambda repo). >>>>> >>>>> Regards, >>>>> >>>>> Bharadwaj >>>>> >>>>>> On 8/03/2013 3:32 AM, Bharadwaj Yadavalli wrote: >>>>>>> I pulled down jdk/tl tree and configured it using the following >>>>>>> command >>>>>>> line: >>>>>>> >>>>>>> sh configure --with-debug-level=slowdebug >>>>>>> --with-boot-jdk=/path/to/installed/jdk7 --disable-zip-debug-info >>>>>>> >>>>>>> and built by running >>>>>>> >>>>>>> make all >>>>>>> >>>>>>> I get the following build error >>>>>>> >>>>>>> Ignoring (other) javax.xml.ws.wsaddressing.package-info : >>>>>>> ClassSymbol >>>>>>> Creating images/lib/ct.sym >>>>>>> gmake[2]: *** No rule to make target >>>>>>> `/path/to/jdk8/workspace/build/linux-x86_64-normal-server-slowdebug/images/_strip_jre/bin/jarsigner.debuginfo.stripped', >>>>>>> >>>>>>> >>>>>>> needed by `jre-image'. Stop. >>>>>>> gmake[2]: *** Waiting for unfinished jobs.... >>>>>>> gmake[1]: *** [images] Error 2 >>>>>>> make: *** [images-only] Error 2 >>>>>>> >>>>>>> The build does not have any problems if I do not specify >>>>>>> --disable-zip-debug-info >>>>>>> >>>>>>> Do I need to specify some other option along with >>>>>>> --disable-zip-debug-info? >>>>>>> >>>>>>> Thanks for your help, >>>>>>> >>>>>>> Bharadwaj >>>>>>> >>>>> From david.holmes at oracle.com Thu Mar 28 03:44:32 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 28 Mar 2013 13:44:32 +1000 Subject: Support building zero with the new build In-Reply-To: <1364393132.5998.9.camel@mercury> References: <5152328A.9040608@redhat.com> <5152B41F.3090207@oracle.com> <5152F760.4020201@redhat.com> <1364393132.5998.9.camel@mercury> Message-ID: <5153BCA0.4090806@oracle.com> I'm not sure which is what but I'd like to see: ifeq ($(INCLUDE_SA), true) ... used. Thanks, David On 28/03/2013 12:05 AM, Roman Kennke wrote: > Am Mittwoch, den 27.03.2013, 09:42 -0400 schrieb Omair Majid: >> Hi, >> >> On 03/27/2013 04:55 AM, Erik Joelsson wrote: >>> Work on this was already initiated in this thread: >>> >>> http://mail.openjdk.java.net/pipermail/build-infra-dev/2013-February/003059.html >>> >> >> Whoops. I was not aware of this. Thanks for pointing this out. >> >>> Would be good if these efforts could be synchronized. >> >> Yes, this would be great. I am happy to throw away all my changes and >> help improve Roman's patch. >> >>> I like that you define and translate these hotspot specific variables in >>> hotspot-spec.gmk. >> >> I had the feeling that my patch would become a lot less desirable if it >> started touching hotspot ;) >> >>> I don't think we need to change any variables in >>> hotspot for this to work as was done in the other thread. ZERO_ARCHDEF >>> should maybe belong to platform.m4, not sure, but might as well be >>> defined where you have it. However, checking for libraries would be >>> better moved to libraries.m4 I think. >> >> One thing worth pointing out is that my patch only addresses zero, while >> Roman's patch addresses both zero and shark. >> >> Roman, how do you want to proceed? > > I'd go with Erik's suggestion and keep your part for JDK changes, and > mine for the rest, if that is ok with you? > > Roman > > From david.holmes at oracle.com Thu Mar 28 04:44:49 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 28 Mar 2013 14:44:49 +1000 Subject: New build, gobjcopy failure, any clues? In-Reply-To: <82DDBE96-18ED-42A7-86BA-2FA3BD275413@oracle.com> References: <5C655765-3638-4C33-8FF9-32D048A898F0@oracle.com> <51525C0A.6070801@oracle.com> <82DDBE96-18ED-42A7-86BA-2FA3BD275413@oracle.com> Message-ID: <5153CAC1.3020407@oracle.com> On 27/03/2013 11:26 PM, David Chase wrote: > It's not "my" version, it's whatever someone else installed on one of the ghostboxes (terminus). > > I was perhaps misled into using a 5.11 box by > (1) seeing it listed as a box for our use; > (2) my success building with Solaris 11 on Intel; > (3) the fact that the exact OS version is not mentioned in the summary output of configure (so, probably not that important); > (4) it does not whine about my choice (for example, if you use the latest Solaris compilers, it complains bitterly throughout the build, which is nonetheless successful). > > gobjcopy: supported targets: elf32-sparc elf64-sparc a.out-sunos-big elf64-little elf64-big elf32-little elf32-big srec symbolsrec tekhex binary ihex > > Isn't this information redundant with the output of "gobjcopy -info" (which appears earlier in this discussion)? > > It would have saved me a little time if you had mentioned that the output you desire > was the result of typing "gobjcopy -v", because this is not implied by TFM, which I did in fact R > yesterday. I didn't mention it because I didn't know about it. If you just type "gobjcopy" it appears at the end of the usage message. David From erik.joelsson at oracle.com Thu Mar 28 08:11:56 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 28 Mar 2013 09:11:56 +0100 Subject: RFR JDK-8010267 & JDK-8010268 : Makefile maintenance for test targets In-Reply-To: <081944A1-4DBD-4E24-8C7C-355AFD37196B@oracle.com> References: <081944A1-4DBD-4E24-8C7C-355AFD37196B@oracle.com> Message-ID: <5153FB4C.2020905@oracle.com> Both of these look good to me, but you still need a jdk8 reviewer. /Erik On 2013-03-27 17:27, Mike Duigou wrote: > I still need a review for both of these changes. > > Mike > > On Mar 18 2013, at 22:48 , Mike Duigou wrote: > >> A two small changes to review: >> >> If approved I will commit to TL (or someone else can commit to build for me) >> >> Mike >> >> JDK-8010267 : Add test-clean for cleaning of testoutput directory from output directory. >> >> diff --git a/common/makefiles/Main.gmk b/common/makefiles/Main.gmk >> --- a/common/makefiles/Main.gmk >> +++ b/common/makefiles/Main.gmk >> @@ -191,7 +191,7 @@ source-tips: $(OUTPUT_ROOT)/source_tips >> >> >> # Remove everything, except the output from configure. >> -clean: clean-langtools clean-corba clean-jaxp clean-jaxws clean-hotspot clean-jdk clean-images clean-overlay-images clean-bootcycle-build clean-docs >> +clean: clean-langtools clean-corba clean-jaxp clean-jaxws clean-hotspot clean-jdk clean-images clean-overlay-images clean-bootcycle-build clean-docs clean-test >> @($(CD) $(OUTPUT_ROOT)&& $(RM) -r tmp source_tips build.log* build-trace*.log*) >> @$(ECHO) Cleaned all build artifacts. >> >> @@ -230,6 +230,8 @@ clean-bootcycle-build: >> clean-docs: >> $(call CleanComponent,docs) >> $(call CleanComponent,docstemp) >> +clean-test: >> + $(call CleanComponent,testoutput) >> >> .PHONY: langtools corba jaxp jaxws hotspot jdk images overlay-images install >> .PHONY: langtools-only corba-only jaxp-only jaxws-only hotspot-only jdk-only images-only overlay-images-only install-only >> >> >> JDK-8010268 : Remove dependence upon clean target from jdk/test/Makefile prep target >> >> None of the current users seem to depend upon the clean behaviour of "prep" >> >> diff --git a/test/Makefile b/test/Makefile >> --- a/test/Makefile >> +++ b/test/Makefile >> @@ -336,7 +336,7 @@ all: jdk_default >> @$(ECHO) "Testing completed successfully" >> >> # Prep for output >> -prep: clean >> +prep: >> @$(MKDIR) -p $(ABS_TEST_OUTPUT_DIR) >> @$(MKDIR) -p `$(DIRNAME) $(ARCHIVE_BUNDLE)` >> >> From erik.joelsson at oracle.com Thu Mar 28 08:27:50 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 28 Mar 2013 09:27:50 +0100 Subject: RFR: 8010908: Images target failes when configured with --disable-zip-debug-info In-Reply-To: <5153BBEB.5000504@oracle.com> References: <5138CF42.1040102@oracle.com> <513936BB.2070404@oracle.com> <515243A4.1080706@oracle.com> <5152C616.5030401@oracle.com> <5152D12D.5020804@oracle.com> <5152E3FB.1020008@oracle.com> <5152ECF1.8050008@oracle.com> <5153BBEB.5000504@oracle.com> Message-ID: <5153FF06.9050808@oracle.com> On 2013-03-28 04:41, David Holmes wrote: > On 27/03/2013 10:58 PM, Erik Joelsson wrote: >> On 2013-03-27 13:20, David Holmes wrote: >>> On 27/03/2013 8:59 PM, Erik Joelsson wrote: >>>> I found the problem and fixed it: >>>> >>>> http://cr.openjdk.java.net/~erikj/8010908/webrev.jdk.01/ >>> >>> I don't understand - how did this: >>> >>> `$(FIND) $(JDK_OUTPUTDIR)/bin -type f -name \*$(EXE_SUFFIX)` >>> >>> match .debuginfo files but not .diz files (EXE_SUFFIX is empty) ??? >>> >> It didn't, that was handled by the file command and grep. The problem is >> file output is more or less the same for the executable and the >> debuginfo file, but at least those can be separated by name. > > Ah! Got it - thanks. > > So is this line buggy anyway: > > ALL_BIN_LIST := $(filter-out %.debuginfo %.diz, $(ALL_BIN_LIST)) > > I thought you could only have a single wildcard. > I wasn't sure, but I added some debug printing around it and verified that it actually works. Both patterns are filtered out. /Erik > David > ----- > >> /Erik >>> David >>> >>>> /Erik >>>> >>>> On 2013-03-27 11:12, Erik Joelsson wrote: >>>>> I just tried this and the failure reproduces for me. Will >>>>> investigate. >>>>> >>>>> /Erik >>>>> >>>>> On 2013-03-27 01:56, Bharadwaj Yadavalli wrote: >>>>>> >>>>>> Hi David, >>>>>> >>>>>> Thanks for the suggestion. >>>>>> >>>>>> On 3/7/2013 7:54 PM, David Holmes wrote: >>>>>>> I think this is a bug in Images.gmk: >>>>>>> >>>>>>> ifneq ($(OPENJDK_TARGET_OS),windows) >>>>>>> ALL_BIN_LIST := $(filter-out %.debuginfo %.diz, >>>>>>> $(ALL_BIN_LIST)) >>>>>>> else >>>>>>> >>>>>>> You can only have a single wildcard in a pattern so I don't think >>>>>>> that expands the way the author intended. >>>>>>> >>>>>>> Can you try editing jdk/makefiles/Images.gmk and changing the >>>>>>> above to: >>>>>>> >>>>>>> ifneq ($(OPENJDK_TARGET_OS),windows) >>>>>>> ALL_BIN_LIST := $(filter-out %.debuginfo, $(ALL_BIN_LIST)) >>>>>>> ALL_BIN_LIST := $(filter-out %.diz, $(ALL_BIN_LIST)) >>>>>>> else >>>>>>> >>>>>> >>>>>> Sadly, that change did not help. I still get the same failure >>>>>> message >>>>>> while building jdk8/tl (or lambda repo). >>>>>> >>>>>> Regards, >>>>>> >>>>>> Bharadwaj >>>>>> >>>>>>> On 8/03/2013 3:32 AM, Bharadwaj Yadavalli wrote: >>>>>>>> I pulled down jdk/tl tree and configured it using the following >>>>>>>> command >>>>>>>> line: >>>>>>>> >>>>>>>> sh configure --with-debug-level=slowdebug >>>>>>>> --with-boot-jdk=/path/to/installed/jdk7 --disable-zip-debug-info >>>>>>>> >>>>>>>> and built by running >>>>>>>> >>>>>>>> make all >>>>>>>> >>>>>>>> I get the following build error >>>>>>>> >>>>>>>> Ignoring (other) javax.xml.ws.wsaddressing.package-info : >>>>>>>> ClassSymbol >>>>>>>> Creating images/lib/ct.sym >>>>>>>> gmake[2]: *** No rule to make target >>>>>>>> `/path/to/jdk8/workspace/build/linux-x86_64-normal-server-slowdebug/images/_strip_jre/bin/jarsigner.debuginfo.stripped', >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> needed by `jre-image'. Stop. >>>>>>>> gmake[2]: *** Waiting for unfinished jobs.... >>>>>>>> gmake[1]: *** [images] Error 2 >>>>>>>> make: *** [images-only] Error 2 >>>>>>>> >>>>>>>> The build does not have any problems if I do not specify >>>>>>>> --disable-zip-debug-info >>>>>>>> >>>>>>>> Do I need to specify some other option along with >>>>>>>> --disable-zip-debug-info? >>>>>>>> >>>>>>>> Thanks for your help, >>>>>>>> >>>>>>>> Bharadwaj >>>>>>>> >>>>>> From tim.bell at oracle.com Thu Mar 28 14:01:48 2013 From: tim.bell at oracle.com (Tim Bell) Date: Thu, 28 Mar 2013 07:01:48 -0700 Subject: RFR JDK-8010267 & JDK-8010268 : Makefile maintenance for test targets In-Reply-To: <5153FB4C.2020905@oracle.com> References: <081944A1-4DBD-4E24-8C7C-355AFD37196B@oracle.com> <5153FB4C.2020905@oracle.com> Message-ID: <51544D4C.9090709@oracle.com> Mike - Looks good to me. Tim On 03/28/13 01:11, Erik Joelsson wrote: > Both of these look good to me, but you still need a jdk8 reviewer. > > /Erik > > On 2013-03-27 17:27, Mike Duigou wrote: >> I still need a review for both of these changes. >> >> Mike >> >> On Mar 18 2013, at 22:48 , Mike Duigou wrote: >> >>> A two small changes to review: >>> >>> If approved I will commit to TL (or someone else can commit to build >>> for me) >>> >>> Mike >>> >>> JDK-8010267 : Add test-clean for cleaning of testoutput directory >>> from output directory. >>> >>> diff --git a/common/makefiles/Main.gmk b/common/makefiles/Main.gmk >>> --- a/common/makefiles/Main.gmk >>> +++ b/common/makefiles/Main.gmk >>> @@ -191,7 +191,7 @@ source-tips: $(OUTPUT_ROOT)/source_tips >>> >>> >>> # Remove everything, except the output from configure. >>> -clean: clean-langtools clean-corba clean-jaxp clean-jaxws >>> clean-hotspot clean-jdk clean-images clean-overlay-images >>> clean-bootcycle-build clean-docs >>> +clean: clean-langtools clean-corba clean-jaxp clean-jaxws >>> clean-hotspot clean-jdk clean-images clean-overlay-images >>> clean-bootcycle-build clean-docs clean-test >>> @($(CD) $(OUTPUT_ROOT)&& $(RM) -r tmp source_tips >>> build.log* build-trace*.log*) >>> @$(ECHO) Cleaned all build artifacts. >>> >>> @@ -230,6 +230,8 @@ clean-bootcycle-build: >>> clean-docs: >>> $(call CleanComponent,docs) >>> $(call CleanComponent,docstemp) >>> +clean-test: >>> + $(call CleanComponent,testoutput) >>> >>> .PHONY: langtools corba jaxp jaxws hotspot jdk images overlay-images >>> install >>> .PHONY: langtools-only corba-only jaxp-only jaxws-only hotspot-only >>> jdk-only images-only overlay-images-only install-only >>> >>> >>> JDK-8010268 : Remove dependence upon clean target from >>> jdk/test/Makefile prep target >>> >>> None of the current users seem to depend upon the clean behaviour of >>> "prep" >>> >>> diff --git a/test/Makefile b/test/Makefile >>> --- a/test/Makefile >>> +++ b/test/Makefile >>> @@ -336,7 +336,7 @@ all: jdk_default >>> @$(ECHO) "Testing completed successfully" >>> >>> # Prep for output >>> -prep: clean >>> +prep: >>> @$(MKDIR) -p $(ABS_TEST_OUTPUT_DIR) >>> @$(MKDIR) -p `$(DIRNAME) $(ARCHIVE_BUNDLE)` >>> >>> From mandy.chung at oracle.com Thu Mar 28 16:16:43 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 28 Mar 2013 09:16:43 -0700 Subject: RFR JDK-8010267 & JDK-8010268 : Makefile maintenance for test targets In-Reply-To: References: Message-ID: <51546CEB.4030603@oracle.com> Looks good to me. Mandy On 3/18/13 10:48 PM, Mike Duigou wrote: > A two small changes to review: > > If approved I will commit to TL (or someone else can commit to build for me) > > Mike > > JDK-8010267 : Add test-clean for cleaning of testoutput directory from output directory. > > diff --git a/common/makefiles/Main.gmk b/common/makefiles/Main.gmk > --- a/common/makefiles/Main.gmk > +++ b/common/makefiles/Main.gmk > @@ -191,7 +191,7 @@ source-tips: $(OUTPUT_ROOT)/source_tips > > > # Remove everything, except the output from configure. > -clean: clean-langtools clean-corba clean-jaxp clean-jaxws clean-hotspot clean-jdk clean-images clean-overlay-images clean-bootcycle-build clean-docs > +clean: clean-langtools clean-corba clean-jaxp clean-jaxws clean-hotspot clean-jdk clean-images clean-overlay-images clean-bootcycle-build clean-docs clean-test > @($(CD) $(OUTPUT_ROOT)&& $(RM) -r tmp source_tips build.log* build-trace*.log*) > @$(ECHO) Cleaned all build artifacts. > > @@ -230,6 +230,8 @@ clean-bootcycle-build: > clean-docs: > $(call CleanComponent,docs) > $(call CleanComponent,docstemp) > +clean-test: > + $(call CleanComponent,testoutput) > > .PHONY: langtools corba jaxp jaxws hotspot jdk images overlay-images install > .PHONY: langtools-only corba-only jaxp-only jaxws-only hotspot-only jdk-only images-only overlay-images-only install-only > > > JDK-8010268 : Remove dependence upon clean target from jdk/test/Makefile prep target > > None of the current users seem to depend upon the clean behaviour of "prep" > > diff --git a/test/Makefile b/test/Makefile > --- a/test/Makefile > +++ b/test/Makefile > @@ -336,7 +336,7 @@ all: jdk_default > @$(ECHO) "Testing completed successfully" > > # Prep for output > -prep: clean > +prep: > @$(MKDIR) -p $(ABS_TEST_OUTPUT_DIR) > @$(MKDIR) -p `$(DIRNAME) $(ARCHIVE_BUNDLE)` > > From erik.joelsson at oracle.com Thu Mar 28 16:25:46 2013 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 28 Mar 2013 17:25:46 +0100 Subject: RFR: 8008373: JFR JTReg tests fail with CompilationError on MacOSX; missing '._sunec.jar' Message-ID: <51546F0A.6020509@oracle.com> For a while since switching to the new build system, tests have begun failing on mac, complaining about files starting with '._' showing up in the jdk image. The source of these files are extended attributes on mac when in certain cases copied to a non mac filesystem. In this case the attribute is com.apple.quarantine, which the OS sets to guard against execution of downloaded binaries. Normally this doesn't happen to developers who get the source code through mercurial, but nightly builds get sources by zip bundles, and when unzipped, the source files get this attribute added. For files generated during the build, this isn't a problem, but a bunch of files are just copied from the source to the build directory and these files retain the attribute. In the old build, cpio was used to copy files into the final image directory, and this removed extended attributes, but in the new build, cp is used and the attribute stays. The solution proposed here explicitly removes the attributes in the install-file macro. Unfortunately the macro wasn't widely used, so all simple copy operations had to also be converted to actually use the macro, which in itself is an improvement on code quality. The -p flag was removed from cp since it's not there on other platforms nor the old build. http://cr.openjdk.java.net/~erikj/8008373/webrev.01/ /Erik From erik.joelsson at oracle.com Thu Mar 28 18:35:42 2013 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Thu, 28 Mar 2013 18:35:42 +0000 Subject: hg: jdk8/build/jdk: 8010908: Images target failes when configured with --disable-zip-debug-info Message-ID: <20130328183618.C70E748473@hg.openjdk.java.net> Changeset: b68094f8263f Author: erikj Date: 2013-03-28 09:36 +0100 URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/b68094f8263f 8010908: Images target failes when configured with --disable-zip-debug-info Reviewed-by: tbell ! makefiles/Images.gmk From daniel.fuchs at oracle.com Thu Mar 28 19:37:08 2013 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 28 Mar 2013 20:37:08 +0100 Subject: JDK-8010495: Update JAXP NetBeans project - add support for generating javadoc In-Reply-To: <515038DA.3010802@oracle.com> References: <515038DA.3010802@oracle.com> Message-ID: <51549BE4.2090102@oracle.com> Hi, Please find below a revised patch: I had oversimplified the changes in project.xml. It seems you need to declare a source folder of type 'java' as well as a compilation-unit in order for 'Find Usage' to work properly in the editor. I have also restrained the packageset for the javadoc target as suggested by Joe. -- daniel On 3/25/13 12:45 PM, Daniel Fuchs wrote: > Hi guys, > > I'd like to propose a small change to jaxp/build.xml and > jaxp/nbproject/project.xml - in order to allow editing > JAXP sources in NetBeans, as well as generating the JAXP > javadoc for previewing purposes. > > I actually stole the javadoc target from > jdk/make/netbeans/common/shared.xml > > The changes are small & targeted at developers. > There should be no impact on the build process. > > Here is the webrev: > > http://cr.openjdk.java.net/~dfuchs/JDK-8010495/jdk8/webrev.00/ > > best regards, > > -- daniel From vladislav.karnaukhov at oracle.com Thu Mar 28 19:50:17 2013 From: vladislav.karnaukhov at oracle.com (vladislav karnaukhov) Date: Thu, 28 Mar 2013 23:50:17 +0400 Subject: Strange build behavior - can't find basic cygwin utilities Message-ID: <51549EF9.30706@oracle.com> Hello, I'm experiencing some strange build behavior under cygwin on Windows 7 64-bit. I cloned jdk8 ws and ran configure - no issues. Please see configure log attached. But when I try to start a build, I get a following error: $ make all make: mkdir: Command not found make: *** [/cygdrive/c/projects/jdk8/build/windows-x86-normal-server-release/source_tips] Error 127 or $ make clean Cleaning langtools build artifacts ... done Cleaning corba build artifacts ... done ... make: echo: Command not found make: *** [clean] Error 127 Both mkdir and echo (and other tools) are available from /usr/bin/ (/cygdrive/c/cygwin/bin) and I can run them as usual just by typing a name. I suspect that somewhere some paths weren't set correctly, but I was unable to resolve this. Could someone help please? Regards, - Vlad From kellyohair at gmail.com Thu Mar 28 19:55:12 2013 From: kellyohair at gmail.com (Kelly O'Hair) Date: Thu, 28 Mar 2013 12:55:12 -0700 Subject: Strange build behavior - can't find basic cygwin utilities In-Reply-To: <51549EF9.30706@oracle.com> References: <51549EF9.30706@oracle.com> Message-ID: <73436624-C0D0-45BD-8A5E-8F87F32BE73C@gmail.com> this is problem we have seen before i think the issue was PATH whatever it is someone might want to add to the troubleshooting section of the Readme-builds.html file at the top of the repo Sent from my iPhone On Mar 28, 2013, at 12:50, vladislav karnaukhov wrote: > Hello, > > I'm experiencing some strange build behavior under cygwin on Windows 7 64-bit. I cloned jdk8 ws and ran configure - no issues. Please see configure log attached. > > But when I try to start a build, I get a following error: > > $ make all > make: mkdir: Command not found > make: *** [/cygdrive/c/projects/jdk8/build/windows-x86-normal-server-release/source_tips] Error 127 > > or > > $ make clean > Cleaning langtools build artifacts ... done > Cleaning corba build artifacts ... done > ... > make: echo: Command not found > make: *** [clean] Error 127 > > Both mkdir and echo (and other tools) are available from /usr/bin/ (/cygdrive/c/cygwin/bin) and I can run them as usual just by typing a name. I suspect that somewhere some paths weren't set correctly, but I was unable to resolve this. > > Could someone help please? > > Regards, > - Vlad From tim.bell at oracle.com Thu Mar 28 20:39:30 2013 From: tim.bell at oracle.com (Tim Bell) Date: Thu, 28 Mar 2013 13:39:30 -0700 Subject: Strange build behavior - can't find basic cygwin utilities In-Reply-To: <73436624-C0D0-45BD-8A5E-8F87F32BE73C@gmail.com> References: <51549EF9.30706@oracle.com> <73436624-C0D0-45BD-8A5E-8F87F32BE73C@gmail.com> Message-ID: <5154AA82.6030404@oracle.com> Hi Vlad Our guidance [1] is to install only C++ out of the VS 2010 package. The problem Kelly is referring to was a developer who installed the entire VS2010 suite, which includes F#. Once that is installed, vsvars32.bat will define an environment variable called FSHARPINSTALLDIR and also add it to PATH: This is from C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\Tools\vsvars32.bat @if not "%FSHARPINSTALLDIR%" == "" ( @set "PATH=%FSHARPINSTALLDIR%;%PATH%" ) The # character on PATH causes problems later on. Since configure places the VS directories on PATH before the Cygwin bin directories, the symptom is that simple commands like mkdir are not found. Check the PATH in your build output. Tim [1] http://hg.openjdk.java.net/jdk8/jdk8/raw-file/tip/README-builds.html#vs2010 On 03/28/13 12:55, Kelly O'Hair wrote: > this is problem we have seen before > i think the issue was PATH > > whatever it is someone might want to add to the troubleshooting section of the Readme-builds.html file at the top of the repo > > > Sent from my iPhone > > On Mar 28, 2013, at 12:50, vladislav karnaukhov wrote: > >> Hello, >> >> I'm experiencing some strange build behavior under cygwin on Windows 7 64-bit. I cloned jdk8 ws and ran configure - no issues. Please see configure log attached. >> >> But when I try to start a build, I get a following error: >> >> $ make all >> make: mkdir: Command not found >> make: *** [/cygdrive/c/projects/jdk8/build/windows-x86-normal-server-release/source_tips] Error 127 >> >> or >> >> $ make clean >> Cleaning langtools build artifacts ... done >> Cleaning corba build artifacts ... done >> ... >> make: echo: Command not found >> make: *** [clean] Error 127 >> >> Both mkdir and echo (and other tools) are available from /usr/bin/ (/cygdrive/c/cygwin/bin) and I can run them as usual just by typing a name. I suspect that somewhere some paths weren't set correctly, but I was unable to resolve this. >> >> Could someone help please? >> >> Regards, >> - Vlad From omajid at redhat.com Thu Mar 28 21:13:04 2013 From: omajid at redhat.com (Omair Majid) Date: Thu, 28 Mar 2013 17:13:04 -0400 Subject: Support building zero with the new build In-Reply-To: <1364393132.5998.9.camel@mercury> References: <5152328A.9040608@redhat.com> <5152B41F.3090207@oracle.com> <5152F760.4020201@redhat.com> <1364393132.5998.9.camel@mercury> Message-ID: <5154B260.7060106@redhat.com> Hi, On 03/27/2013 10:05 AM, Roman Kennke wrote: > Am Mittwoch, den 27.03.2013, 09:42 -0400 schrieb Omair Majid: >> Roman, how do you want to proceed? > > I'd go with Erik's suggestion and keep your part for JDK changes, and > mine for the rest, if that is ok with you? Updated webrev at: http://cr.openjdk.java.net/~omajid/webrevs/zero-newbuild/01/ It uses the configure stuff that you proposed but avoids touching hotspot (as suggested by Erik) and uses INCLUDE_SA as suggested by David (though I am far from sure where to set it properly). Any comments or suggestions? Thanks, Omair -- PGP Key: 66484681 (http://pgp.mit.edu/) Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 From philip.race at oracle.com Thu Mar 28 21:29:14 2013 From: philip.race at oracle.com (Phil Race) Date: Thu, 28 Mar 2013 14:29:14 -0700 Subject: A couple of questions about the new build system Message-ID: <5154B62A.3020706@oracle.com> 1. Why do we have both --with-cups and --with-cups-include ? All we use is the header files so the latter is what matters and I'm not sure which one the build system prefers if both are set. 2. In the old build I could do cd make/sun/font make clean make all Is there anything analagous to 'make clean' here,where I can have a level of comfort that all generated files related to building just a particular area are removed. This was useful after I touched a header file. Now when I touch a header file, the new build system doesn't notice, so I have to manually purge, but nor does it (as far as I can see) give me a target to purge that component. To do this I need to go hunt down the directory with the object files and remove them. Is there something better I can do ? -phil. From jonathan.gibbons at oracle.com Thu Mar 28 21:45:39 2013 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 28 Mar 2013 14:45:39 -0700 Subject: A couple of questions about the new build system In-Reply-To: <5154B62A.3020706@oracle.com> References: <5154B62A.3020706@oracle.com> Message-ID: <5154BA03.9010407@oracle.com> On 03/28/2013 02:29 PM, Phil Race wrote: > 1. Why do we have both --with-cups and --with-cups-include ? > All we use is the header files so the latter is what matters and > I'm not sure which one the build system prefers if both are set. > > 2. In the old build I could do > cd make/sun/font > make clean > make all > > Is there anything analagous to 'make clean' here,where I can have a > level of comfort > that all generated files related to building just a particular area > are removed. > This was useful after I touched a header file. > Now when I touch a header file, the new build system doesn't notice, > so I have to manually purge, but nor does it (as far as I can see) > give me > a target to purge that component. To do this I need to go hunt down > the directory with the object files and remove them. > Is there something better I can do ? > > -phil. > If you touch a header fie, the build is supposed to notice and "do the right thing". -- Jon From philip.race at oracle.com Thu Mar 28 23:00:13 2013 From: philip.race at oracle.com (Phil Race) Date: Thu, 28 Mar 2013 16:00:13 -0700 Subject: A couple of questions about the new build system In-Reply-To: <5154BA03.9010407@oracle.com> References: <5154B62A.3020706@oracle.com> <5154BA03.9010407@oracle.com> Message-ID: <5154CB7D.7080705@oracle.com> > If you touch a header fie, the build is supposed to notice and "do the right thing". It did not do so. If I touched a C file, no problem, but not so for the header file. This was observed on Solaris 10 SPARC. -phil. On 3/28/2013 2:45 PM, Jonathan Gibbons wrote: > On 03/28/2013 02:29 PM, Phil Race wrote: >> 1. Why do we have both --with-cups and --with-cups-include ? >> All we use is the header files so the latter is what matters and >> I'm not sure which one the build system prefers if both are set. >> >> 2. In the old build I could do >> cd make/sun/font >> make clean >> make all >> >> Is there anything analagous to 'make clean' here,where I can have a >> level of comfort >> that all generated files related to building just a particular area >> are removed. >> This was useful after I touched a header file. >> Now when I touch a header file, the new build system doesn't notice, >> so I have to manually purge, but nor does it (as far as I can see) >> give me >> a target to purge that component. To do this I need to go hunt down >> the directory with the object files and remove them. >> Is there something better I can do ? >> >> -phil. >> > > If you touch a header fie, the build is supposed to notice and "do the > right thing". > > -- Jon From mike.duigou at oracle.com Thu Mar 28 23:06:36 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Thu, 28 Mar 2013 16:06:36 -0700 Subject: A couple of questions about the new build system In-Reply-To: <5154B62A.3020706@oracle.com> References: <5154B62A.3020706@oracle.com> Message-ID: <0DBB101F-0C27-4EF3-B069-E843FDBB3B1F@oracle.com> On Mar 28 2013, at 14:29 , Phil Race wrote: > 1. Why do we have both --with-cups and --with-cups-include ? > All we use is the header files so the latter is what matters and > I'm not sure which one the build system prefers if both are set. You will often see this style in configure scripts. It is common to see --with-XXX, --with-XXX-include, --with-XXX-libs. The former is a catch all that is usually expected to point to an exploded tarball distribution and will look for sub-dirs inside the provided directory. The two later options, includes and libs, supersede definitions derived from the base form and allow explicit specification of the include and libs dirs. Mike From tim.bell at oracle.com Fri Mar 29 00:14:13 2013 From: tim.bell at oracle.com (Tim Bell) Date: Thu, 28 Mar 2013 17:14:13 -0700 Subject: RFR: 8008373: JFR JTReg tests fail with CompilationError on MacOSX; missing '._sunec.jar' In-Reply-To: <51546F0A.6020509@oracle.com> References: <51546F0A.6020509@oracle.com> Message-ID: <5154DCD5.7000504@oracle.com> Hi Erik: > The solution proposed here explicitly removes the attributes in the > install-file macro. Unfortunately the macro wasn't widely used, so all > simple copy operations had to also be converted to actually use the > macro, which in itself is an improvement on code quality. The -p flag > was removed from cp since it's not there on other platforms nor the > old build. > > http://cr.openjdk.java.net/~erikj/8008373/webrev.01/ > Looks good. Thanks for doing the work to use install-file everywhere. Tim From tim.bell at oracle.com Fri Mar 29 00:37:11 2013 From: tim.bell at oracle.com (Tim Bell) Date: Thu, 28 Mar 2013 17:37:11 -0700 Subject: RFR: 8010908: Images target failes when configured with --disable-zip-debug-info In-Reply-To: <5153FF06.9050808@oracle.com> References: <5138CF42.1040102@oracle.com> <513936BB.2070404@oracle.com> <515243A4.1080706@oracle.com> <5152C616.5030401@oracle.com> <5152D12D.5020804@oracle.com> <5152E3FB.1020008@oracle.com> <5152ECF1.8050008@oracle.com> <5153BBEB.5000504@oracle.com> <5153FF06.9050808@oracle.com> Message-ID: <5154E237.8070502@oracle.com> See inline... On 03/28/13 01:27, Erik Joelsson wrote: > > > On 2013-03-28 04:41, David Holmes wrote: >> On 27/03/2013 10:58 PM, Erik Joelsson wrote: >>> On 2013-03-27 13:20, David Holmes wrote: >>>> On 27/03/2013 8:59 PM, Erik Joelsson wrote: >>>>> I found the problem and fixed it: >>>>> >>>>> http://cr.openjdk.java.net/~erikj/8010908/webrev.jdk.01/ >>>> >>>> I don't understand - how did this: >>>> >>>> `$(FIND) $(JDK_OUTPUTDIR)/bin -type f -name \*$(EXE_SUFFIX)` >>>> >>>> match .debuginfo files but not .diz files (EXE_SUFFIX is empty) ??? >>>> >>> It didn't, that was handled by the file command and grep. The >>> problem is >>> file output is more or less the same for the executable and the >>> debuginfo file, but at least those can be separated by name. >> >> Ah! Got it - thanks. >> >> So is this line buggy anyway: >> >> ALL_BIN_LIST := $(filter-out %.debuginfo %.diz, $(ALL_BIN_LIST)) >> >> I thought you could only have a single wildcard. >> > I wasn't sure, but I added some debug printing around it and verified > that it actually works. Both patterns are filtered out. > > /Erik I agree with Erik. According to my reading of the doc: http://www.gnu.org/software/make/manual/make.html#index-filter-574 It is ok to have more than one % pattern before the , in a filter or a filter-out call. patsubst is the function where only the first % has a special meaning. Tim From huizhe.wang at oracle.com Fri Mar 29 07:37:41 2013 From: huizhe.wang at oracle.com (huizhe wang) Date: Fri, 29 Mar 2013 00:37:41 -0700 Subject: JDK-8010495: Update JAXP NetBeans project - add support for generating javadoc In-Reply-To: <51549BE4.2090102@oracle.com> References: <515038DA.3010802@oracle.com> <51549BE4.2090102@oracle.com> Message-ID: <515544C5.90205@oracle.com> Hi Daniel, Looks good. The docs are "for preview purposes only" anyways, I shouldn't be picky :-) Thanks, Joe On 3/28/2013 12:37 PM, Daniel Fuchs wrote: > Hi, > > Please find below a revised patch: > > > > I had oversimplified the changes in project.xml. > It seems you need to declare a source folder of type 'java' > as well as a compilation-unit in order for 'Find Usage' to work > properly in the editor. > > I have also restrained the packageset for the javadoc > target as suggested by Joe. > > -- daniel > > > On 3/25/13 12:45 PM, Daniel Fuchs wrote: >> Hi guys, >> >> I'd like to propose a small change to jaxp/build.xml and >> jaxp/nbproject/project.xml - in order to allow editing >> JAXP sources in NetBeans, as well as generating the JAXP >> javadoc for previewing purposes. >> >> I actually stole the javadoc target from >> jdk/make/netbeans/common/shared.xml >> >> The changes are small & targeted at developers. >> There should be no impact on the build process. >> >> Here is the webrev: >> >> http://cr.openjdk.java.net/~dfuchs/JDK-8010495/jdk8/webrev.00/ >> >> best regards, >> >> -- daniel > From david.holmes at oracle.com Fri Mar 29 12:26:01 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 29 Mar 2013 22:26:01 +1000 Subject: A couple of questions about the new build system In-Reply-To: <5154B62A.3020706@oracle.com> References: <5154B62A.3020706@oracle.com> Message-ID: <51558859.4030605@oracle.com> On 29/03/2013 7:29 AM, Phil Race wrote: > 1. Why do we have both --with-cups and --with-cups-include ? > All we use is the header files so the latter is what matters and > I'm not sure which one the build system prefers if both are set. > > 2. In the old build I could do > cd make/sun/font > make clean > make all > > Is there anything analagous to 'make clean' here,where I can have a > level of comfort > that all generated files related to building just a particular area are > removed. The new build doesn't work on "particular areas" to that granularity. For each of the main targets in the new build there is a corresponding "clean" target eg: jdk clean-jdk langtools clean-langtools hotspot clean-hotspot images clean-images David ----- > This was useful after I touched a header file. > Now when I touch a header file, the new build system doesn't notice, > so I have to manually purge, but nor does it (as far as I can see) give me > a target to purge that component. To do this I need to go hunt down > the directory with the object files and remove them. > Is there something better I can do ? > > -phil. > From david.holmes at oracle.com Fri Mar 29 12:35:46 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 29 Mar 2013 22:35:46 +1000 Subject: RFR: 8010908: Images target failes when configured with --disable-zip-debug-info In-Reply-To: <5154E237.8070502@oracle.com> References: <5138CF42.1040102@oracle.com> <513936BB.2070404@oracle.com> <515243A4.1080706@oracle.com> <5152C616.5030401@oracle.com> <5152D12D.5020804@oracle.com> <5152E3FB.1020008@oracle.com> <5152ECF1.8050008@oracle.com> <5153BBEB.5000504@oracle.com> <5153FF06.9050808@oracle.com> <5154E237.8070502@oracle.com> Message-ID: <51558AA2.80107@oracle.com> On 29/03/2013 10:37 AM, Tim Bell wrote: > See inline... > > On 03/28/13 01:27, Erik Joelsson wrote: >> >> >> On 2013-03-28 04:41, David Holmes wrote: >>> On 27/03/2013 10:58 PM, Erik Joelsson wrote: >>>> On 2013-03-27 13:20, David Holmes wrote: >>>>> On 27/03/2013 8:59 PM, Erik Joelsson wrote: >>>>>> I found the problem and fixed it: >>>>>> >>>>>> http://cr.openjdk.java.net/~erikj/8010908/webrev.jdk.01/ >>>>> >>>>> I don't understand - how did this: >>>>> >>>>> `$(FIND) $(JDK_OUTPUTDIR)/bin -type f -name \*$(EXE_SUFFIX)` >>>>> >>>>> match .debuginfo files but not .diz files (EXE_SUFFIX is empty) ??? >>>>> >>>> It didn't, that was handled by the file command and grep. The >>>> problem is >>>> file output is more or less the same for the executable and the >>>> debuginfo file, but at least those can be separated by name. >>> >>> Ah! Got it - thanks. >>> >>> So is this line buggy anyway: >>> >>> ALL_BIN_LIST := $(filter-out %.debuginfo %.diz, $(ALL_BIN_LIST)) >>> >>> I thought you could only have a single wildcard. >>> >> I wasn't sure, but I added some debug printing around it and verified >> that it actually works. Both patterns are filtered out. >> >> /Erik > > I agree with Erik. > > According to my reading of the doc: > http://www.gnu.org/software/make/manual/make.html#index-filter-574 > > It is ok to have more than one % pattern before the , in a filter or a > filter-out call. > > patsubst is the function where only the first % has a special meaning. But filter states "The patterns are written using ?%?, just like the patterns used in the patsubst function above." Which implied to me that the same limitation existed. I know I ran into a problem trying to use two % in one string - which is different to this case. Anyway Erik has verified it works so all good. Thanks, David > Tim > From vladislav.karnaukhov at oracle.com Fri Mar 29 21:23:27 2013 From: vladislav.karnaukhov at oracle.com (vladislav karnaukhov) Date: Sat, 30 Mar 2013 01:23:27 +0400 Subject: Strange build behavior - can't find basic cygwin utilities In-Reply-To: <5154AA82.6030404@oracle.com> References: <51549EF9.30706@oracle.com> <73436624-C0D0-45BD-8A5E-8F87F32BE73C@gmail.com> <5154AA82.6030404@oracle.com> Message-ID: <5156064F.9050805@oracle.com> Thanks a lot Tim! A removal of F# really helped. - Vlad On 3/29/2013 00:39, Tim Bell wrote: > Hi Vlad > > Our guidance [1] is to install only C++ out of the VS 2010 package. > > The problem Kelly is referring to was a developer who installed the > entire VS2010 suite, which includes F#. Once that is installed, > vsvars32.bat will define an environment variable called FSHARPINSTALLDIR > and also add it to PATH: > > This is from C:\Program Files (x86)\Microsoft Visual Studio > 10.0\Common7\Tools\vsvars32.bat > > @if not "%FSHARPINSTALLDIR%" == "" ( > @set "PATH=%FSHARPINSTALLDIR%;%PATH%" > ) > > > The # character on PATH causes problems later on. Since configure > places the VS directories on PATH before the Cygwin bin directories, the > symptom is that simple commands like mkdir are not found. > > Check the PATH in your build output. > > > Tim > > [1] > http://hg.openjdk.java.net/jdk8/jdk8/raw-file/tip/README-builds.html#vs2010 > > > On 03/28/13 12:55, Kelly O'Hair wrote: >> this is problem we have seen before >> i think the issue was PATH >> >> whatever it is someone might want to add to the troubleshooting >> section of the Readme-builds.html file at the top of the repo >> >> >> Sent from my iPhone >> >> On Mar 28, 2013, at 12:50, vladislav >> karnaukhov wrote: >> >>> Hello, >>> >>> I'm experiencing some strange build behavior under cygwin on Windows >>> 7 64-bit. I cloned jdk8 ws and ran configure - no issues. Please see >>> configure log attached. >>> >>> But when I try to start a build, I get a following error: >>> >>> $ make all >>> make: mkdir: Command not found >>> make: *** >>> [/cygdrive/c/projects/jdk8/build/windows-x86-normal-server-release/source_tips] >>> Error 127 >>> >>> or >>> >>> $ make clean >>> Cleaning langtools build artifacts ... done >>> Cleaning corba build artifacts ... done >>> ... >>> make: echo: Command not found >>> make: *** [clean] Error 127 >>> >>> Both mkdir and echo (and other tools) are available from /usr/bin/ >>> (/cygdrive/c/cygwin/bin) and I can run them as usual just by typing a >>> name. I suspect that somewhere some paths weren't set correctly, but >>> I was unable to resolve this. >>> >>> Could someone help please? >>> >>> Regards, >>> - Vlad > >