From david.holmes at oracle.com Thu Nov 1 01:38:49 2012 From: david.holmes at oracle.com (David Holmes) Date: Thu, 01 Nov 2012 11:38:49 +1000 Subject: RFR: JDK-8001191: use -source 8 -target 8 when compiling the JDK In-Reply-To: <5091635A.3010000@oracle.COM> References: <5091635A.3010000@oracle.COM> Message-ID: <5091D2A9.7030901@oracle.com> Hi Kumar, So after this jdk8 builds will have to use current langtools javac in order to work? The corresponding changes to the new build system will be needed as well. David On 1/11/2012 3:43 AM, Kumar Srinivasan wrote: > Hello, > > Please review changes to rev up the default -source and -target for jdk > compilation, > thus producing v52.0 class files. > > Bug is here: > https://jbs.oracle.com/bugs/browse/JDK-8001191 > > Webrev is here: > http://cr.openjdk.java.net/~ksrini/8001191/webrev.0/ > > Note: this webrev is generated against the master repository but changes > will be > pushed via tl after the tl-master sync is completed. > > Thanks > Kumar > From david.holmes at oracle.com Thu Nov 1 01:48:44 2012 From: david.holmes at oracle.com (David Holmes) Date: Thu, 01 Nov 2012 11:48:44 +1000 Subject: RFR: 7050936: (pack200) Support version 52.0 class files In-Reply-To: <50916AAE.8080105@oracle.COM> References: <50916AAE.8080105@oracle.COM> Message-ID: <5091D4FC.1060300@oracle.com> Hi Kumar, On 1/11/2012 4:15 AM, Kumar Srinivasan wrote: > Please review change which allows pack200 to recognize the class > file v52.0. Looks fine, but I'm curious - if constants.h was never updated for 51.0 are those values even being used? David > > Bug is here: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7050936 > > Webrev is here: > http://cr.openjdk.java.net/~ksrini/7050936/webrev.0/ > > Thanks > Kumar > > > From david.holmes at oracle.com Thu Nov 1 02:22:12 2012 From: david.holmes at oracle.com (David Holmes) Date: Thu, 01 Nov 2012 12:22:12 +1000 Subject: RFR: JDK-8001191: use -source 8 -target 8 when compiling the JDK In-Reply-To: <5091D9DF.8090400@oracle.com> References: <5091635A.3010000@oracle.COM> <5091D2A9.7030901@oracle.com> <5091D9DF.8090400@oracle.com> Message-ID: <5091DCD4.2090409@oracle.com> Hi Jon, On 1/11/2012 12:09 PM, Jonathan Gibbons wrote: > David, > > For a long time now, the JDK 8 langtools repo has accepted -source 8 and > -target 8, so this should not affect which version of langtools you need > to use. Of course, you do need to make sure that these options are not > used with the bootstrap javac, which will typically be from JDK 7. That wasn't quite my query/concern - I wasn't very clear. If someone is doing a partial build, ie JDK repo only, they will now have to use a JDK8 boot JDK (or point to suitable langtools import?) - correct? (Where a full build would use the current langtools to build the rest of the JDK.) Just trying to understand if there may be places (JPRT?) where we've so far been able to use a JDK7 boot JDK but will no longer be able to. Thanks, David > -- Jon > > > On 10/31/2012 06:38 PM, David Holmes wrote: >> Hi Kumar, >> >> So after this jdk8 builds will have to use current langtools javac in >> order to work? >> >> The corresponding changes to the new build system will be needed as well. >> >> David >> >> On 1/11/2012 3:43 AM, Kumar Srinivasan wrote: >>> Hello, >>> >>> Please review changes to rev up the default -source and -target for jdk >>> compilation, >>> thus producing v52.0 class files. >>> >>> Bug is here: >>> https://jbs.oracle.com/bugs/browse/JDK-8001191 >>> >>> Webrev is here: >>> http://cr.openjdk.java.net/~ksrini/8001191/webrev.0/ >>> >>> Note: this webrev is generated against the master repository but changes >>> will be >>> pushed via tl after the tl-master sync is completed. >>> >>> Thanks >>> Kumar >>> > From david.holmes at oracle.com Thu Nov 1 05:24:41 2012 From: david.holmes at oracle.com (David Holmes) Date: Thu, 01 Nov 2012 15:24:41 +1000 Subject: XS RFR: 7198815 Add the minimal VM as "known" in jvm.cfg Message-ID: <50920799.6020205@oracle.com> http://cr.openjdk.java.net/~dholmes/7198815/webrev/ The minimal VM has just reached jdk8/jdk8/hotspot. This change makes it easy for anyone building the minimal VM to actually select it at runtime. Only 32-bit linux platforms are targeted. This will be pushed via the TL repo. Thanks, David From Alan.Bateman at oracle.com Thu Nov 1 07:34:40 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 01 Nov 2012 07:34:40 +0000 Subject: XS RFR: 7198815 Add the minimal VM as "known" in jvm.cfg In-Reply-To: <50920799.6020205@oracle.com> References: <50920799.6020205@oracle.com> Message-ID: <50922610.9070000@oracle.com> On 01/11/2012 05:24, David Holmes wrote: > http://cr.openjdk.java.net/~dholmes/7198815/webrev/ > > The minimal VM has just reached jdk8/jdk8/hotspot. This change makes > it easy for anyone building the minimal VM to actually select it at > runtime. > > Only 32-bit linux platforms are targeted. > > This will be pushed via the TL repo. This looks okay to me. -Alan From Alan.Bateman at oracle.com Thu Nov 1 08:29:58 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 01 Nov 2012 08:29:58 +0000 Subject: Review Request: CR#8001634 : Initial set of lambda functional interfaces In-Reply-To: <0A5D3B62-5D32-47ED-AF1E-5D6BF269B1E8@oracle.com> References: <0A5D3B62-5D32-47ED-AF1E-5D6BF269B1E8@oracle.com> Message-ID: <50923306.6000307@oracle.com> On 31/10/2012 20:16, Mike Duigou wrote: > There's a large set of library changes that will be coming with Lambda. We're getting near the end of the runway and there's lots left to do so we want to start the process of getting some of the more stable pieces put back to the JDK8 repositories. We've spent a some time slicing things into manageable chunks. This is the first bunch. We'd like to time-box this review at one week, since there are many more pieces to follow. > > : > > http://cr.openjdk.java.net/~mduigou/8001634/2/webrev/ This mail concerns some side issues that are nothing to do with the functional interfaces themselves, so file this separately to the feedback on the API. jdk8 still builds with the old build system and I don't think there is a transition date yet. Even after the transition then I expect that the old build system will need to be kept on life support for a few weeks. I just mention this as I don't see any updates to make/java/java/* in the webrev. As the functions are in their own package and are pure java then they just need to be compiled. I think this should do it (no need to list specific classes): --- a/make/java/java/Makefile +++ b/make/java/java/Makefile @@ -62,6 +62,8 @@ include FILES_c.gmk include FILES_c.gmk include FILES_java.gmk include Exportedfiles.gmk + +AUTO_FILES_JAVA_DIRS = java/util/functions ifeq ($(PLATFORM),windows) FILES_java += java/io/WinNTFileSystem.java \ The other minor thing is the copyright headers, a few of the interfaces (such as Block and Mapper) have three dates in the header. There are scripts around that check the format, might be worth running those to avoid noise during the reviews. -Alan From fredrik.ohrstrom at oracle.com Thu Nov 1 09:35:10 2012 From: fredrik.ohrstrom at oracle.com (fredrik.ohrstrom at oracle.com) Date: Thu, 01 Nov 2012 09:35:10 +0000 Subject: hg: jdk8/tl/jdk: 8002101: break out auxiliary classes that will prevent multi-core compilation of the JDK Message-ID: <20121101093556.A2642476E9@hg.openjdk.java.net> Changeset: 8b944ebef8a7 Author: ohrstrom Date: 2012-11-01 10:33 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8b944ebef8a7 8002101: break out auxiliary classes that will prevent multi-core compilation of the JDK Reviewed-by: alanb, sla + src/share/classes/com/sun/jmx/snmp/agent/AcmChecker.java + src/share/classes/com/sun/jmx/snmp/agent/LongList.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpMib.java From david.holmes at oracle.com Thu Nov 1 09:43:42 2012 From: david.holmes at oracle.com (David Holmes) Date: Thu, 01 Nov 2012 19:43:42 +1000 Subject: Review Request: CR#8001634 : Initial set of lambda functional interfaces In-Reply-To: <0A5D3B62-5D32-47ED-AF1E-5D6BF269B1E8@oracle.com> References: <0A5D3B62-5D32-47ED-AF1E-5D6BF269B1E8@oracle.com> Message-ID: <5092444E.2030708@oracle.com> Hi Mike, A few small comments: BinaryOperator: Typo: the the --- Block: * @param t an input object -> the input object --- typeBinaryOperator * Combines two {@code type} operands of the same type As opposed to two type operands of different type? :) typeMapper explicitly says it is the type specialization of Mapper, but typeBinaryOperator doesn't say the same thing about BinaryOperator. Ditto for UnaryOperator. We need a consistent approach here. --- DoubleUnaryOperator IntUnaryOperator: @param operand The operand value. The -> the General consistency note: sometimes the @param descriptive text starts with a capital and sometimes not. ---- Mapper: "A mapper may variously provide a mapping between types, object instances or keys and values or any other form of transformation upon the input." I can't parse this sentence and I'm not sure it is adding value beyond what is already said in the first sentence. --- UnaryOperator: * @param the type of input objects to {@code operate} and of the result. objects -> object and perhaps "the type of ^the^ input object ..." --- package-info.java * Functional interfaces provide typing for lambda methods. lambda methods? Do you mean lambda expressions? "non-defaulted" is a horrible term. Isn't it simply abstract? Seems to me that "abstract default" should not be permitted and that default wipes out any implicit abstract. That way a default method is not an abstract method, while an abstract method is what it always has been: a method signature with no implementation. + *

All functional interface implementations are expected to: The above lead in does not read correctly with the subsequent bullet points Cheers, David On 1/11/2012 6:16 AM, Mike Duigou wrote: > There's a large set of library changes that will be coming with Lambda. We're getting near the end of the runway and there's lots left to do so we want to start the process of getting some of the more stable pieces put back to the JDK8 repositories. We've spent a some time slicing things into manageable chunks. This is the first bunch. We'd like to time-box this review at one week, since there are many more pieces to follow. > > The first chunk is the basic set of functional interface types. While this set is not complete, it is enough to be able to proceed on some other pieces. This set contains no extension methods (we'll do those separately) and does not contain all the specializations we may eventually need. > > The specification is limited; most of the interesting restrictions (side-effect-freedom, idempotency, stability) would really be imposed not by the SAM itself by by how the SAM is used in a calculation. However, some common doc for "how to write good SAMs" that we can stick in the package doc would be helpful. Suggestions welcome. > > Elements of this naming scheme include: > - Each SAM type has a unique (arity, method name) pair. This allows SAMs to implement other SAMs without collision. > - The argument lists are structured so that specializations act on the first argument(s), so IntMapper is a specialization of Mapper, and IntBinaryOperator is a specialization of BinaryOperator. > > In order to get the most useful feedback out of this review, we'd like to ask you follow the following guidelines for the review: > > - We are time-boxed at one week. (until Nov. 7th) > > - Please review the whole bunch in a single message if possible, rather than in bits and pieces. It is far easier to extract useful feedback from one complete review than from a dozen partial ones. > > - Please wait a few days before replying to other people's reviews! We want to keep the discussion on-topic to maximize the useful review content. It is far too easy for the discussion to spiral off into minutia and lose sight of the goal -- which is to provide useful feedback on the API we're asking for feedback on. > > http://cr.openjdk.java.net/~mduigou/8001634/2/webrev/ From fredrik.ohrstrom at oracle.com Thu Nov 1 09:49:28 2012 From: fredrik.ohrstrom at oracle.com (fredrik.ohrstrom at oracle.com) Date: Thu, 01 Nov 2012 09:49:28 +0000 Subject: hg: jdk8/tl/langtools: 7153951: Add new lint option -Xlint:auxiliaryclass Message-ID: <20121101094933.822A5476EA@hg.openjdk.java.net> Changeset: bf54daa9dcd8 Author: ohrstrom Date: 2012-11-01 10:48 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/bf54daa9dcd8 7153951: Add new lint option -Xlint:auxiliaryclass Reviewed-by: jjg, mcimadamore, forax ! 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/MemberEnter.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties + test/tools/javac/diags/examples/AuxiliaryClassWarning/ClassUsingAuxiliary.java + test/tools/javac/diags/examples/AuxiliaryClassWarning/ClassWithAuxiliary.java + test/tools/javac/warnings/AuxiliaryClass/ClassUsingAnotherAuxiliary.java + test/tools/javac/warnings/AuxiliaryClass/ClassUsingAnotherAuxiliary.out + test/tools/javac/warnings/AuxiliaryClass/ClassUsingAuxiliary.java + test/tools/javac/warnings/AuxiliaryClass/ClassUsingAuxiliary1.out + test/tools/javac/warnings/AuxiliaryClass/ClassUsingAuxiliary2.out + test/tools/javac/warnings/AuxiliaryClass/ClassWithAuxiliary.java + test/tools/javac/warnings/AuxiliaryClass/NotAClassName.java + test/tools/javac/warnings/AuxiliaryClass/SelfClassWithAux.java From forax at univ-mlv.fr Thu Nov 1 11:46:32 2012 From: forax at univ-mlv.fr (Remi Forax) Date: Thu, 01 Nov 2012 12:46:32 +0100 Subject: Review Request: CR#8001634 : Initial set of lambda functional interfaces In-Reply-To: <5092444E.2030708@oracle.com> References: <0A5D3B62-5D32-47ED-AF1E-5D6BF269B1E8@oracle.com> <5092444E.2030708@oracle.com> Message-ID: <50926118.6030403@univ-mlv.fr> On 11/01/2012 10:43 AM, David Holmes wrote: [...] > package-info.java > > * Functional interfaces provide typing for lambda methods. > > lambda methods? Do you mean lambda expressions? > > "non-defaulted" is a horrible term. Isn't it simply abstract? Seems to > me that "abstract default" should not be permitted and that default > wipes out any implicit abstract. That way a default method is not an > abstract method, while an abstract method is what it always has been: > a method signature with no implementation. I agree that a single abstract method is a better term here. Nitpicking, Java 8 allows static methods in interface so non-default doesn't mean abstract but abstract or static methods. > > Cheers, > David Cheers, R?mi > > On 1/11/2012 6:16 AM, Mike Duigou wrote: >> There's a large set of library changes that will be coming with >> Lambda. We're getting near the end of the runway and there's lots >> left to do so we want to start the process of getting some of the >> more stable pieces put back to the JDK8 repositories. We've spent a >> some time slicing things into manageable chunks. This is the first >> bunch. We'd like to time-box this review at one week, since there are >> many more pieces to follow. >> >> The first chunk is the basic set of functional interface types. While >> this set is not complete, it is enough to be able to proceed on some >> other pieces. This set contains no extension methods (we'll do those >> separately) and does not contain all the specializations we may >> eventually need. >> >> The specification is limited; most of the interesting restrictions >> (side-effect-freedom, idempotency, stability) would really be imposed >> not by the SAM itself by by how the SAM is used in a calculation. >> However, some common doc for "how to write good SAMs" that we can >> stick in the package doc would be helpful. Suggestions welcome. >> >> Elements of this naming scheme include: >> - Each SAM type has a unique (arity, method name) pair. This allows >> SAMs to implement other SAMs without collision. >> - The argument lists are structured so that specializations act on >> the first argument(s), so IntMapper is a specialization of >> Mapper, and IntBinaryOperator is a specialization of >> BinaryOperator. >> >> In order to get the most useful feedback out of this review, we'd >> like to ask you follow the following guidelines for the review: >> >> - We are time-boxed at one week. (until Nov. 7th) >> >> - Please review the whole bunch in a single message if possible, >> rather than in bits and pieces. It is far easier to extract useful >> feedback from one complete review than from a dozen partial ones. >> >> - Please wait a few days before replying to other people's reviews! >> We want to keep the discussion on-topic to maximize the useful review >> content. It is far too easy for the discussion to spiral off into >> minutia and lose sight of the goal -- which is to provide useful >> feedback on the API we're asking for feedback on. >> >> http://cr.openjdk.java.net/~mduigou/8001634/2/webrev/ From forax at univ-mlv.fr Thu Nov 1 11:49:48 2012 From: forax at univ-mlv.fr (Remi Forax) Date: Thu, 01 Nov 2012 12:49:48 +0100 Subject: XS RFR: 7198815 Add the minimal VM as "known" in jvm.cfg In-Reply-To: <50922610.9070000@oracle.com> References: <50920799.6020205@oracle.com> <50922610.9070000@oracle.com> Message-ID: <509261DC.90903@univ-mlv.fr> On 11/01/2012 08:34 AM, Alan Bateman wrote: > On 01/11/2012 05:24, David Holmes wrote: >> http://cr.openjdk.java.net/~dholmes/7198815/webrev/ >> >> The minimal VM has just reached jdk8/jdk8/hotspot. This change makes >> it easy for anyone building the minimal VM to actually select it at >> runtime. >> >> Only 32-bit linux platforms are targeted. >> >> This will be pushed via the TL repo. > This looks okay to me. > > -Alan Okay, to me too. R?mi From kumar.x.srinivasan at oracle.COM Thu Nov 1 13:43:18 2012 From: kumar.x.srinivasan at oracle.COM (Kumar Srinivasan) Date: Thu, 01 Nov 2012 06:43:18 -0700 Subject: RFR: 7050936: (pack200) Support version 52.0 class files In-Reply-To: <5091D4FC.1060300@oracle.com> References: <50916AAE.8080105@oracle.COM> <5091D4FC.1060300@oracle.com> Message-ID: <50927C76.5080604@oracle.COM> Hi David, > Hi Kumar, > > On 1/11/2012 4:15 AM, Kumar Srinivasan wrote: >> Please review change which allows pack200 to recognize the class >> file v52.0. > > Looks fine, but I'm curious - if constants.h was never updated for > 51.0 are those values even being used? You are absolutely right, class file version is not used by the unpacker (constant.h), I thought I will update this for the sake of completeness. Thanks for the review! Kumar > > David > >> >> Bug is here: >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7050936 >> >> Webrev is here: >> http://cr.openjdk.java.net/~ksrini/7050936/webrev.0/ >> >> Thanks >> Kumar >> >> >> From mandy.chung at oracle.com Thu Nov 1 14:45:13 2012 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 01 Nov 2012 07:45:13 -0700 Subject: XS RFR: 7198815 Add the minimal VM as "known" in jvm.cfg In-Reply-To: <50920799.6020205@oracle.com> References: <50920799.6020205@oracle.com> Message-ID: <50928AF9.2040909@oracle.com> Looks good to me. Mandy On 10/31/2012 10:24 PM, David Holmes wrote: > http://cr.openjdk.java.net/~dholmes/7198815/webrev/ > > The minimal VM has just reached jdk8/jdk8/hotspot. This change makes > it easy for anyone building the minimal VM to actually select it at > runtime. > > Only 32-bit linux platforms are targeted. > > This will be pushed via the TL repo. > > Thanks, > David From jim.gish at oracle.com Thu Nov 1 14:49:15 2012 From: jim.gish at oracle.com (Jim Gish) Date: Thu, 01 Nov 2012 10:49:15 -0400 Subject: Review Request: CR#8001634 : Initial set of lambda functional interfaces In-Reply-To: <0A5D3B62-5D32-47ED-AF1E-5D6BF269B1E8@oracle.com> References: <0A5D3B62-5D32-47ED-AF1E-5D6BF269B1E8@oracle.com> Message-ID: <50928BEB.6050702@oracle.com> Hi Mike, Just a few minor javadoc suggestions. Otherwise, the "meat" looks good. Thanks, Jim ----------------------------------------------------------------------------------- Copyrights - - why do some of the copyrights say 2010, 2011, 2012 ? Is this the correct format? DoubleBinaryOperater.java (and others) just have 2012 java/util/BinaryOperator.java - why is extends Combiner commented out on the interface decl? Is this part of the phase-in of these changes? - for the javadoc for operate(T,T), I'd say "Returns the result of some /binary /operation upon the operands." java/util/DoubleBinaryOperator.java - for the javadoc for operate(double,double), I'd say "Returns the result of some /binary /operation upon the operands." java/util/DoubleMapper.java - javadoc - simply insert comma between "Given an input object" and "maps to an appropriate {@code double) value" java/util/DoubleUnaryOperator.java - "Returns a {@code double} value computed from the double operand." Should the second "double" also be "{@code double}"? java/util/functions/Factory.java - "Returns an object. The returned object may be an existing object or a newly created object." This might be better: "Returns an object which may have been created previously or is newly created." - for make() - "Returns an object" --> "Creates and returns an object or returns one previously created" java/util/functions/IntBinaryOperator.java - " Combines two {@code int} operands of the same type producing an {@code int} result" -- I'd insert a comma between "type" and "producing" - "some operation" -> "some /binary/ operation" java/util/IntMapper.java - javadoc - simply insert comma between "Given an input object" and "maps to an appropriate {@code int) value" java/util/functions/LongBinaryOperator.java - "some operation" -> "some /binary/ operation" java/util/LongMapper.java - javadoc - simply insert comma between "Given an input object" and "maps to an appropriate {@code long) value" java/util/Mapper.java - javadoc - simply insert comma between "Given an input object" and "maps to an appropriate output object" java.util/functions/Predicate.java - I think "condition" might be better than "criteria" java/util/functions/UnaryOperator.java - "@param the type of input objects to {@code operate} and of the result" is hard to parse. Perhaps this would be better: "@param the operand and result type of the {@code operate} method" - why is "extends Map" commented out? java/util/functions/package-info.html - this seems a little awkward: 35 *

All functional interface implementations are expected to: 36 *

It appears you were/are expecting additional things to be added to the list of expectations. Maybe it would be best to reserve the list structure of the comment for the time where additional conditions are added. Until then a simpler sentence would be cleaner: "When used for aggregate operations upon many elements, no functional interface implementation should assume that the operation will be called upon elements in any specific order. As Porky would say, That's all folks! :-) On 10/31/2012 04:16 PM, Mike Duigou wrote: > There's a large set of library changes that will be coming with Lambda. We're getting near the end of the runway and there's lots left to do so we want to start the process of getting some of the more stable pieces put back to the JDK8 repositories. We've spent a some time slicing things into manageable chunks. This is the first bunch. We'd like to time-box this review at one week, since there are many more pieces to follow. > > The first chunk is the basic set of functional interface types. While this set is not complete, it is enough to be able to proceed on some other pieces. This set contains no extension methods (we'll do those separately) and does not contain all the specializations we may eventually need. > > The specification is limited; most of the interesting restrictions (side-effect-freedom, idempotency, stability) would really be imposed not by the SAM itself by by how the SAM is used in a calculation. However, some common doc for "how to write good SAMs" that we can stick in the package doc would be helpful. Suggestions welcome. > > Elements of this naming scheme include: > - Each SAM type has a unique (arity, method name) pair. This allows SAMs to implement other SAMs without collision. > - The argument lists are structured so that specializations act on the first argument(s), so IntMapper is a specialization of Mapper, and IntBinaryOperator is a specialization of BinaryOperator. > > In order to get the most useful feedback out of this review, we'd like to ask you follow the following guidelines for the review: > > - We are time-boxed at one week. (until Nov. 7th) > > - Please review the whole bunch in a single message if possible, rather than in bits and pieces. It is far easier to extract useful feedback from one complete review than from a dozen partial ones. > > - Please wait a few days before replying to other people's reviews! We want to keep the discussion on-topic to maximize the useful review content. It is far too easy for the discussion to spiral off into minutia and lose sight of the goal -- which is to provide useful feedback on the API we're asking for feedback on. > > http://cr.openjdk.java.net/~mduigou/8001634/2/webrev/ -- 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 kelly.ohair at oracle.com Thu Nov 1 16:17:59 2012 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Thu, 1 Nov 2012 09:17:59 -0700 Subject: RFR: JDK-8001191: use -source 8 -target 8 when compiling the JDK In-Reply-To: <5091DCD4.2090409@oracle.com> References: <5091635A.3010000@oracle.COM> <5091D2A9.7030901@oracle.com> <5091D9DF.8090400@oracle.com> <5091DCD4.2090409@oracle.com> Message-ID: <3F615A55-4238-4AFA-947F-BC1A019BC653@oracle.com> If someone is doing a partial build (without langtools) the import jdk is used for javac compilation, not the boot jdk javac. This has not changed. The boot jdk javac is only used to build langtools and the hotspot serviceability agent. -kto On Oct 31, 2012, at 7:22 PM, David Holmes wrote: > Hi Jon, > > On 1/11/2012 12:09 PM, Jonathan Gibbons wrote: >> David, >> >> For a long time now, the JDK 8 langtools repo has accepted -source 8 and >> -target 8, so this should not affect which version of langtools you need >> to use. Of course, you do need to make sure that these options are not >> used with the bootstrap javac, which will typically be from JDK 7. > > That wasn't quite my query/concern - I wasn't very clear. If someone is doing a partial build, ie JDK repo only, they will now have to use a JDK8 boot JDK (or point to suitable langtools import?) - correct? (Where a full build would use the current langtools to build the rest of the JDK.) > > Just trying to understand if there may be places (JPRT?) where we've so far been able to use a JDK7 boot JDK but will no longer be able to. > > Thanks, > David > >> -- Jon >> >> >> On 10/31/2012 06:38 PM, David Holmes wrote: >>> Hi Kumar, >>> >>> So after this jdk8 builds will have to use current langtools javac in >>> order to work? >>> >>> The corresponding changes to the new build system will be needed as well. >>> >>> David >>> >>> On 1/11/2012 3:43 AM, Kumar Srinivasan wrote: >>>> Hello, >>>> >>>> Please review changes to rev up the default -source and -target for jdk >>>> compilation, >>>> thus producing v52.0 class files. >>>> >>>> Bug is here: >>>> https://jbs.oracle.com/bugs/browse/JDK-8001191 >>>> >>>> Webrev is here: >>>> http://cr.openjdk.java.net/~ksrini/8001191/webrev.0/ >>>> >>>> Note: this webrev is generated against the master repository but changes >>>> will be >>>> pushed via tl after the tl-master sync is completed. >>>> >>>> Thanks >>>> Kumar >>>> >> From Alan.Bateman at oracle.com Thu Nov 1 18:03:25 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 01 Nov 2012 18:03:25 +0000 Subject: Review request for 8001536 updated In-Reply-To: <175719F7-CE8C-455E-9E5C-2F2AB5B8A1FB@oracle.com> References: <509016F3.2030509@univ-mlv.fr> <175719F7-CE8C-455E-9E5C-2F2AB5B8A1FB@oracle.com> Message-ID: <5092B96D.4070206@oracle.com> On 31/10/2012 15:08, Lance Andersen - Oracle wrote: > Here is revised webrev taking into account Remi's suggestions http://cr.openjdk.java.net/~lancea/8001536/webrev.01/ > > I skimmed over the updated webrev and the changes mostly look okay to me. One comment on the clone method is that "The internal {@code Blob} field will be set to null" doesn't seem right. Shouldn't this say that the resulting object doesn't have an underlying Blob? I don't know if you want formatting/type comments but a couple of nits: - In both classes then it looks like the javadoc comment on equals has been shunted right by space - In equals then "if(" seems to be missing a space between "if" and "(". There's another one in readObject. - The spacing around "+" in hashCode is a bit odd, it doesn't matter of course but would be good to be consistent - the first line of both readObject has also been shunted right by one space. -Alan. From martijnverburg at gmail.com Thu Nov 1 20:09:08 2012 From: martijnverburg at gmail.com (Martijn Verburg) Date: Thu, 1 Nov 2012 21:09:08 +0100 Subject: about JavaOne2012 Finding and Solving Java Deadlocks In-Reply-To: <5091773A.4060804@oracle.com> References: <5091773A.4060804@oracle.com> Message-ID: I've pinged Heinz - M On 31 October 2012 20:08, Jim Gish wrote: > I'd be very interested in this too, and would also like to see the slides. > > Thanks, > Jim > > On 10/15/2012 05:50 PM, Mike Duigou wrote: > >> The session was a hands on lab so was not recorded that I can tell. >> >> Here's the official session page: >> >> https://oracleus.activeevents.**com/connect/search.ww?event=** >> javaone#loadSearch-event=**javaone&searchPhrase=&** >> searchType=session&tc=0&**sortBy=&p=&i%2811424%29=18653&** >> i%2810050%29=&i%2810090%29=&i%**2810092%29=&i%2811842%29=&i%**2810086%29= >> >> Some of the presenters are subscribers to this list. If they don't >> respond with the slides perhaps you can contact them. >> >> Mike >> >> On Oct 13 2012, at 03:44 , fuyou wrote: >> >> hi all >>> >>> I am very interested in session of HOL6500 - Finding and Solving Java >>> Deadlocks(JavaOne 2012) .how can i watch video or download slides. >>> >>> Thanks! >>> >>> -- >>> ==============================**=============== >>> >>> fuyou001 >>> Best Regards >>> >> > -- > 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 heinz at javaspecialists.eu Thu Nov 1 20:26:11 2012 From: heinz at javaspecialists.eu (Dr Heinz M. Kabutz) Date: Thu, 01 Nov 2012 22:26:11 +0200 Subject: about JavaOne2012 Finding and Solving Java Deadlocks In-Reply-To: <5091773A.4060804@oracle.com> References: <5091773A.4060804@oracle.com> Message-ID: <5092DAE3.9050609@javaspecialists.eu> You can download the lab with the slides from here: https://github.com/henri-tremblay/DeadlockLabJavaOne2012 If you have any comments or questions, please email me directly to heinz at javaspecialists.eu. Even though I am on this list, I don't read every message that comes past. I did see your one, but I forgot to reply and without Martijn's prompting it would have escaped into the mists of time. Regards Heinz -- Dr Heinz M. Kabutz (PhD CompSci) Author of "The Java(tm) Specialists' Newsletter" Sun Java Champion IEEE Certified Software Development Professional http://www.javaspecialists.eu Tel: +30 69 75 595 262 Skype: kabutz On 10/31/12 9:08 PM, Jim Gish wrote: > I'd be very interested in this too, and would also like to see the > slides. > > Thanks, > Jim > > On 10/15/2012 05:50 PM, Mike Duigou wrote: >> The session was a hands on lab so was not recorded that I can tell. >> >> Here's the official session page: >> >> https://oracleus.activeevents.com/connect/search.ww?event=javaone#loadSearch-event=javaone&searchPhrase=&searchType=session&tc=0&sortBy=&p=&i%2811424%29=18653&i%2810050%29=&i%2810090%29=&i%2810092%29=&i%2811842%29=&i%2810086%29= >> >> >> Some of the presenters are subscribers to this list. If they don't >> respond with the slides perhaps you can contact them. >> >> Mike >> >> On Oct 13 2012, at 03:44 , fuyou wrote: >> >>> hi all >>> >>> I am very interested in session of HOL6500 - Finding and Solving Java >>> Deadlocks(JavaOne 2012) .how can i watch video or download slides. >>> >>> Thanks! >>> >>> -- >>> ============================================= >>> >>> fuyou001 >>> Best Regards > From naoto.sato at oracle.com Thu Nov 1 20:29:55 2012 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Thu, 01 Nov 2012 20:29:55 +0000 Subject: hg: jdk8/tl/jdk: 8001440: CLDR adapter: Invalid number extension in language tag causes exception in NumberFormat.format() Message-ID: <20121101203035.99244476F6@hg.openjdk.java.net> Changeset: 6420fcd61c10 Author: naoto Date: 2012-11-01 13:28 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6420fcd61c10 8001440: CLDR adapter: Invalid number extension in language tag causes exception in NumberFormat.format() Reviewed-by: okutsu ! src/share/classes/java/text/DecimalFormatSymbols.java ! test/java/util/Locale/LocaleProviders.java ! test/java/util/Locale/LocaleProviders.sh From Alan.Bateman at oracle.com Thu Nov 1 21:12:54 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 01 Nov 2012 21:12:54 +0000 Subject: 8002120: ProblemList.txt updates (11/2012) Message-ID: <5092E5D6.2030805@oracle.com> I need a reviewer to remove 5 tests from the exclude list. 4 of the tests were excluded temporarily during the perm gen removal work. The other one was a compiler2 bug that is long fixed. While I was there I updated TEST.ROOT to add the top-level directories for the client area to othervm.dirs. This ensures that the tests for those areas is run in jtreg othervm mode even if samevm or agentvm mode is specified to jtreg. If the tests in those areas are updated so that each test doesn't require its own VM then they can be removed from the othervm.dirs list. The patch is trivial and inlined below. -Alan diff --git a/test/ProblemList.txt b/test/ProblemList.txt --- a/test/ProblemList.txt +++ b/test/ProblemList.txt @@ -136,12 +136,6 @@ java/lang/management/MemoryMXBean/ResetP # 7196801 java/lang/management/MemoryMXBean/LowMemoryTest2.sh generic-all - -# Exclude until the fix for 7195557 propagates widely. -java/lang/management/MemoryMXBean/CollectionUsageThresholdParallelGC.sh generic-all -java/lang/management/MemoryMXBean/CollectionUsageThresholdSerialGC.sh generic-all -java/lang/management/MemoryMXBean/MemoryTest.java generic-all -java/lang/management/MemoryMXBean/MemoryTestAllGC.sh generic-all # Exclude until hotspot/jdk repos are sync'd w.r.t. JAVA_MAX_SUPPORTED_VERSION # Needed when hotspot fix 7054345 is present. Remove when the JDK source is @@ -334,9 +328,6 @@ sun/security/krb5/auto/MaxRetries.java # jdk_text -# 7196199 -java/text/Bidi/Bug6665028.java generic-all - ############################################################################ # jdk_tools diff --git a/test/TEST.ROOT b/test/TEST.ROOT --- a/test/TEST.ROOT +++ b/test/TEST.ROOT @@ -6,7 +6,7 @@ keys=2d dnd i18n keys=2d dnd i18n # Tests that must run in othervm mode -othervm.dirs=java/rmi sun/rmi javax/management +othervm.dirs=java/awt java/beans java/rmi javax/accessibility javax/imageio javax/sound javax/print javax/management com/sun/awt sun/awt sun/java2d sun/pisces sun/rmi # Tests that cannot run concurrently exclusiveAccess.dirs=java/rmi/Naming sun/management/jmxremote sun/tools/jstatd From Lance.Andersen at oracle.com Thu Nov 1 21:23:50 2012 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Thu, 1 Nov 2012 17:23:50 -0400 Subject: 8002120: ProblemList.txt updates (11/2012) In-Reply-To: <5092E5D6.2030805@oracle.com> References: <5092E5D6.2030805@oracle.com> Message-ID: looks fine On Nov 1, 2012, at 5:12 PM, Alan Bateman wrote: > > I need a reviewer to remove 5 tests from the exclude list. 4 of the tests were excluded temporarily during the perm gen removal work. The other one was a compiler2 bug that is long fixed. > > While I was there I updated TEST.ROOT to add the top-level directories for the client area to othervm.dirs. This ensures that the tests for those areas is run in jtreg othervm mode even if samevm or agentvm mode is specified to jtreg. If the tests in those areas are updated so that each test doesn't require its own VM then they can be removed from the othervm.dirs list. > > The patch is trivial and inlined below. > > -Alan > > > diff --git a/test/ProblemList.txt b/test/ProblemList.txt > --- a/test/ProblemList.txt > +++ b/test/ProblemList.txt > @@ -136,12 +136,6 @@ java/lang/management/MemoryMXBean/ResetP > > # 7196801 > java/lang/management/MemoryMXBean/LowMemoryTest2.sh generic-all > - > -# Exclude until the fix for 7195557 propagates widely. > -java/lang/management/MemoryMXBean/CollectionUsageThresholdParallelGC.sh generic-all > -java/lang/management/MemoryMXBean/CollectionUsageThresholdSerialGC.sh generic-all > -java/lang/management/MemoryMXBean/MemoryTest.java generic-all > -java/lang/management/MemoryMXBean/MemoryTestAllGC.sh generic-all > > # Exclude until hotspot/jdk repos are sync'd w.r.t. JAVA_MAX_SUPPORTED_VERSION > # Needed when hotspot fix 7054345 is present. Remove when the JDK source is > @@ -334,9 +328,6 @@ sun/security/krb5/auto/MaxRetries.java > > # jdk_text > > -# 7196199 > -java/text/Bidi/Bug6665028.java generic-all > - > ############################################################################ > > # jdk_tools > diff --git a/test/TEST.ROOT b/test/TEST.ROOT > --- a/test/TEST.ROOT > +++ b/test/TEST.ROOT > @@ -6,7 +6,7 @@ keys=2d dnd i18n > keys=2d dnd i18n > > # Tests that must run in othervm mode > -othervm.dirs=java/rmi sun/rmi javax/management > +othervm.dirs=java/awt java/beans java/rmi javax/accessibility javax/imageio javax/sound javax/print javax/management com/sun/awt sun/awt sun/java2d sun/pisces sun/rmi > > # Tests that cannot run concurrently > exclusiveAccess.dirs=java/rmi/Naming sun/management/jmxremote sun/tools/jstatd > -------------- next part -------------- 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 jim.gish at oracle.com Thu Nov 1 21:34:58 2012 From: jim.gish at oracle.com (Jim Gish) Date: Thu, 01 Nov 2012 17:34:58 -0400 Subject: about JavaOne2012 Finding and Solving Java Deadlocks In-Reply-To: <5092DAE3.9050609@javaspecialists.eu> References: <5091773A.4060804@oracle.com> <5092DAE3.9050609@javaspecialists.eu> Message-ID: <5092EB02.9010504@oracle.com> Thank you -- it's much appreciated. Jim On 11/01/2012 04:26 PM, Dr Heinz M. Kabutz wrote: > You can download the lab with the slides from here: > > https://github.com/henri-tremblay/DeadlockLabJavaOne2012 > > If you have any comments or questions, please email me directly to > heinz at javaspecialists.eu. Even though I am on this list, I don't read > every message that comes past. I did see your one, but I forgot to > reply and without Martijn's prompting it would have escaped into the > mists of time. > > Regards > > Heinz -- 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 lance.andersen at oracle.com Thu Nov 1 21:36:05 2012 From: lance.andersen at oracle.com (lance.andersen at oracle.com) Date: Thu, 01 Nov 2012 21:36:05 +0000 Subject: hg: jdk8/tl/jdk: 8001536: Added readObject, writeObject, clone, equals, hashcode to SerialXLob Message-ID: <20121101213629.2702B476F7@hg.openjdk.java.net> Changeset: 8748331f63cf Author: lancea Date: 2012-11-01 17:35 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8748331f63cf 8001536: Added readObject,writeObject,clone, equals, hashcode to SerialXLob Reviewed-by: alanb, forax ! src/share/classes/javax/sql/rowset/serial/SerialBlob.java ! src/share/classes/javax/sql/rowset/serial/SerialClob.java From alan.bateman at oracle.com Thu Nov 1 21:59:09 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 01 Nov 2012 21:59:09 +0000 Subject: hg: jdk8/tl/jdk: 8002120: ProblemList.txt updates (11/2012) Message-ID: <20121101215934.1CC65476F8@hg.openjdk.java.net> Changeset: 79774104a1f4 Author: alanb Date: 2012-11-01 21:59 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/79774104a1f4 8002120: ProblemList.txt updates (11/2012) Reviewed-by: lancea ! test/ProblemList.txt ! test/TEST.ROOT From david.holmes at oracle.com Thu Nov 1 22:10:36 2012 From: david.holmes at oracle.com (david.holmes at oracle.com) Date: Thu, 01 Nov 2012 22:10:36 +0000 Subject: hg: jdk8/tl/jdk: 7198815: Add the minimal VM as "known" in jvm.cfg Message-ID: <20121101221103.1E29C476F9@hg.openjdk.java.net> Changeset: 9b3867244eec Author: dholmes Date: 2012-11-01 18:09 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9b3867244eec 7198815: Add the minimal VM as "known" in jvm.cfg Reviewed-by: alanb, forax, mchung ! src/solaris/bin/arm/jvm.cfg ! src/solaris/bin/i586/jvm.cfg ! src/solaris/bin/ppc/jvm.cfg ! src/solaris/bin/sparc/jvm.cfg From weijun.wang at oracle.com Fri Nov 2 03:07:40 2012 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Fri, 02 Nov 2012 03:07:40 +0000 Subject: hg: jdk8/tl/jdk: 7110803: SASL service for multiple hostnames Message-ID: <20121102030816.A07C847703@hg.openjdk.java.net> Changeset: 36f962518499 Author: weijun Date: 2012-11-02 10:48 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/36f962518499 7110803: SASL service for multiple hostnames Reviewed-by: mullan ! src/share/classes/com/sun/security/ntlm/Server.java ! src/share/classes/com/sun/security/sasl/CramMD5Server.java ! src/share/classes/com/sun/security/sasl/digest/DigestMD5Base.java ! src/share/classes/com/sun/security/sasl/digest/DigestMD5Server.java ! src/share/classes/com/sun/security/sasl/gsskerb/GssKrb5Server.java ! src/share/classes/com/sun/security/sasl/ntlm/NTLMServer.java ! src/share/classes/com/sun/security/sasl/util/AbstractSaslImpl.java ! src/share/classes/javax/security/sasl/Sasl.java ! src/share/classes/javax/security/sasl/SaslServerFactory.java + test/com/sun/security/sasl/digest/Unbound.java + test/sun/security/krb5/auto/SaslBasic.java From alexander.knoeller at gmail.com Fri Nov 2 10:03:15 2012 From: alexander.knoeller at gmail.com (=?iso-8859-1?Q?Alexander_Kn=F6ller?=) Date: Fri, 2 Nov 2012 11:03:15 +0100 Subject: bottleneck by java.lang.Class.getAnnotations() References: <924D06EC-F603-4E6A-A7FE-7A05C77B1217@gmail.com> Message-ID: <23313EDE-3AB7-4E53-8EB1-A6F6CC9383B9@gmail.com> Hello there. (Reposting this request for improvement as suggested in mailing list jdk6-dev) java.lang.Class.getAnnotations() always enters a synchronized-block (initAnnotationsIfNecessary() ), slowing down multi core machines that heavily make use of Annotations. (in our Case we use LoadTimeWeaving in the spring-framework 3.1.2) We are using sun-jdk 6u27 on CentOS which has the same performance-bottleneck. I could not easily find sources for sunjdk (no open source anymore). So I do not know if Versions 7 or 8 contain fixes for this. openjdk7 and 8 show no fix so far, although it looks like it might be possible to build a kind of double-checked locking using local variables? I am not very familiar with concurrency while using SoftReferences, but I guess using a local Variable for concurrency-avoidance for the annotations-field or the target of the SoftReference, then doing a nonsynchronized check for the redefinition and a potential null-value on the local copy of the annotations-variable should suffice to decide that one could leave out the synced call and just returns the annotations-value (referenced by the local variable)? Also you would need to use a local variable while calculating the annotations prior to assigning the result to the annotations-field to avoid concurrency-effects on the double-checked locking. Since Code using getAnnotations() always could get hit by an annotations-result not fitting any more to the class because of a concurrent thread redefining the class we would not need to take care of this (and the current code could cause unexpected behaviour already inside "getAnnotations()" after exiting the lock on initAnnotationsIfNecessary()). Regards Alex Anfang der weitergeleiteten E-Mail: > Von: Alexander Kn?ller > Betreff: Re: bottleneck by java.lang.Class.getAnnotations() > Datum: 2. November 2012 08:43:06 MEZ > An: Joe Darcy > Kopie: Alan Bateman , jdk6-dev at openjdk.java.net > > I know. But there is a usual solution to those kind of problems: double checked locking. > This would avoid synchronization for all the cases where no redefinitions take place. > (I also put in a bug-report for the sunjdk where I elaborated this a bit more.) > I am not so familiar with concurrency while using SoftReferences, but I guess using a local Variable for concurrency-avoidance for the annotations-field or the target of the SoftReference, then doing a nonsynchronized check for the redefinition and a potentially null-value on the local copy of the annotations-variable should suffice to decide that one could leave out the synced call and just returns the annotations-value (in the local variable)? > > Also you would need to use a local variable while calculating the annotations-Field prior to assigning the result to the field to avoid concurrency-effects on the double-checked locking. > > Since Code using getAnnotations() always could trap in an annotations-result not fitting any more to the class because of concurrent redefinition we would not need to take care of this (and the current code could cause this already inside "getAnnotations()". > > -Alex > > Am 01.11.2012 um 15:56 schrieb Joe Darcy: > >> >> On 11/1/2012 7:11 AM, Alan Bateman wrote: >>> On 01/11/2012 13:17, Alexander Kn?ller wrote: >>>> Hi there. >>>> >>>> java.lang.Class.getAnnotations() always enters a synchronized-block, slowing down multi core machines that heavily make use of Annotations. >>>> (in our Case we use LoadTimeWeaving in the spring-framework 3.1.2) >>>> We are using sun-jdk 6 which has the same performance-bottleneck. >>>> openjdk7 and 8 show no fix so far, although it looks like it might be possible to build a kind of double-checked locking? >>>> >>>> Has this issue ever been persued? >>>> >>>> Special Regards >>>> Alex Kn?ller >>>> >>> If you have a proposal then I suggest bringing it to core-libs-dev for discussion. In addition to contention there are other issues that need attention there too, particularly the potential to deadlock and the overhead per Class when annotations aren't used. There's definitely some useful work that could be done there. >>> >>> >> >> Note that the block in question is synchronized so that getAnnotations returns the right result if the class has been redefined at runtime using an API for that purpose. >> >> -Joe >> > From peter.levart at gmail.com Fri Nov 2 11:04:51 2012 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 02 Nov 2012 12:04:51 +0100 Subject: bottleneck by java.lang.Class.getAnnotations() In-Reply-To: <23313EDE-3AB7-4E53-8EB1-A6F6CC9383B9@gmail.com> References: <924D06EC-F603-4E6A-A7FE-7A05C77B1217@gmail.com> <23313EDE-3AB7-4E53-8EB1-A6F6CC9383B9@gmail.com> Message-ID: <5093A8D3.4030800@gmail.com> On 11/02/2012 11:03 AM, Alexander Kn?ller wrote: > Hello there. > > (Reposting this request for improvement as suggested in mailing list jdk6-dev) > > java.lang.Class.getAnnotations() always enters a synchronized-block (initAnnotationsIfNecessary() ), slowing down multi core machines that heavily make use of Annotations. > (in our Case we use LoadTimeWeaving in the spring-framework 3.1.2) > We are using sun-jdk 6u27 on CentOS which has the same performance-bottleneck. I could not easily find sources for sunjdk (no open source anymore). > So I do not know if Versions 7 or 8 contain fixes for this. > openjdk7 and 8 show no fix so far, although it looks like it might be possible to build a kind of double-checked locking using local variables? > > > I am not very familiar with concurrency while using SoftReferences, but I guess using a local Variable for concurrency-avoidance for the annotations-field or the target of the SoftReference, then doing a nonsynchronized check for the redefinition and a potential null-value on the local copy of the annotations-variable should suffice to decide that one could leave out the synced call and just returns the annotations-value (referenced by the local variable)? > Also you would need to use a local variable while calculating the annotations prior to assigning the result to the annotations-field to avoid concurrency-effects on the double-checked locking. > > Since Code using getAnnotations() always could get hit by an annotations-result not fitting any more to the class because of a concurrent thread redefining the class we would not need to take care of this (and the current code could cause unexpected behaviour already inside "getAnnotations()" after exiting the lock on initAnnotationsIfNecessary()). > > Regards > Alex > > Anfang der weitergeleiteten E-Mail: > >> Von: Alexander Kn?ller >> Betreff: Re: bottleneck by java.lang.Class.getAnnotations() >> Datum: 2. November 2012 08:43:06 MEZ >> An: Joe Darcy >> Kopie: Alan Bateman , jdk6-dev at openjdk.java.net >> >> I know. But there is a usual solution to those kind of problems: double checked locking. >> This would avoid synchronization for all the cases where no redefinitions take place. >> (I also put in a bug-report for the sunjdk where I elaborated this a bit more.) >> I am not so familiar with concurrency while using SoftReferences, but I guess using a local Variable for concurrency-avoidance for the annotations-field or the target of the SoftReference, then doing a nonsynchronized check for the redefinition and a potentially null-value on the local copy of the annotations-variable should suffice to decide that one could leave out the synced call and just returns the annotations-value (in the local variable)? >> >> Also you would need to use a local variable while calculating the annotations-Field prior to assigning the result to the field to avoid concurrency-effects on the double-checked locking. >> >> Since Code using getAnnotations() always could trap in an annotations-result not fitting any more to the class because of concurrent redefinition we would not need to take care of this (and the current code could cause this already inside "getAnnotations()". >> >> -Alex >> >> Am 01.11.2012 um 15:56 schrieb Joe Darcy: >> >>> On 11/1/2012 7:11 AM, Alan Bateman wrote: >>>> On 01/11/2012 13:17, Alexander Kn?ller wrote: >>>>> Hi there. >>>>> >>>>> java.lang.Class.getAnnotations() always enters a synchronized-block, slowing down multi core machines that heavily make use of Annotations. >>>>> (in our Case we use LoadTimeWeaving in the spring-framework 3.1.2) >>>>> We are using sun-jdk 6 which has the same performance-bottleneck. >>>>> openjdk7 and 8 show no fix so far, although it looks like it might be possible to build a kind of double-checked locking? >>>>> >>>>> Has this issue ever been persued? >>>>> >>>>> Special Regards >>>>> Alex Kn?ller >>>>> >>>> If you have a proposal then I suggest bringing it to core-libs-dev for discussion. In addition to contention there are other issues that need attention there too, particularly the potential to deadlock and the overhead per Class when annotations aren't used. There's definitely some useful work that could be done there. Hi all, initAnnotationsIfNecessary() is at least synchronized, so that it always gets the result right in face of concurrent calls to it and class redefinitions performed by VM, but other methods, such as for example: private Field[] privateGetDeclaredFields(boolean publicOnly) ...and many others are not. Therefore a theoretical race exists that could install an old version of fields into cached storage (declaredPublicFields or declaredFields in this case) that was taken before class was redefined and write it over the new version of fields... I suggest redesigning the lazy construction / caching by employing versioned containers like the following: static class VersionedSoftRef extends SoftReference { final int redefinedCount; VersionedSoftRef(T referent, int redefinedCount) { super(referent); this.redefinedCount = redefinedCount; } } ...to be used instead of plain SoftReferences in places like declaredPublicFields and such and using CAS (via Unsafe or AtomicReferenceFieldUpdater) to optimistically install lazily constructed data... The versioned containers would serve two purposes: each access to a part of cached data could be independently version-checked against current value of classRedefinedCount on a fast path before returning a cached value. In case of cache-miss (not data or stale data), a thread could compute the data concurrently with any other threads doing the same and using CAS at the end, install the latest version of data into cache. For getAnnotations() I would use a similar technique (a versioned private subclass of HashMap for example). If you like, I can prepare a patch and send it for review. Regards, Peter >>>> >>>> >>> Note that the block in question is synchronized so that getAnnotations returns the right result if the class has been redefined at runtime using an API for that purpose. >>> >>> -Joe >>> From Alan.Bateman at oracle.com Fri Nov 2 12:46:02 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 02 Nov 2012 12:46:02 +0000 Subject: 7197491: update copyright year to match last edit in jdk8 jdk repository Message-ID: <5093C08A.8060705@oracle.com> Now for some noise. The copyright date in the source files needs updating. The man behind the curtain is Steve Sides from the Quality and Release Engineering team in Oracle. Jon pushed, on Steve's behalf, the update to the langtools files recently [1], and Mikael updated hotspot [2]. The elephant is the jdk repository as there are 3000+ files that need their headers updated. To keep the disruption to a minimum I propose that we do the jdk repository in two steps: non-client area now to jdk8/tl, and then the client-area later in jdk8/awt once the changes get there. I use the term "client-area" loosely to mean the source files for awt, swing, font, java2d, etc. (and I appreciate that there is also a jdk8/2d forest in use). To that end here is the proposed patch for today: http://cr.openjdk.java.net/~alanb/7197491/copyright.patch This patch updates the headers on 2370 files. I don't propose to publish a webrev as it's just too big. This patch was created with: cd jdk sh ../make/scripts/update_copyright_year.sh 2011 sh ../make/scripts/update_copyright_year.sh 2012 hg revert --no-backup `cat clientdirs.list` hg diff -g > copyright.patch where clientdirs.list is most of the directories corresponding to the client area. Note that I ran the update_copyright_year.sh script twice, once for 2011 and then a second time for 2012. The reason for this is that there are several hundred files in the jdk repository that were last updated in 2011 but have an older date on the header. Reviewer welcome but I should say that I don't have cycles to spend on this. Also the patch has an a very short shelf life. Finally, I think that there needs to be wider discussion as to how to keep the headers from falling behind too much. Some people do update the headers when editing files, some people (including myself) do not. It seems to me that it should be done regularly anyway, perhaps every few months or at integration time every so often. -Alan. [1] http://hg.openjdk.java.net/jdk8/tl/langtools/rev/9d47f4850714 [2] http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/b9a9ed0f8eeb From chris.hegarty at oracle.com Fri Nov 2 13:44:05 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 2 Nov 2012 06:44:05 -0700 (PDT) Subject: 7197491: update copyright year to match last edit in jdk8 jdk repository In-Reply-To: <5093C08A.8060705@oracle.com> References: <5093C08A.8060705@oracle.com> Message-ID: <5093CE25.4040009@oracle.com> I'm not sure what you are looking for here, but I skimmed quickly up and down the patch stopping occasionally, and the updated headers look ok. On the general issue, is there a reason what on the 1st of January ever source file cannot have its year range updated to that year. Then just forget about it until the next year? Anyway, I'm ok with this as is for now. -Chris. On 11/02/2012 12:46 PM, Alan Bateman wrote: > > Now for some noise. > > The copyright date in the source files needs updating. The man behind > the curtain is Steve Sides from the Quality and Release Engineering team > in Oracle. Jon pushed, on Steve's behalf, the update to the langtools > files recently [1], and Mikael updated hotspot [2]. The elephant is the > jdk repository as there are 3000+ files that need their headers updated. > > To keep the disruption to a minimum I propose that we do the jdk > repository in two steps: non-client area now to jdk8/tl, and then the > client-area later in jdk8/awt once the changes get there. I use the term > "client-area" loosely to mean the source files for awt, swing, font, > java2d, etc. (and I appreciate that there is also a jdk8/2d forest in > use). To that end here is the proposed patch for today: > > http://cr.openjdk.java.net/~alanb/7197491/copyright.patch > > This patch updates the headers on 2370 files. I don't propose to publish > a webrev as it's just too big. > > This patch was created with: > > cd jdk > sh ../make/scripts/update_copyright_year.sh 2011 > sh ../make/scripts/update_copyright_year.sh 2012 > hg revert --no-backup `cat clientdirs.list` > hg diff -g > copyright.patch > > where clientdirs.list is most of the directories corresponding to the > client area. > > Note that I ran the update_copyright_year.sh script twice, once for 2011 > and then a second time for 2012. The reason for this is that there are > several hundred files in the jdk repository that were last updated in > 2011 but have an older date on the header. > > Reviewer welcome but I should say that I don't have cycles to spend on > this. Also the patch has an a very short shelf life. > > Finally, I think that there needs to be wider discussion as to how to > keep the headers from falling behind too much. Some people do update the > headers when editing files, some people (including myself) do not. It > seems to me that it should be done regularly anyway, perhaps every few > months or at integration time every so often. > > -Alan. > > [1] http://hg.openjdk.java.net/jdk8/tl/langtools/rev/9d47f4850714 > [2] http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/b9a9ed0f8eeb From kumar.x.srinivasan at oracle.COM Fri Nov 2 14:14:05 2012 From: kumar.x.srinivasan at oracle.COM (Kumar Srinivasan) Date: Fri, 02 Nov 2012 07:14:05 -0700 Subject: 7197491: update copyright year to match last edit in jdk8 jdk repository In-Reply-To: <5093C08A.8060705@oracle.com> References: <5093C08A.8060705@oracle.com> Message-ID: <5093D52D.1030906@oracle.COM> Alan, I grepped the patch and it seems to be ok. You can add me as a reviewer. Kumar > > Now for some noise. > > The copyright date in the source files needs updating. The man behind > the curtain is Steve Sides from the Quality and Release Engineering > team in Oracle. Jon pushed, on Steve's behalf, the update to the > langtools files recently [1], and Mikael updated hotspot [2]. The > elephant is the jdk repository as there are 3000+ files that need > their headers updated. > > To keep the disruption to a minimum I propose that we do the jdk > repository in two steps: non-client area now to jdk8/tl, and then the > client-area later in jdk8/awt once the changes get there. I use the > term "client-area" loosely to mean the source files for awt, swing, > font, java2d, etc. (and I appreciate that there is also a jdk8/2d > forest in use). To that end here is the proposed patch for today: > > http://cr.openjdk.java.net/~alanb/7197491/copyright.patch > > This patch updates the headers on 2370 files. I don't propose to > publish a webrev as it's just too big. > > This patch was created with: > > cd jdk > sh ../make/scripts/update_copyright_year.sh 2011 > sh ../make/scripts/update_copyright_year.sh 2012 > hg revert --no-backup `cat clientdirs.list` > hg diff -g > copyright.patch > > where clientdirs.list is most of the directories corresponding to the > client area. > > Note that I ran the update_copyright_year.sh script twice, once for > 2011 and then a second time for 2012. The reason for this is that > there are several hundred files in the jdk repository that were last > updated in 2011 but have an older date on the header. > > Reviewer welcome but I should say that I don't have cycles to spend on > this. Also the patch has an a very short shelf life. > > Finally, I think that there needs to be wider discussion as to how to > keep the headers from falling behind too much. Some people do update > the headers when editing files, some people (including myself) do not. > It seems to me that it should be done regularly anyway, perhaps every > few months or at integration time every so often. > > -Alan. > > [1] http://hg.openjdk.java.net/jdk8/tl/langtools/rev/9d47f4850714 > [2] http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/b9a9ed0f8eeb From yuka.kamiya at oracle.com Fri Nov 2 14:19:00 2012 From: yuka.kamiya at oracle.com (yuka.kamiya at oracle.com) Date: Fri, 02 Nov 2012 14:19:00 +0000 Subject: hg: jdk8/tl/jdk: 8001209: Evaluate findbugs reprot for java.text.ChoiceFormat Message-ID: <20121102141926.BF1BA47737@hg.openjdk.java.net> Changeset: 98a47dc23296 Author: peytoia Date: 2012-11-02 23:17 +0900 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/98a47dc23296 8001209: Evaluate findbugs reprot for java.text.ChoiceFormat Reviewed-by: okutsu ! src/share/classes/java/text/ChoiceFormat.java + test/java/text/Format/ChoiceFormat/Bug8001209.java From alan.bateman at oracle.com Fri Nov 2 15:55:16 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Fri, 02 Nov 2012 15:55:16 +0000 Subject: hg: jdk8/tl/jdk: 7197491: update copyright year to match last edit in jdk8 jdk repository Message-ID: <20121102155538.C04BE47740@hg.openjdk.java.net> Changeset: cea72c2bf071 Author: alanb Date: 2012-11-02 15:50 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cea72c2bf071 7197491: update copyright year to match last edit in jdk8 jdk repository Reviewed-by: chegar, ksrini ! make/apple/Makefile ! make/apple/applescript/Makefile ! make/com/Makefile ! make/com/apple/Makefile ! make/com/apple/osx/Makefile ! make/com/apple/osxui/Makefile ! make/com/oracle/jfr/Makefile ! make/com/sun/Makefile ! make/com/sun/demo/jvmti/hprof/Makefile ! make/com/sun/java/browser/net/Makefile ! make/com/sun/java/pack/Makefile ! make/com/sun/net/ssl/Makefile ! make/com/sun/nio/Makefile ! make/com/sun/nio/sctp/Exportedfiles.gmk ! make/com/sun/nio/sctp/FILES_java.gmk ! make/com/sun/nio/sctp/Makefile ! make/com/sun/nio/sctp/mapfile-vers ! make/com/sun/security/auth/module/Makefile ! make/com/sun/tools/Makefile ! make/com/sun/tools/attach/Exportedfiles.gmk ! make/com/sun/tools/attach/FILES_c.gmk ! make/com/sun/tools/attach/FILES_java.gmk ! make/com/sun/tools/attach/mapfile-bsd ! make/com/sun/tracing/Makefile ! make/com/sun/tracing/dtrace/Makefile ! make/common/Demo.gmk ! make/common/Mapfile-vers.gmk ! make/common/Release-macosx.gmk ! make/common/Rules.gmk ! make/common/Sanity.gmk ! make/common/internal/Defs-jaxws.gmk ! make/common/internal/NativeCompileRules.gmk ! make/common/internal/Resources.gmk ! make/common/shared/Compiler-gcc.gmk ! make/common/shared/Compiler-llvm.gmk ! make/common/shared/Compiler-sun.gmk ! make/common/shared/Defs-linux.gmk ! make/common/shared/Defs-macosx.gmk ! make/common/shared/Defs-solaris.gmk ! make/common/shared/Defs-utils.gmk ! make/common/shared/Defs-versions.gmk ! make/common/shared/Defs-windows.gmk ! make/common/shared/Defs.gmk ! make/common/shared/Sanity-Settings.gmk ! make/docs/CORE_PKGS.gmk ! make/java/Makefile ! make/java/awt/Makefile ! make/java/fdlibm/FILES_c.gmk ! make/java/java/genlocales.gmk ! make/java/java/reflect/Makefile ! make/java/jobjc/Makefile ! make/java/jvm/Makefile ! make/java/management/mapfile-vers ! make/java/net/FILES_c.gmk ! make/java/net/Makefile ! make/java/nio/FILES_java.gmk ! make/java/nio/Makefile ! make/java/nio/mapfile-bsd ! make/java/nio/mapfile-linux ! make/java/nio/mapfile-solaris ! make/java/rmi/Makefile ! make/java/security/Makefile ! make/java/sun_nio/FILES_java.gmk ! make/java/text/bidi/Makefile ! make/java/zip/FILES_c.gmk ! make/java/zip/Makefile ! make/java/zip/mapfile-vers ! make/javax/accessibility/Makefile ! make/javax/crypto/Makefile ! make/javax/sound/FILES_c.gmk ! make/javax/sound/SoundDefs.gmk ! make/javax/sound/jsoundalsa/Makefile ! make/jdk_generic_profile.sh ! make/jpda/back/Makefile ! make/jpda/jdwp/jdwp.spec ! make/jprt.properties ! make/mksample/Makefile ! make/netbeans/common/architectures/name-Bsd.properties ! make/netbeans/common/closed-share-view.ent ! make/netbeans/common/jtreg-view.ent ! make/netbeans/common/sample-view.ent ! make/netbeans/common/share-view.ent ! make/netbeans/common/unix-view.ent ! make/netbeans/common/windows-view.ent ! make/netbeans/jconsole/build.xml ! make/org/ietf/jgss/Makefile ! make/sun/Makefile ! make/sun/awt/FILES_c_macosx.gmk ! make/sun/awt/FILES_c_unix.gmk ! make/sun/awt/FILES_export_macosx.gmk ! make/sun/awt/FILES_export_unix.gmk ! make/sun/awt/mapfile-vers-bsd ! make/sun/awt/mawt.gmk ! make/sun/cmm/lcms/Makefile ! make/sun/font/Makefile ! make/sun/font/t2k/Makefile ! make/sun/headless/Makefile ! make/sun/image/generic/Makefile ! make/sun/image/vis/Makefile ! make/sun/jawt/Makefile ! make/sun/jconsole/FILES.gmk ! make/sun/jconsole/Makefile ! make/sun/jdga/Makefile ! make/sun/lwawt/FILES_c_macosx.gmk ! make/sun/lwawt/FILES_export_macosx.gmk ! make/sun/lwawt/Makefile ! make/sun/net/FILES_java.gmk ! make/sun/net/spi/Makefile ! make/sun/nio/cs/FILES_java.gmk ! make/sun/osxapp/Makefile ! make/sun/rmi/cgi/Makefile ! make/sun/rmi/registry/Makefile ! make/sun/rmi/rmi/Makefile ! make/sun/rmi/rmi/mapfile-vers ! make/sun/rmi/rmid/Makefile ! make/sun/security/jgss/wrapper/Makefile ! make/sun/security/krb5/Makefile ! make/sun/security/other/Makefile ! make/sun/security/smartcardio/Makefile ! make/sun/splashscreen/FILES_c.gmk ! make/sun/splashscreen/Makefile ! make/sun/tools/Makefile ! make/sun/util/Makefile ! make/tools/CharsetMapping/DoubleByte-X.java.template ! make/tools/CharsetMapping/SingleByte-X.java.template ! make/tools/GenerateCharacter/CharacterData01.java.template ! make/tools/GenerateCharacter/CharacterData02.java.template ! make/tools/GenerateCharacter/CharacterData0E.java.template ! make/tools/GenerateCharacter/CharacterDataLatin1.java.template ! make/tools/freetypecheck/Makefile ! make/tools/reorder/Makefile ! make/tools/src/build/tools/charsetmapping/DBCS.java ! make/tools/src/build/tools/charsetmapping/SBCS.java ! make/tools/src/build/tools/compileproperties/CompileProperties.java ! make/tools/src/build/tools/generatenimbus/AbstractGradient.java ! make/tools/src/build/tools/generatenimbus/Border.java ! make/tools/src/build/tools/generatenimbus/Canvas.java ! make/tools/src/build/tools/generatenimbus/ComponentColor.java ! make/tools/src/build/tools/generatenimbus/Dimension.java ! make/tools/src/build/tools/generatenimbus/Ellipse.java ! make/tools/src/build/tools/generatenimbus/Gradient.java ! make/tools/src/build/tools/generatenimbus/GradientStop.java ! make/tools/src/build/tools/generatenimbus/Insets.java ! make/tools/src/build/tools/generatenimbus/Layer.java ! make/tools/src/build/tools/generatenimbus/Matte.java ! make/tools/src/build/tools/generatenimbus/Paint.java ! make/tools/src/build/tools/generatenimbus/Path.java ! make/tools/src/build/tools/generatenimbus/Point.java ! make/tools/src/build/tools/generatenimbus/RadialGradient.java ! make/tools/src/build/tools/generatenimbus/Rectangle.java ! make/tools/src/build/tools/generatenimbus/Shape.java ! make/tools/src/build/tools/generatenimbus/SynthModel.java ! make/tools/src/build/tools/generatenimbus/Typeface.java ! make/tools/src/build/tools/generatenimbus/UIColor.java ! make/tools/src/build/tools/generatenimbus/UIComponent.java ! make/tools/src/build/tools/generatenimbus/UIDefault.java ! make/tools/src/build/tools/generatenimbus/UIFont.java ! make/tools/src/build/tools/generatenimbus/UIIconRegion.java ! make/tools/src/build/tools/generatenimbus/UIProperty.java ! make/tools/src/build/tools/generatenimbus/UIRegion.java ! make/tools/src/build/tools/generatenimbus/UIState.java ! make/tools/src/build/tools/generatenimbus/UIStateType.java ! make/tools/src/build/tools/generatenimbus/UIStyle.java ! make/tools/src/build/tools/jdwpgen/ArrayRegionTypeNode.java ! make/tools/src/build/tools/stripproperties/StripProperties.java ! makefiles/GendataBreakIterator.gmk ! makefiles/GendataTimeZone.gmk ! makefiles/GensrcSwing.gmk ! makefiles/docs/CORE_PKGS.gmk ! makefiles/jpda/jdwp/jdwp.spec ! makefiles/jprt.gmk ! makefiles/jprt.properties ! makefiles/mapfiles/launchers/mapfile-amd64 ! makefiles/mapfiles/launchers/mapfile-i586 ! makefiles/mapfiles/launchers/mapfile-sparc ! makefiles/mapfiles/launchers/mapfile-sparcv9 ! makefiles/mapfiles/launchers/mapfile-x86 ! makefiles/mapfiles/launchers/mapfile-x86_64 ! makefiles/mapfiles/libattach/mapfile-linux ! makefiles/mapfiles/libattach/mapfile-solaris ! makefiles/mapfiles/libawt/mapfile-mawt-vers ! makefiles/mapfiles/libawt/mapfile-vers ! makefiles/mapfiles/libawt/mapfile-vers-linux ! makefiles/mapfiles/libawt_headless/mapfile-vers ! makefiles/mapfiles/libawt_xawt/mapfile-vers ! makefiles/mapfiles/libdcpr/mapfile-vers ! makefiles/mapfiles/libdt_socket/mapfile-vers ! makefiles/mapfiles/libfontmanager/mapfile-vers ! makefiles/mapfiles/libfontmanager/mapfile-vers.openjdk ! makefiles/mapfiles/libhprof/mapfile-vers ! makefiles/mapfiles/libinstrument/mapfile-vers ! makefiles/mapfiles/libj2gss/mapfile-vers ! makefiles/mapfiles/libj2pcsc/mapfile-vers ! makefiles/mapfiles/libjaas/mapfile-vers ! makefiles/mapfiles/libjava_crw_demo/mapfile-vers ! makefiles/mapfiles/libjawt/mapfile-vers ! makefiles/mapfiles/libjdga/mapfile-vers ! makefiles/mapfiles/libjdwp/mapfile-vers ! makefiles/mapfiles/libjli/mapfile-vers ! makefiles/mapfiles/libjpeg/mapfile-vers ! makefiles/mapfiles/libjpeg/mapfile-vers-closed ! makefiles/mapfiles/libjsdt/mapfile-vers ! makefiles/mapfiles/libjsound/mapfile-vers ! makefiles/mapfiles/libjsoundalsa/mapfile-vers ! makefiles/mapfiles/libkcms/mapfile-vers ! makefiles/mapfiles/liblcms/mapfile-vers ! makefiles/mapfiles/libmanagement/mapfile-vers ! makefiles/mapfiles/libmlib_image/mapfile-vers ! makefiles/mapfiles/libnet/mapfile-vers ! makefiles/mapfiles/libnio/mapfile-bsd ! makefiles/mapfiles/libnio/mapfile-linux ! makefiles/mapfiles/libnio/mapfile-macosx ! makefiles/mapfiles/libnio/mapfile-solaris ! makefiles/mapfiles/libnpt/mapfile-vers ! makefiles/mapfiles/libsctp/mapfile-vers ! makefiles/mapfiles/libsplashscreen/mapfile-vers ! makefiles/mapfiles/libsunec/mapfile-vers ! makefiles/mapfiles/libt2k/mapfile-vers ! makefiles/mapfiles/libunpack/mapfile-vers ! makefiles/mapfiles/libunpack/mapfile-vers-unpack200 ! makefiles/mapfiles/libverify/mapfile-vers ! makefiles/mapfiles/libzip/mapfile-vers ! makefiles/scripts/addNotices.sh ! makefiles/scripts/genCharsetProvider.sh ! makefiles/scripts/genExceptions.sh ! makefiles/scripts/localelist.sh ! makefiles/sun/xawt/ToBin.java ! src/bsd/doc/man/appletviewer.1 ! src/bsd/doc/man/apt.1 ! src/bsd/doc/man/extcheck.1 ! src/bsd/doc/man/idlj.1 ! src/bsd/doc/man/ja/appletviewer.1 ! src/bsd/doc/man/ja/apt.1 ! src/bsd/doc/man/ja/extcheck.1 ! src/bsd/doc/man/ja/idlj.1 ! src/bsd/doc/man/ja/jar.1 ! src/bsd/doc/man/ja/jarsigner.1 ! src/bsd/doc/man/ja/java.1 ! src/bsd/doc/man/ja/javac.1 ! src/bsd/doc/man/ja/javadoc.1 ! src/bsd/doc/man/ja/javah.1 ! src/bsd/doc/man/ja/javap.1 ! src/bsd/doc/man/ja/javaws.1 ! src/bsd/doc/man/ja/jconsole.1 ! src/bsd/doc/man/ja/jdb.1 ! src/bsd/doc/man/ja/jhat.1 ! src/bsd/doc/man/ja/jinfo.1 ! src/bsd/doc/man/ja/jmap.1 ! src/bsd/doc/man/ja/jps.1 ! src/bsd/doc/man/ja/jrunscript.1 ! src/bsd/doc/man/ja/jsadebugd.1 ! src/bsd/doc/man/ja/jstack.1 ! src/bsd/doc/man/ja/jstat.1 ! src/bsd/doc/man/ja/jstatd.1 ! src/bsd/doc/man/ja/keytool.1 ! src/bsd/doc/man/ja/native2ascii.1 ! src/bsd/doc/man/ja/orbd.1 ! src/bsd/doc/man/ja/pack200.1 ! src/bsd/doc/man/ja/policytool.1 ! src/bsd/doc/man/ja/rmic.1 ! src/bsd/doc/man/ja/rmid.1 ! src/bsd/doc/man/ja/rmiregistry.1 ! src/bsd/doc/man/ja/schemagen.1 ! src/bsd/doc/man/ja/serialver.1 ! src/bsd/doc/man/ja/servertool.1 ! src/bsd/doc/man/ja/tnameserv.1 ! src/bsd/doc/man/ja/unpack200.1 ! src/bsd/doc/man/ja/wsgen.1 ! src/bsd/doc/man/ja/wsimport.1 ! src/bsd/doc/man/ja/xjc.1 ! src/bsd/doc/man/jar.1 ! src/bsd/doc/man/java.1 ! src/bsd/doc/man/javac.1 ! src/bsd/doc/man/javah.1 ! src/bsd/doc/man/javap.1 ! src/bsd/doc/man/javaws.1 ! src/bsd/doc/man/jconsole.1 ! src/bsd/doc/man/jdb.1 ! src/bsd/doc/man/jhat.1 ! src/bsd/doc/man/jinfo.1 ! src/bsd/doc/man/jmap.1 ! src/bsd/doc/man/jps.1 ! src/bsd/doc/man/jrunscript.1 ! src/bsd/doc/man/jsadebugd.1 ! src/bsd/doc/man/jstack.1 ! src/bsd/doc/man/jstatd.1 ! src/bsd/doc/man/native2ascii.1 ! src/bsd/doc/man/orbd.1 ! src/bsd/doc/man/pack200.1 ! src/bsd/doc/man/policytool.1 ! src/bsd/doc/man/rmic.1 ! src/bsd/doc/man/rmid.1 ! src/bsd/doc/man/rmiregistry.1 ! src/bsd/doc/man/schemagen.1 ! src/bsd/doc/man/serialver.1 ! src/bsd/doc/man/servertool.1 ! src/bsd/doc/man/tnameserv.1 ! src/bsd/doc/man/unpack200.1 ! src/bsd/doc/man/xjc.1 ! src/linux/doc/man/jcmd.1 ! src/macosx/bundle/JavaAppLauncher/src/JVMArgs.h ! src/macosx/bundle/JavaAppLauncher/src/JVMArgs.m ! src/macosx/bundle/JavaAppLauncher/src/JavaAppLauncher.h ! src/macosx/bundle/JavaAppLauncher/src/JavaAppLauncher.m ! src/macosx/bundle/JavaAppLauncher/src/JavaAppLauncher_Prefix.pch ! src/macosx/bundle/JavaAppLauncher/src/main.m ! src/macosx/classes/apple/applescript/AppleScriptEngineFactory.java ! src/macosx/classes/apple/launcher/JavaAppLauncher.java ! src/macosx/classes/apple/security/AppleProvider.java ! src/macosx/classes/apple/security/KeychainStore.java ! src/macosx/classes/com/apple/concurrent/Dispatch.java ! src/macosx/classes/com/apple/concurrent/LibDispatchConcurrentQueue.java ! src/macosx/classes/com/apple/concurrent/LibDispatchMainQueue.java ! src/macosx/classes/com/apple/concurrent/LibDispatchNative.java ! src/macosx/classes/com/apple/concurrent/LibDispatchQueue.java ! src/macosx/classes/com/apple/concurrent/LibDispatchRetainedResource.java ! src/macosx/classes/com/apple/concurrent/LibDispatchSerialQueue.java ! src/macosx/classes/com/apple/eio/FileManager.java ! src/macosx/classes/com/apple/resources/MacOSXResourceBundle.java ! src/macosx/classes/java/net/DefaultInterface.java ! src/macosx/classes/java/util/prefs/MacOSXPreferences.java ! src/macosx/classes/java/util/prefs/MacOSXPreferencesFactory.java ! src/macosx/classes/java/util/prefs/MacOSXPreferencesFile.java ! src/macosx/classes/sun/nio/ch/DefaultSelectorProvider.java ! src/macosx/classes/sun/nio/ch/KQueueArrayWrapper.java ! src/macosx/classes/sun/nio/ch/KQueueSelectorImpl.java ! src/macosx/classes/sun/nio/ch/KQueueSelectorProvider.java ! src/macosx/native/apple/applescript/AS_NS_ConversionUtils.h ! src/macosx/native/apple/applescript/AS_NS_ConversionUtils.m ! src/macosx/native/apple/applescript/AppleScriptEngine.m ! src/macosx/native/apple/applescript/AppleScriptExecutionContext.h ! src/macosx/native/apple/applescript/AppleScriptExecutionContext.m ! src/macosx/native/apple/applescript/NS_Java_ConversionUtils.h ! src/macosx/native/apple/applescript/NS_Java_ConversionUtils.m ! src/macosx/native/apple/launcher/JavaAppLauncher.m ! src/macosx/native/com/apple/concurrent/Dispatch.m ! src/macosx/native/com/apple/eio/CFileManager.m ! src/macosx/native/com/apple/resources/MacOSXResourceBundle.m ! src/macosx/native/java/util/MacOSXPreferencesFile.m ! src/macosx/native/java/util/SCDynamicStoreConfig.m ! src/macosx/native/jobjc/JObjC.xcodeproj/default.pbxuser ! src/macosx/native/jobjc/README.txt ! src/macosx/native/jobjc/TODOS ! src/macosx/native/jobjc/bridgesupport.gmk ! src/macosx/native/jobjc/build.xml ! src/macosx/native/jobjc/extract_classes.pl ! src/macosx/native/jobjc/run-and-write-if-okay ! src/macosx/native/jobjc/rungen ! src/macosx/native/jobjc/runjava ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/CFType.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/CIF.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/Coder.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/FFIType.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/Function.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/ID.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/Invoke.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/JObjCRuntime.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/MacOSXFramework.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/NSClass.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/NativeArgumentBuffer.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/NativeBuffer.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/NativeObjectLifecycleManager.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/Opaque.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/Pointer.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/SEL.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/Struct.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/Subclassing.java ! src/macosx/native/jobjc/src/core/native/CIF.m ! src/macosx/native/jobjc/src/core/native/Coder.m ! src/macosx/native/jobjc/src/core/native/FFIType.m ! src/macosx/native/jobjc/src/core/native/Function.m ! src/macosx/native/jobjc/src/core/native/ID.m ! src/macosx/native/jobjc/src/core/native/Invoke.m ! src/macosx/native/jobjc/src/core/native/JObjCRuntime.m ! src/macosx/native/jobjc/src/core/native/MacOSXFramework.m ! src/macosx/native/jobjc/src/core/native/NSClass.m ! src/macosx/native/jobjc/src/core/native/NativeBuffer.h ! src/macosx/native/jobjc/src/core/native/NativeBuffer.m ! src/macosx/native/jobjc/src/core/native/NativeObjectLifecycleManager.m ! src/macosx/native/jobjc/src/core/native/SEL.m ! src/macosx/native/jobjc/src/core/native/Subclassing.m ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/BootClassPathMinus.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/ClassConsolidator.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/ClassGenerator.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/FileCopier.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/FrameworkGenerator.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/FunctionGenerator.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/Generator.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/MethodDisambiguator.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/RestrictedKeywords.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/Utils.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/classes/AbstractObjCClassFile.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/classes/CFTypeClassFile.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/classes/CategoryClassClassFile.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/classes/CategoryClassFile.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/classes/CopiedFile.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/classes/FrameworkClassFile.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/classes/GeneratedClassFile.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/classes/JObjCClassClassFile.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/classes/JObjCClassFile.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/classes/MixedPrimitiveCoderClassFile.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/classes/OpaqueClassFile.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/classes/OutputFile.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/classes/RootJObjCClass.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/classes/StructClassFile.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/Arg.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/CFType.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/Category.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/Clazz.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/Constant.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/Element.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/ElementWType.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/Framework.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/Function.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/FunctionAlias.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/InformalProtocol.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/Method.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/NativeEnum.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/Opaque.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/OutputFileGenerator.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/Protocol.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/ReturnValue.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/StringConstant.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/Struct.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/TypeElement.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/coders/CoderDescriptor.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/coders/ComplexCoderDescriptor.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/coders/PrimitiveCoderDescriptor.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/types/JType.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/types/NType.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/types/Type.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/types/TypeCache.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/types/TypeToJType.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/utils/Fp.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/utils/JavaLang.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/utils/NTypeMerger.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/utils/NTypeParser.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/utils/NTypePrinter.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/utils/ObjectInspector.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/utils/QA.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/utils/StringStream.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/utils/StructOffsetResolver.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/utils/StructOffsetResolverBigBang.java ! src/macosx/native/jobjc/src/generator/java/com/apple/jobjc/SuperClassExtractor.java ! src/macosx/native/jobjc/src/generator/java/com/apple/jobjc/UnsafeRuntimeAccess.java ! src/macosx/native/jobjc/src/runtime-additions/java/com/apple/jobjc/Utils.java ! src/macosx/native/jobjc/src/runtime-additions/native/NativeNumber.m ! src/macosx/native/jobjc/src/runtime-additions/native/NativeString.m ! src/macosx/native/jobjc/src/runtime-additions/native/NativeThread.m ! src/macosx/native/jobjc/src/tests/java/com/apple/jobjc/BaseBench.java ! src/macosx/native/jobjc/src/tests/java/com/apple/jobjc/BenchFunCall.java ! src/macosx/native/jobjc/src/tests/java/com/apple/jobjc/BenchIDPop.java ! src/macosx/native/jobjc/src/tests/java/com/apple/jobjc/BenchStructCoding.java ! src/macosx/native/jobjc/src/tests/java/com/apple/jobjc/BenchUnsafe.java ! src/macosx/native/jobjc/src/tests/java/com/apple/jobjc/CategoryTest.java ! src/macosx/native/jobjc/src/tests/java/com/apple/jobjc/FunctionTest.java ! src/macosx/native/jobjc/src/tests/java/com/apple/jobjc/GUIDemo.java ! src/macosx/native/jobjc/src/tests/java/com/apple/jobjc/IBDemo.java ! src/macosx/native/jobjc/src/tests/java/com/apple/jobjc/IntroTest.java ! src/macosx/native/jobjc/src/tests/java/com/apple/jobjc/NSClassTest.java ! src/macosx/native/jobjc/src/tests/java/com/apple/jobjc/NativeBufferTest.java ! src/macosx/native/jobjc/src/tests/java/com/apple/jobjc/NativeTypeTest.java ! src/macosx/native/jobjc/src/tests/java/com/apple/jobjc/PooledTestCase.java ! src/macosx/native/jobjc/src/tests/java/com/apple/jobjc/SELTest.java ! src/macosx/native/jobjc/src/tests/java/com/apple/jobjc/StructTest.java ! src/macosx/native/jobjc/src/tests/java/com/apple/jobjc/SubclassingTest.java ! src/macosx/native/jobjc/src/tests/java/com/apple/jobjc/TestUtils.java ! src/macosx/native/jobjc/src/tests/java/com/apple/jobjc/UtilsTest.java ! src/macosx/native/jobjc/src/tests/java/com/apple/jobjc/VarArgsTest.java ! src/macosx/native/jobjc/src/tests/native/FunCallBench.m ! src/macosx/native/sun/nio/ch/KQueueArrayWrapper.c ! src/macosx/native/sun/osxapp/AWT_debug.h ! src/macosx/native/sun/osxapp/NSApplicationAWT.h ! src/macosx/native/sun/osxapp/NSApplicationAWT.m ! src/macosx/native/sun/osxapp/PropertiesUtilities.h ! src/macosx/native/sun/osxapp/PropertiesUtilities.m ! src/macosx/native/sun/osxapp/QueuingApplicationDelegate.h ! src/macosx/native/sun/osxapp/QueuingApplicationDelegate.m ! src/macosx/native/sun/osxapp/ThreadUtilities.h ! src/macosx/native/sun/osxapp/ThreadUtilities.m ! src/share/back/commonRef.c ! src/share/back/error_messages.h ! src/share/back/log_messages.h ! src/share/bin/emessages.h ! src/share/classes/com/sun/crypto/provider/PBEKey.java ! src/share/classes/com/sun/crypto/provider/PKCS12PBECipherCore.java ! src/share/classes/com/sun/imageio/plugins/jpeg/JFIFMarkerSegment.java ! src/share/classes/com/sun/imageio/plugins/jpeg/JPEGImageReader.java ! src/share/classes/com/sun/imageio/plugins/jpeg/JPEGImageWriter.java ! src/share/classes/com/sun/java/util/jar/pack/NativeUnpack.java ! src/share/classes/com/sun/java/util/jar/pack/package.html ! src/share/classes/com/sun/jdi/AbsentInformationException.java ! src/share/classes/com/sun/jdi/Accessible.java ! src/share/classes/com/sun/jdi/ArrayType.java ! src/share/classes/com/sun/jdi/ClassLoaderReference.java ! src/share/classes/com/sun/jdi/ClassNotLoadedException.java ! src/share/classes/com/sun/jdi/ClassNotPreparedException.java ! src/share/classes/com/sun/jdi/ClassType.java ! src/share/classes/com/sun/jdi/IncompatibleThreadStateException.java ! src/share/classes/com/sun/jdi/InconsistentDebugInfoException.java ! src/share/classes/com/sun/jdi/InternalException.java ! src/share/classes/com/sun/jdi/InvalidCodeIndexException.java ! src/share/classes/com/sun/jdi/InvalidLineNumberException.java ! src/share/classes/com/sun/jdi/InvalidStackFrameException.java ! src/share/classes/com/sun/jdi/InvalidTypeException.java ! src/share/classes/com/sun/jdi/InvocationException.java ! src/share/classes/com/sun/jdi/JDIPermission.java ! src/share/classes/com/sun/jdi/LocalVariable.java ! src/share/classes/com/sun/jdi/Method.java ! src/share/classes/com/sun/jdi/NativeMethodException.java ! src/share/classes/com/sun/jdi/ObjectCollectedException.java ! src/share/classes/com/sun/jdi/ObjectReference.java ! src/share/classes/com/sun/jdi/ReferenceType.java ! src/share/classes/com/sun/jdi/TypeComponent.java ! src/share/classes/com/sun/jdi/VMCannotBeModifiedException.java ! src/share/classes/com/sun/jdi/VMDisconnectedException.java ! src/share/classes/com/sun/jdi/VMMismatchException.java ! src/share/classes/com/sun/jdi/VMOutOfMemoryException.java ! src/share/classes/com/sun/jdi/connect/IllegalConnectorArgumentsException.java ! src/share/classes/com/sun/jdi/connect/TransportTimeoutException.java ! src/share/classes/com/sun/jdi/connect/VMStartException.java ! src/share/classes/com/sun/jdi/connect/spi/ClosedConnectionException.java ! src/share/classes/com/sun/jdi/request/DuplicateRequestException.java ! src/share/classes/com/sun/jdi/request/InvalidRequestStateException.java ! src/share/classes/com/sun/jmx/mbeanserver/DefaultMXBeanMappingFactory.java ! src/share/classes/com/sun/jmx/mbeanserver/MXBeanMapping.java ! src/share/classes/com/sun/jmx/remote/internal/IIOPHelper.java ! src/share/classes/com/sun/jmx/remote/internal/ServerNotifForwarder.java ! src/share/classes/com/sun/jmx/remote/util/EnvHelp.java ! src/share/classes/com/sun/jmx/snmp/SnmpCounter64.java ! src/share/classes/com/sun/jmx/snmp/SnmpInt.java ! src/share/classes/com/sun/jmx/snmp/SnmpNull.java ! src/share/classes/com/sun/jmx/snmp/SnmpString.java ! src/share/classes/com/sun/jmx/snmp/agent/AcmChecker.java ! src/share/classes/com/sun/jmx/snmp/agent/LongList.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpMib.java ! src/share/classes/com/sun/jmx/snmp/daemon/SnmpRequestHandler.java ! src/share/classes/com/sun/jndi/toolkit/url/UrlUtil.java ! src/share/classes/com/sun/management/OperatingSystemMXBean.java ! src/share/classes/com/sun/management/VMOption.java ! src/share/classes/com/sun/net/httpserver/spi/HttpServerProvider.java ! src/share/classes/com/sun/net/ssl/internal/www/protocol/https/DelegateHttpsURLConnection.java ! src/share/classes/com/sun/nio/sctp/MessageInfo.java ! src/share/classes/com/sun/nio/sctp/SctpChannel.java ! src/share/classes/com/sun/nio/sctp/SctpMultiChannel.java ! src/share/classes/com/sun/nio/sctp/SctpServerChannel.java ! src/share/classes/com/sun/nio/sctp/SctpSocketOption.java ! src/share/classes/com/sun/nio/sctp/SctpStandardSocketOptions.java ! src/share/classes/com/sun/rmi/rmid/ExecOptionPermission.java ! src/share/classes/com/sun/rmi/rmid/ExecPermission.java ! src/share/classes/com/sun/rowset/JdbcRowSetResourceBundle.java ! src/share/classes/com/sun/rowset/JoinRowSetImpl.java ! src/share/classes/com/sun/rowset/internal/CachedRowSetReader.java ! src/share/classes/com/sun/rowset/internal/SyncResolverImpl.java ! src/share/classes/com/sun/rowset/internal/XmlReaderContentHandler.java ! src/share/classes/com/sun/security/auth/callback/DialogCallbackHandler.java ! src/share/classes/com/sun/security/auth/module/Krb5LoginModule.java ! src/share/classes/com/sun/security/ntlm/Client.java ! src/share/classes/com/sun/security/ntlm/NTLM.java ! src/share/classes/com/sun/security/ntlm/Server.java ! src/share/classes/com/sun/security/sasl/CramMD5Server.java ! src/share/classes/com/sun/security/sasl/digest/DigestMD5Base.java ! src/share/classes/com/sun/security/sasl/digest/DigestMD5Server.java ! src/share/classes/com/sun/security/sasl/gsskerb/GssKrb5Server.java ! src/share/classes/com/sun/security/sasl/ntlm/FactoryImpl.java ! src/share/classes/com/sun/security/sasl/ntlm/NTLMServer.java ! src/share/classes/com/sun/security/sasl/util/AbstractSaslImpl.java ! src/share/classes/com/sun/servicetag/BrowserSupport.java ! src/share/classes/com/sun/servicetag/Installer.java ! src/share/classes/com/sun/servicetag/RegistrationDocument.java ! src/share/classes/com/sun/servicetag/SunConnection.java ! src/share/classes/com/sun/tools/example/debug/bdi/AccessWatchpointSpec.java ! src/share/classes/com/sun/tools/example/debug/bdi/AmbiguousMethodException.java ! src/share/classes/com/sun/tools/example/debug/bdi/BreakpointSpec.java ! src/share/classes/com/sun/tools/example/debug/bdi/ChildSession.java ! src/share/classes/com/sun/tools/example/debug/bdi/EvaluationException.java ! src/share/classes/com/sun/tools/example/debug/bdi/EventRequestSpec.java ! src/share/classes/com/sun/tools/example/debug/bdi/EventRequestSpecList.java ! src/share/classes/com/sun/tools/example/debug/bdi/ExceptionSpec.java ! src/share/classes/com/sun/tools/example/debug/bdi/ExecutionManager.java ! src/share/classes/com/sun/tools/example/debug/bdi/FrameIndexOutOfBoundsException.java ! src/share/classes/com/sun/tools/example/debug/bdi/InputListener.java ! src/share/classes/com/sun/tools/example/debug/bdi/JDIEventSource.java ! src/share/classes/com/sun/tools/example/debug/bdi/LineBreakpointSpec.java ! src/share/classes/com/sun/tools/example/debug/bdi/LineNotFoundException.java ! src/share/classes/com/sun/tools/example/debug/bdi/MalformedMemberNameException.java ! src/share/classes/com/sun/tools/example/debug/bdi/MethodBreakpointSpec.java ! src/share/classes/com/sun/tools/example/debug/bdi/MethodNotFoundException.java ! src/share/classes/com/sun/tools/example/debug/bdi/ModificationWatchpointSpec.java ! src/share/classes/com/sun/tools/example/debug/bdi/NoSessionException.java ! src/share/classes/com/sun/tools/example/debug/bdi/NoThreadException.java ! src/share/classes/com/sun/tools/example/debug/bdi/OutputListener.java ! src/share/classes/com/sun/tools/example/debug/bdi/ParseException.java ! src/share/classes/com/sun/tools/example/debug/bdi/PatternReferenceTypeSpec.java ! src/share/classes/com/sun/tools/example/debug/bdi/ReferenceTypeSpec.java ! src/share/classes/com/sun/tools/example/debug/bdi/Session.java ! src/share/classes/com/sun/tools/example/debug/bdi/SessionListener.java ! src/share/classes/com/sun/tools/example/debug/bdi/SourceNameReferenceTypeSpec.java ! src/share/classes/com/sun/tools/example/debug/bdi/SpecErrorEvent.java ! src/share/classes/com/sun/tools/example/debug/bdi/SpecEvent.java ! src/share/classes/com/sun/tools/example/debug/bdi/SpecListener.java ! src/share/classes/com/sun/tools/example/debug/bdi/ThreadGroupIterator.java ! src/share/classes/com/sun/tools/example/debug/bdi/ThreadInfo.java ! src/share/classes/com/sun/tools/example/debug/bdi/ThreadIterator.java ! src/share/classes/com/sun/tools/example/debug/bdi/Utils.java ! src/share/classes/com/sun/tools/example/debug/bdi/VMLaunchFailureException.java ! src/share/classes/com/sun/tools/example/debug/bdi/VMNotInterruptedException.java ! src/share/classes/com/sun/tools/example/debug/bdi/WatchpointSpec.java ! src/share/classes/com/sun/tools/example/debug/event/AbstractEventSet.java ! src/share/classes/com/sun/tools/example/debug/event/AccessWatchpointEventSet.java ! src/share/classes/com/sun/tools/example/debug/event/ClassPrepareEventSet.java ! src/share/classes/com/sun/tools/example/debug/event/ClassUnloadEventSet.java ! src/share/classes/com/sun/tools/example/debug/event/ExceptionEventSet.java ! src/share/classes/com/sun/tools/example/debug/event/JDIAdapter.java ! src/share/classes/com/sun/tools/example/debug/event/JDIListener.java ! src/share/classes/com/sun/tools/example/debug/event/LocatableEventSet.java ! src/share/classes/com/sun/tools/example/debug/event/LocationTriggerEventSet.java ! src/share/classes/com/sun/tools/example/debug/event/ModificationWatchpointEventSet.java ! src/share/classes/com/sun/tools/example/debug/event/ThreadDeathEventSet.java ! src/share/classes/com/sun/tools/example/debug/event/ThreadStartEventSet.java ! src/share/classes/com/sun/tools/example/debug/event/VMDeathEventSet.java ! src/share/classes/com/sun/tools/example/debug/event/VMDisconnectEventSet.java ! src/share/classes/com/sun/tools/example/debug/event/VMStartEventSet.java ! src/share/classes/com/sun/tools/example/debug/event/WatchpointEventSet.java ! src/share/classes/com/sun/tools/example/debug/expr/ASCII_UCodeESC_CharStream.java ! src/share/classes/com/sun/tools/example/debug/expr/ExpressionParser.java ! src/share/classes/com/sun/tools/example/debug/expr/ExpressionParserConstants.java ! src/share/classes/com/sun/tools/example/debug/expr/ExpressionParserTokenManager.java ! src/share/classes/com/sun/tools/example/debug/expr/LValue.java ! src/share/classes/com/sun/tools/example/debug/expr/ParseException.java ! src/share/classes/com/sun/tools/example/debug/expr/Token.java ! src/share/classes/com/sun/tools/example/debug/expr/TokenMgrError.java ! src/share/classes/com/sun/tools/example/debug/gui/ApplicationTool.java ! src/share/classes/com/sun/tools/example/debug/gui/ClassManager.java ! src/share/classes/com/sun/tools/example/debug/gui/ClassTreeTool.java ! src/share/classes/com/sun/tools/example/debug/gui/CommandInterpreter.java ! src/share/classes/com/sun/tools/example/debug/gui/CommandTool.java ! src/share/classes/com/sun/tools/example/debug/gui/ContextListener.java ! src/share/classes/com/sun/tools/example/debug/gui/ContextManager.java ! src/share/classes/com/sun/tools/example/debug/gui/CurrentFrameChangedEvent.java ! src/share/classes/com/sun/tools/example/debug/gui/Environment.java ! src/share/classes/com/sun/tools/example/debug/gui/GUI.java ! src/share/classes/com/sun/tools/example/debug/gui/Icons.java ! src/share/classes/com/sun/tools/example/debug/gui/JDBFileFilter.java ! src/share/classes/com/sun/tools/example/debug/gui/JDBMenuBar.java ! src/share/classes/com/sun/tools/example/debug/gui/JDBToolBar.java ! src/share/classes/com/sun/tools/example/debug/gui/LaunchTool.java ! src/share/classes/com/sun/tools/example/debug/gui/MonitorListModel.java ! src/share/classes/com/sun/tools/example/debug/gui/MonitorTool.java ! src/share/classes/com/sun/tools/example/debug/gui/OutputSink.java ! src/share/classes/com/sun/tools/example/debug/gui/SearchPath.java ! src/share/classes/com/sun/tools/example/debug/gui/SingleLeafTreeSelectionModel.java ! src/share/classes/com/sun/tools/example/debug/gui/SourceListener.java ! src/share/classes/com/sun/tools/example/debug/gui/SourceManager.java ! src/share/classes/com/sun/tools/example/debug/gui/SourceModel.java ! src/share/classes/com/sun/tools/example/debug/gui/SourceTool.java ! src/share/classes/com/sun/tools/example/debug/gui/SourceTreeTool.java ! src/share/classes/com/sun/tools/example/debug/gui/SourcepathChangedEvent.java ! src/share/classes/com/sun/tools/example/debug/gui/StackTraceTool.java ! src/share/classes/com/sun/tools/example/debug/gui/ThreadTreeTool.java ! src/share/classes/com/sun/tools/example/debug/gui/TypeScript.java ! src/share/classes/com/sun/tools/example/debug/gui/TypeScriptOutputListener.java ! src/share/classes/com/sun/tools/example/debug/gui/TypeScriptWriter.java ! src/share/classes/com/sun/tools/example/debug/tty/AccessWatchpointSpec.java ! src/share/classes/com/sun/tools/example/debug/tty/AmbiguousMethodException.java ! src/share/classes/com/sun/tools/example/debug/tty/BreakpointSpec.java ! src/share/classes/com/sun/tools/example/debug/tty/Commands.java ! src/share/classes/com/sun/tools/example/debug/tty/Env.java ! src/share/classes/com/sun/tools/example/debug/tty/EventHandler.java ! src/share/classes/com/sun/tools/example/debug/tty/EventNotifier.java ! src/share/classes/com/sun/tools/example/debug/tty/EventRequestSpec.java ! src/share/classes/com/sun/tools/example/debug/tty/EventRequestSpecList.java ! src/share/classes/com/sun/tools/example/debug/tty/ExceptionSpec.java ! src/share/classes/com/sun/tools/example/debug/tty/LineNotFoundException.java ! src/share/classes/com/sun/tools/example/debug/tty/MalformedMemberNameException.java ! src/share/classes/com/sun/tools/example/debug/tty/MessageOutput.java ! src/share/classes/com/sun/tools/example/debug/tty/ModificationWatchpointSpec.java ! src/share/classes/com/sun/tools/example/debug/tty/PatternReferenceTypeSpec.java ! src/share/classes/com/sun/tools/example/debug/tty/ReferenceTypeSpec.java ! src/share/classes/com/sun/tools/example/debug/tty/SourceMapper.java ! src/share/classes/com/sun/tools/example/debug/tty/TTY.java ! src/share/classes/com/sun/tools/example/debug/tty/TTYResources.java ! src/share/classes/com/sun/tools/example/debug/tty/ThreadGroupIterator.java ! src/share/classes/com/sun/tools/example/debug/tty/ThreadInfo.java ! src/share/classes/com/sun/tools/example/debug/tty/ThreadIterator.java ! src/share/classes/com/sun/tools/example/debug/tty/VMConnection.java ! src/share/classes/com/sun/tools/example/debug/tty/VMNotConnectedException.java ! src/share/classes/com/sun/tools/example/debug/tty/WatchpointSpec.java ! src/share/classes/com/sun/tools/example/trace/EventThread.java ! src/share/classes/com/sun/tools/example/trace/StreamRedirectThread.java ! src/share/classes/com/sun/tools/example/trace/Trace.java ! src/share/classes/com/sun/tools/jdi/ArrayReferenceImpl.java ! src/share/classes/com/sun/tools/jdi/ArrayTypeImpl.java ! src/share/classes/com/sun/tools/jdi/BooleanValueImpl.java ! src/share/classes/com/sun/tools/jdi/CharValueImpl.java ! src/share/classes/com/sun/tools/jdi/ClassLoaderReferenceImpl.java ! src/share/classes/com/sun/tools/jdi/ClassTypeImpl.java ! src/share/classes/com/sun/tools/jdi/ConcreteMethodImpl.java ! src/share/classes/com/sun/tools/jdi/ConnectorImpl.java ! src/share/classes/com/sun/tools/jdi/DoubleValueImpl.java ! src/share/classes/com/sun/tools/jdi/EventRequestManagerImpl.java ! src/share/classes/com/sun/tools/jdi/EventSetImpl.java ! src/share/classes/com/sun/tools/jdi/FloatValueImpl.java ! src/share/classes/com/sun/tools/jdi/GenericAttachingConnector.java ! src/share/classes/com/sun/tools/jdi/IntegerValueImpl.java ! src/share/classes/com/sun/tools/jdi/InterfaceTypeImpl.java ! src/share/classes/com/sun/tools/jdi/InternalEventHandler.java ! src/share/classes/com/sun/tools/jdi/JDWPException.java ! src/share/classes/com/sun/tools/jdi/LongValueImpl.java ! src/share/classes/com/sun/tools/jdi/MethodImpl.java ! src/share/classes/com/sun/tools/jdi/MirrorImpl.java ! src/share/classes/com/sun/tools/jdi/ObjectReferenceImpl.java ! src/share/classes/com/sun/tools/jdi/ProcessAttachingConnector.java ! src/share/classes/com/sun/tools/jdi/RawCommandLineLauncher.java ! src/share/classes/com/sun/tools/jdi/ReferenceTypeImpl.java ! src/share/classes/com/sun/tools/jdi/ShortValueImpl.java ! src/share/classes/com/sun/tools/jdi/SunCommandLineLauncher.java ! src/share/classes/com/sun/tools/jdi/TargetVM.java ! src/share/classes/com/sun/tools/jdi/ThreadAction.java ! src/share/classes/com/sun/tools/jdi/ThreadGroupReferenceImpl.java ! src/share/classes/com/sun/tools/jdi/ThreadReferenceImpl.java ! src/share/classes/com/sun/tools/jdi/VMAction.java ! src/share/classes/com/sun/tools/jdi/VMState.java ! src/share/classes/com/sun/tools/jdi/VirtualMachineImpl.java ! src/share/classes/java/applet/Applet.java ! src/share/classes/java/io/Closeable.java ! src/share/classes/java/io/ExpiringCache.java ! src/share/classes/java/io/InputStream.java ! src/share/classes/java/io/LineNumberReader.java ! src/share/classes/java/io/ObjectInputStream.java ! src/share/classes/java/io/PrintWriter.java ! src/share/classes/java/io/Reader.java ! src/share/classes/java/io/SequenceInputStream.java ! src/share/classes/java/io/Writer.java ! src/share/classes/java/lang/AssertionError.java ! src/share/classes/java/lang/CharSequence.java ! src/share/classes/java/lang/CharacterData.java ! src/share/classes/java/lang/CharacterName.java ! src/share/classes/java/lang/Class.java ! src/share/classes/java/lang/ClassValue.java ! src/share/classes/java/lang/ConditionalSpecialCasing.java ! src/share/classes/java/lang/Enum.java ! src/share/classes/java/lang/EnumConstantNotPresentException.java ! src/share/classes/java/lang/InheritableThreadLocal.java ! src/share/classes/java/lang/Math.java ! src/share/classes/java/lang/Object.java ! src/share/classes/java/lang/Override.java ! src/share/classes/java/lang/Package.java ! src/share/classes/java/lang/ProcessBuilder.java ! src/share/classes/java/lang/Runtime.java ! src/share/classes/java/lang/SecurityManager.java ! src/share/classes/java/lang/StrictMath.java ! src/share/classes/java/lang/StringBuilder.java ! src/share/classes/java/lang/StringCoding.java ! src/share/classes/java/lang/System.java ! src/share/classes/java/lang/Thread.java ! src/share/classes/java/lang/ThreadGroup.java ! src/share/classes/java/lang/ThreadLocal.java ! src/share/classes/java/lang/Throwable.java ! src/share/classes/java/lang/Void.java ! src/share/classes/java/lang/annotation/Annotation.java ! src/share/classes/java/lang/instrument/ClassDefinition.java ! src/share/classes/java/lang/instrument/ClassFileTransformer.java ! src/share/classes/java/lang/instrument/Instrumentation.java ! src/share/classes/java/lang/invoke/CallSite.java ! src/share/classes/java/lang/invoke/DirectMethodHandle.java ! src/share/classes/java/lang/invoke/Invokers.java ! src/share/classes/java/lang/invoke/MemberName.java ! src/share/classes/java/lang/invoke/MethodHandle.java ! src/share/classes/java/lang/invoke/MethodHandleProxies.java ! src/share/classes/java/lang/invoke/MethodTypeForm.java ! src/share/classes/java/lang/invoke/SimpleMethodHandle.java ! src/share/classes/java/lang/invoke/WrongMethodTypeException.java ! src/share/classes/java/lang/invoke/package-info.java ! src/share/classes/java/lang/management/BufferPoolMXBean.java ! src/share/classes/java/lang/management/LockInfo.java ! src/share/classes/java/lang/management/ManagementPermission.java ! src/share/classes/java/lang/management/PlatformComponent.java ! src/share/classes/java/lang/management/PlatformLoggingMXBean.java ! src/share/classes/java/lang/management/PlatformManagedObject.java ! src/share/classes/java/lang/management/ThreadInfo.java ! src/share/classes/java/lang/management/package.html ! src/share/classes/java/lang/ref/Reference.java ! src/share/classes/java/lang/reflect/AccessibleObject.java ! src/share/classes/java/lang/reflect/Array.java ! src/share/classes/java/lang/reflect/Constructor.java ! src/share/classes/java/lang/reflect/Executable.java ! src/share/classes/java/lang/reflect/Field.java ! src/share/classes/java/lang/reflect/GenericDeclaration.java ! src/share/classes/java/lang/reflect/Method.java ! src/share/classes/java/lang/reflect/Modifier.java ! src/share/classes/java/lang/reflect/Proxy.java ! src/share/classes/java/lang/reflect/TypeVariable.java ! src/share/classes/java/net/AbstractPlainSocketImpl.java ! src/share/classes/java/net/ContentHandler.java ! src/share/classes/java/net/CookieManager.java ! src/share/classes/java/net/DatagramPacket.java ! src/share/classes/java/net/DatagramSocket.java ! src/share/classes/java/net/InMemoryCookieStore.java ! src/share/classes/java/net/Inet4Address.java ! src/share/classes/java/net/InetAddress.java ! src/share/classes/java/net/MulticastSocket.java ! src/share/classes/java/net/NetworkInterface.java ! src/share/classes/java/net/ProxySelector.java ! src/share/classes/java/net/ServerSocket.java ! src/share/classes/java/net/SocketImpl.java ! src/share/classes/java/net/SocketInputStream.java ! src/share/classes/java/net/SocketOption.java ! src/share/classes/java/net/SocketPermission.java ! src/share/classes/java/net/SocksSocketImpl.java ! src/share/classes/java/net/StandardSocketOptions.java ! src/share/classes/java/net/URL.java ! src/share/classes/java/net/URLConnection.java ! src/share/classes/java/net/URLStreamHandler.java ! src/share/classes/java/net/package.html ! src/share/classes/java/nio/MappedByteBuffer.java ! src/share/classes/java/nio/X-Buffer.java.template ! src/share/classes/java/nio/channels/AsynchronousFileChannel.java ! src/share/classes/java/nio/channels/AsynchronousServerSocketChannel.java ! src/share/classes/java/nio/channels/AsynchronousSocketChannel.java ! src/share/classes/java/nio/channels/Channels.java ! src/share/classes/java/nio/channels/DatagramChannel.java ! src/share/classes/java/nio/channels/FileChannel.java ! src/share/classes/java/nio/channels/MulticastChannel.java ! src/share/classes/java/nio/channels/NetworkChannel.java ! src/share/classes/java/nio/channels/ServerSocketChannel.java ! src/share/classes/java/nio/channels/spi/AbstractSelectableChannel.java ! src/share/classes/java/nio/file/FileSystem.java ! src/share/classes/java/nio/file/FileTreeWalker.java ! src/share/classes/java/nio/file/Files.java ! src/share/classes/java/nio/file/StandardWatchEventKinds.java ! src/share/classes/java/nio/file/Watchable.java ! src/share/classes/java/nio/file/attribute/AclFileAttributeView.java ! src/share/classes/java/nio/file/attribute/FileTime.java ! src/share/classes/java/rmi/MarshalledObject.java ! src/share/classes/java/rmi/dgc/VMID.java ! src/share/classes/java/rmi/server/LogStream.java ! src/share/classes/java/rmi/server/RemoteObject.java ! src/share/classes/java/security/AllPermission.java ! src/share/classes/java/security/BasicPermission.java ! src/share/classes/java/security/KeyRep.java ! src/share/classes/java/security/KeyStore.java ! src/share/classes/java/security/cert/Certificate.java ! src/share/classes/java/security/cert/CollectionCertStoreParameters.java ! src/share/classes/java/security/cert/LDAPCertStoreParameters.java ! src/share/classes/java/security/cert/PKIXCertPathValidatorResult.java ! src/share/classes/java/security/cert/PKIXParameters.java ! src/share/classes/java/security/cert/X509CRL.java ! src/share/classes/java/security/cert/X509Certificate.java ! src/share/classes/java/sql/CallableStatement.java ! src/share/classes/java/sql/Date.java ! src/share/classes/java/sql/PreparedStatement.java ! src/share/classes/java/sql/ResultSet.java ! src/share/classes/java/sql/SQLPermission.java ! src/share/classes/java/sql/Statement.java ! src/share/classes/java/sql/Time.java ! src/share/classes/java/text/AttributedCharacterIterator.java ! src/share/classes/java/text/AttributedString.java ! src/share/classes/java/text/BreakIterator.java ! src/share/classes/java/text/CharacterIteratorFieldDelegate.java ! src/share/classes/java/text/ChoiceFormat.java ! src/share/classes/java/text/CollationElementIterator.java ! src/share/classes/java/text/DateFormat.java ! src/share/classes/java/text/DigitList.java ! src/share/classes/java/text/Format.java ! src/share/classes/java/text/MergeCollation.java ! src/share/classes/java/text/MessageFormat.java ! src/share/classes/java/text/ParseException.java ! src/share/classes/java/text/RBCollationTables.java ! src/share/classes/java/text/RBTableBuilder.java ! src/share/classes/java/text/StringCharacterIterator.java ! src/share/classes/java/util/AbstractCollection.java ! src/share/classes/java/util/AbstractList.java ! src/share/classes/java/util/AbstractMap.java ! src/share/classes/java/util/AbstractSet.java ! src/share/classes/java/util/ArrayList.java ! src/share/classes/java/util/BitSet.java ! src/share/classes/java/util/Calendar.java ! src/share/classes/java/util/Collection.java ! src/share/classes/java/util/EnumMap.java ! src/share/classes/java/util/EnumSet.java ! src/share/classes/java/util/Formatter.java ! src/share/classes/java/util/HashSet.java ! src/share/classes/java/util/Hashtable.java ! src/share/classes/java/util/IdentityHashMap.java ! src/share/classes/java/util/IllegalFormatConversionException.java ! src/share/classes/java/util/InvalidPropertiesFormatException.java ! src/share/classes/java/util/LinkedHashMap.java ! src/share/classes/java/util/List.java ! src/share/classes/java/util/ListIterator.java ! src/share/classes/java/util/Map.java ! src/share/classes/java/util/Observable.java ! src/share/classes/java/util/PropertyPermission.java ! src/share/classes/java/util/Random.java ! src/share/classes/java/util/RegularEnumSet.java ! src/share/classes/java/util/Scanner.java ! src/share/classes/java/util/Set.java ! src/share/classes/java/util/SortedMap.java ! src/share/classes/java/util/TreeMap.java ! src/share/classes/java/util/TreeSet.java ! src/share/classes/java/util/UUID.java ! src/share/classes/java/util/WeakHashMap.java ! src/share/classes/java/util/concurrent/CopyOnWriteArrayList.java ! src/share/classes/java/util/jar/Attributes.java ! src/share/classes/java/util/logging/Handler.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/LoggingMXBean.java ! src/share/classes/java/util/logging/LoggingProxyImpl.java ! src/share/classes/java/util/logging/SimpleFormatter.java ! src/share/classes/java/util/prefs/AbstractPreferences.java ! src/share/classes/java/util/prefs/XmlSupport.java ! src/share/classes/java/util/regex/Matcher.java ! src/share/classes/java/util/regex/Pattern.java ! src/share/classes/java/util/spi/CurrencyNameProvider.java ! src/share/classes/java/util/zip/Adler32.java ! src/share/classes/java/util/zip/CRC32.java ! src/share/classes/java/util/zip/Deflater.java ! src/share/classes/java/util/zip/DeflaterOutputStream.java ! src/share/classes/java/util/zip/GZIPInputStream.java ! src/share/classes/java/util/zip/Inflater.java ! src/share/classes/java/util/zip/ZipCoder.java ! src/share/classes/java/util/zip/ZipOutputStream.java ! src/share/classes/javax/accessibility/AccessibleContext.java ! src/share/classes/javax/crypto/CryptoAllPermission.java ! src/share/classes/javax/crypto/CryptoPermission.java ! src/share/classes/javax/crypto/CryptoPolicyParser.java ! src/share/classes/javax/crypto/NullCipherSpi.java ! src/share/classes/javax/imageio/metadata/IIOMetadataNode.java ! src/share/classes/javax/imageio/metadata/doc-files/jpeg_metadata.html ! src/share/classes/javax/management/modelmbean/DescriptorSupport.java ! src/share/classes/javax/management/modelmbean/ModelMBeanAttributeInfo.java ! src/share/classes/javax/management/openmbean/CompositeDataInvocationHandler.java ! src/share/classes/javax/management/openmbean/TabularDataSupport.java ! src/share/classes/javax/management/remote/rmi/RMIConnector.java ! src/share/classes/javax/management/remote/rmi/RMIConnectorServer.java ! src/share/classes/javax/management/timer/Timer.java ! src/share/classes/javax/management/timer/TimerAlarmClock.java ! src/share/classes/javax/naming/spi/NamingManager.java ! src/share/classes/javax/net/ssl/SSLContext.java ! src/share/classes/javax/print/attribute/standard/PrinterStateReasons.java ! src/share/classes/javax/print/attribute/standard/ReferenceUriSchemesSupported.java ! src/share/classes/javax/script/ScriptEngineManager.java ! src/share/classes/javax/script/ScriptException.java ! src/share/classes/javax/security/auth/Subject.java ! src/share/classes/javax/security/auth/kerberos/DelegationPermission.java ! src/share/classes/javax/security/auth/kerberos/KerberosPrincipal.java ! src/share/classes/javax/security/auth/kerberos/ServicePermission.java ! src/share/classes/javax/security/auth/login/LoginContext.java ! src/share/classes/javax/security/cert/CertificateEncodingException.java ! src/share/classes/javax/security/cert/CertificateException.java ! src/share/classes/javax/security/cert/CertificateExpiredException.java ! src/share/classes/javax/security/cert/CertificateNotYetValidException.java ! src/share/classes/javax/security/cert/X509Certificate.java ! src/share/classes/javax/security/sasl/Sasl.java ! src/share/classes/javax/security/sasl/SaslServerFactory.java ! src/share/classes/javax/smartcardio/TerminalFactory.java ! src/share/classes/javax/sql/ConnectionPoolDataSource.java ! src/share/classes/javax/sql/PooledConnection.java ! src/share/classes/javax/sql/StatementEvent.java ! src/share/classes/javax/sql/rowset/RowSetMetaDataImpl.java ! src/share/classes/javax/sql/rowset/RowSetProvider.java ! src/share/classes/javax/sql/rowset/package.html ! src/share/classes/javax/sql/rowset/serial/SerialArray.java ! src/share/classes/javax/sql/rowset/serial/SerialRef.java ! src/share/classes/javax/sql/rowset/spi/SyncProvider.java ! src/share/classes/javax/xml/crypto/NodeSetData.java ! src/share/classes/javax/xml/crypto/dom/DOMCryptoContext.java ! src/share/classes/javax/xml/crypto/dsig/Manifest.java ! src/share/classes/javax/xml/crypto/dsig/Reference.java ! src/share/classes/javax/xml/crypto/dsig/SignatureProperties.java ! src/share/classes/javax/xml/crypto/dsig/SignatureProperty.java ! src/share/classes/javax/xml/crypto/dsig/SignedInfo.java ! src/share/classes/javax/xml/crypto/dsig/TransformService.java ! src/share/classes/javax/xml/crypto/dsig/XMLObject.java ! src/share/classes/javax/xml/crypto/dsig/XMLSignature.java ! src/share/classes/javax/xml/crypto/dsig/XMLSignatureFactory.java ! src/share/classes/javax/xml/crypto/dsig/keyinfo/KeyInfo.java ! src/share/classes/javax/xml/crypto/dsig/keyinfo/KeyInfoFactory.java ! src/share/classes/javax/xml/crypto/dsig/keyinfo/PGPData.java ! src/share/classes/javax/xml/crypto/dsig/keyinfo/RetrievalMethod.java ! src/share/classes/javax/xml/crypto/dsig/keyinfo/X509Data.java ! src/share/classes/javax/xml/crypto/dsig/spec/ExcC14NParameterSpec.java ! src/share/classes/javax/xml/crypto/dsig/spec/XPathFilter2ParameterSpec.java ! src/share/classes/javax/xml/crypto/dsig/spec/XPathFilterParameterSpec.java ! src/share/classes/javax/xml/crypto/dsig/spec/XPathType.java ! src/share/classes/org/ietf/jgss/Oid.java ! src/share/classes/sun/dc/DuctusRenderingEngine.java ! src/share/classes/sun/instrument/InstrumentationImpl.java ! src/share/classes/sun/instrument/TransformerManager.java ! src/share/classes/sun/invoke/util/VerifyAccess.java ! src/share/classes/sun/invoke/util/VerifyType.java ! src/share/classes/sun/invoke/util/Wrapper.java ! src/share/classes/sun/launcher/resources/launcher.properties ! src/share/classes/sun/management/ConnectorAddressLink.java ! src/share/classes/sun/management/Flag.java ! src/share/classes/sun/management/GarbageCollectionNotifInfoCompositeData.java ! src/share/classes/sun/management/GarbageCollectorImpl.java ! src/share/classes/sun/management/GcInfoBuilder.java ! src/share/classes/sun/management/GcInfoCompositeData.java ! src/share/classes/sun/management/HotspotCompilation.java ! src/share/classes/sun/management/HotspotThread.java ! src/share/classes/sun/management/LazyCompositeData.java ! src/share/classes/sun/management/ManagementFactoryHelper.java ! src/share/classes/sun/management/MappedMXBeanType.java ! src/share/classes/sun/management/MonitorInfoCompositeData.java ! src/share/classes/sun/management/NotificationEmitterSupport.java ! src/share/classes/sun/management/RuntimeImpl.java ! src/share/classes/sun/management/ThreadInfoCompositeData.java ! src/share/classes/sun/management/counter/perf/PerfDataEntry.java ! src/share/classes/sun/management/counter/perf/PerfDataType.java ! src/share/classes/sun/management/counter/perf/PerfInstrumentation.java ! src/share/classes/sun/management/snmp/AdaptorBootstrap.java ! src/share/classes/sun/management/snmp/jvminstr/JVM_MANAGEMENT_MIB_IMPL.java ! src/share/classes/sun/management/snmp/jvminstr/JvmMemGCTableMetaImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmMemManagerTableMetaImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmMemMgrPoolRelTableMetaImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmMemPoolTableMetaImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmMemoryImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmMemoryMetaImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmOSImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmRTBootClassPathEntryImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmRTBootClassPathTableMetaImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmRTClassPathEntryImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmRTClassPathTableMetaImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmRTInputArgsEntryImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmRTInputArgsTableMetaImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmRTLibraryPathEntryImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmRTLibraryPathTableMetaImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmRuntimeMetaImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmThreadInstanceEntryImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmThreadInstanceTableMetaImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmThreadingMetaImpl.java ! src/share/classes/sun/management/snmp/jvmmib/EnumJvmClassesVerboseLevel.java ! src/share/classes/sun/management/snmp/jvmmib/EnumJvmJITCompilerTimeMonitoring.java ! src/share/classes/sun/management/snmp/jvmmib/EnumJvmMemManagerState.java ! src/share/classes/sun/management/snmp/jvmmib/EnumJvmMemPoolCollectThreshdSupport.java ! src/share/classes/sun/management/snmp/jvmmib/EnumJvmMemPoolState.java ! src/share/classes/sun/management/snmp/jvmmib/EnumJvmMemPoolThreshdSupport.java ! src/share/classes/sun/management/snmp/jvmmib/EnumJvmMemPoolType.java ! src/share/classes/sun/management/snmp/jvmmib/EnumJvmMemoryGCCall.java ! src/share/classes/sun/management/snmp/jvmmib/EnumJvmMemoryGCVerboseLevel.java ! src/share/classes/sun/management/snmp/jvmmib/EnumJvmRTBootClassPathSupport.java ! src/share/classes/sun/management/snmp/jvmmib/EnumJvmThreadContentionMonitoring.java ! src/share/classes/sun/management/snmp/jvmmib/EnumJvmThreadCpuTimeMonitoring.java ! src/share/classes/sun/management/snmp/jvmmib/JVM_MANAGEMENT_MIB.java ! src/share/classes/sun/management/snmp/jvmmib/JVM_MANAGEMENT_MIBOidTable.java ! src/share/classes/sun/management/snmp/jvmmib/JvmClassLoadingMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmCompilationMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmMemGCEntryMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmMemGCTableMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmMemManagerEntryMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmMemManagerTableMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmMemMgrPoolRelEntryMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmMemMgrPoolRelTableMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmMemPoolEntryMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmMemPoolTableMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmOSMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmRTBootClassPathEntryMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmRTBootClassPathTableMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmRTClassPathEntryMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmRTClassPathTableMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmRTInputArgsEntryMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmRTInputArgsTableMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmRTLibraryPathEntryMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmRTLibraryPathTableMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmRuntimeMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmThreadInstanceEntryMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmThreadInstanceTableMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmThreadingMeta.java ! src/share/classes/sun/management/snmp/util/MibLogger.java ! src/share/classes/sun/management/snmp/util/SnmpListTableCache.java ! src/share/classes/sun/management/snmp/util/SnmpNamedListTableCache.java ! src/share/classes/sun/management/snmp/util/SnmpTableCache.java ! src/share/classes/sun/misc/BASE64Decoder.java ! src/share/classes/sun/misc/CEFormatException.java ! src/share/classes/sun/misc/CEStreamExhausted.java ! src/share/classes/sun/misc/ClassLoaderUtil.java ! src/share/classes/sun/misc/CompoundEnumeration.java ! src/share/classes/sun/misc/ExtensionDependency.java ! src/share/classes/sun/misc/ExtensionInstallationException.java ! src/share/classes/sun/misc/FDBigInt.java ! src/share/classes/sun/misc/FloatingDecimal.java ! src/share/classes/sun/misc/InvalidJarIndexException.java ! src/share/classes/sun/misc/JarIndex.java ! src/share/classes/sun/misc/JavaLangAccess.java ! src/share/classes/sun/misc/LRUCache.java ! src/share/classes/sun/misc/MetaIndex.java ! src/share/classes/sun/misc/ProxyGenerator.java ! src/share/classes/sun/misc/Queue.java ! src/share/classes/sun/misc/REException.java ! src/share/classes/sun/misc/RequestProcessor.java ! src/share/classes/sun/misc/Service.java ! src/share/classes/sun/misc/ServiceConfigurationError.java ! src/share/classes/sun/misc/Signal.java ! src/share/classes/sun/misc/Unsafe.java ! src/share/classes/sun/misc/VM.java ! src/share/classes/sun/net/NetworkClient.java ! src/share/classes/sun/net/NetworkServer.java ! src/share/classes/sun/net/ftp/impl/FtpClient.java ! src/share/classes/sun/net/httpserver/Event.java ! src/share/classes/sun/net/httpserver/Request.java ! src/share/classes/sun/net/httpserver/WriteFinishedEvent.java ! src/share/classes/sun/net/sdp/SdpSupport.java ! src/share/classes/sun/net/smtp/SmtpClient.java ! src/share/classes/sun/net/spi/DefaultProxySelector.java ! src/share/classes/sun/net/www/content/image/gif.java ! src/share/classes/sun/net/www/content/image/jpeg.java ! src/share/classes/sun/net/www/content/image/png.java ! src/share/classes/sun/net/www/content/image/x_xbitmap.java ! src/share/classes/sun/net/www/content/image/x_xpixmap.java ! src/share/classes/sun/net/www/http/ChunkedOutputStream.java ! src/share/classes/sun/net/www/http/KeepAliveCleanerEntry.java ! src/share/classes/sun/net/www/http/KeepAliveStream.java ! src/share/classes/sun/net/www/protocol/https/HttpsClient.java ! src/share/classes/sun/net/www/protocol/mailto/Handler.java ! src/share/classes/sun/nio/ch/AbstractPollArrayWrapper.java ! src/share/classes/sun/nio/ch/AbstractPollSelectorImpl.java ! src/share/classes/sun/nio/ch/AsynchronousServerSocketChannelImpl.java ! src/share/classes/sun/nio/ch/AsynchronousSocketChannelImpl.java ! src/share/classes/sun/nio/ch/DatagramSocketAdaptor.java ! src/share/classes/sun/nio/ch/ExtendedSocketOption.java ! src/share/classes/sun/nio/ch/IOStatus.java ! src/share/classes/sun/nio/ch/IOUtil.java ! src/share/classes/sun/nio/ch/NativeThreadSet.java ! src/share/classes/sun/nio/ch/Net.java ! src/share/classes/sun/nio/ch/SelChImpl.java ! src/share/classes/sun/nio/ch/SelectionKeyImpl.java ! src/share/classes/sun/nio/ch/SelectorImpl.java ! src/share/classes/sun/nio/ch/ServerSocketAdaptor.java ! src/share/classes/sun/nio/ch/SocketAdaptor.java ! src/share/classes/sun/nio/ch/Util.java ! src/share/classes/sun/nio/ch/sctp/MessageInfoImpl.java ! src/share/classes/sun/nio/ch/sctp/SctpStdSocketOption.java ! src/share/classes/sun/nio/cs/AbstractCharsetProvider.java ! src/share/classes/sun/nio/cs/SingleByte.java ! src/share/classes/sun/nio/cs/UTF_8.java ! src/share/classes/sun/nio/cs/ext/DoubleByte.java ! src/share/classes/sun/nio/cs/ext/EUC_JP.java ! src/share/classes/sun/nio/cs/ext/EUC_JP_LINUX.java ! src/share/classes/sun/nio/cs/ext/EUC_JP_Open.java ! src/share/classes/sun/nio/cs/ext/GB18030.java ! src/share/classes/sun/nio/cs/ext/HKSCS.java ! src/share/classes/sun/nio/cs/ext/IBM33722.java ! src/share/classes/sun/nio/cs/ext/IBM834.java ! src/share/classes/sun/nio/cs/ext/IBM964.java ! src/share/classes/sun/nio/cs/ext/ISCII91.java ! src/share/classes/sun/nio/cs/ext/ISO2022_JP.java ! src/share/classes/sun/nio/cs/ext/ISO2022_JP_2.java ! src/share/classes/sun/nio/cs/ext/MS50220.java ! src/share/classes/sun/nio/cs/ext/MS50221.java ! src/share/classes/sun/nio/cs/ext/MSISO2022JP.java ! src/share/classes/sun/nio/cs/standard-charsets ! src/share/classes/sun/print/RasterPrinterJob.java ! src/share/classes/sun/print/ServiceDialog.java ! src/share/classes/sun/reflect/AccessorGenerator.java ! src/share/classes/sun/reflect/BootstrapConstructorAccessorImpl.java ! src/share/classes/sun/reflect/ClassDefiner.java ! src/share/classes/sun/reflect/ConstantPool.java ! src/share/classes/sun/reflect/Label.java ! src/share/classes/sun/reflect/MethodAccessorGenerator.java ! src/share/classes/sun/reflect/NativeConstructorAccessorImpl.java ! src/share/classes/sun/reflect/Reflection.java ! src/share/classes/sun/reflect/ReflectionFactory.java ! src/share/classes/sun/reflect/UTF8.java ! src/share/classes/sun/reflect/UnsafeFieldAccessorFactory.java ! src/share/classes/sun/reflect/UnsafeFieldAccessorImpl.java ! src/share/classes/sun/reflect/annotation/AnnotationParser.java ! src/share/classes/sun/reflect/generics/reflectiveObjects/TypeVariableImpl.java ! src/share/classes/sun/reflect/generics/repository/GenericDeclRepository.java ! src/share/classes/sun/reflect/generics/scope/AbstractScope.java ! src/share/classes/sun/reflect/generics/scope/ConstructorScope.java ! src/share/classes/sun/reflect/generics/tree/ClassSignature.java ! src/share/classes/sun/reflect/generics/tree/MethodTypeSignature.java ! src/share/classes/sun/reflect/misc/ReflectUtil.java ! src/share/classes/sun/rmi/log/ReliableLog.java ! src/share/classes/sun/rmi/registry/RegistryImpl.java ! src/share/classes/sun/rmi/rmic/BatchEnvironment.java ! src/share/classes/sun/rmi/rmic/Main.java ! src/share/classes/sun/rmi/rmic/RMIGenerator.java ! src/share/classes/sun/rmi/rmic/newrmic/Main.java ! src/share/classes/sun/rmi/rmic/newrmic/Resources.java ! src/share/classes/sun/rmi/server/ActivatableRef.java ! src/share/classes/sun/rmi/server/ActivationGroupImpl.java ! src/share/classes/sun/rmi/server/LoaderHandler.java ! src/share/classes/sun/rmi/server/MarshalInputStream.java ! src/share/classes/sun/rmi/server/UnicastRef.java ! src/share/classes/sun/rmi/server/UnicastRef2.java ! src/share/classes/sun/rmi/server/UnicastServerRef.java ! src/share/classes/sun/rmi/server/Util.java ! src/share/classes/sun/rmi/server/WeakClassHashMap.java ! src/share/classes/sun/rmi/transport/ConnectionInputStream.java ! src/share/classes/sun/rmi/transport/DGCAckHandler.java ! src/share/classes/sun/rmi/transport/DGCClient.java ! src/share/classes/sun/rmi/transport/DGCImpl.java ! src/share/classes/sun/rmi/transport/LiveRef.java ! src/share/classes/sun/rmi/transport/ObjectTable.java ! src/share/classes/sun/rmi/transport/StreamRemoteCall.java ! src/share/classes/sun/rmi/transport/Target.java ! src/share/classes/sun/rmi/transport/Transport.java ! src/share/classes/sun/rmi/transport/WeakRef.java ! src/share/classes/sun/rmi/transport/proxy/CGIHandler.java ! src/share/classes/sun/rmi/transport/proxy/HttpInputStream.java ! src/share/classes/sun/rmi/transport/proxy/HttpSendSocket.java ! src/share/classes/sun/rmi/transport/proxy/RMIMasterSocketFactory.java ! src/share/classes/sun/rmi/transport/tcp/ConnectionMultiplexer.java ! src/share/classes/sun/rmi/transport/tcp/TCPChannel.java ! src/share/classes/sun/rmi/transport/tcp/TCPEndpoint.java ! src/share/classes/sun/rmi/transport/tcp/TCPTransport.java ! src/share/classes/sun/security/ec/ECPublicKeyImpl.java ! src/share/classes/sun/security/jgss/GSSCredentialImpl.java ! src/share/classes/sun/security/jgss/krb5/AcceptSecContextToken.java ! src/share/classes/sun/security/jgss/krb5/Krb5NameElement.java ! src/share/classes/sun/security/jgss/krb5/MessageToken_v2.java ! src/share/classes/sun/security/jgss/spi/GSSContextSpi.java ! src/share/classes/sun/security/krb5/Checksum.java ! src/share/classes/sun/security/krb5/KdcComm.java ! src/share/classes/sun/security/krb5/KrbApReq.java ! src/share/classes/sun/security/krb5/KrbAsRep.java ! src/share/classes/sun/security/krb5/KrbAsReq.java ! src/share/classes/sun/security/krb5/KrbAsReqBuilder.java ! src/share/classes/sun/security/krb5/KrbCred.java ! src/share/classes/sun/security/krb5/KrbException.java ! src/share/classes/sun/security/krb5/KrbPriv.java ! src/share/classes/sun/security/krb5/KrbSafe.java ! src/share/classes/sun/security/krb5/KrbTgsRep.java ! src/share/classes/sun/security/krb5/KrbTgsReq.java ! src/share/classes/sun/security/krb5/PrincipalName.java ! src/share/classes/sun/security/krb5/Realm.java ! src/share/classes/sun/security/krb5/RealmException.java ! src/share/classes/sun/security/krb5/SCDynamicStoreConfig.java ! src/share/classes/sun/security/krb5/internal/CredentialsUtil.java ! src/share/classes/sun/security/krb5/internal/KRBError.java ! src/share/classes/sun/security/krb5/internal/NetClient.java ! src/share/classes/sun/security/krb5/internal/ccache/FileCredentialsCache.java ! src/share/classes/sun/security/krb5/internal/crypto/CksumType.java ! src/share/classes/sun/security/krb5/internal/crypto/EType.java ! src/share/classes/sun/security/krb5/internal/ktab/KeyTab.java ! src/share/classes/sun/security/krb5/internal/ktab/KeyTabInputStream.java ! src/share/classes/sun/security/krb5/internal/rcache/ReplayCache.java ! src/share/classes/sun/security/pkcs11/Config.java ! src/share/classes/sun/security/pkcs12/PKCS12KeyStore.java ! src/share/classes/sun/security/provider/DigestBase.java ! src/share/classes/sun/security/provider/JavaKeyStore.java ! src/share/classes/sun/security/provider/MD2.java ! src/share/classes/sun/security/provider/MD4.java ! src/share/classes/sun/security/provider/MD5.java ! src/share/classes/sun/security/provider/PolicyFile.java ! src/share/classes/sun/security/provider/SHA.java ! src/share/classes/sun/security/provider/SHA5.java ! src/share/classes/sun/security/smartcardio/PCSC.java ! src/share/classes/sun/security/smartcardio/TerminalImpl.java ! src/share/classes/sun/security/ssl/ExtensionType.java ! src/share/classes/sun/security/ssl/HelloExtension.java ! src/share/classes/sun/security/ssl/RenegotiationInfoExtension.java ! src/share/classes/sun/security/ssl/ServerNameExtension.java ! src/share/classes/sun/security/ssl/SignatureAlgorithmsExtension.java ! src/share/classes/sun/security/ssl/SupportedEllipticCurvesExtension.java ! src/share/classes/sun/security/ssl/SupportedEllipticPointFormatsExtension.java ! src/share/classes/sun/security/ssl/UnknownExtension.java ! src/share/classes/sun/security/ssl/krb5/KerberosClientKeyExchangeImpl.java ! src/share/classes/sun/security/util/Debug.java ! src/share/classes/sun/security/util/HostnameChecker.java ! src/share/classes/sun/security/util/SecurityConstants.java ! src/share/classes/sun/security/validator/PKIXValidator.java ! src/share/classes/sun/security/x509/CRLExtensions.java ! src/share/classes/sun/security/x509/CertificateExtensions.java ! src/share/classes/sun/security/x509/DNSName.java ! src/share/classes/sun/security/x509/RFC822Name.java ! src/share/classes/sun/security/x509/URIName.java ! src/share/classes/sun/security/x509/X509CRLEntryImpl.java ! src/share/classes/sun/security/x509/X509CRLImpl.java ! src/share/classes/sun/security/x509/X509CertImpl.java ! src/share/classes/sun/security/x509/X509CertInfo.java ! src/share/classes/sun/text/CompactByteArray.java ! src/share/classes/sun/text/IntHashtable.java ! src/share/classes/sun/text/bidi/BidiBase.java ! src/share/classes/sun/text/normalizer/ICUData.java ! src/share/classes/sun/text/normalizer/NormalizerBase.java ! src/share/classes/sun/text/normalizer/NormalizerImpl.java ! src/share/classes/sun/text/normalizer/SymbolTable.java ! src/share/classes/sun/text/normalizer/UnicodeSet.java ! src/share/classes/sun/text/normalizer/UnicodeSetIterator.java ! src/share/classes/sun/text/normalizer/VersionInfo.java ! src/share/classes/sun/tools/attach/HotSpotVirtualMachine.java ! src/share/classes/sun/tools/attach/META-INF/services/com.sun.tools.attach.spi.AttachProvider ! src/share/classes/sun/tools/jar/CommandLine.java ! src/share/classes/sun/tools/jar/Manifest.java ! src/share/classes/sun/tools/jar/SignatureFile.java ! src/share/classes/sun/tools/javac/resources/javac.properties ! src/share/classes/sun/tools/jcmd/Arguments.java ! src/share/classes/sun/tools/jconsole/AboutDialog.java ! src/share/classes/sun/tools/jconsole/BorderedComponent.java ! src/share/classes/sun/tools/jconsole/ClassTab.java ! src/share/classes/sun/tools/jconsole/ConnectDialog.java ! src/share/classes/sun/tools/jconsole/CreateMBeanDialog.java ! src/share/classes/sun/tools/jconsole/Formatter.java ! src/share/classes/sun/tools/jconsole/HTMLPane.java ! src/share/classes/sun/tools/jconsole/InternalDialog.java ! src/share/classes/sun/tools/jconsole/JConsole.java ! src/share/classes/sun/tools/jconsole/LabeledComponent.java ! src/share/classes/sun/tools/jconsole/LocalVirtualMachine.java ! src/share/classes/sun/tools/jconsole/MBeansTab.java ! src/share/classes/sun/tools/jconsole/MaximizableInternalFrame.java ! src/share/classes/sun/tools/jconsole/MemoryPoolProxy.java ! src/share/classes/sun/tools/jconsole/MemoryPoolStat.java ! src/share/classes/sun/tools/jconsole/MemoryTab.java ! src/share/classes/sun/tools/jconsole/OverviewPanel.java ! src/share/classes/sun/tools/jconsole/OverviewTab.java ! src/share/classes/sun/tools/jconsole/Plotter.java ! src/share/classes/sun/tools/jconsole/PlotterPanel.java ! src/share/classes/sun/tools/jconsole/ProxyClient.java ! src/share/classes/sun/tools/jconsole/Resources.java ! src/share/classes/sun/tools/jconsole/SummaryTab.java ! src/share/classes/sun/tools/jconsole/Tab.java ! src/share/classes/sun/tools/jconsole/ThreadTab.java ! src/share/classes/sun/tools/jconsole/VMInternalFrame.java ! src/share/classes/sun/tools/jconsole/VMPanel.java ! src/share/classes/sun/tools/jconsole/VariableGridLayout.java ! src/share/classes/sun/tools/jconsole/Version.java.template ! src/share/classes/sun/tools/jconsole/inspector/OperationEntry.java ! src/share/classes/sun/tools/jconsole/inspector/TableSorter.java ! src/share/classes/sun/tools/jconsole/inspector/ThreadDialog.java ! src/share/classes/sun/tools/jconsole/inspector/Utils.java ! src/share/classes/sun/tools/jconsole/inspector/XArrayDataViewer.java ! src/share/classes/sun/tools/jconsole/inspector/XDataViewer.java ! src/share/classes/sun/tools/jconsole/inspector/XMBeanAttributes.java ! src/share/classes/sun/tools/jconsole/inspector/XMBeanInfo.java ! src/share/classes/sun/tools/jconsole/inspector/XMBeanNotifications.java ! src/share/classes/sun/tools/jconsole/inspector/XObject.java ! src/share/classes/sun/tools/jconsole/inspector/XOpenTypeViewer.java ! src/share/classes/sun/tools/jconsole/inspector/XOperations.java ! src/share/classes/sun/tools/jconsole/inspector/XPlotter.java ! src/share/classes/sun/tools/jconsole/inspector/XPlottingViewer.java ! src/share/classes/sun/tools/jconsole/inspector/XSheet.java ! src/share/classes/sun/tools/jconsole/inspector/XTable.java ! src/share/classes/sun/tools/jconsole/inspector/XTextField.java ! src/share/classes/sun/tools/jconsole/inspector/XTree.java ! src/share/classes/sun/tools/jconsole/inspector/XTreeRenderer.java ! src/share/classes/sun/tools/jinfo/JInfo.java ! src/share/classes/sun/tools/jmap/JMap.java ! src/share/classes/sun/tools/jstack/JStack.java ! src/share/classes/sun/tools/serialver/SerialVer.java ! src/share/classes/sun/tools/tree/Node.java ! src/share/classes/sun/tracing/dtrace/DTraceProvider.java ! src/share/classes/sun/tracing/dtrace/JVM.java ! src/share/classes/sun/util/PreHashedMap.java ! src/share/classes/sun/util/calendar/CalendarDate.java ! src/share/classes/sun/util/locale/LocaleUtils.java ! src/share/classes/sun/util/logging/LoggingProxy.java ! src/share/classes/sun/util/logging/LoggingSupport.java ! src/share/classes/sun/util/logging/PlatformLogger.java ! src/share/classes/sun/util/resources/OpenListResourceBundle.java ! src/share/classes/sun/util/resources/TimeZoneNames.java ! src/share/classes/sun/util/resources/ar/CalendarData_ar.properties ! src/share/classes/sun/util/resources/ar/CurrencyNames_ar_AE.properties ! src/share/classes/sun/util/resources/ar/CurrencyNames_ar_BH.properties ! src/share/classes/sun/util/resources/ar/CurrencyNames_ar_DZ.properties ! src/share/classes/sun/util/resources/ar/CurrencyNames_ar_EG.properties ! src/share/classes/sun/util/resources/ar/CurrencyNames_ar_IQ.properties ! src/share/classes/sun/util/resources/ar/CurrencyNames_ar_JO.properties ! src/share/classes/sun/util/resources/ar/CurrencyNames_ar_KW.properties ! src/share/classes/sun/util/resources/ar/CurrencyNames_ar_LB.properties ! src/share/classes/sun/util/resources/ar/CurrencyNames_ar_LY.properties ! src/share/classes/sun/util/resources/ar/CurrencyNames_ar_MA.properties ! src/share/classes/sun/util/resources/ar/CurrencyNames_ar_OM.properties ! src/share/classes/sun/util/resources/ar/CurrencyNames_ar_QA.properties ! src/share/classes/sun/util/resources/ar/CurrencyNames_ar_SA.properties ! src/share/classes/sun/util/resources/ar/CurrencyNames_ar_SD.properties ! src/share/classes/sun/util/resources/ar/CurrencyNames_ar_SY.properties ! src/share/classes/sun/util/resources/ar/CurrencyNames_ar_TN.properties ! src/share/classes/sun/util/resources/ar/CurrencyNames_ar_YE.properties ! src/share/classes/sun/util/resources/ar/LocaleNames_ar.properties ! src/share/classes/sun/util/resources/be/CalendarData_be.properties ! src/share/classes/sun/util/resources/be/CurrencyNames_be_BY.properties ! src/share/classes/sun/util/resources/be/LocaleNames_be.properties ! src/share/classes/sun/util/resources/bg/CalendarData_bg.properties ! src/share/classes/sun/util/resources/bg/CurrencyNames_bg_BG.properties ! src/share/classes/sun/util/resources/bg/LocaleNames_bg.properties ! src/share/classes/sun/util/resources/ca/CalendarData_ca.properties ! src/share/classes/sun/util/resources/ca/CurrencyNames_ca_ES.properties ! src/share/classes/sun/util/resources/ca/LocaleNames_ca.properties ! src/share/classes/sun/util/resources/cs/CalendarData_cs.properties ! src/share/classes/sun/util/resources/cs/CurrencyNames_cs_CZ.properties ! src/share/classes/sun/util/resources/cs/LocaleNames_cs.properties ! src/share/classes/sun/util/resources/da/CalendarData_da.properties ! src/share/classes/sun/util/resources/da/CurrencyNames_da_DK.properties ! src/share/classes/sun/util/resources/da/LocaleNames_da.properties ! src/share/classes/sun/util/resources/de/CalendarData_de.properties ! src/share/classes/sun/util/resources/de/CurrencyNames_de.properties ! src/share/classes/sun/util/resources/de/CurrencyNames_de_AT.properties ! src/share/classes/sun/util/resources/de/CurrencyNames_de_CH.properties ! src/share/classes/sun/util/resources/de/CurrencyNames_de_DE.properties ! src/share/classes/sun/util/resources/de/CurrencyNames_de_GR.properties ! src/share/classes/sun/util/resources/de/CurrencyNames_de_LU.properties ! src/share/classes/sun/util/resources/de/LocaleNames_de.properties ! src/share/classes/sun/util/resources/el/CalendarData_el.properties ! src/share/classes/sun/util/resources/el/CalendarData_el_CY.properties ! src/share/classes/sun/util/resources/el/CurrencyNames_el_CY.properties ! src/share/classes/sun/util/resources/el/CurrencyNames_el_GR.properties ! src/share/classes/sun/util/resources/el/LocaleNames_el.properties ! src/share/classes/sun/util/resources/el/LocaleNames_el_CY.properties ! src/share/classes/sun/util/resources/en/CalendarData_en.properties ! src/share/classes/sun/util/resources/en/CalendarData_en_GB.properties ! src/share/classes/sun/util/resources/en/CalendarData_en_IE.properties ! src/share/classes/sun/util/resources/en/CalendarData_en_MT.properties ! src/share/classes/sun/util/resources/en/CurrencyNames_en_AU.properties ! src/share/classes/sun/util/resources/en/CurrencyNames_en_CA.properties ! src/share/classes/sun/util/resources/en/CurrencyNames_en_GB.properties ! src/share/classes/sun/util/resources/en/CurrencyNames_en_IE.properties ! src/share/classes/sun/util/resources/en/CurrencyNames_en_IN.properties ! src/share/classes/sun/util/resources/en/CurrencyNames_en_MT.properties ! src/share/classes/sun/util/resources/en/CurrencyNames_en_NZ.properties ! src/share/classes/sun/util/resources/en/CurrencyNames_en_PH.properties ! src/share/classes/sun/util/resources/en/CurrencyNames_en_SG.properties ! src/share/classes/sun/util/resources/en/CurrencyNames_en_US.properties ! src/share/classes/sun/util/resources/en/CurrencyNames_en_ZA.properties ! src/share/classes/sun/util/resources/en/LocaleNames_en.properties ! src/share/classes/sun/util/resources/en/LocaleNames_en_MT.properties ! src/share/classes/sun/util/resources/en/LocaleNames_en_PH.properties ! src/share/classes/sun/util/resources/en/LocaleNames_en_SG.properties ! src/share/classes/sun/util/resources/es/CalendarData_es.properties ! src/share/classes/sun/util/resources/es/CalendarData_es_ES.properties ! src/share/classes/sun/util/resources/es/CalendarData_es_US.properties ! src/share/classes/sun/util/resources/es/CurrencyNames_es.properties ! src/share/classes/sun/util/resources/es/CurrencyNames_es_AR.properties ! src/share/classes/sun/util/resources/es/CurrencyNames_es_BO.properties ! src/share/classes/sun/util/resources/es/CurrencyNames_es_CL.properties ! src/share/classes/sun/util/resources/es/CurrencyNames_es_CO.properties ! src/share/classes/sun/util/resources/es/CurrencyNames_es_CR.properties ! src/share/classes/sun/util/resources/es/CurrencyNames_es_CU.properties ! src/share/classes/sun/util/resources/es/CurrencyNames_es_DO.properties ! src/share/classes/sun/util/resources/es/CurrencyNames_es_EC.properties ! src/share/classes/sun/util/resources/es/CurrencyNames_es_ES.properties ! src/share/classes/sun/util/resources/es/CurrencyNames_es_GT.properties ! src/share/classes/sun/util/resources/es/CurrencyNames_es_HN.properties ! src/share/classes/sun/util/resources/es/CurrencyNames_es_MX.properties ! src/share/classes/sun/util/resources/es/CurrencyNames_es_NI.properties ! src/share/classes/sun/util/resources/es/CurrencyNames_es_PA.properties ! src/share/classes/sun/util/resources/es/CurrencyNames_es_PR.properties ! src/share/classes/sun/util/resources/es/CurrencyNames_es_PY.properties ! src/share/classes/sun/util/resources/es/CurrencyNames_es_SV.properties ! src/share/classes/sun/util/resources/es/CurrencyNames_es_US.properties ! src/share/classes/sun/util/resources/es/CurrencyNames_es_UY.properties ! src/share/classes/sun/util/resources/es/CurrencyNames_es_VE.properties ! src/share/classes/sun/util/resources/es/LocaleNames_es.properties ! src/share/classes/sun/util/resources/es/LocaleNames_es_US.properties ! src/share/classes/sun/util/resources/et/CalendarData_et.properties ! src/share/classes/sun/util/resources/et/CurrencyNames_et_EE.properties ! src/share/classes/sun/util/resources/et/LocaleNames_et.properties ! src/share/classes/sun/util/resources/fi/CalendarData_fi.properties ! src/share/classes/sun/util/resources/fi/CurrencyNames_fi_FI.properties ! src/share/classes/sun/util/resources/fi/LocaleNames_fi.properties ! src/share/classes/sun/util/resources/fr/CalendarData_fr.properties ! src/share/classes/sun/util/resources/fr/CalendarData_fr_CA.properties ! src/share/classes/sun/util/resources/fr/CurrencyNames_fr.properties ! src/share/classes/sun/util/resources/fr/CurrencyNames_fr_BE.properties ! src/share/classes/sun/util/resources/fr/CurrencyNames_fr_CA.properties ! src/share/classes/sun/util/resources/fr/CurrencyNames_fr_CH.properties ! src/share/classes/sun/util/resources/fr/CurrencyNames_fr_FR.properties ! src/share/classes/sun/util/resources/fr/CurrencyNames_fr_LU.properties ! src/share/classes/sun/util/resources/fr/LocaleNames_fr.properties ! src/share/classes/sun/util/resources/ga/CurrencyNames_ga_IE.properties ! src/share/classes/sun/util/resources/ga/LocaleNames_ga.properties ! src/share/classes/sun/util/resources/hi/CalendarData_hi.properties ! src/share/classes/sun/util/resources/hi/CurrencyNames_hi_IN.properties ! src/share/classes/sun/util/resources/hi/LocaleNames_hi.properties ! src/share/classes/sun/util/resources/hr/CalendarData_hr.properties ! src/share/classes/sun/util/resources/hr/CurrencyNames_hr_HR.properties ! src/share/classes/sun/util/resources/hr/LocaleNames_hr.properties ! src/share/classes/sun/util/resources/hu/CalendarData_hu.properties ! src/share/classes/sun/util/resources/hu/CurrencyNames_hu_HU.properties ! src/share/classes/sun/util/resources/hu/LocaleNames_hu.properties ! src/share/classes/sun/util/resources/in/CalendarData_in_ID.properties ! src/share/classes/sun/util/resources/in/CurrencyNames_in_ID.properties ! src/share/classes/sun/util/resources/in/LocaleNames_in.properties ! src/share/classes/sun/util/resources/is/CalendarData_is.properties ! src/share/classes/sun/util/resources/is/CurrencyNames_is_IS.properties ! src/share/classes/sun/util/resources/is/LocaleNames_is.properties ! src/share/classes/sun/util/resources/it/CalendarData_it.properties ! src/share/classes/sun/util/resources/it/CurrencyNames_it.properties ! src/share/classes/sun/util/resources/it/CurrencyNames_it_CH.properties ! src/share/classes/sun/util/resources/it/CurrencyNames_it_IT.properties ! src/share/classes/sun/util/resources/it/LocaleNames_it.properties ! src/share/classes/sun/util/resources/iw/CalendarData_iw.properties ! src/share/classes/sun/util/resources/iw/CurrencyNames_iw_IL.properties ! src/share/classes/sun/util/resources/iw/LocaleNames_iw.properties ! src/share/classes/sun/util/resources/ja/CalendarData_ja.properties ! src/share/classes/sun/util/resources/ja/CurrencyNames_ja.properties ! src/share/classes/sun/util/resources/ja/CurrencyNames_ja_JP.properties ! src/share/classes/sun/util/resources/ja/LocaleNames_ja.properties ! src/share/classes/sun/util/resources/ko/CalendarData_ko.properties ! src/share/classes/sun/util/resources/ko/CurrencyNames_ko.properties ! src/share/classes/sun/util/resources/ko/CurrencyNames_ko_KR.properties ! src/share/classes/sun/util/resources/ko/LocaleNames_ko.properties ! src/share/classes/sun/util/resources/lt/CalendarData_lt.properties ! src/share/classes/sun/util/resources/lt/CurrencyNames_lt_LT.properties ! src/share/classes/sun/util/resources/lt/LocaleNames_lt.properties ! src/share/classes/sun/util/resources/lv/CalendarData_lv.properties ! src/share/classes/sun/util/resources/lv/CurrencyNames_lv_LV.properties ! src/share/classes/sun/util/resources/lv/LocaleNames_lv.properties ! src/share/classes/sun/util/resources/mk/CalendarData_mk.properties ! src/share/classes/sun/util/resources/mk/CurrencyNames_mk_MK.properties ! src/share/classes/sun/util/resources/mk/LocaleNames_mk.properties ! src/share/classes/sun/util/resources/ms/CalendarData_ms_MY.properties ! src/share/classes/sun/util/resources/ms/CurrencyNames_ms_MY.properties ! src/share/classes/sun/util/resources/ms/LocaleNames_ms.properties ! src/share/classes/sun/util/resources/mt/CalendarData_mt.properties ! src/share/classes/sun/util/resources/mt/CalendarData_mt_MT.properties ! src/share/classes/sun/util/resources/mt/CurrencyNames_mt_MT.properties ! src/share/classes/sun/util/resources/mt/LocaleNames_mt.properties ! src/share/classes/sun/util/resources/nl/CalendarData_nl.properties ! src/share/classes/sun/util/resources/nl/CurrencyNames_nl_BE.properties ! src/share/classes/sun/util/resources/nl/CurrencyNames_nl_NL.properties ! src/share/classes/sun/util/resources/nl/LocaleNames_nl.properties ! src/share/classes/sun/util/resources/no/CalendarData_no.properties ! src/share/classes/sun/util/resources/no/CurrencyNames_no_NO.properties ! src/share/classes/sun/util/resources/no/LocaleNames_no.properties ! src/share/classes/sun/util/resources/no/LocaleNames_no_NO_NY.properties ! src/share/classes/sun/util/resources/pl/CalendarData_pl.properties ! src/share/classes/sun/util/resources/pl/CurrencyNames_pl_PL.properties ! src/share/classes/sun/util/resources/pl/LocaleNames_pl.properties ! src/share/classes/sun/util/resources/pt/CalendarData_pt.properties ! src/share/classes/sun/util/resources/pt/CalendarData_pt_PT.properties ! src/share/classes/sun/util/resources/pt/CurrencyNames_pt.properties ! src/share/classes/sun/util/resources/pt/CurrencyNames_pt_BR.properties ! src/share/classes/sun/util/resources/pt/CurrencyNames_pt_PT.properties ! src/share/classes/sun/util/resources/pt/LocaleNames_pt.properties ! src/share/classes/sun/util/resources/pt/LocaleNames_pt_BR.properties ! src/share/classes/sun/util/resources/pt/LocaleNames_pt_PT.properties ! src/share/classes/sun/util/resources/ro/CalendarData_ro.properties ! src/share/classes/sun/util/resources/ro/CurrencyNames_ro_RO.properties ! src/share/classes/sun/util/resources/ro/LocaleNames_ro.properties ! src/share/classes/sun/util/resources/ru/CalendarData_ru.properties ! src/share/classes/sun/util/resources/ru/CurrencyNames_ru_RU.properties ! src/share/classes/sun/util/resources/ru/LocaleNames_ru.properties ! src/share/classes/sun/util/resources/sk/CalendarData_sk.properties ! src/share/classes/sun/util/resources/sk/CurrencyNames_sk_SK.properties ! src/share/classes/sun/util/resources/sk/LocaleNames_sk.properties ! src/share/classes/sun/util/resources/sl/CalendarData_sl.properties ! src/share/classes/sun/util/resources/sl/CurrencyNames_sl_SI.properties ! src/share/classes/sun/util/resources/sl/LocaleNames_sl.properties ! src/share/classes/sun/util/resources/sq/CalendarData_sq.properties ! src/share/classes/sun/util/resources/sq/CurrencyNames_sq_AL.properties ! src/share/classes/sun/util/resources/sq/LocaleNames_sq.properties ! src/share/classes/sun/util/resources/sr/CalendarData_sr.properties ! src/share/classes/sun/util/resources/sr/CalendarData_sr_Latn_BA.properties ! src/share/classes/sun/util/resources/sr/CalendarData_sr_Latn_ME.properties ! src/share/classes/sun/util/resources/sr/CalendarData_sr_Latn_RS.properties ! src/share/classes/sun/util/resources/sr/CurrencyNames_sr_BA.properties ! src/share/classes/sun/util/resources/sr/CurrencyNames_sr_CS.properties ! src/share/classes/sun/util/resources/sr/CurrencyNames_sr_Latn_BA.properties ! src/share/classes/sun/util/resources/sr/CurrencyNames_sr_Latn_ME.properties ! src/share/classes/sun/util/resources/sr/CurrencyNames_sr_Latn_RS.properties ! src/share/classes/sun/util/resources/sr/CurrencyNames_sr_ME.properties ! src/share/classes/sun/util/resources/sr/CurrencyNames_sr_RS.properties ! src/share/classes/sun/util/resources/sr/LocaleNames_sr.properties ! src/share/classes/sun/util/resources/sr/LocaleNames_sr_Latn.properties ! src/share/classes/sun/util/resources/sv/CalendarData_sv.properties ! src/share/classes/sun/util/resources/sv/CurrencyNames_sv.properties ! src/share/classes/sun/util/resources/sv/CurrencyNames_sv_SE.properties ! src/share/classes/sun/util/resources/sv/LocaleNames_sv.properties ! src/share/classes/sun/util/resources/th/CalendarData_th.properties ! src/share/classes/sun/util/resources/th/CurrencyNames_th_TH.properties ! src/share/classes/sun/util/resources/th/LocaleNames_th.properties ! src/share/classes/sun/util/resources/tr/CalendarData_tr.properties ! src/share/classes/sun/util/resources/tr/CurrencyNames_tr_TR.properties ! src/share/classes/sun/util/resources/tr/LocaleNames_tr.properties ! src/share/classes/sun/util/resources/uk/CalendarData_uk.properties ! src/share/classes/sun/util/resources/uk/CurrencyNames_uk_UA.properties ! src/share/classes/sun/util/resources/uk/LocaleNames_uk.properties ! src/share/classes/sun/util/resources/vi/CalendarData_vi.properties ! src/share/classes/sun/util/resources/vi/CurrencyNames_vi_VN.properties ! src/share/classes/sun/util/resources/vi/LocaleNames_vi.properties ! src/share/classes/sun/util/resources/zh/CalendarData_zh.properties ! src/share/classes/sun/util/resources/zh/CurrencyNames_zh_CN.properties ! src/share/classes/sun/util/resources/zh/CurrencyNames_zh_TW.properties ! src/share/classes/sun/util/resources/zh/LocaleNames_zh.properties ! src/share/classes/sun/util/resources/zh/LocaleNames_zh_SG.properties ! src/share/classes/sun/util/resources/zh/LocaleNames_zh_TW.properties ! src/share/classes/sun/util/xml/PlatformXmlPropertiesProvider.java ! src/share/demo/jfc/Font2DTest/Font2DTest.java ! src/share/demo/jfc/Font2DTest/Font2DTestApplet.java ! src/share/demo/jfc/Font2DTest/FontPanel.java ! src/share/demo/jfc/Notepad/Notepad.java ! src/share/demo/jvmti/agent_util/agent_util.c ! src/share/demo/jvmti/agent_util/agent_util.h ! src/share/demo/jvmti/compiledMethodLoad/compiledMethodLoad.c ! src/share/demo/jvmti/compiledMethodLoad/sample.makefile.txt ! src/share/demo/jvmti/gctest/gctest.c ! src/share/demo/jvmti/gctest/sample.makefile.txt ! src/share/demo/jvmti/heapTracker/HeapTracker.java ! src/share/demo/jvmti/heapTracker/heapTracker.c ! src/share/demo/jvmti/heapTracker/heapTracker.h ! src/share/demo/jvmti/heapTracker/sample.makefile.txt ! src/share/demo/jvmti/heapViewer/heapViewer.c ! src/share/demo/jvmti/heapViewer/sample.makefile.txt ! src/share/demo/jvmti/hprof/debug_malloc.c ! src/share/demo/jvmti/hprof/debug_malloc.h ! src/share/demo/jvmti/hprof/hprof.h ! src/share/demo/jvmti/hprof/hprof_blocks.c ! src/share/demo/jvmti/hprof/hprof_blocks.h ! src/share/demo/jvmti/hprof/hprof_check.c ! src/share/demo/jvmti/hprof/hprof_check.h ! src/share/demo/jvmti/hprof/hprof_class.c ! src/share/demo/jvmti/hprof/hprof_class.h ! src/share/demo/jvmti/hprof/hprof_cpu.c ! src/share/demo/jvmti/hprof/hprof_cpu.h ! src/share/demo/jvmti/hprof/hprof_error.c ! src/share/demo/jvmti/hprof/hprof_error.h ! src/share/demo/jvmti/hprof/hprof_event.c ! src/share/demo/jvmti/hprof/hprof_event.h ! src/share/demo/jvmti/hprof/hprof_frame.c ! src/share/demo/jvmti/hprof/hprof_frame.h ! src/share/demo/jvmti/hprof/hprof_init.c ! src/share/demo/jvmti/hprof/hprof_init.h ! src/share/demo/jvmti/hprof/hprof_io.c ! src/share/demo/jvmti/hprof/hprof_io.h ! src/share/demo/jvmti/hprof/hprof_ioname.c ! src/share/demo/jvmti/hprof/hprof_ioname.h ! src/share/demo/jvmti/hprof/hprof_listener.c ! src/share/demo/jvmti/hprof/hprof_listener.h ! src/share/demo/jvmti/hprof/hprof_loader.c ! src/share/demo/jvmti/hprof/hprof_loader.h ! src/share/demo/jvmti/hprof/hprof_md.h ! src/share/demo/jvmti/hprof/hprof_monitor.c ! src/share/demo/jvmti/hprof/hprof_monitor.h ! src/share/demo/jvmti/hprof/hprof_object.c ! src/share/demo/jvmti/hprof/hprof_object.h ! src/share/demo/jvmti/hprof/hprof_reference.c ! src/share/demo/jvmti/hprof/hprof_reference.h ! src/share/demo/jvmti/hprof/hprof_site.c ! src/share/demo/jvmti/hprof/hprof_site.h ! src/share/demo/jvmti/hprof/hprof_stack.c ! src/share/demo/jvmti/hprof/hprof_stack.h ! src/share/demo/jvmti/hprof/hprof_string.c ! src/share/demo/jvmti/hprof/hprof_string.h ! src/share/demo/jvmti/hprof/hprof_table.c ! src/share/demo/jvmti/hprof/hprof_table.h ! src/share/demo/jvmti/hprof/hprof_tag.c ! src/share/demo/jvmti/hprof/hprof_tag.h ! src/share/demo/jvmti/hprof/hprof_tls.c ! src/share/demo/jvmti/hprof/hprof_tls.h ! src/share/demo/jvmti/hprof/hprof_trace.c ! src/share/demo/jvmti/hprof/hprof_trace.h ! src/share/demo/jvmti/hprof/hprof_tracker.c ! src/share/demo/jvmti/hprof/hprof_tracker.h ! src/share/demo/jvmti/hprof/hprof_util.c ! src/share/demo/jvmti/hprof/hprof_util.h ! src/share/demo/jvmti/hprof/sample.makefile.txt ! src/share/demo/jvmti/java_crw_demo/java_crw_demo.c ! src/share/demo/jvmti/java_crw_demo/java_crw_demo.h ! src/share/demo/jvmti/java_crw_demo/sample.makefile.txt ! src/share/demo/jvmti/minst/Minst.java ! src/share/demo/jvmti/minst/minst.c ! src/share/demo/jvmti/minst/minst.h ! src/share/demo/jvmti/minst/sample.makefile.txt ! src/share/demo/jvmti/mtrace/Mtrace.java ! src/share/demo/jvmti/mtrace/mtrace.c ! src/share/demo/jvmti/mtrace/mtrace.h ! src/share/demo/jvmti/mtrace/sample.makefile.txt ! src/share/demo/jvmti/versionCheck/sample.makefile.txt ! src/share/demo/jvmti/versionCheck/versionCheck.c ! src/share/demo/jvmti/waiters/Agent.cpp ! src/share/demo/jvmti/waiters/Agent.hpp ! src/share/demo/jvmti/waiters/Monitor.cpp ! src/share/demo/jvmti/waiters/Monitor.hpp ! src/share/demo/jvmti/waiters/Thread.cpp ! src/share/demo/jvmti/waiters/Thread.hpp ! src/share/demo/jvmti/waiters/sample.makefile.txt ! src/share/demo/jvmti/waiters/waiters.cpp ! src/share/demo/management/FullThreadDump/Deadlock.java ! src/share/demo/management/FullThreadDump/FullThreadDump.java ! src/share/demo/management/FullThreadDump/ThreadMonitor.java ! src/share/demo/management/JTop/JTop.java ! src/share/demo/management/JTop/JTopPlugin.java ! src/share/demo/management/MemoryMonitor/MemoryMonitor.java ! src/share/demo/management/MemoryMonitor/README.txt ! src/share/demo/management/VerboseGC/PrintGCStat.java ! src/share/demo/management/VerboseGC/VerboseGC.java ! src/share/demo/nbproject/project.xml ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/JarFileSystemProvider.java ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipCoder.java ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipConstants.java ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileAttributes.java ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileStore.java ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileSystem.java ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileSystemProvider.java ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipInfo.java ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipUtils.java ! src/share/demo/scripting/jconsole-plugin/src/com/sun/demo/scripting/jconsole/EditableAtEndDocument.java ! src/share/demo/scripting/jconsole-plugin/src/com/sun/demo/scripting/jconsole/ScriptJConsolePlugin.java ! src/share/demo/scripting/jconsole-plugin/src/com/sun/demo/scripting/jconsole/ScriptShellPanel.java ! src/share/demo/scripting/jconsole-plugin/src/resources/jconsole.js ! src/share/demo/scripting/jconsole-plugin/src/scripts/heapdump.js ! src/share/demo/scripting/jconsole-plugin/src/scripts/hello.js ! src/share/demo/scripting/jconsole-plugin/src/scripts/invoke.js ! src/share/demo/scripting/jconsole-plugin/src/scripts/jstack.js ! src/share/demo/scripting/jconsole-plugin/src/scripts/jtop.js ! src/share/demo/scripting/jconsole-plugin/src/scripts/sysprops.js ! src/share/demo/scripting/jconsole-plugin/src/scripts/verbose.js ! src/share/instrument/JPLISAssert.h ! src/share/javavm/export/classfile_constants.h ! src/share/javavm/export/jawt.h ! src/share/javavm/export/jmm.h ! src/share/javavm/export/jvm.h ! src/share/native/com/sun/java/util/jar/pack/main.cpp ! src/share/native/common/check_code.c ! src/share/native/common/jdk_util.h ! src/share/native/java/io/ObjectInputStream.c ! src/share/native/java/io/io_util.h ! src/share/native/java/lang/System.c ! src/share/native/java/lang/Thread.c ! src/share/native/java/lang/fdlibm/include/fdlibm.h ! src/share/native/java/lang/fdlibm/include/jfdlibm.h ! src/share/native/java/lang/java_props.h ! src/share/native/java/util/zip/Adler32.c ! src/share/native/java/util/zip/CRC32.c ! src/share/native/java/util/zip/Deflater.c ! src/share/native/java/util/zip/Inflater.c ! src/share/native/java/util/zip/ZipFile.c ! src/share/native/java/util/zip/zip_util.c ! src/share/native/sun/misc/VM.c ! src/share/native/sun/nio/ch/genSocketOptionRegistry.c ! src/share/native/sun/security/ec/impl/ecc_impl.h ! src/share/native/sun/security/ec/impl/ecdecode.c ! src/share/native/sun/security/ec/impl/oid.c ! src/share/native/sun/security/ec/impl/secitem.c ! src/share/native/sun/security/krb5/nativeccache.c ! src/share/native/sun/security/pkcs11/wrapper/p11_digest.c ! src/share/native/sun/security/pkcs11/wrapper/p11_dual.c ! src/share/native/sun/security/pkcs11/wrapper/p11_general.c ! src/share/native/sun/security/pkcs11/wrapper/p11_keymgmt.c ! src/share/native/sun/security/pkcs11/wrapper/p11_mutex.c ! src/share/native/sun/security/pkcs11/wrapper/p11_objmgmt.c ! src/share/native/sun/security/pkcs11/wrapper/p11_sessmgmt.c ! src/share/native/sun/security/pkcs11/wrapper/p11_sign.c ! src/share/native/sun/security/pkcs11/wrapper/p11_util.c ! src/share/npt/utf.h ! src/share/sample/jmx/jmx-scandir/src/com/sun/jmx/examples/scandir/DirectoryScanner.java ! src/share/sample/jmx/jmx-scandir/src/com/sun/jmx/examples/scandir/DirectoryScannerMXBean.java ! src/share/sample/jmx/jmx-scandir/src/com/sun/jmx/examples/scandir/ResultLogManager.java ! src/share/sample/jmx/jmx-scandir/src/com/sun/jmx/examples/scandir/ResultLogManagerMXBean.java ! src/share/sample/jmx/jmx-scandir/src/com/sun/jmx/examples/scandir/ScanDirAgent.java ! src/share/sample/jmx/jmx-scandir/src/com/sun/jmx/examples/scandir/ScanDirClient.java ! src/share/sample/jmx/jmx-scandir/src/com/sun/jmx/examples/scandir/ScanDirConfig.java ! src/share/sample/jmx/jmx-scandir/src/com/sun/jmx/examples/scandir/ScanDirConfigMXBean.java ! src/share/sample/jmx/jmx-scandir/src/com/sun/jmx/examples/scandir/ScanManager.java ! src/share/sample/jmx/jmx-scandir/src/com/sun/jmx/examples/scandir/ScanManagerMXBean.java ! src/share/sample/jmx/jmx-scandir/src/com/sun/jmx/examples/scandir/config/DirectoryScannerConfig.java ! src/share/sample/jmx/jmx-scandir/src/com/sun/jmx/examples/scandir/config/FileMatch.java ! src/share/sample/jmx/jmx-scandir/src/com/sun/jmx/examples/scandir/config/ResultLogConfig.java ! src/share/sample/jmx/jmx-scandir/src/com/sun/jmx/examples/scandir/config/ResultRecord.java ! src/share/sample/jmx/jmx-scandir/src/com/sun/jmx/examples/scandir/config/ScanManagerConfig.java ! src/share/sample/jmx/jmx-scandir/src/com/sun/jmx/examples/scandir/config/XmlConfigUtils.java ! src/share/sample/jmx/jmx-scandir/test/com/sun/jmx/examples/scandir/DirectoryScannerTest.java ! src/share/sample/jmx/jmx-scandir/test/com/sun/jmx/examples/scandir/ScanDirConfigTest.java ! src/share/sample/jmx/jmx-scandir/test/com/sun/jmx/examples/scandir/ScanManagerTest.java ! src/share/sample/jmx/jmx-scandir/test/com/sun/jmx/examples/scandir/TestUtils.java ! src/share/sample/jmx/jmx-scandir/test/com/sun/jmx/examples/scandir/config/XmlConfigUtilsTest.java ! src/share/sample/nio/multicast/MulticastAddress.java ! src/share/sample/nio/multicast/Reader.java ! src/share/sample/nio/multicast/Sender.java ! src/share/sample/nio/server/AcceptHandler.java ! src/share/sample/nio/server/Acceptor.java ! src/share/sample/nio/server/B1.java ! src/share/sample/nio/server/BN.java ! src/share/sample/nio/server/BP.java ! src/share/sample/nio/server/ChannelIO.java ! src/share/sample/nio/server/ChannelIOSecure.java ! src/share/sample/nio/server/Content.java ! src/share/sample/nio/server/Dispatcher.java ! src/share/sample/nio/server/Dispatcher1.java ! src/share/sample/nio/server/DispatcherN.java ! src/share/sample/nio/server/FileContent.java ! src/share/sample/nio/server/Handler.java ! src/share/sample/nio/server/MalformedRequestException.java ! src/share/sample/nio/server/N1.java ! src/share/sample/nio/server/N2.java ! src/share/sample/nio/server/Reply.java ! src/share/sample/nio/server/Request.java ! src/share/sample/nio/server/RequestHandler.java ! src/share/sample/nio/server/RequestServicer.java ! src/share/sample/nio/server/Sendable.java ! src/share/sample/nio/server/Server.java ! src/share/sample/nio/server/StringContent.java ! src/share/sample/nio/server/URLDumper.java ! src/share/sample/scripting/scriptpad/src/com/sun/sample/scriptpad/Main.java ! src/share/sample/scripting/scriptpad/src/resources/Main.js ! src/share/sample/scripting/scriptpad/src/resources/conc.js ! src/share/sample/scripting/scriptpad/src/resources/gui.js ! src/share/sample/scripting/scriptpad/src/resources/mm.js ! src/share/sample/scripting/scriptpad/src/resources/scriptpad.js ! src/share/sample/scripting/scriptpad/src/scripts/browse.js ! src/share/sample/scripting/scriptpad/src/scripts/insertfile.js ! src/share/sample/scripting/scriptpad/src/scripts/linewrap.js ! src/share/sample/scripting/scriptpad/src/scripts/mail.js ! src/share/sample/scripting/scriptpad/src/scripts/memmonitor.js ! src/share/sample/scripting/scriptpad/src/scripts/memory.js ! src/share/sample/scripting/scriptpad/src/scripts/textcolor.js ! src/share/sample/vm/clr-jvm/invoked.java ! src/share/sample/vm/clr-jvm/jinvoker.cpp ! src/share/sample/vm/clr-jvm/jinvokerExp.h ! src/share/sample/vm/jvm-clr/invoker.cpp ! src/share/sample/vm/jvm-clr/invoker.h ! src/share/sample/vm/jvm-clr/invoker.java ! src/share/sample/vm/jvm-clr/invokerExp.h ! src/share/transport/shmem/shmemBase.h ! src/share/transport/socket/socketTransport.c ! src/solaris/back/exec_md.c ! src/solaris/back/linker_md.c ! src/solaris/back/util_md.h ! src/solaris/bin/arm/jvm.cfg ! src/solaris/bin/i586/jvm.cfg ! src/solaris/bin/ppc/jvm.cfg ! src/solaris/bin/sparc/jvm.cfg ! src/solaris/classes/com/sun/management/UnixOperatingSystem.java ! src/solaris/classes/java/lang/ProcessEnvironment.java ! src/solaris/classes/java/lang/Terminator.java ! src/solaris/classes/java/net/DefaultInterface.java ! src/solaris/classes/sun/management/FileSystemImpl.java ! src/solaris/classes/sun/net/dns/ResolverConfigurationImpl.java ! src/solaris/classes/sun/nio/ch/DefaultSelectorProvider.java ! src/solaris/classes/sun/nio/ch/DevPollArrayWrapper.java ! src/solaris/classes/sun/nio/ch/DevPollSelectorImpl.java ! src/solaris/classes/sun/nio/ch/DevPollSelectorProvider.java ! src/solaris/classes/sun/nio/ch/EPoll.java ! src/solaris/classes/sun/nio/ch/EPollArrayWrapper.java ! src/solaris/classes/sun/nio/ch/EPollSelectorImpl.java ! src/solaris/classes/sun/nio/ch/InheritedChannel.java ! src/solaris/classes/sun/nio/ch/NativeThread.java ! src/solaris/classes/sun/nio/ch/PollArrayWrapper.java ! src/solaris/classes/sun/nio/ch/SolarisEventPort.java ! src/solaris/classes/sun/nio/ch/sctp/AssociationChange.java ! src/solaris/classes/sun/nio/ch/sctp/AssociationImpl.java ! src/solaris/classes/sun/nio/ch/sctp/PeerAddrChange.java ! src/solaris/classes/sun/nio/ch/sctp/ResultContainer.java ! src/solaris/classes/sun/nio/ch/sctp/SctpChannelImpl.java ! src/solaris/classes/sun/nio/ch/sctp/SctpMultiChannelImpl.java ! src/solaris/classes/sun/nio/ch/sctp/SctpNet.java ! src/solaris/classes/sun/nio/ch/sctp/SctpNotification.java ! src/solaris/classes/sun/nio/ch/sctp/SctpServerChannelImpl.java ! src/solaris/classes/sun/nio/ch/sctp/SendFailed.java ! src/solaris/classes/sun/nio/ch/sctp/Shutdown.java ! src/solaris/classes/sun/nio/fs/BsdFileStore.java ! src/solaris/classes/sun/nio/fs/BsdFileSystem.java ! src/solaris/classes/sun/nio/fs/BsdFileSystemProvider.java ! src/solaris/classes/sun/nio/fs/BsdNativeDispatcher.java ! src/solaris/classes/sun/nio/fs/DefaultFileTypeDetector.java ! src/solaris/classes/sun/nio/fs/LinuxFileSystem.java ! src/solaris/classes/sun/nio/fs/LinuxFileSystemProvider.java ! src/solaris/classes/sun/nio/fs/LinuxNativeDispatcher.java ! src/solaris/classes/sun/nio/fs/MacOSXFileSystem.java ! src/solaris/classes/sun/nio/fs/MacOSXFileSystemProvider.java ! src/solaris/classes/sun/nio/fs/MacOSXNativeDispatcher.java ! src/solaris/classes/sun/nio/fs/SolarisFileSystem.java ! src/solaris/classes/sun/nio/fs/SolarisFileSystemProvider.java ! src/solaris/classes/sun/nio/fs/SolarisNativeDispatcher.java ! src/solaris/classes/sun/nio/fs/UnixChannelFactory.java ! src/solaris/classes/sun/nio/fs/UnixFileSystem.java ! src/solaris/classes/sun/nio/fs/UnixNativeDispatcher.java ! src/solaris/classes/sun/print/CUPSPrinter.java ! src/solaris/classes/sun/security/smartcardio/PlatformPCSC.java ! src/solaris/classes/sun/tools/attach/BsdAttachProvider.java ! src/solaris/classes/sun/tools/attach/LinuxVirtualMachine.java ! src/solaris/classes/sun/tools/attach/SolarisVirtualMachine.java ! src/solaris/demo/jni/Poller/Client.java ! src/solaris/demo/jni/Poller/LinkedQueue.java ! src/solaris/demo/jni/Poller/Poller.c ! src/solaris/demo/jni/Poller/Poller.java ! src/solaris/demo/jni/Poller/PollingServer.java ! src/solaris/demo/jni/Poller/SimpleServer.java ! src/solaris/demo/jvmti/hprof/hprof_md.c ! src/solaris/doc/sun/man/man1/jcmd.1 ! src/solaris/instrument/EncodingSupport_md.c ! src/solaris/javavm/export/jvm_md.h ! src/solaris/native/com/sun/management/MacosxOperatingSystem.c ! src/solaris/native/com/sun/management/UnixOperatingSystem_md.c ! src/solaris/native/com/sun/security/auth/module/Unix.c ! src/solaris/native/java/io/UnixFileSystem_md.c ! src/solaris/native/java/io/canonicalize_md.c ! src/solaris/native/java/io/io_util_md.c ! src/solaris/native/java/io/io_util_md.h ! src/solaris/native/java/lang/ProcessEnvironment_md.c ! src/solaris/native/java/lang/java_props_macosx.c ! src/solaris/native/java/lang/java_props_macosx.h ! src/solaris/native/java/lang/java_props_md.c ! src/solaris/native/java/net/Inet4AddressImpl.c ! src/solaris/native/java/net/NetworkInterface.c ! src/solaris/native/java/net/PlainDatagramSocketImpl.c ! src/solaris/native/java/net/PlainSocketImpl.c ! src/solaris/native/java/net/SocketInputStream.c ! src/solaris/native/java/net/bsd_close.c ! src/solaris/native/java/net/net_util_md.h ! src/solaris/native/java/util/FileSystemPreferences.c ! src/solaris/native/sun/jdga/dgalock.c ! src/solaris/native/sun/management/FileSystemImpl.c ! src/solaris/native/sun/net/dns/ResolverConfigurationImpl.c ! src/solaris/native/sun/net/spi/DefaultProxySelector.c ! src/solaris/native/sun/nio/ch/DatagramChannelImpl.c ! src/solaris/native/sun/nio/ch/DatagramDispatcher.c ! src/solaris/native/sun/nio/ch/DevPollArrayWrapper.c ! src/solaris/native/sun/nio/ch/EPoll.c ! src/solaris/native/sun/nio/ch/EPollArrayWrapper.c ! src/solaris/native/sun/nio/ch/FileChannelImpl.c ! src/solaris/native/sun/nio/ch/FileDispatcherImpl.c ! src/solaris/native/sun/nio/ch/FileKey.c ! src/solaris/native/sun/nio/ch/IOUtil.c ! src/solaris/native/sun/nio/ch/Net.c ! src/solaris/native/sun/nio/ch/SolarisEventPort.c ! src/solaris/native/sun/nio/ch/sctp/Sctp.h ! src/solaris/native/sun/nio/ch/sctp/SctpChannelImpl.c ! src/solaris/native/sun/nio/ch/sctp/SctpNet.c ! src/solaris/native/sun/nio/ch/sctp/SctpServerChannelImpl.c ! src/solaris/native/sun/nio/fs/BsdNativeDispatcher.c ! src/solaris/native/sun/nio/fs/GnomeFileTypeDetector.c ! src/solaris/native/sun/nio/fs/LinuxNativeDispatcher.c ! src/solaris/native/sun/nio/fs/LinuxWatchService.c ! src/solaris/native/sun/nio/fs/MacOSXNativeDispatcher.c ! src/solaris/native/sun/nio/fs/SolarisNativeDispatcher.c ! src/solaris/native/sun/nio/fs/UnixNativeDispatcher.c ! src/solaris/native/sun/nio/fs/genSolarisConstants.c ! src/solaris/native/sun/nio/fs/genUnixConstants.c ! src/solaris/native/sun/security/jgss/wrapper/NativeFunc.c ! src/solaris/native/sun/security/pkcs11/j2secmod_md.c ! src/solaris/native/sun/security/pkcs11/wrapper/p11_md.c ! src/solaris/native/sun/security/smartcardio/pcsc_md.c ! src/solaris/npt/npt_md.h ! src/solaris/transport/socket/socket_md.c ! src/windows/classes/com/sun/management/OperatingSystem.java ! src/windows/classes/java/lang/ProcessEnvironment.java ! src/windows/classes/java/lang/Terminator.java ! src/windows/classes/java/net/DefaultInterface.java ! src/windows/classes/java/net/TwoStacksPlainSocketImpl.java ! src/windows/classes/sun/management/FileSystemImpl.java ! src/windows/classes/sun/net/dns/ResolverConfigurationImpl.java ! src/windows/classes/sun/nio/ch/NativeThread.java ! src/windows/classes/sun/nio/ch/SocketDispatcher.java ! src/windows/classes/sun/nio/ch/WindowsSelectorImpl.java ! src/windows/classes/sun/nio/ch/sctp/SctpChannelImpl.java ! src/windows/classes/sun/nio/ch/sctp/SctpMultiChannelImpl.java ! src/windows/classes/sun/nio/ch/sctp/SctpServerChannelImpl.java ! src/windows/classes/sun/nio/fs/WindowsDirectoryStream.java ! src/windows/classes/sun/nio/fs/WindowsFileSystemProvider.java ! src/windows/classes/sun/print/Win32PrintServiceLookup.java ! src/windows/classes/sun/security/krb5/internal/tools/Kinit.java ! src/windows/classes/sun/security/krb5/internal/tools/KinitOptions.java ! src/windows/classes/sun/security/krb5/internal/tools/Ktab.java ! src/windows/classes/sun/security/smartcardio/PlatformPCSC.java ! src/windows/classes/sun/tools/attach/WindowsAttachProvider.java ! src/windows/native/java/io/WinNTFileSystem_md.c ! src/windows/native/java/io/io_util_md.h ! src/windows/native/java/lang/java_props_md.c ! src/windows/native/java/net/DualStackPlainDatagramSocketImpl.c ! src/windows/native/java/net/Inet6AddressImpl.c ! src/windows/native/java/net/NetworkInterface.c ! src/windows/native/java/net/NetworkInterface.h ! src/windows/native/java/net/NetworkInterface_winXP.c ! src/windows/native/java/net/TwoStacksPlainDatagramSocketImpl.c ! src/windows/native/java/net/TwoStacksPlainSocketImpl.c ! src/windows/native/java/net/net_util_md.c ! src/windows/native/java/net/net_util_md.h ! src/windows/native/sun/management/FileSystemImpl.c ! src/windows/native/sun/net/www/protocol/http/ntlm/NTLMAuthSequence.c ! src/windows/native/sun/nio/ch/DatagramChannelImpl.c ! src/windows/native/sun/nio/ch/IOUtil.c ! src/windows/native/sun/nio/ch/Net.c ! src/windows/native/sun/nio/ch/SocketDispatcher.c ! src/windows/native/sun/nio/ch/WindowsAsynchronousSocketChannelImpl.c ! src/windows/native/sun/nio/ch/nio_util.h ! src/windows/native/sun/security/krb5/NativeCreds.c ! src/windows/native/sun/security/pkcs11/j2secmod_md.c ! src/windows/native/sun/security/provider/WinCAPISeedGenerator.c ! src/windows/native/sun/tools/attach/WindowsAttachProvider.c ! src/windows/native/sun/tools/attach/WindowsVirtualMachine.c ! src/windows/native/sun/tracing/dtrace/jvm_symbols_md.c ! src/windows/npt/npt_md.h ! src/windows/transport/shmem/shmem_md.c ! test/com/sun/crypto/provider/Cipher/DES/PaddingTest.java ! test/com/sun/crypto/provider/KeyGenerator/Test4628062.java ! test/com/sun/jdi/ConnectedVMs.java ! test/com/sun/jdi/EarlyReturnTest.java ! test/com/sun/jdi/ImmutableResourceTest.sh ! test/com/sun/jdi/JITDebug.sh ! test/com/sun/jdi/MethodEntryExitEvents.java ! test/com/sun/jdi/MethodExitReturnValuesTest.java ! test/com/sun/jdi/PrivateTransportTest.sh ! test/com/sun/jdi/ShellScaffold.sh ! test/com/sun/jdi/Solaris32AndSolaris64Test.sh ! test/com/sun/jdi/connect/spi/JdiLoadedByCustomLoader.sh ! test/com/sun/jndi/ldap/LdapTimeoutTest.java ! test/com/sun/management/OperatingSystemMXBean/TestTotalSwap.sh ! test/com/sun/net/httpserver/Test1.java ! test/com/sun/net/httpserver/Test10.java ! test/com/sun/net/httpserver/bugs/B6373555.java ! test/com/sun/nio/sctp/SctpChannel/SocketOptionTests.java ! test/com/sun/nio/sctp/SctpMultiChannel/SocketOptionTests.java ! test/com/sun/security/auth/login/ConfigFile/IllegalURL.java ! test/com/sun/servicetag/JavaServiceTagTest.java ! test/com/sun/servicetag/JavaServiceTagTest1.java ! test/com/sun/tools/attach/CommonSetup.sh ! test/demo/zipfs/basic.sh ! test/java/io/File/MaxPathLength.java ! test/java/io/File/basic.sh ! test/java/io/FileInputStream/LargeFileAvailable.java ! test/java/io/IOException/LastErrorString.java ! test/java/io/Serializable/badSubstByReplace/BadSubstByReplace.java ! test/java/io/Serializable/evolution/RenamePackage/run.sh ! test/java/io/Serializable/expectedStackTrace/ExpectedStackTrace.java ! test/java/io/Serializable/replaceStringArray/ReplaceStringArray.java ! test/java/io/Serializable/replaceWithNull/ReplaceWithNull.java ! test/java/io/Serializable/serialver/classpath/run.sh ! test/java/io/Serializable/serialver/nested/run.sh ! test/java/io/Serializable/verifyDynamicObjHandleTable/VerifyDynamicObjHandleTable.java ! test/java/lang/Character/CheckProp.java ! test/java/lang/Character/CheckScript.java ! test/java/lang/ClassLoader/deadlock/TestCrossDelegate.sh ! test/java/lang/ClassLoader/deadlock/TestOneWayDelegate.sh ! test/java/lang/Double/ToHexString.java ! test/java/lang/Runtime/exec/StreamsSurviveDestroy.java ! test/java/lang/StringCoding/CheckEncodings.sh ! test/java/lang/ThreadGroup/NullThreadName.java ! test/java/lang/ThreadGroup/Stop.java ! test/java/lang/annotation/loaderLeak/LoaderLeak.sh ! test/java/lang/annotation/loaderLeak/Main.java ! test/java/lang/instrument/appendToClassLoaderSearch/CommonSetup.sh ! test/java/lang/invoke/CallSiteTest.java ! test/java/lang/invoke/ClassValueTest.java ! test/java/lang/invoke/JavaDocExamplesTest.java ! test/java/lang/invoke/MethodHandlesTest.java ! test/java/lang/invoke/MethodTypeTest.java ! test/java/lang/invoke/PrivateInvokeTest.java ! test/java/lang/invoke/RicochetTest.java ! test/java/lang/invoke/ThrowExceptionsTest.java ! test/java/lang/management/BufferPoolMXBean/Basic.java ! test/java/lang/management/ManagementFactory/GetPlatformMXBeans.java ! test/java/lang/management/ManagementFactory/MBeanServerMXBeanUnsupportedTest.java ! test/java/lang/management/ManagementFactory/ThreadMXBeanProxy.java ! test/java/lang/management/MemoryMXBean/CollectionUsageThreshold.java ! test/java/lang/management/MemoryMXBean/MemoryTest.java ! test/java/lang/management/OperatingSystemMXBean/TestSystemLoadAvg.sh ! test/java/lang/management/PlatformLoggingMXBean/PlatformLoggingMXBeanTest.java ! test/java/lang/ref/Basic.java ! test/java/net/Authenticator/B4678055.java ! test/java/net/Authenticator/B4722333.java ! test/java/net/Authenticator/B4759514.java ! test/java/net/Authenticator/B4769350.java ! test/java/net/Authenticator/B4921848.java ! test/java/net/Authenticator/B4933582.java ! test/java/net/Authenticator/B4933582.sh ! test/java/net/Authenticator/B4962064.java ! test/java/net/CookieHandler/CookieManagerTest.java ! test/java/net/CookieHandler/NullUriCookieTest.java ! test/java/net/CookieHandler/TestHttpCookie.java ! test/java/net/DatagramPacket/ReuseBuf.java ! test/java/net/DatagramSocket/Send12k.java ! test/java/net/DatagramSocket/SendDatagramToBadAddress.java ! test/java/net/DatagramSocket/SetDatagramSocketImplFactory/ADatagramSocket.sh ! test/java/net/InetAddress/GetLocalHostWithSM.java ! test/java/net/NetworkInterface/NetParamsTest.java ! test/java/net/ProxySelector/LoopbackAddresses.java ! test/java/net/ProxySelector/ProxyTest.java ! test/java/net/Socket/OldSocketImpl.sh ! test/java/net/Socket/setReuseAddress/Basic.java ! test/java/net/Socket/setReuseAddress/Restart.java ! test/java/net/Socks/SocksServer.java ! test/java/net/Socks/SocksV4Test.java ! test/java/net/URL/B5086147.sh ! test/java/net/URL/OpenStream.java ! test/java/net/URL/PerConnectionProxy.java ! test/java/net/URL/Test.java ! test/java/net/URL/runconstructor.sh ! test/java/net/URLClassLoader/B5077773.sh ! test/java/net/URLClassLoader/closetest/CloseTest.java ! test/java/net/URLClassLoader/sealing/checksealed.sh ! test/java/net/URLConnection/6212146/test.sh ! test/java/net/URLConnection/B5052093.java ! test/java/net/URLConnection/Redirect307Test.java ! test/java/nio/Buffer/Basic-X.java.template ! test/java/nio/Buffer/Basic.java ! test/java/nio/Buffer/BasicByte.java ! test/java/nio/Buffer/BasicChar.java ! test/java/nio/Buffer/BasicDouble.java ! test/java/nio/Buffer/BasicFloat.java ! test/java/nio/Buffer/BasicInt.java ! test/java/nio/Buffer/BasicLong.java ! test/java/nio/Buffer/BasicShort.java ! test/java/nio/MappedByteBuffer/Truncate.java ! test/java/nio/channels/AsynchronousChannelGroup/AsExecutor.java ! test/java/nio/channels/AsynchronousChannelGroup/Basic.java ! test/java/nio/channels/AsynchronousChannelGroup/Restart.java ! test/java/nio/channels/AsynchronousServerSocketChannel/Basic.java ! test/java/nio/channels/DatagramChannel/BasicMulticastTests.java ! test/java/nio/channels/DatagramChannel/MulticastSendReceiveTests.java ! test/java/nio/channels/DatagramChannel/NetworkConfiguration.java ! test/java/nio/channels/DatagramChannel/Refused.java ! test/java/nio/channels/DatagramChannel/SelectWhenRefused.java ! test/java/nio/channels/DatagramChannel/SocketOptionTests.java ! test/java/nio/channels/FileChannel/ClosedByInterrupt.java ! test/java/nio/channels/Selector/OpRead.java ! test/java/nio/channels/Selector/lots_of_updates.sh ! test/java/nio/channels/ServerSocketChannel/SocketOptionTests.java ! test/java/nio/channels/SocketChannel/AdaptSocket.java ! test/java/nio/channels/SocketChannel/Open.sh ! test/java/nio/channels/SocketChannel/Shutdown.java ! test/java/nio/channels/SocketChannel/SocketOptionTests.java ! test/java/nio/channels/TestUtil.java ! test/java/nio/charset/Charset/NIOCharsetAvailabilityTest.java ! test/java/nio/charset/coders/CheckSJISMappingProp.sh ! test/java/nio/charset/coders/Errors.java ! test/java/nio/charset/spi/basic.sh ! test/java/nio/file/Files/CustomOptions.java ! test/java/nio/file/Path/PathOps.java ! test/java/nio/file/WatchService/Basic.java ! test/java/nio/file/WatchService/SensitivityModifier.java ! test/java/nio/file/WatchService/WithSecurityManager.java ! test/java/rmi/activation/checkusage/CheckUsage.java ! test/java/rmi/testlibrary/JavaVM.java ! test/java/rmi/transport/pinLastArguments/PinLastArguments.java ! test/java/security/Security/ClassLoaderDeadlock/ClassLoaderDeadlock.sh ! test/java/security/Security/ClassLoaderDeadlock/Deadlock.sh ! test/java/security/Security/ClassLoaderDeadlock/Deadlock2.sh ! test/java/security/Security/signedfirst/Dyn.sh ! test/java/security/Security/signedfirst/Static.sh ! test/java/text/Bidi/Bug6850113.java ! test/java/util/Collection/BiggernYours.java ! test/java/util/Collections/EmptyIterator.java ! test/java/util/Currency/CurrencyTest.java ! test/java/util/Hashtable/HashCode.java ! test/java/util/Hashtable/SimpleSerialization.java ! test/java/util/Locale/Bug6989440.java ! test/java/util/Locale/LocaleCategory.sh ! test/java/util/Map/Get.java ! test/java/util/PluggableLocale/CurrencyNameProviderTest.sh ! test/java/util/PluggableLocale/DateFormatSymbolsProviderTest.sh ! test/java/util/PluggableLocale/ExecTest.sh ! test/java/util/PluggableLocale/LocaleNameProviderTest.sh ! test/java/util/PluggableLocale/ProviderTest.java ! test/java/util/PluggableLocale/providersrc/DateFormatSymbolsProviderImpl.java ! test/java/util/PluggableLocale/providersrc/LocaleNameProviderImpl.java ! test/java/util/ResourceBundle/Bug4168625Test.java ! test/java/util/ResourceBundle/Bug6299235Test.sh ! test/java/util/ResourceBundle/Control/Bug6530694.java ! test/java/util/ServiceLoader/basic.sh ! test/java/util/Timer/Args.java ! test/java/util/Timer/KillThread.java ! test/java/util/UUID/UUIDTest.java ! test/java/util/concurrent/FutureTask/BlockingTaskExecutor.java ! test/java/util/concurrent/ThreadPoolExecutor/Custom.java ! test/java/util/concurrent/locks/Lock/FlakyMutex.java ! test/java/util/concurrent/locks/Lock/TimedAcquireLeak.java ! test/java/util/logging/LoggingDeadlock4.java ! test/java/util/regex/RegExTest.java ! test/java/util/zip/ZipFile/ManyZipFiles.java ! test/javax/crypto/SecretKeyFactory/FailOverTest.sh ! test/javax/imageio/stream/StreamCloserLeak/run_test.sh ! test/javax/management/remote/mandatory/URLTest.java ! test/javax/management/remote/mandatory/notif/ListenerScaleTest.java ! test/javax/naming/spi/DirectoryManager/GetContDirCtx.java ! test/javax/script/CommonSetup.sh ! test/javax/security/auth/Subject/Synch.java ! test/javax/security/auth/Subject/Synch2.java ! test/javax/security/auth/Subject/Synch3.java ! test/javax/security/auth/Subject/doAs/Test.sh ! test/javax/security/auth/login/LoginContext/ResetConfigModule.java ! test/javax/xml/crypto/dsig/SecurityManager/XMLDSigWithSecMgr.java ! test/lib/security/java.policy/Ext_AllPolicy.sh ! test/sun/invoke/util/ValueConversionsTest.java ! test/sun/misc/Cleaner/exitOnThrow.sh ! test/sun/misc/Version/Version.java ! test/sun/net/www/AuthHeaderTest.java ! test/sun/net/www/MarkResetTest.sh ! test/sun/net/www/http/ChunkedInputStream/ChunkedEncodingWithProgressMonitorTest.java ! test/sun/net/www/http/HttpClient/RetryPost.sh ! test/sun/net/www/http/KeepAliveCache/B5045306.java ! test/sun/net/www/httptest/HttpTransaction.java ! test/sun/net/www/httptest/TestHttpServer.java ! test/sun/net/www/protocol/file/DirPermissionDenied.sh ! test/sun/net/www/protocol/http/B6296310.java ! test/sun/net/www/protocol/http/B6299712.java ! test/sun/net/www/protocol/http/RelativeRedirect.java ! test/sun/net/www/protocol/http/ResponseCacheStream.java ! test/sun/net/www/protocol/http/SetChunkedStreamingMode.java ! test/sun/net/www/protocol/jar/B5105410.sh ! test/sun/net/www/protocol/jar/jarbug/run.sh ! test/sun/nio/cs/OLD/DoubleByteDecoder.java ! test/sun/nio/cs/OLD/DoubleByteEncoder.java ! test/sun/nio/cs/OLD/EUC_JP_LINUX_OLD.java ! test/sun/nio/cs/OLD/EUC_JP_OLD.java ! test/sun/nio/cs/OLD/EUC_JP_Open_OLD.java ! test/sun/nio/cs/OLD/JIS_X_0201_OLD.java ! test/sun/nio/cs/OLD/JIS_X_0208_Decoder.java ! test/sun/nio/cs/OLD/JIS_X_0208_Encoder.java ! test/sun/nio/cs/OLD/JIS_X_0208_OLD.java ! test/sun/nio/cs/OLD/JIS_X_0208_Solaris_Decoder.java ! test/sun/nio/cs/OLD/JIS_X_0208_Solaris_Encoder.java ! test/sun/nio/cs/OLD/JIS_X_0212_Decoder.java ! test/sun/nio/cs/OLD/JIS_X_0212_Encoder.java ! test/sun/nio/cs/OLD/JIS_X_0212_OLD.java ! test/sun/nio/cs/OLD/JIS_X_0212_Solaris_Decoder.java ! test/sun/nio/cs/OLD/JIS_X_0212_Solaris_Encoder.java ! test/sun/nio/cs/OLD/MS932_OLD.java ! test/sun/nio/cs/OLD/PCK_OLD.java ! test/sun/nio/cs/OLD/SJIS_OLD.java ! test/sun/nio/cs/OLD/SingleByteDecoder.java ! test/sun/nio/cs/OLD/SingleByteEncoder.java ! test/sun/nio/cs/OLD/TestIBMDB.java ! test/sun/nio/cs/StrCodingBenchmark.java ! test/sun/nio/cs/StrCodingBenchmarkDB.java ! test/sun/nio/cs/TestCp834_SBCS.java ! test/sun/nio/cs/TestStringCoding.java ! test/sun/nio/cs/TestUTF8.java ! test/sun/nio/cs/TestX11JIS0201.java ! test/sun/security/krb5/ConfPlusProp.java ! test/sun/security/krb5/DnsFallback.java ! test/sun/security/krb5/Krb5NameEquals.java ! test/sun/security/krb5/ParseConfig.java ! test/sun/security/krb5/auto/BadKdc.java ! test/sun/security/krb5/auto/BadKdc1.java ! test/sun/security/krb5/auto/BadKdc2.java ! test/sun/security/krb5/auto/BadKdc3.java ! test/sun/security/krb5/auto/BadKdc4.java ! test/sun/security/krb5/auto/BasicKrb5Test.java ! test/sun/security/krb5/auto/Context.java ! test/sun/security/krb5/auto/MaxRetries.java ! test/sun/security/krb5/auto/OneKDC.java ! test/sun/security/krb5/auto/SSL.java ! test/sun/security/krb5/auto/TcpTimeout.java ! test/sun/security/krb5/auto/W83.java ! test/sun/security/krb5/runNameEquals.sh ! test/sun/security/pkcs11/KeyStore/SecretKeysBasic.sh ! test/sun/security/pkcs11/Provider/ConfigQuotedString.sh ! test/sun/security/pkcs11/Provider/Login.sh ! test/sun/security/pkcs11/Secmod/AddPrivateKey.java ! test/sun/security/pkcs11/Secmod/AddTrustedCert.java ! test/sun/security/pkcs11/Secmod/Crypto.java ! test/sun/security/pkcs11/Secmod/GetPrivateKey.java ! test/sun/security/pkcs11/Secmod/JksSetPrivateKey.java ! test/sun/security/pkcs11/Secmod/TrustAnchors.java ! test/sun/security/pkcs11/SecmodTest.java ! test/sun/security/pkcs11/ec/ReadCertificates.java ! test/sun/security/pkcs11/ec/ReadPKCS12.java ! test/sun/security/pkcs11/ec/TestECDH.java ! test/sun/security/pkcs11/ec/TestECDSA.java ! test/sun/security/pkcs11/fips/TrustManagerTest.java ! test/sun/security/pkcs11/rsa/TestCACerts.java ! test/sun/security/pkcs11/sslecc/ClientJSSEServerJSSE.java ! test/sun/security/pkcs12/PKCS12SameKeyId.java ! test/sun/security/provider/DSA/TestKeyPairGenerator.java ! test/sun/security/provider/PolicyFile/Comparator.java ! test/sun/security/provider/PolicyFile/getinstance/getinstance.sh ! test/sun/security/provider/X509Factory/BigCRL.java ! test/sun/security/ssl/com/sun/net/ssl/SSLSecurity/ProviderTest.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/AppInputStream/ReadBlocksClose.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/AppInputStream/ReadHandshake.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/AppInputStream/ReadZeroBytes.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/AppInputStream/RemoveMarkReset.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/AppOutputStream/NoExceptionOnClose.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/ClientHandshaker/CipherSuiteOrder.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/ClientHandshaker/RSAExport.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/GenSSLConfigs/main.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/HandshakeOutStream/NullCerts.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/InputRecord/SSLSocketTimeoutNulls.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLContextImpl/BadKSProvider.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLContextImpl/BadTSProvider.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLContextImpl/GoodProvider.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl/RehandshakeFinished.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl/SSLEngineDeadlock.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSessionImpl/HashCodeMissing.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/AsyncSSLSocketClose.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/ClientModeClientAuth.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/ClientTimeout.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/CloseSocketException.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/InvalidateServerSessionRenegotiate.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/NewSocketMethods.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/NonAutoClose.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/NotifyHandshakeTest.sh ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/ReuseAddr.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/ReverseNameLookup.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/SSLSocketImplThrowsWrongExceptions.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/ServerTimeout.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/SetClientMode.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/UnconnectedSocketWrongExceptions.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/ServerHandshaker/AnonCipherWithWantClientAuth.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/ServerHandshaker/GetPeerHost.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SocketCreation/SocketCreation.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/ClientServer.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/PKIXExtendedTM.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/SelfIssuedCert.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/SunX509ExtendedTM.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/X509ExtendedTMEnabled.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/spi/ProviderInit.java ! test/sun/security/ssl/com/sun/net/ssl/internal/www/protocol/https/HttpsURLConnection/CriticalSubjectAltName.java ! test/sun/security/ssl/com/sun/net/ssl/internal/www/protocol/https/HttpsURLConnection/GetResponseCode.java ! test/sun/security/ssl/javax/net/ssl/FixingJavadocs/ImplicitHandshake.java ! test/sun/security/ssl/javax/net/ssl/FixingJavadocs/SSLSessionNulls.java ! test/sun/security/ssl/javax/net/ssl/FixingJavadocs/SSLSocketInherit.java ! test/sun/security/ssl/javax/net/ssl/NewAPIs/CheckMyTrustedKeystore.java ! test/sun/security/ssl/javax/net/ssl/NewAPIs/HttpsURLConnectionLocalCertificateChain.java ! test/sun/security/ssl/javax/net/ssl/NewAPIs/JSSERenegotiate.java ! test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLCtxAccessToSessCtx.java ! test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/AcceptLargeFragments.java ! test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/ExtendedKeySocket.java ! test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/NoAuthClientAuth.java ! test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngineResult/Deserialize.java ! test/sun/security/ssl/javax/net/ssl/NewAPIs/SessionCacheSizeTests.java ! test/sun/security/ssl/javax/net/ssl/NewAPIs/SessionTimeOutTests.java ! test/sun/security/ssl/javax/net/ssl/NewAPIs/testEnabledProtocols.java ! test/sun/security/ssl/javax/net/ssl/TLSv11/EmptyCertificateAuthorities.java ! test/sun/security/ssl/javax/net/ssl/TLSv11/ExportableBlockCipher.java ! test/sun/security/ssl/javax/net/ssl/TLSv11/ExportableStreamCipher.java ! test/sun/security/ssl/javax/net/ssl/TLSv11/GenericBlockCipher.java ! test/sun/security/ssl/javax/net/ssl/TLSv11/GenericStreamCipher.java ! test/sun/security/ssl/sanity/pluggability/CheckSSLContextExport.java ! test/sun/security/ssl/sun/net/www/http/ChunkedOutputStream/Test.java ! test/sun/security/ssl/sun/net/www/httpstest/HttpTransaction.java ! test/sun/security/ssl/sun/net/www/httpstest/TestHttpsServer.java ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/DNSIdentities.java ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/HttpsCreateSockTest.java ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/HttpsSocketFacTest.java ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/PostThruProxy.sh ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/PostThruProxyWithAuth.sh ! test/sun/security/ssl/sun/net/www/protocol/https/NewImpl/ComHostnameVerifier.java ! test/sun/security/ssl/sun/net/www/protocol/https/NewImpl/JavaxHostnameVerifier.java ! test/sun/security/ssl/templates/SSLEngineTemplate.java ! test/sun/security/ssl/templates/SSLSocketTemplate.java ! test/sun/security/tools/jarsigner/AlgOptions.sh ! test/sun/security/tools/jarsigner/JarSigningNonAscii.java ! test/sun/security/tools/jarsigner/LargeJarEntry.java ! test/sun/security/tools/jarsigner/PercentSign.sh ! test/sun/security/tools/jarsigner/concise_jarsigner.sh ! test/sun/security/tools/jarsigner/diffend.sh ! test/sun/security/tools/jarsigner/oldsig.sh ! test/sun/security/tools/keytool/AltProviderPath.sh ! test/sun/security/tools/keytool/CloneKeyAskPassword.sh ! test/sun/security/tools/keytool/NoExtNPE.sh ! test/sun/security/tools/keytool/SecretKeyKS.sh ! test/sun/security/tools/keytool/StandardAlgName.sh ! test/sun/security/tools/keytool/i18n.sh ! test/sun/security/tools/keytool/printssl.sh ! test/sun/security/tools/keytool/resource.sh ! test/sun/security/tools/keytool/standard.sh ! test/sun/security/tools/policytool/Alias.sh ! test/sun/security/tools/policytool/ChangeUI.sh ! test/sun/security/tools/policytool/OpenPolicy.sh ! test/sun/security/tools/policytool/SaveAs.sh ! test/sun/security/tools/policytool/UpdatePermissions.sh ! test/sun/security/tools/policytool/UsePolicy.sh ! test/sun/security/tools/policytool/i18n.sh ! test/sun/security/util/Oid/S11N.sh ! test/sun/security/util/Resources/NewNamesFormat.java ! test/sun/security/x509/AlgorithmId/ExtensibleAlgorithmId.java ! test/sun/tools/common/CommonSetup.sh ! test/sun/tools/jcmd/jcmd-Defaults.sh ! test/sun/tools/jcmd/jcmd-f.sh ! test/sun/tools/jcmd/jcmd-help-help.sh ! test/sun/tools/jcmd/jcmd-help.sh ! test/sun/tools/jcmd/jcmd-pid.sh ! test/sun/tools/jconsole/ImmutableResourceTest.sh ! test/sun/tools/jinfo/Basic.sh ! test/sun/tools/jrunscript/common.sh ! test/sun/tools/jrunscript/jrunscript-argsTest.sh ! test/sun/tools/jrunscript/jrunscript-eTest.sh ! test/sun/tools/jrunscript/jrunscript-fTest.sh ! test/sun/tools/jrunscript/jrunscriptTest.sh ! test/sun/tools/native2ascii/resources/ImmutableResourceTest.sh ! test/sun/util/logging/PlatformLoggerTest.java ! test/tools/launcher/DefaultLocaleTest.java ! test/tools/pack200/CommandLineTests.java ! test/tools/pack200/TimeStamp.java From Alan.Bateman at oracle.com Fri Nov 2 16:07:16 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 02 Nov 2012 16:07:16 +0000 Subject: 7197491: update copyright year to match last edit in jdk8 jdk repository In-Reply-To: <5093CE25.4040009@oracle.com> References: <5093C08A.8060705@oracle.com> <5093CE25.4040009@oracle.com> Message-ID: <5093EFB4.5070100@oracle.com> On 02/11/2012 13:44, Chris Hegarty wrote: > I'm not sure what you are looking for here, but I skimmed quickly up > and down the patch stopping occasionally, and the updated headers look > ok. > > On the general issue, is there a reason what on the 1st of January > ever source file cannot have its year range updated to that year. Then > just forget about it until the next year? Anyway, I'm ok with this as > is for now. > > -Chris. > I was just looking for a reviewer so that I could push this change and get it out of the way. Steve has the engine running in the get away car :-) I think there needs to be wider discussion as to how to deal with the copyright dates. It regularly comes up during code reviews because some reviewers insist on the dates being updated. I don't know if a yearly on Jan 1 will work as there will be outgoing changes in the team forests that will be missed. Also I'm not sure we want to leave it as long as a year anyway. Every few months or periodically at integration time feels right to me although I don't have a strong opinion on this topic. -Alan From philip.race at oracle.com Fri Nov 2 16:08:37 2012 From: philip.race at oracle.com (Phil Race) Date: Fri, 02 Nov 2012 09:08:37 -0700 Subject: 7197491: update copyright year to match last edit in jdk8 jdk repository In-Reply-To: <5093C08A.8060705@oracle.com> References: <5093C08A.8060705@oracle.com> Message-ID: <5093F005.8060607@oracle.com> Looks fine to me although I don't know how I can easily (ie not tediously) verify that a particular file is correctly updated to 2011 vs 2012 .. I don't think doing the updates at integration time is particularly desirable as it would suggest that a file is updated once by the engineer who is making the change and then again by the integration process, doubling (approx) the number of changesets. I'm fine with once or twice a year. For infrequently touched files it will maybe amount to the 2X changesets I suppose but still .. When you get around to the client changes will you be doing the closed sources too ? -phil. On 11/2/2012 5:46 AM, Alan Bateman wrote: > > Now for some noise. > > The copyright date in the source files needs updating. The man behind > the curtain is Steve Sides from the Quality and Release Engineering > team in Oracle. Jon pushed, on Steve's behalf, the update to the > langtools files recently [1], and Mikael updated hotspot [2]. The > elephant is the jdk repository as there are 3000+ files that need > their headers updated. > > To keep the disruption to a minimum I propose that we do the jdk > repository in two steps: non-client area now to jdk8/tl, and then the > client-area later in jdk8/awt once the changes get there. I use the > term "client-area" loosely to mean the source files for awt, swing, > font, java2d, etc. (and I appreciate that there is also a jdk8/2d > forest in use). To that end here is the proposed patch for today: > > http://cr.openjdk.java.net/~alanb/7197491/copyright.patch > > This patch updates the headers on 2370 files. I don't propose to > publish a webrev as it's just too big. > > This patch was created with: > > cd jdk > sh ../make/scripts/update_copyright_year.sh 2011 > sh ../make/scripts/update_copyright_year.sh 2012 > hg revert --no-backup `cat clientdirs.list` > hg diff -g > copyright.patch > > where clientdirs.list is most of the directories corresponding to the > client area. > > Note that I ran the update_copyright_year.sh script twice, once for > 2011 and then a second time for 2012. The reason for this is that > there are several hundred files in the jdk repository that were last > updated in 2011 but have an older date on the header. > > Reviewer welcome but I should say that I don't have cycles to spend on > this. Also the patch has an a very short shelf life. > > Finally, I think that there needs to be wider discussion as to how to > keep the headers from falling behind too much. Some people do update > the headers when editing files, some people (including myself) do not. > It seems to me that it should be done regularly anyway, perhaps every > few months or at integration time every so often. > > -Alan. > > [1] http://hg.openjdk.java.net/jdk8/tl/langtools/rev/9d47f4850714 > [2] http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/b9a9ed0f8eeb From lana.steuck at oracle.com Fri Nov 2 16:18:51 2012 From: lana.steuck at oracle.com (Lana Steuck) Date: Fri, 02 Nov 2012 09:18:51 -0700 Subject: 7197491: update copyright year to match last edit in jdk8 jdk repository In-Reply-To: <5093EFB4.5070100@oracle.com> References: <5093C08A.8060705@oracle.com> <5093CE25.4040009@oracle.com> <5093EFB4.5070100@oracle.com> Message-ID: <5093F26B.3020805@oracle.com> Hi Alan, Thank you for doing this. I see that Kumar volunteered to be your reviewer. So are you pushing the change today? > BTW: Would it make sense to integrate jdk8/tl -> master next week too? I thought about this too and yes, this would make everybody's life easier. I can start TL PIT as soon as you push the change (please let me know when you push it). Thank you, Lana On 11/02/2012 09:07 AM, Alan Bateman wrote: > On 02/11/2012 13:44, Chris Hegarty wrote: >> I'm not sure what you are looking for here, but I skimmed quickly up >> and down the patch stopping occasionally, and the updated headers >> look ok. >> >> On the general issue, is there a reason what on the 1st of January >> ever source file cannot have its year range updated to that year. >> Then just forget about it until the next year? Anyway, I'm ok with >> this as is for now. >> >> -Chris. >> > I was just looking for a reviewer so that I could push this change and > get it out of the way. Steve has the engine running in the get away > car :-) > > I think there needs to be wider discussion as to how to deal with the > copyright dates. It regularly comes up during code reviews because > some reviewers insist on the dates being updated. I don't know if a > yearly on Jan 1 will work as there will be outgoing changes in the > team forests that will be missed. Also I'm not sure we want to leave > it as long as a year anyway. Every few months or periodically at > integration time feels right to me although I don't have a strong > opinion on this topic. > > -Alan > From Alan.Bateman at oracle.com Fri Nov 2 16:22:09 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 02 Nov 2012 16:22:09 +0000 Subject: 7197491: update copyright year to match last edit in jdk8 jdk repository In-Reply-To: <5093F005.8060607@oracle.com> References: <5093C08A.8060705@oracle.com> <5093F005.8060607@oracle.com> Message-ID: <5093F331.7000505@oracle.com> On 02/11/2012 16:08, Phil Race wrote: > Looks fine to me although I don't know how I can easily (ie not > tediously) > verify that a particular file is correctly updated to 2011 vs 2012 .. Thanks, although I've already pushed it, just to get it out of the way. I looked at a few samples, as I think Chris and Kumar did, to make sure that they were okay. > > I don't think doing the updates at integration time is particularly > desirable > as it would suggest that a file is updated once by the engineer who is > making the change and then again by the integration process, doubling > (approx) the number of changesets. > > I'm fine with once or twice a year. For infrequently touched files > it will maybe amount to the 2X changesets I suppose but still .. I think Steve should start a thread on jdk8-dev about this, I don't think it matters too much except that doing it every few months feels, perhaps at integration time, about right to me. The other approach is of course to insist that people change the header when changing files but arguably that just adds noise to patches. > > When you get around to the client changes will you be doing the closed > sources too ? I'm just helping out today, I hadn't planned on running with this. -Alan. From darryl.mocek at oracle.com Fri Nov 2 16:37:16 2012 From: darryl.mocek at oracle.com (Darryl Mocek) Date: Fri, 02 Nov 2012 09:37:16 -0700 Subject: 7197491: update copyright year to match last edit in jdk8 jdk repository In-Reply-To: <5093C08A.8060705@oracle.com> References: <5093C08A.8060705@oracle.com> Message-ID: <5093F6BC.8040003@oracle.com> Alan, I was responsible for updating the copyrights for JavaME. I used a Perl script to update the copyright year in the source files. I can point you to the relevant information if you like. There were challenges as there are various copyrights in the source files (Oracle, Oracle + 3rd-party, 3rd party only, and no copyright), all with different formats, and even within the Oracle copyrights, people used subtle differences which caused difficulties. I ended updating all copyrights to a few formats and adding a post-commit script which scrubbed the copyright and notified the committer if the copyright wasn't in the correct format and didn't have an ending year (or sole year) which is the current year. There are plenty of options here: - Do nothing (policy) - Pre-commit script which changes the year automatically - Pre-commit script which rejects commit with wrong year - Post-commit script which flags a bad copyright, but accepts commit - Others Updating the copyright year as you commit is a good habit to get into, but ultimately there are files which never get touched which will need processing to update the year. I think doing this at the end/beginning of the year is good, we just need to make sure we get the copyright correct when processing. Darryl On 11/02/2012 05:46 AM, Alan Bateman wrote: > > Now for some noise. > > The copyright date in the source files needs updating. The man behind > the curtain is Steve Sides from the Quality and Release Engineering > team in Oracle. Jon pushed, on Steve's behalf, the update to the > langtools files recently [1], and Mikael updated hotspot [2]. The > elephant is the jdk repository as there are 3000+ files that need > their headers updated. > > To keep the disruption to a minimum I propose that we do the jdk > repository in two steps: non-client area now to jdk8/tl, and then the > client-area later in jdk8/awt once the changes get there. I use the > term "client-area" loosely to mean the source files for awt, swing, > font, java2d, etc. (and I appreciate that there is also a jdk8/2d > forest in use). To that end here is the proposed patch for today: > > http://cr.openjdk.java.net/~alanb/7197491/copyright.patch > > This patch updates the headers on 2370 files. I don't propose to > publish a webrev as it's just too big. > > This patch was created with: > > cd jdk > sh ../make/scripts/update_copyright_year.sh 2011 > sh ../make/scripts/update_copyright_year.sh 2012 > hg revert --no-backup `cat clientdirs.list` > hg diff -g > copyright.patch > > where clientdirs.list is most of the directories corresponding to the > client area. > > Note that I ran the update_copyright_year.sh script twice, once for > 2011 and then a second time for 2012. The reason for this is that > there are several hundred files in the jdk repository that were last > updated in 2011 but have an older date on the header. > > Reviewer welcome but I should say that I don't have cycles to spend on > this. Also the patch has an a very short shelf life. > > Finally, I think that there needs to be wider discussion as to how to > keep the headers from falling behind too much. Some people do update > the headers when editing files, some people (including myself) do not. > It seems to me that it should be done regularly anyway, perhaps every > few months or at integration time every so often. > > -Alan. > > [1] http://hg.openjdk.java.net/jdk8/tl/langtools/rev/9d47f4850714 > [2] http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/b9a9ed0f8eeb From philip.race at oracle.com Fri Nov 2 16:47:18 2012 From: philip.race at oracle.com (Phil Race) Date: Fri, 02 Nov 2012 09:47:18 -0700 Subject: 7197491: update copyright year to match last edit in jdk8 jdk repository In-Reply-To: <5093F6BC.8040003@oracle.com> References: <5093C08A.8060705@oracle.com> <5093F6BC.8040003@oracle.com> Message-ID: <5093F916.4030409@oracle.com> > but ultimately there are files which never get touched which will need processing to update the year. The policy has varied over the years, but presently the policy is not to update the year in files that have not been updated code-wise. -phil. On 11/2/2012 9:37 AM, Darryl Mocek wrote: > Alan, > > I was responsible for updating the copyrights for JavaME. I used > a Perl script to update the copyright year in the source files. I can > point you to the relevant information if you like. There were > challenges as there are various copyrights in the source files > (Oracle, Oracle + 3rd-party, 3rd party only, and no copyright), all > with different formats, and even within the Oracle copyrights, people > used subtle differences which caused difficulties. I ended updating > all copyrights to a few formats and adding a post-commit script which > scrubbed the copyright and notified the committer if the copyright > wasn't in the correct format and didn't have an ending year (or sole > year) which is the current year. > > There are plenty of options here: > > - Do nothing (policy) > - Pre-commit script which changes the year automatically > - Pre-commit script which rejects commit with wrong year > - Post-commit script which flags a bad copyright, but accepts commit > - Others > > Updating the copyright year as you commit is a good habit to get into, > but ultimately there are files which never get touched which will need > processing to update the year. I think doing this at the > end/beginning of the year is good, we just need to make sure we get > the copyright correct when processing. > > Darryl > > On 11/02/2012 05:46 AM, Alan Bateman wrote: >> >> Now for some noise. >> >> The copyright date in the source files needs updating. The man behind >> the curtain is Steve Sides from the Quality and Release Engineering >> team in Oracle. Jon pushed, on Steve's behalf, the update to the >> langtools files recently [1], and Mikael updated hotspot [2]. The >> elephant is the jdk repository as there are 3000+ files that need >> their headers updated. >> >> To keep the disruption to a minimum I propose that we do the jdk >> repository in two steps: non-client area now to jdk8/tl, and then the >> client-area later in jdk8/awt once the changes get there. I use the >> term "client-area" loosely to mean the source files for awt, swing, >> font, java2d, etc. (and I appreciate that there is also a jdk8/2d >> forest in use). To that end here is the proposed patch for today: >> >> http://cr.openjdk.java.net/~alanb/7197491/copyright.patch >> >> This patch updates the headers on 2370 files. I don't propose to >> publish a webrev as it's just too big. >> >> This patch was created with: >> >> cd jdk >> sh ../make/scripts/update_copyright_year.sh 2011 >> sh ../make/scripts/update_copyright_year.sh 2012 >> hg revert --no-backup `cat clientdirs.list` >> hg diff -g > copyright.patch >> >> where clientdirs.list is most of the directories corresponding to the >> client area. >> >> Note that I ran the update_copyright_year.sh script twice, once for >> 2011 and then a second time for 2012. The reason for this is that >> there are several hundred files in the jdk repository that were last >> updated in 2011 but have an older date on the header. >> >> Reviewer welcome but I should say that I don't have cycles to spend >> on this. Also the patch has an a very short shelf life. >> >> Finally, I think that there needs to be wider discussion as to how to >> keep the headers from falling behind too much. Some people do update >> the headers when editing files, some people (including myself) do >> not. It seems to me that it should be done regularly anyway, perhaps >> every few months or at integration time every so often. >> >> -Alan. >> >> [1] http://hg.openjdk.java.net/jdk8/tl/langtools/rev/9d47f4850714 >> [2] http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/b9a9ed0f8eeb > From kelly.ohair at oracle.com Fri Nov 2 16:47:53 2012 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Fri, 2 Nov 2012 09:47:53 -0700 Subject: 7197491: update copyright year to match last edit in jdk8 jdk repository In-Reply-To: <5093F331.7000505@oracle.com> References: <5093C08A.8060705@oracle.com> <5093F005.8060607@oracle.com> <5093F331.7000505@oracle.com> Message-ID: It looked fine to me. One of the reasons this has fallen through the cracks so much is because nobody has any time to do it. Completely automating it is risky, and it needs to be reviewed. So it needs an official owner and someone to automate the whole thing as much as possible. My recommendation would be that it should be done monthly, but I'd also like to see some stats generated along with it, e.g. per repository: changesets created in the month, source files changed for the month, lines changed, number of copyrights corrected, etc. But of course that takes some resources, someone to own it, and someone to review the changesets. The more frequently it happens, the smaller the patch to review. :^) -kto P.S. I discovered that if you used 'hg diff -C 1' or somehow reduced the context lines to just one line, the diff file becomes smaller, and easier to run through a grep looking for any non-Copyright lines that have changed. That's usually what I am looking for here, changes to anything but the Copyright lines. ;^) P.P.S. The script being used assumes that a changeset that touches any source file means that the copyright year needs updating. There are some exclusions, if the changeset comment mentions "rebranding" or "copyright" it is ignored. So if people are paranoid about this, they should review the script make/scripts/update_copyright_year.sh On Nov 2, 2012, at 9:22 AM, Alan Bateman wrote: > On 02/11/2012 16:08, Phil Race wrote: >> Looks fine to me although I don't know how I can easily (ie not tediously) >> verify that a particular file is correctly updated to 2011 vs 2012 .. > Thanks, although I've already pushed it, just to get it out of the way. I looked at a few samples, as I think Chris and Kumar did, to make sure that they were okay. > >> >> I don't think doing the updates at integration time is particularly desirable >> as it would suggest that a file is updated once by the engineer who is >> making the change and then again by the integration process, doubling >> (approx) the number of changesets. >> >> I'm fine with once or twice a year. For infrequently touched files >> it will maybe amount to the 2X changesets I suppose but still .. > I think Steve should start a thread on jdk8-dev about this, I don't think it matters too much except that doing it every few months feels, perhaps at integration time, about right to me. The other approach is of course to insist that people change the header when changing files but arguably that just adds noise to patches. > >> >> When you get around to the client changes will you be doing the closed sources too ? > I'm just helping out today, I hadn't planned on running with this. > > -Alan. From darryl.mocek at oracle.com Fri Nov 2 16:51:55 2012 From: darryl.mocek at oracle.com (Darryl Mocek) Date: Fri, 02 Nov 2012 09:51:55 -0700 Subject: 7197491: update copyright year to match last edit in jdk8 jdk repository In-Reply-To: <5093F916.4030409@oracle.com> References: <5093C08A.8060705@oracle.com> <5093F6BC.8040003@oracle.com> <5093F916.4030409@oracle.com> Message-ID: <5093FA2B.9030006@oracle.com> So the 3000+ files Alan is referring to are all files which have been modified but which haven't had their year updated? If we're not worried about files which haven't been modified then a pre/post-commit script will suffice and depending on how we implement it we might not need periodic updates. Darryl On 11/02/2012 09:47 AM, Phil Race wrote: > > but ultimately there are files which never get touched which will > need processing to update the year. > > The policy has varied over the years, but presently the policy is not to > update the year in files that have not been updated code-wise. > > -phil. > > On 11/2/2012 9:37 AM, Darryl Mocek wrote: >> Alan, >> >> I was responsible for updating the copyrights for JavaME. I used >> a Perl script to update the copyright year in the source files. I >> can point you to the relevant information if you like. There were >> challenges as there are various copyrights in the source files >> (Oracle, Oracle + 3rd-party, 3rd party only, and no copyright), all >> with different formats, and even within the Oracle copyrights, people >> used subtle differences which caused difficulties. I ended updating >> all copyrights to a few formats and adding a post-commit script which >> scrubbed the copyright and notified the committer if the copyright >> wasn't in the correct format and didn't have an ending year (or sole >> year) which is the current year. >> >> There are plenty of options here: >> >> - Do nothing (policy) >> - Pre-commit script which changes the year automatically >> - Pre-commit script which rejects commit with wrong year >> - Post-commit script which flags a bad copyright, but accepts commit >> - Others >> >> Updating the copyright year as you commit is a good habit to get >> into, but ultimately there are files which never get touched which >> will need processing to update the year. I think doing this at the >> end/beginning of the year is good, we just need to make sure we get >> the copyright correct when processing. >> >> Darryl >> >> On 11/02/2012 05:46 AM, Alan Bateman wrote: >>> >>> Now for some noise. >>> >>> The copyright date in the source files needs updating. The man >>> behind the curtain is Steve Sides from the Quality and Release >>> Engineering team in Oracle. Jon pushed, on Steve's behalf, the >>> update to the langtools files recently [1], and Mikael updated >>> hotspot [2]. The elephant is the jdk repository as there are 3000+ >>> files that need their headers updated. >>> >>> To keep the disruption to a minimum I propose that we do the jdk >>> repository in two steps: non-client area now to jdk8/tl, and then >>> the client-area later in jdk8/awt once the changes get there. I use >>> the term "client-area" loosely to mean the source files for awt, >>> swing, font, java2d, etc. (and I appreciate that there is also a >>> jdk8/2d forest in use). To that end here is the proposed patch for >>> today: >>> >>> http://cr.openjdk.java.net/~alanb/7197491/copyright.patch >>> >>> This patch updates the headers on 2370 files. I don't propose to >>> publish a webrev as it's just too big. >>> >>> This patch was created with: >>> >>> cd jdk >>> sh ../make/scripts/update_copyright_year.sh 2011 >>> sh ../make/scripts/update_copyright_year.sh 2012 >>> hg revert --no-backup `cat clientdirs.list` >>> hg diff -g > copyright.patch >>> >>> where clientdirs.list is most of the directories corresponding to >>> the client area. >>> >>> Note that I ran the update_copyright_year.sh script twice, once for >>> 2011 and then a second time for 2012. The reason for this is that >>> there are several hundred files in the jdk repository that were last >>> updated in 2011 but have an older date on the header. >>> >>> Reviewer welcome but I should say that I don't have cycles to spend >>> on this. Also the patch has an a very short shelf life. >>> >>> Finally, I think that there needs to be wider discussion as to how >>> to keep the headers from falling behind too much. Some people do >>> update the headers when editing files, some people (including >>> myself) do not. It seems to me that it should be done regularly >>> anyway, perhaps every few months or at integration time every so often. >>> >>> -Alan. >>> >>> [1] http://hg.openjdk.java.net/jdk8/tl/langtools/rev/9d47f4850714 >>> [2] http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/b9a9ed0f8eeb >> > From kelly.ohair at oracle.com Fri Nov 2 17:27:56 2012 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Fri, 2 Nov 2012 10:27:56 -0700 Subject: 7197491: update copyright year to match last edit in jdk8 jdk repository In-Reply-To: <5093FA2B.9030006@oracle.com> References: <5093C08A.8060705@oracle.com> <5093F6BC.8040003@oracle.com> <5093F916.4030409@oracle.com> <5093FA2B.9030006@oracle.com> Message-ID: All changes to JDK sources require a CR, an OpenJDK author name, and a review by a second OpenJDK author. So although you can automate the preparation of the commit, you cannot fully automate this process. There have been many discussions over the years about automating various changes, anything from tag generation, to whitespace normalization, and this copyright year change issue. Our policy has been that changesets need human authors, and all changes need a human review. -kto On Nov 2, 2012, at 9:51 AM, Darryl Mocek wrote: > So the 3000+ files Alan is referring to are all files which have been modified but which haven't had their year updated? If we're not worried about files which haven't been modified then a pre/post-commit script will suffice and depending on how we implement it we might not need periodic updates. > > Darryl > > On 11/02/2012 09:47 AM, Phil Race wrote: >> > but ultimately there are files which never get touched which will need processing to update the year. >> >> The policy has varied over the years, but presently the policy is not to >> update the year in files that have not been updated code-wise. >> >> -phil. >> >> On 11/2/2012 9:37 AM, Darryl Mocek wrote: >>> Alan, >>> >>> I was responsible for updating the copyrights for JavaME. I used a Perl script to update the copyright year in the source files. I can point you to the relevant information if you like. There were challenges as there are various copyrights in the source files (Oracle, Oracle + 3rd-party, 3rd party only, and no copyright), all with different formats, and even within the Oracle copyrights, people used subtle differences which caused difficulties. I ended updating all copyrights to a few formats and adding a post-commit script which scrubbed the copyright and notified the committer if the copyright wasn't in the correct format and didn't have an ending year (or sole year) which is the current year. >>> >>> There are plenty of options here: >>> >>> - Do nothing (policy) >>> - Pre-commit script which changes the year automatically >>> - Pre-commit script which rejects commit with wrong year >>> - Post-commit script which flags a bad copyright, but accepts commit >>> - Others >>> >>> Updating the copyright year as you commit is a good habit to get into, but ultimately there are files which never get touched which will need processing to update the year. I think doing this at the end/beginning of the year is good, we just need to make sure we get the copyright correct when processing. >>> >>> Darryl >>> >>> On 11/02/2012 05:46 AM, Alan Bateman wrote: >>>> >>>> Now for some noise. >>>> >>>> The copyright date in the source files needs updating. The man behind the curtain is Steve Sides from the Quality and Release Engineering team in Oracle. Jon pushed, on Steve's behalf, the update to the langtools files recently [1], and Mikael updated hotspot [2]. The elephant is the jdk repository as there are 3000+ files that need their headers updated. >>>> >>>> To keep the disruption to a minimum I propose that we do the jdk repository in two steps: non-client area now to jdk8/tl, and then the client-area later in jdk8/awt once the changes get there. I use the term "client-area" loosely to mean the source files for awt, swing, font, java2d, etc. (and I appreciate that there is also a jdk8/2d forest in use). To that end here is the proposed patch for today: >>>> >>>> http://cr.openjdk.java.net/~alanb/7197491/copyright.patch >>>> >>>> This patch updates the headers on 2370 files. I don't propose to publish a webrev as it's just too big. >>>> >>>> This patch was created with: >>>> >>>> cd jdk >>>> sh ../make/scripts/update_copyright_year.sh 2011 >>>> sh ../make/scripts/update_copyright_year.sh 2012 >>>> hg revert --no-backup `cat clientdirs.list` >>>> hg diff -g > copyright.patch >>>> >>>> where clientdirs.list is most of the directories corresponding to the client area. >>>> >>>> Note that I ran the update_copyright_year.sh script twice, once for 2011 and then a second time for 2012. The reason for this is that there are several hundred files in the jdk repository that were last updated in 2011 but have an older date on the header. >>>> >>>> Reviewer welcome but I should say that I don't have cycles to spend on this. Also the patch has an a very short shelf life. >>>> >>>> Finally, I think that there needs to be wider discussion as to how to keep the headers from falling behind too much. Some people do update the headers when editing files, some people (including myself) do not. It seems to me that it should be done regularly anyway, perhaps every few months or at integration time every so often. >>>> >>>> -Alan. >>>> >>>> [1] http://hg.openjdk.java.net/jdk8/tl/langtools/rev/9d47f4850714 >>>> [2] http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/b9a9ed0f8eeb >>> >> > From steve.sides at oracle.com Fri Nov 2 17:56:38 2012 From: steve.sides at oracle.com (Steve Sides) Date: Fri, 02 Nov 2012 10:56:38 -0700 Subject: 7197491: update copyright year to match last edit in jdk8 jdk repository In-Reply-To: <5093C08A.8060705@oracle.com> References: <5093C08A.8060705@oracle.com> Message-ID: <50940956.6060905@oracle.com> On 11/2/2012 5:46 AM, Alan Bateman wrote: > > Now for some noise. > > The copyright date in the source files needs updating. The man behind > the curtain is Steve Sides from the Quality and Release Engineering > team in Oracle. Jon pushed, on Steve's behalf, the update to the > langtools files recently [1], and Mikael updated hotspot [2]. The > elephant is the jdk repository as there are 3000+ files that need > their headers updated. > > To keep the disruption to a minimum I propose that we do the jdk > repository in two steps: non-client area now to jdk8/tl, and then the > client-area later in jdk8/awt once the changes get there. I use the > term "client-area" loosely to mean the source files for awt, swing, > font, java2d, etc. (and I appreciate that there is also a jdk8/2d > forest in use). To that end here is the proposed patch for today: > > http://cr.openjdk.java.net/~alanb/7197491/copyright.patch > > This patch updates the headers on 2370 files. I don't propose to > publish a webrev as it's just too big. It should be noted the every change is only a change to the copyright update line to either 2011 or 2012, no other changes. > > This patch was created with: > > cd jdk > sh ../make/scripts/update_copyright_year.sh 2011 > sh ../make/scripts/update_copyright_year.sh 2012 > hg revert --no-backup `cat clientdirs.list` > hg diff -g > copyright.patch > > where clientdirs.list is most of the directories corresponding to the > client area. > > Note that I ran the update_copyright_year.sh script twice, once for > 2011 and then a second time for 2012. The reason for this is that > there are several hundred files in the jdk repository that were last > updated in 2011 but have an older date on the header. > > Reviewer welcome but I should say that I don't have cycles to spend on > this. Also the patch has an a very short shelf life. > > Finally, I think that there needs to be wider discussion as to how to > keep the headers from falling behind too much. Some people do update > the headers when editing files, some people (including myself) do not. > It seems to me that it should be done regularly anyway, perhaps every > few months or at integration time every so often. The proprosal is to do this "peridocially" by re after this initial set...it just hasn't been done fore quite a while. Also, part of the EFP is "RE integrate year fix script into promotion build process". This should keep subsequent changesets substantially smaller. -steve > > -Alan. > > [1] http://hg.openjdk.java.net/jdk8/tl/langtools/rev/9d47f4850714 > [2] http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/b9a9ed0f8eeb From staffan.larsen at oracle.com Fri Nov 2 18:36:44 2012 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 2 Nov 2012 19:36:44 +0100 Subject: Preliminary review: Adding tracing of I/O calls Message-ID: <22767084-EAC2-4D87-800B-3E5E5BFC666A@oracle.com> This is a preliminary review request for adding an API for tracing I/O calls. For now, this is an empty infrastructure intended to enable diagnosing/tracing of i/o calls. A user of the API can register a listener and get callbacks for read and write operations on sockets and files. It does not (yet) cover asynchronous i/o calls. When not used, the implementation should add a minimum of overhead. To provide useful information to the user, FileInputStream, FileOutputStream and RandomAccessFile have been modified to keep track of the path they operate on (when available). Webrev: http://cr.openjdk.java.net/~sla/iotrace/webrev.00/ Feedback is most welcome, /Staffan From steve.sides at oracle.com Fri Nov 2 20:08:59 2012 From: steve.sides at oracle.com (Steve Sides) Date: Fri, 02 Nov 2012 13:08:59 -0700 Subject: 7197491: update copyright year to match last edit in jdk8 jdk repository In-Reply-To: References: <5093C08A.8060705@oracle.com> <5093F005.8060607@oracle.com> <5093F331.7000505@oracle.com> Message-ID: <5094285B.9070601@oracle.com> On 11/2/2012 9:47 AM, Kelly O'Hair wrote: > It looked fine to me. > > One of the reasons this has fallen through the cracks so much is > because nobody has any time to do it. > Completely automating it is risky, and it needs to be reviewed. So it > needs an official owner and I agree. You can't completely automate for reasons you mentioned earlier(or later?). RE is official owner since ultimately they are responsible and "must" make sure it is done prior to GA. So far developers only should check it, but RE must check it. > someone to automate the whole thing as much as possible. > > My recommendation would be that it should be done monthly, but I'd > also like to see some stats generated > along with it, e.g. per repository: changesets created in the month, > source files changed for the month, > lines changed, number of copyrights corrected, etc. > But of course that takes some resources, someone to own it, and > someone to review the changesets. RE owns it and will put at least part of the process in place. It's not so hard to run a check, and create a patch..which then needs to be reviewed before going further. By our own processes, some of it will need human intervention. We'll have to see what the cost of ownership is. :) Until GA it wouldn't stop anything, just generate a report and that would set into motion some updates that need to be done for some "next time". It's just a matter of how often to do this...get an acceptable number for "periodically". > The more frequently it happens, the smaller the patch to review. :^) That's the hope. -steve > -kto > > P.S. I discovered that if you used 'hg diff -C 1' or somehow reduced > the context lines to just one line, the > diff file becomes smaller, and easier to run through a grep looking > for any non-Copyright lines that have changed. > That's usually what I am looking for here, changes to anything but the > Copyright lines. ;^) > > P.P.S. The script being used assumes that a changeset that touches any > source file means that the copyright year > needs updating. There are some exclusions, if the changeset comment > mentions "rebranding" or "copyright" it > is ignored. So if people are paranoid about this, they should review > the script > make/scripts/update_copyright_year.sh > > On Nov 2, 2012, at 9:22 AM, Alan Bateman wrote: > >> On 02/11/2012 16:08, Phil Race wrote: >>> Looks fine to me although I don't know how I can easily (ie not >>> tediously) >>> verify that a particular file is correctly updated to 2011 vs 2012 .. >> Thanks, although I've already pushed it, just to get it out of the >> way. I looked at a few samples, as I think Chris and Kumar did, to >> make sure that they were okay. >> >>> >>> I don't think doing the updates at integration time is particularly >>> desirable >>> as it would suggest that a file is updated once by the engineer who is >>> making the change and then again by the integration process, doubling >>> (approx) the number of changesets. >>> >>> I'm fine with once or twice a year. For infrequently touched files >>> it will maybe amount to the 2X changesets I suppose but still .. >> I think Steve should start a thread on jdk8-dev about this, I don't >> think it matters too much except that doing it every few months >> feels, perhaps at integration time, about right to me. The other >> approach is of course to insist that people change the header when >> changing files but arguably that just adds noise to patches. >> >>> >>> When you get around to the client changes will you be doing the >>> closed sources too ? >> I'm just helping out today, I hadn't planned on running with this. >> >> -Alan. > From mandy.chung at oracle.com Fri Nov 2 20:12:33 2012 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 02 Nov 2012 13:12:33 -0700 Subject: Preliminary review: Adding tracing of I/O calls In-Reply-To: <22767084-EAC2-4D87-800B-3E5E5BFC666A@oracle.com> References: <22767084-EAC2-4D87-800B-3E5E5BFC666A@oracle.com> Message-ID: <50942931.4000001@oracle.com> Hi Staffan, On 11/2/2012 11:36 AM, Staffan Larsen wrote: > This is a preliminary review request for adding an API for tracing I/O calls. For now, this is an empty infrastructure intended to enable diagnosing/tracing of i/o calls. A user of the API can register a listener and get callbacks for read and write operations on sockets and files. It does not (yet) cover asynchronous i/o calls. When not used, the implementation should add a minimum of overhead. To provide useful information to the user, FileInputStream, FileOutputStream and RandomAccessFile have been modified to keep track of the path they operate on (when available). > > Webrev: http://cr.openjdk.java.net/~sla/iotrace/webrev.00/ This looks okay to me. Minor comments: sun/misc/IoTrace.java L36: should it be volatile in case another thread is setting to another listener? The *Begin() methods return a "handle" that will be passed to the *End() methods. Have you considered to define a type for it rather than Object? Do you have any performance measurement result that you can share? As for the unit tests, I know you have tests written for the feature that implements the listeners. I wonder if it's worth adding some sanity tests along with this change? Mandy > Feedback is most welcome, > /Staffan > From jim.gish at oracle.com Fri Nov 2 20:27:10 2012 From: jim.gish at oracle.com (Jim Gish) Date: Fri, 02 Nov 2012 16:27:10 -0400 Subject: Preliminary review: Adding tracing of I/O calls In-Reply-To: <50942931.4000001@oracle.com> References: <22767084-EAC2-4D87-800B-3E5E5BFC666A@oracle.com> <50942931.4000001@oracle.com> Message-ID: <50942C9E.7090408@oracle.com> Hi Staffan, This looks fine to me as well, but I had the same question as Mandy about performance. Given the sensitivity to changes in I/O it would be good to have some micro-benchmarks here. Thanks, Jim On 11/02/2012 04:12 PM, Mandy Chung wrote: > Hi Staffan, > > On 11/2/2012 11:36 AM, Staffan Larsen wrote: >> This is a preliminary review request for adding an API for tracing >> I/O calls. For now, this is an empty infrastructure intended to >> enable diagnosing/tracing of i/o calls. A user of the API can >> register a listener and get callbacks for read and write operations >> on sockets and files. It does not (yet) cover asynchronous i/o calls. >> When not used, the implementation should add a minimum of overhead. >> To provide useful information to the user, FileInputStream, >> FileOutputStream and RandomAccessFile have been modified to keep >> track of the path they operate on (when available). >> >> Webrev: http://cr.openjdk.java.net/~sla/iotrace/webrev.00/ > > This looks okay to me. > > Minor comments: > sun/misc/IoTrace.java L36: should it be volatile in case another > thread is setting to another listener? > > The *Begin() methods return a "handle" that will be passed to the > *End() methods. Have you considered to define a type for it rather > than Object? > > Do you have any performance measurement result that you can share? As > for the unit tests, I know you have tests written for the feature that > implements the listeners. I wonder if it's worth adding some sanity > tests along with this change? > > Mandy > >> Feedback is most welcome, >> /Staffan >> -- 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 staffan.larsen at oracle.com Fri Nov 2 20:47:19 2012 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 2 Nov 2012 21:47:19 +0100 Subject: Preliminary review: Adding tracing of I/O calls In-Reply-To: <50942931.4000001@oracle.com> References: <22767084-EAC2-4D87-800B-3E5E5BFC666A@oracle.com> <50942931.4000001@oracle.com> Message-ID: <08183803-2563-461C-9514-B7FAE1E14C10@oracle.com> On 2 nov 2012, at 21:12, Mandy Chung wrote: > Hi Staffan, > > On 11/2/2012 11:36 AM, Staffan Larsen wrote: >> This is a preliminary review request for adding an API for tracing I/O calls. For now, this is an empty infrastructure intended to enable diagnosing/tracing of i/o calls. A user of the API can register a listener and get callbacks for read and write operations on sockets and files. It does not (yet) cover asynchronous i/o calls. When not used, the implementation should add a minimum of overhead. To provide useful information to the user, FileInputStream, FileOutputStream and RandomAccessFile have been modified to keep track of the path they operate on (when available). >> >> Webrev: http://cr.openjdk.java.net/~sla/iotrace/webrev.00/ > > This looks okay to me. > > Minor comments: > sun/misc/IoTrace.java L36: should it be volatile in case another thread is setting to another listener? Yes, that could be a good idea. > The *Begin() methods return a "handle" that will be passed to the *End() methods. Have you considered to define a type for it rather than Object? Something like an empty interface, just to signal the intent? > Do you have any performance measurement result that you can share? I don't yet have any specific numbers - I'll try to get some. The testing I have done indicates that the overhead is negligible. But it would be good to confirm this. > As for the unit tests, I know you have tests written for the feature that implements the listeners. I wonder if it's worth adding some sanity tests along with this change? Yes, that is probably a good addition, too. Thanks! /Staffan > > Mandy > >> Feedback is most welcome, >> /Staffan >> From staffan.larsen at oracle.com Fri Nov 2 20:49:06 2012 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 2 Nov 2012 21:49:06 +0100 Subject: Preliminary review: Adding tracing of I/O calls In-Reply-To: <50942C9E.7090408@oracle.com> References: <22767084-EAC2-4D87-800B-3E5E5BFC666A@oracle.com> <50942931.4000001@oracle.com> <50942C9E.7090408@oracle.com> Message-ID: <73739B92-D928-49E7-861B-4DAA78F45582@oracle.com> Thanks, Jim. I'll come back with micro-benchmark numbers. /Staffan On 2 nov 2012, at 21:27, Jim Gish wrote: > Hi Staffan, > > This looks fine to me as well, but I had the same question as Mandy about performance. Given the sensitivity to changes in I/O it would be good to have some micro-benchmarks here. > > Thanks, > Jim > On 11/02/2012 04:12 PM, Mandy Chung wrote: >> Hi Staffan, >> >> On 11/2/2012 11:36 AM, Staffan Larsen wrote: >>> This is a preliminary review request for adding an API for tracing I/O calls. For now, this is an empty infrastructure intended to enable diagnosing/tracing of i/o calls. A user of the API can register a listener and get callbacks for read and write operations on sockets and files. It does not (yet) cover asynchronous i/o calls. When not used, the implementation should add a minimum of overhead. To provide useful information to the user, FileInputStream, FileOutputStream and RandomAccessFile have been modified to keep track of the path they operate on (when available). >>> >>> Webrev: http://cr.openjdk.java.net/~sla/iotrace/webrev.00/ >> >> This looks okay to me. >> >> Minor comments: >> sun/misc/IoTrace.java L36: should it be volatile in case another thread is setting to another listener? >> >> The *Begin() methods return a "handle" that will be passed to the *End() methods. Have you considered to define a type for it rather than Object? >> >> Do you have any performance measurement result that you can share? As for the unit tests, I know you have tests written for the feature that implements the listeners. I wonder if it's worth adding some sanity tests along with this change? >> >> Mandy >> >>> Feedback is most welcome, >>> /Staffan >>> > > -- > 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 kumar.x.srinivasan at oracle.COM Fri Nov 2 21:00:45 2012 From: kumar.x.srinivasan at oracle.COM (Kumar Srinivasan) Date: Fri, 02 Nov 2012 14:00:45 -0700 Subject: RFR: JDK-8001191: use -source 8 -target 8 when compiling the JDK In-Reply-To: <3F615A55-4238-4AFA-947F-BC1A019BC653@oracle.com> References: <5091635A.3010000@oracle.COM> <5091D2A9.7030901@oracle.com> <5091D9DF.8090400@oracle.com> <5091DCD4.2090409@oracle.com> <3F615A55-4238-4AFA-947F-BC1A019BC653@oracle.com> Message-ID: <5094347D.6030101@oracle.COM> Hi David, Kelly, Erik, as Kelly stated the jdk only build, uses the compiler from the import JDK, this works with -source 8 -target, which was prepped by Joe earlier. I also checked with a jdk only jprt build submission, which exposed another location that needed a bump. I have fixed the new infra build as well as Erik suggested, here is the new webrev: http://cr.openjdk.java.net/~ksrini/8001191/webrev.1/ The delta webrev ie. changes since the last reviewed: http://cr.openjdk.java.net/~ksrini/8001191/webrev.1/webrev.delta/index.html Thanks Kumar > If someone is doing a partial build (without langtools) the import jdk is used for javac compilation, not the boot jdk javac. > This has not changed. > The boot jdk javac is only used to build langtools and the hotspot serviceability agent. > > -kto > > On Oct 31, 2012, at 7:22 PM, David Holmes wrote: > >> Hi Jon, >> >> On 1/11/2012 12:09 PM, Jonathan Gibbons wrote: >>> David, >>> >>> For a long time now, the JDK 8 langtools repo has accepted -source 8 and >>> -target 8, so this should not affect which version of langtools you need >>> to use. Of course, you do need to make sure that these options are not >>> used with the bootstrap javac, which will typically be from JDK 7. >> That wasn't quite my query/concern - I wasn't very clear. If someone is doing a partial build, ie JDK repo only, they will now have to use a JDK8 boot JDK (or point to suitable langtools import?) - correct? (Where a full build would use the current langtools to build the rest of the JDK.) >> >> Just trying to understand if there may be places (JPRT?) where we've so far been able to use a JDK7 boot JDK but will no longer be able to. >> >> Thanks, >> David >> >>> -- Jon >>> >>> >>> On 10/31/2012 06:38 PM, David Holmes wrote: >>>> Hi Kumar, >>>> >>>> So after this jdk8 builds will have to use current langtools javac in >>>> order to work? >>>> >>>> The corresponding changes to the new build system will be needed as well. >>>> >>>> David >>>> >>>> On 1/11/2012 3:43 AM, Kumar Srinivasan wrote: >>>>> Hello, >>>>> >>>>> Please review changes to rev up the default -source and -target for jdk >>>>> compilation, >>>>> thus producing v52.0 class files. >>>>> >>>>> Bug is here: >>>>> https://jbs.oracle.com/bugs/browse/JDK-8001191 >>>>> >>>>> Webrev is here: >>>>> http://cr.openjdk.java.net/~ksrini/8001191/webrev.0/ >>>>> >>>>> Note: this webrev is generated against the master repository but changes >>>>> will be >>>>> pushed via tl after the tl-master sync is completed. >>>>> >>>>> Thanks >>>>> Kumar >>>>> From forax at univ-mlv.fr Fri Nov 2 21:03:06 2012 From: forax at univ-mlv.fr (Remi Forax) Date: Fri, 02 Nov 2012 22:03:06 +0100 Subject: Preliminary review: Adding tracing of I/O calls In-Reply-To: <73739B92-D928-49E7-861B-4DAA78F45582@oracle.com> References: <22767084-EAC2-4D87-800B-3E5E5BFC666A@oracle.com> <50942931.4000001@oracle.com> <50942C9E.7090408@oracle.com> <73739B92-D928-49E7-861B-4DAA78F45582@oracle.com> Message-ID: <5094350A.2080408@univ-mlv.fr> On 11/02/2012 09:49 PM, Staffan Larsen wrote: > Thanks, Jim. I'll come back with micro-benchmark numbers. > > /Staffan I think this code is a good candidate for the almost final design pattern :) http://weblogs.java.net/blog/forax/archive/2011/12/17/jsr-292-goodness-almost-static-final-field Basically you want a volatile value that becomes final so it can be optimized by the VM. cheers, R?mi > > On 2 nov 2012, at 21:27, Jim Gish wrote: > >> Hi Staffan, >> >> This looks fine to me as well, but I had the same question as Mandy about performance. Given the sensitivity to changes in I/O it would be good to have some micro-benchmarks here. >> >> Thanks, >> Jim >> On 11/02/2012 04:12 PM, Mandy Chung wrote: >>> Hi Staffan, >>> >>> On 11/2/2012 11:36 AM, Staffan Larsen wrote: >>>> This is a preliminary review request for adding an API for tracing I/O calls. For now, this is an empty infrastructure intended to enable diagnosing/tracing of i/o calls. A user of the API can register a listener and get callbacks for read and write operations on sockets and files. It does not (yet) cover asynchronous i/o calls. When not used, the implementation should add a minimum of overhead. To provide useful information to the user, FileInputStream, FileOutputStream and RandomAccessFile have been modified to keep track of the path they operate on (when available). >>>> >>>> Webrev: http://cr.openjdk.java.net/~sla/iotrace/webrev.00/ >>> This looks okay to me. >>> >>> Minor comments: >>> sun/misc/IoTrace.java L36: should it be volatile in case another thread is setting to another listener? >>> >>> The *Begin() methods return a "handle" that will be passed to the *End() methods. Have you considered to define a type for it rather than Object? >>> >>> Do you have any performance measurement result that you can share? As for the unit tests, I know you have tests written for the feature that implements the listeners. I wonder if it's worth adding some sanity tests along with this change? >>> >>> Mandy >>> >>>> Feedback is most welcome, >>>> /Staffan >>>> >> -- >> 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 jonathan.gibbons at oracle.com Fri Nov 2 21:04:16 2012 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Fri, 02 Nov 2012 21:04:16 +0000 Subject: hg: jdk8/tl/langtools: 8000483: cryptic error message when source file contains hash Message-ID: <20121102210418.C99B74774D@hg.openjdk.java.net> Changeset: 75c936d14c6a Author: vromero Date: 2012-11-01 12:47 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/75c936d14c6a 8000483: cryptic error message when source file contains hash Summary: cryptic error message when source file contains hash Reviewed-by: jjg, mcimadamore Contributed-by: vicente.romero at oracle.com ! src/share/classes/com/sun/tools/javac/parser/JavaTokenizer.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! test/tools/javac/quid/T6999438.out From mandy.chung at oracle.com Fri Nov 2 21:15:28 2012 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 2 Nov 2012 14:15:28 -0700 (PDT) Subject: Preliminary review: Adding tracing of I/O calls In-Reply-To: <08183803-2563-461C-9514-B7FAE1E14C10@oracle.com> References: <22767084-EAC2-4D87-800B-3E5E5BFC666A@oracle.com> <50942931.4000001@oracle.com> <08183803-2563-461C-9514-B7FAE1E14C10@oracle.com> Message-ID: <509437F0.4020409@oracle.com> On 11/2/2012 1:47 PM, Staffan Larsen wrote: > On 2 nov 2012, at 21:12, Mandy Chung wrote: > >> The *Begin() methods return a "handle" that will be passed to the *End() methods. Have you considered to define a type for it rather than Object? > Something like an empty interface, just to signal the intent? Yes I think so. A marker interface would suffice. >> Do you have any performance measurement result that you can share? > I don't yet have any specific numbers - I'll try to get some. The testing I have done indicates that the overhead is negligible. But it would be good to confirm this. refworkload is easy to run. You probably have talked with the performance team. You can find out from them which benchmarks, if they have any, are applicable for IO instrumentation. Mandy From jiangli.zhou at oracle.com Fri Nov 2 21:36:03 2012 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Fri, 02 Nov 2012 14:36:03 -0700 Subject: Review request:7197210: java/lang/invoke/CallSiteTest.java failing on armsflt In-Reply-To: <50943C3E.2020708@oracle.com> References: <5089C7E1.2040206@oracle.com> <7EC5973C-0E05-4DC1-AC64-143698B6D027@oracle.com> <5089D6D0.3070909@oracle.com> <5565E56D-0131-4A77-9C4D-D70B4B9F1FD0@oracle.com> <50901EC1.3080506@oracle.com> <50943C3E.2020708@oracle.com> Message-ID: <50943CC3.3020103@oracle.com> On 11/02/2012 02:33 PM, Jiangli Zhou wrote: > Redirecting the review request to core-libs-dev at openjdk.java.net mail > list (second try) ... > > Here is the webrev based on the jdk8/tl/jdk repository: > > http://cr.openjdk.java.net/~jiangli/7197210/webrev.02/ > > The '-XX:+IgnoreUnrecognizedVMOptions -XX:-VerifyDependencies' options > are added to following tests to reduce workload. The > -DRicochetTest.MAX_ARITY of RicochetTest is changed from 50 to10 to > reduce execution time on slower device and binary. Timeout settings > are also added to each test. The '-esa' option is added to > BigArityTest and MethodHandlesTest to enable asserts. > > java.lang.invoke.BigArityTest > java.lang.invoke.MethodHandlesTest > java.lang.invoke.CallSiteTest > java.lang.invoke.RicochetTest > > Thanks, > Jiangli > > On 10/30/2012 11:38 AM, Jiangli Zhou wrote: >> Hi Chris, >> >> Here is the updated webrev with added >> '-XX:+IgnoreUnrecognizedVMOptions -XX:-VerifyDependencies' options >> and timeout setting for the following tests: >> >> test.java.lang.invoke.RicochetTest >> test.java.lang.invoke.BigArityTest >> test.java.lang.invoke.MethodHandlesTest >> test.java.lang.invoke.CallSiteTest >> >> http://cr.openjdk.java.net/~jiangli/7197210/webrev.01/ >> >> Thanks, >> >> Jiangli > > From jonathan.gibbons at oracle.com Fri Nov 2 21:39:42 2012 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Fri, 02 Nov 2012 21:39:42 +0000 Subject: hg: jdk8/tl/langtools: 7169362: JDK8: Write compiler tests for repeating annotations for JDK8 Message-ID: <20121102213946.E72054774E@hg.openjdk.java.net> Changeset: bf76f4190ef8 Author: jjg Date: 2012-11-02 14:35 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/bf76f4190ef8 7169362: JDK8: Write compiler tests for repeating annotations for JDK8 Reviewed-by: darcy, jjg Contributed-by: sonali.goel at oracle.com + test/tools/javac/annotations/repeatingAnnotations/BaseAnnoAsContainerAnno.java + test/tools/javac/annotations/repeatingAnnotations/BaseAnnoAsContainerAnno.out + test/tools/javac/annotations/repeatingAnnotations/CyclicAnnotation.java + test/tools/javac/annotations/repeatingAnnotations/CyclicAnnotation.out + test/tools/javac/annotations/repeatingAnnotations/DefaultCasePresent.java + test/tools/javac/annotations/repeatingAnnotations/DocumentedContainerAnno.java + test/tools/javac/annotations/repeatingAnnotations/DocumentedContainerAnno.out + test/tools/javac/annotations/repeatingAnnotations/InheritedContainerAnno.java + test/tools/javac/annotations/repeatingAnnotations/InheritedContainerAnno.out + test/tools/javac/annotations/repeatingAnnotations/MissingContainer.java + test/tools/javac/annotations/repeatingAnnotations/MissingContainer.out + test/tools/javac/annotations/repeatingAnnotations/MissingDefaultCase1.java + test/tools/javac/annotations/repeatingAnnotations/MissingDefaultCase1.out + test/tools/javac/annotations/repeatingAnnotations/MissingDefaultCase2.java + test/tools/javac/annotations/repeatingAnnotations/MissingDefaultCase2.out + test/tools/javac/annotations/repeatingAnnotations/MissingValueMethod.java + test/tools/javac/annotations/repeatingAnnotations/MissingValueMethod.out + test/tools/javac/annotations/repeatingAnnotations/MultiLevelRepeatableAnno.java + test/tools/javac/annotations/repeatingAnnotations/MultipleAnnoMixedOrder.java + test/tools/javac/annotations/repeatingAnnotations/NoRepeatableAnno.java + test/tools/javac/annotations/repeatingAnnotations/NoRepeatableAnno.out + test/tools/javac/annotations/repeatingAnnotations/WrongReturnTypeForValue.java + test/tools/javac/annotations/repeatingAnnotations/WrongReturnTypeForValue.out From jiangli.zhou at oracle.com Fri Nov 2 22:05:11 2012 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Fri, 02 Nov 2012 15:05:11 -0700 Subject: Review request:7197210: java/lang/invoke/CallSiteTest.java failing on armsflt In-Reply-To: <50944337.3020006@oracle.com> References: <5089C7E1.2040206@oracle.com> <7EC5973C-0E05-4DC1-AC64-143698B6D027@oracle.com> <5089D6D0.3070909@oracle.com> <5565E56D-0131-4A77-9C4D-D70B4B9F1FD0@oracle.com> <50901EC1.3080506@oracle.com> <50943C3E.2020708@oracle.com> <50944337.3020006@oracle.com> Message-ID: <50944397.8030607@oracle.com> Hi Vladimir, Thanks for the review! Jiangli On 11/02/2012 03:03 PM, Vladimir Kozlov wrote: > Looks good. > > We know that VerifyDependencies has significant effect on debug VM > performance. > > Thanks, > Vladimir > > Jiangli Zhou wrote: >> Redirecting the review request to core-libs-dev at openjdk.java.net mail >> list (second try) ... >> >> Here is the webrev based on the jdk8/tl/jdk repository: >> >> http://cr.openjdk.java.net/~jiangli/7197210/webrev.02/ >> >> The '-XX:+IgnoreUnrecognizedVMOptions -XX:-VerifyDependencies' >> options are added to following tests to reduce workload. The >> -DRicochetTest.MAX_ARITY of RicochetTest is changed from 50 to10 to >> reduce execution time on slower device and binary. Timeout settings >> are also added to each test. The '-esa' option is added to >> BigArityTest and MethodHandlesTest to enable asserts. >> >> java.lang.invoke.BigArityTest >> java.lang.invoke.MethodHandlesTest >> java.lang.invoke.CallSiteTest >> java.lang.invoke.RicochetTest >> >> Thanks, >> Jiangli >> >> On 10/30/2012 11:38 AM, Jiangli Zhou wrote: >>> Hi Chris, >>> >>> Here is the updated webrev with added >>> '-XX:+IgnoreUnrecognizedVMOptions -XX:-VerifyDependencies' options >>> and timeout setting for the following tests: >>> >>> test.java.lang.invoke.RicochetTest >>> test.java.lang.invoke.BigArityTest >>> test.java.lang.invoke.MethodHandlesTest >>> test.java.lang.invoke.CallSiteTest >>> >>> http://cr.openjdk.java.net/~jiangli/7197210/webrev.01/ >>> >>> Thanks, >>> >>> Jiangli >> >> From kelly.ohair at oracle.com Fri Nov 2 22:15:33 2012 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Fri, 2 Nov 2012 15:15:33 -0700 Subject: 7197491: update copyright year to match last edit in jdk8 jdk repository In-Reply-To: <5094285B.9070601@oracle.com> References: <5093C08A.8060705@oracle.com> <5093F005.8060607@oracle.com> <5093F331.7000505@oracle.com> <5094285B.9070601@oracle.com> Message-ID: <573F870C-499D-4DC2-A9ED-A6B5209C7858@oracle.com> Include me on any review requests for these things, I'll be happy to be a reviewer. -kto On Nov 2, 2012, at 1:08 PM, Steve Sides wrote: > On 11/2/2012 9:47 AM, Kelly O'Hair wrote: >> >> It looked fine to me. >> >> One of the reasons this has fallen through the cracks so much is because nobody has any time to do it. >> Completely automating it is risky, and it needs to be reviewed. So it needs an official owner and > I agree. You can't completely automate for reasons you mentioned earlier(or later?). > RE is official owner since ultimately they are responsible and "must" make sure it is done prior to GA. > So far developers only should check it, but RE must check it. > >> someone to automate the whole thing as much as possible. >> >> My recommendation would be that it should be done monthly, but I'd also like to see some stats generated >> along with it, e.g. per repository: changesets created in the month, source files changed for the month, >> lines changed, number of copyrights corrected, etc. >> But of course that takes some resources, someone to own it, and someone to review the changesets. > RE owns it and will put at least part of the process in place. It's not so hard to run a check, and create a patch..which then needs to be reviewed before going further. > By our own processes, some of it will need human intervention. We'll have to see what the cost of ownership is. :) > > Until GA it wouldn't stop anything, just generate a report and that would set into motion some updates that need to be done for some "next time". > It's just a matter of how often to do this...get an acceptable number for "periodically". > >> The more frequently it happens, the smaller the patch to review. :^) > That's the hope. > > -steve > > >> -kto >> >> P.S. I discovered that if you used 'hg diff -C 1' or somehow reduced the context lines to just one line, the >> diff file becomes smaller, and easier to run through a grep looking for any non-Copyright lines that have changed. >> That's usually what I am looking for here, changes to anything but the Copyright lines. ;^) >> >> P.P.S. The script being used assumes that a changeset that touches any source file means that the copyright year >> needs updating. There are some exclusions, if the changeset comment mentions "rebranding" or "copyright" it >> is ignored. So if people are paranoid about this, they should review the script >> make/scripts/update_copyright_year.sh >> >> On Nov 2, 2012, at 9:22 AM, Alan Bateman wrote: >> >>> On 02/11/2012 16:08, Phil Race wrote: >>>> Looks fine to me although I don't know how I can easily (ie not tediously) >>>> verify that a particular file is correctly updated to 2011 vs 2012 .. >>> Thanks, although I've already pushed it, just to get it out of the way. I looked at a few samples, as I think Chris and Kumar did, to make sure that they were okay. >>> >>>> >>>> I don't think doing the updates at integration time is particularly desirable >>>> as it would suggest that a file is updated once by the engineer who is >>>> making the change and then again by the integration process, doubling >>>> (approx) the number of changesets. >>>> >>>> I'm fine with once or twice a year. For infrequently touched files >>>> it will maybe amount to the 2X changesets I suppose but still .. >>> I think Steve should start a thread on jdk8-dev about this, I don't think it matters too much except that doing it every few months feels, perhaps at integration time, about right to me. The other approach is of course to insist that people change the header when changing files but arguably that just adds noise to patches. >>> >>>> >>>> When you get around to the client changes will you be doing the closed sources too ? >>> I'm just helping out today, I hadn't planned on running with this. >>> >>> -Alan. >> > From Alan.Bateman at oracle.com Fri Nov 2 22:21:33 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 02 Nov 2012 22:21:33 +0000 Subject: Preliminary review: Adding tracing of I/O calls In-Reply-To: <22767084-EAC2-4D87-800B-3E5E5BFC666A@oracle.com> References: <22767084-EAC2-4D87-800B-3E5E5BFC666A@oracle.com> Message-ID: <5094476D.3090501@oracle.com> On 02/11/2012 18:36, Staffan Larsen wrote: > This is a preliminary review request for adding an API for tracing I/O calls. For now, this is an empty infrastructure intended to enable diagnosing/tracing of i/o calls. A user of the API can register a listener and get callbacks for read and write operations on sockets and files. It does not (yet) cover asynchronous i/o calls. When not used, the implementation should add a minimum of overhead. To provide useful information to the user, FileInputStream, FileOutputStream and RandomAccessFile have been modified to keep track of the path they operate on (when available). > > Webrev: http://cr.openjdk.java.net/~sla/iotrace/webrev.00/ > > Feedback is most welcome, > /Staffan > Part of me is a somewhat disappointed to see hooks going into the I/O paths, but I understand why it needs to be done. I see the mails that getting some performance figures on the overhead and that would be good to have. I think IoTrace/IoTraceListener needs to have some javadoc. I suggest this because it's impossible to implement IoTraceListener (even in the JDK) without some documentation as to how it is used. I see there is a block comment in IoTraceListener but there are other things that an implementer needs to know, particularly as to possible behavior when there is an I/O error. Looking at the usages then it looks like in *End might not be called, in other cases it can be called with 0 when there is an error. I also see mails about IoTrace.listener needing to be volatile, that would be good to do. I also think it would be useful to have a basic sanity test of the hooks. I realize there will be product usage elsewhere but we should have something simple in the jdk repository too. In FileInputStream, FileOutputStream and FileChannelImpl then the comment on path is that it is null "if there is no file" but I think this should say that the stream (or parent stream in the case of a file channel) is created with a file descriptor. In SocketChannelImpl then if the channel is configured non-blocking socketReadEnd will be called without a socketReadBegin. If this is intended then it will be something for the IoTrace/IoTraceListener javadoc. I realize the focus is blocking I/O for now but one thing to know is that timed read operations on socket adapters (the socket obtained by calling SocketChannel's socket method) configures the socket channel to be non-blocking so this means that this I/O will not be observed by the IoTraceListener. In both FileChannelImpl and SocketChannelImpl then normalize will now be called twice on each return status, I don't expect this will be observable from a performance perspective. SolarisUserDefinedFileAttributeView - this is I/O on a file's extended attributes rather than its contents, it might not interesting to the IoTraceListener. UnixChannelFactory L137, this line is getting long, might be better to go into a second line. WindowsChannelFactory - one thing to be aware of is newFileChannel will also be called when open named streams so pathForWindows won't be the name of a file that you see on the file system. I don't know if this is interesting here or not, it should be rare. That's all I have. -Alan. From joe.darcy at oracle.com Fri Nov 2 22:44:05 2012 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 02 Nov 2012 15:44:05 -0700 Subject: CloneNotSupportedException should extends RuntimeException not Exception In-Reply-To: <507BEBD0.1080009@oracle.com> References: <507AE604.3060204@univ-mlv.fr> <507B3DF8.1030902@oracle.com> <507BE551.9090607@oracle.com> <507BEBD0.1080009@oracle.com> Message-ID: <50944CB5.6050101@oracle.com> On 10/15/2012 03:56 AM, Alan Bateman wrote: > On 15/10/2012 11:28, Joel Borggr?n-Franck wrote: >> On 10/15/2012 12:34 AM, David Holmes wrote: >> > Remi, >> > >> > This ship has sailed you can't recall it. >> CloneNotSupportedException > is a checked exception and needs to >> remain so for source and binary >> > compatibility. >> > >> >> I see how this is source incompatible and also behaviorally >> incompatible in a few cases, but how is this binary incompatible? > I think you're right as there wouldn't be a linkage error. > > his thread reminds of Joe Darcy's classic blog on compatibility kinds: > > https://blogs.oracle.com/darcy/entry/kinds_of_compatibility > Hello, Catching up on email, changing the supertype of an exception from Exception to RuntimeException exception is *binary* compatible under the rules for superclasses and interfaces evolution given in the JLS: "Changing the direct superclass or the set of direct superinterfaces of a class type will not break compatibility with pre-existing binaries, provided that the total set of superclasses or superinterfaces, respectively, of the class type loses no members." http://docs.oracle.com/javase/specs/jls/se7/html/jls-13.html#jls-13.4.4 Since the subtype (RuntimeException) has all the members of its parent (Exception), and also the same set of constructor signatures, this change is binary compatible and will *not* cause a linkage error at runtime (which is the definition of binary compatible). As Brian pointed out, there is a small risk of source and behavioural compatibility change is a try block had both catch clauses for CloneNotSupportedException and RuntimeException. That in and of itself doesn't rule out such a change since our general evolution policy for the JDK is: > 1. Don't break binary compatibility (as defined in the Java > Language Specification). > > 2. Avoid introducing source incompatibilities. > > 3. Manage behavioral compatibility changes. http://cr.openjdk.java.net/~darcy/OpenJdkDevGuide/OpenJdkDevelopersGuide.v0.775.html#general_evolution_policy In some lesser-used corners of the platform, we've made just this sort of change with exception superclasses, in full awareness of the potential issues: 6519115 MirroredTypeException thrown but should be MirroredTypesException http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6519115 http://hg.openjdk.java.net/jdk7/jdk7/langtools/rev/852d8bb356bc However, given the prevalence of CloneNotSupportedException, I don't think making it an unchecked exception after it was a checked exception is appropriate. -Joe From lance.andersen at oracle.com Fri Nov 2 22:57:50 2012 From: lance.andersen at oracle.com (Lance Andersen - Oracle) Date: Fri, 2 Nov 2012 15:57:50 -0700 (PDT) Subject: Review request 8002212 - adding read/writeObject to additional SerialXXX classes Message-ID: This is similar to 8001536, just additional classes. This adds read/writeObject, equals, clone methods to additional SerialXXX classes SQE, JCK and JDBC Unit tests all pass. The webrev can be viewed at http://cr.openjdk.java.net/~lancea/8002212/webrev.00 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 forax at univ-mlv.fr Fri Nov 2 23:05:32 2012 From: forax at univ-mlv.fr (Remi Forax) Date: Sat, 03 Nov 2012 00:05:32 +0100 Subject: CloneNotSupportedException should extends RuntimeException not Exception In-Reply-To: <50944CB5.6050101@oracle.com> References: <507AE604.3060204@univ-mlv.fr> <507B3DF8.1030902@oracle.com> <507BE551.9090607@oracle.com> <507BEBD0.1080009@oracle.com> <50944CB5.6050101@oracle.com> Message-ID: <509451BC.6030402@univ-mlv.fr> On 11/02/2012 11:44 PM, Joe Darcy wrote: > On 10/15/2012 03:56 AM, Alan Bateman wrote: >> On 15/10/2012 11:28, Joel Borggr?n-Franck wrote: >>> On 10/15/2012 12:34 AM, David Holmes wrote: >>> > Remi, >>> > >>> > This ship has sailed you can't recall it. >>> CloneNotSupportedException > is a checked exception and needs to >>> remain so for source and binary >>> > compatibility. >>> > >>> >>> I see how this is source incompatible and also behaviorally >>> incompatible in a few cases, but how is this binary incompatible? >> I think you're right as there wouldn't be a linkage error. >> >> his thread reminds of Joe Darcy's classic blog on compatibility kinds: >> >> https://blogs.oracle.com/darcy/entry/kinds_of_compatibility >> > > Hello, > > Catching up on email, changing the supertype of an exception from > Exception to RuntimeException exception is *binary* compatible under > the rules for superclasses and interfaces evolution given in the JLS: > > "Changing the direct superclass or the set of direct superinterfaces > of a class type will not break compatibility with pre-existing > binaries, provided that the total set of superclasses or > superinterfaces, respectively, of the class type loses no members." > http://docs.oracle.com/javase/specs/jls/se7/html/jls-13.html#jls-13.4.4 > > Since the subtype (RuntimeException) has all the members of its parent > (Exception), and also the same set of constructor signatures, this > change is binary compatible and will *not* cause a linkage error at > runtime (which is the definition of binary compatible). > > As Brian pointed out, there is a small risk of source and behavioural > compatibility change is a try block had both catch clauses for > CloneNotSupportedException and RuntimeException. That in and of > itself doesn't rule out such a change since our general evolution > policy for the JDK is: > >> 1. Don't break binary compatibility (as defined in the Java >> Language Specification). >> >> 2. Avoid introducing source incompatibilities. >> >> 3. Manage behavioral compatibility changes. > http://cr.openjdk.java.net/~darcy/OpenJdkDevGuide/OpenJdkDevelopersGuide.v0.775.html#general_evolution_policy > > > In some lesser-used corners of the platform, we've made just this sort > of change with exception superclasses, in full awareness of the > potential issues: > > 6519115 MirroredTypeException thrown but should be > MirroredTypesException > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6519115 > http://hg.openjdk.java.net/jdk7/jdk7/langtools/rev/852d8bb356bc > > However, given the prevalence of CloneNotSupportedException, I don't > think making it an unchecked exception after it was a checked > exception is appropriate. We also add a common super types (ReflectiveOperationException) of all exceptions thrown by reflection code. But in that case, because the exception ReflectiveOperationException didn't exist before, there was no problem of compatibility. BTW, I've found a way to solve the problem of CloneNotSupportedException, I don't say that we should do that, The idea just to explicitly change the JLS to say that CloneNotSupportedException is now unchecked. In that case, this is a binary compatible change and there is no behavioural incompatibility. > > -Joe > R?mi From forax at univ-mlv.fr Fri Nov 2 23:42:51 2012 From: forax at univ-mlv.fr (Remi Forax) Date: Sat, 03 Nov 2012 00:42:51 +0100 Subject: Review request 8002212 - adding read/writeObject to additional SerialXXX classes In-Reply-To: References: Message-ID: <50945A7B.6030309@univ-mlv.fr> On 11/02/2012 11:57 PM, Lance Andersen - Oracle wrote: > This is similar to 8001536, just additional classes. > > This adds read/writeObject, equals, clone methods to additional SerialXXX classes > > SQE, JCK and JDBC Unit tests all pass. > > The webrev can be viewed at http://cr.openjdk.java.net/~lancea/8002212/webrev.00 Hi Lance, in SerialArray.equals(), I prefer return baseType == sa.baseType && baseTypeName.equals(sa.baseTypeName)) && Arrays.equals(elements, sa.elements); instead of if(baseType == sa.baseType && baseTypeName.equals(sa.baseTypeName)) { return Arrays.equals(elements, sa.elements); } In SerialDataLink, do you really need readObject/writeObject given that you call the default implementations. in SerialJavaObject, in equals, you should declare a local variable like in SerialDataLink.equals, even if the local varialble is used once, it's more readable. Also like in SerialArray.equals, you can do a return directly instead of if(...) return true. in clone(), you can use the diamond syntax, sjo.chain = new Vector<>(chain); in setWarning(), you can use the diamond syntax as the original source does. and in readObject, you can use the diamond syntax too. In readObject, you forget to throw an exception if there are some static fields in getClass().getFields() as the constructor does (this code can be moved in a private static method). Also, you should add a comment that because you call getClass() on obj, there is an implicit null check. This can be fixed as a separated bug or not but the code of method SerialJavaObject.getField() is weird, the code checks if fields can be null, but fields is never null. Also, cloning the field array is perhaps a better idea if the reflection implementation doesn't cache the array of fields. In SerialRef.equals, again, if(...) return should be transformed into return ... > > Best > Lance cheers, R?mi > > 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 Sat Nov 3 00:46:33 2012 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Fri, 2 Nov 2012 20:46:33 -0400 Subject: Review request 8002212 - adding read/writeObject to additional SerialXXX classes In-Reply-To: <50945A7B.6030309@univ-mlv.fr> References: <50945A7B.6030309@univ-mlv.fr> Message-ID: Hi Remi, Thank you for the feedback On Nov 2, 2012, at 7:42 PM, Remi Forax wrote: > On 11/02/2012 11:57 PM, Lance Andersen - Oracle wrote: >> This is similar to 8001536, just additional classes. >> >> This adds read/writeObject, equals, clone methods to additional SerialXXX classes >> >> SQE, JCK and JDBC Unit tests all pass. >> >> The webrev can be viewed at http://cr.openjdk.java.net/~lancea/8002212/webrev.00 > > Hi Lance, > in SerialArray.equals(), I prefer > > return baseType == sa.baseType && > baseTypeName.equals(sa.baseTypeName)) && > Arrays.equals(elements, sa.elements); > > instead of > > if(baseType == sa.baseType && baseTypeName.equals(sa.baseTypeName)) { > return Arrays.equals(elements, sa.elements); > } > That is fine, I can make the change. > In SerialDataLink, do you really need readObject/writeObject given > that you call the default implementations. I thought about that but had decided to add them for consistency > > in SerialJavaObject, in equals, you should declare a local variable like in SerialDataLink.equals, > even if the local varialble is used once, it's more readable. OK > Also like in SerialArray.equals, you can do a return directly instead of if(...) return true. > in clone(), you can use the diamond syntax, > sjo.chain = new Vector<>(chain); Yeah, long story, but I forgot to reset to diamond syntax (will tell you over a beer sometime :-) ) > in setWarning(), you can use the diamond syntax as the original source does. > and in readObject, you can use the diamond syntax too. OK > In readObject, you forget to throw an exception if there are some static fields > in getClass().getFields() as the constructor does > (this code can be moved in a private static method). I thought about that, but figured since it was already through that check when the object was created, I did not think it required repeating in the readObject method > Also, you should add a comment that because you call getClass() on obj, > there is an implicit null check. Would it be better to put an null check in explicitly? > > This can be fixed as a separated bug or not but the code of > method SerialJavaObject.getField() is weird, the code checks if fields can be null, > but fields is never null. Also, cloning the field array is perhaps a better idea > if the reflection implementation doesn't cache the array of fields. I will do this in a separate bug, trying to keep things clear on the bug > > In SerialRef.equals, again, if(...) return should be transformed into return ... OK Thank you again, will send an update webrev over the weekend Best Lance > >> >> Best >> Lance > > cheers, > R?mi > >> >> 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 >> > -------------- next part -------------- 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 jonathan.gibbons at oracle.com Sat Nov 3 02:17:15 2012 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Sat, 03 Nov 2012 02:17:15 +0000 Subject: hg: jdk8/tl/langtools: 2 new changesets Message-ID: <20121103021721.BA32D47755@hg.openjdk.java.net> Changeset: 2443d24d096a Author: vromero Date: 2012-11-01 13:06 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/2443d24d096a 6949443: visitTree assertion triggered using -Xjcov on small sample program Reviewed-by: jjg, mcimadamore ! src/share/classes/com/sun/tools/javac/jvm/CRTable.java + test/tools/javac/options/T6949443.java Changeset: a33770a91b00 Author: jjg Date: 2012-11-02 19:17 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/a33770a91b00 Merge From Lance.Andersen at oracle.com Sat Nov 3 14:11:00 2012 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Sat, 3 Nov 2012 10:11:00 -0400 Subject: Review request 8002212 - adding read/writeObject to additional SerialXXX classes -- Updated In-Reply-To: <50945A7B.6030309@univ-mlv.fr> References: <50945A7B.6030309@univ-mlv.fr> Message-ID: <33853E0A-C810-4526-BA38-98EE4B08F1FE@oracle.com> I revised the webrev, http://cr.openjdk.java.net/~lancea/8002212/webrev.01, taking into account the vast majority of Remi's suggestions. I also added SerialStruct to the webrev. Have a great weekend. Best Lance On Nov 2, 2012, at 7:42 PM, Remi Forax wrote: > On 11/02/2012 11:57 PM, Lance Andersen - Oracle wrote: >> This is similar to 8001536, just additional classes. >> >> This adds read/writeObject, equals, clone methods to additional SerialXXX classes >> >> SQE, JCK and JDBC Unit tests all pass. >> >> The webrev can be viewed at http://cr.openjdk.java.net/~lancea/8002212/webrev.00 > > Hi Lance, > in SerialArray.equals(), I prefer > > return baseType == sa.baseType && > baseTypeName.equals(sa.baseTypeName)) && > Arrays.equals(elements, sa.elements); > > instead of > > if(baseType == sa.baseType && baseTypeName.equals(sa.baseTypeName)) { > return Arrays.equals(elements, sa.elements); > } > > In SerialDataLink, do you really need readObject/writeObject given > that you call the default implementations. > > in SerialJavaObject, in equals, you should declare a local variable like in SerialDataLink.equals, > even if the local varialble is used once, it's more readable. > Also like in SerialArray.equals, you can do a return directly instead of if(...) return true. > in clone(), you can use the diamond syntax, > sjo.chain = new Vector<>(chain); > in setWarning(), you can use the diamond syntax as the original source does. > and in readObject, you can use the diamond syntax too. > In readObject, you forget to throw an exception if there are some static fields > in getClass().getFields() as the constructor does > (this code can be moved in a private static method). > Also, you should add a comment that because you call getClass() on obj, > there is an implicit null check. > > This can be fixed as a separated bug or not but the code of > method SerialJavaObject.getField() is weird, the code checks if fields can be null, > but fields is never null. Also, cloning the field array is perhaps a better idea > if the reflection implementation doesn't cache the array of fields. > > In SerialRef.equals, again, if(...) return should be transformed into return ... > >> >> Best >> Lance > > cheers, > R?mi > >> >> 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 >> > -------------- next part -------------- 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 forax at univ-mlv.fr Sat Nov 3 15:14:52 2012 From: forax at univ-mlv.fr (Remi Forax) Date: Sat, 03 Nov 2012 16:14:52 +0100 Subject: Review request 8002212 - adding read/writeObject to additional SerialXXX classes In-Reply-To: References: <50945A7B.6030309@univ-mlv.fr> Message-ID: <509534EC.3020206@univ-mlv.fr> On 11/03/2012 01:46 AM, Lance Andersen - Oracle wrote: > Hi Remi, > [...] >> In SerialDataLink, do you really need readObject/writeObject given >> that you call the default implementations. > I thought about that but had decided to add them for consistency The serialization implementation needs to create metadata associated with readObject/writeObject, so if we can avoid to implement them, we reduce the runtime memory footprint a little. I would prefer to have a comment saying that default serialization is Ok here. >> in SerialJavaObject, in equals, you should declare a local variable like in SerialDataLink.equals, >> even if the local varialble is used once, it's more readable. > OK >> Also like in SerialArray.equals, you can do a return directly instead of if(...) return true. >> in clone(), you can use the diamond syntax, >> sjo.chain = new Vector<>(chain); > Yeah, long story, but I forgot to reset to diamond syntax (will tell you over a beer sometime :-) ) sure, now or you have to visit Paris or I have to go to NY :) >> in setWarning(), you can use the diamond syntax as the original source does. >> and in readObject, you can use the diamond syntax too. > OK >> In readObject, you forget to throw an exception if there are some static fields >> in getClass().getFields() as the constructor does >> (this code can be moved in a private static method). > I thought about that, but figured since it was already through that check when the object was created, I did not think it required repeating in the readObject method A serialization stream can be forged to encode a SerialJavaObject that references an object that have a static field without creating a SerialJavaObject in memory. >> Also, you should add a comment that because you call getClass() on obj, >> there is an implicit null check. > Would it be better to put an null check in explicitly? As you prefer :) [...] > Thank you again, will send an update webrev over the weekend > > Best > Lance cheers, R?mi From Lance.Andersen at oracle.com Sat Nov 3 15:29:37 2012 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Sat, 3 Nov 2012 11:29:37 -0400 Subject: Review request 8002212 - adding read/writeObject to additional SerialXXX classes In-Reply-To: <509534EC.3020206@univ-mlv.fr> References: <50945A7B.6030309@univ-mlv.fr> <509534EC.3020206@univ-mlv.fr> Message-ID: On Nov 3, 2012, at 11:14 AM, Remi Forax wrote: > On 11/03/2012 01:46 AM, Lance Andersen - Oracle wrote: >> Hi Remi, >> > [...] > >>> In SerialDataLink, do you really need readObject/writeObject given >>> that you call the default implementations. >> I thought about that but had decided to add them for consistency > > The serialization implementation needs to create metadata associated with readObject/writeObject, > so if we can avoid to implement them, we reduce the runtime memory footprint a little. > I would prefer to have a comment saying that default serialization is Ok here. OK, I will just comment the methods out and add a comment as you suggest > >>> in SerialJavaObject, in equals, you should declare a local variable like in SerialDataLink.equals, >>> even if the local varialble is used once, it's more readable. >> OK >>> Also like in SerialArray.equals, you can do a return directly instead of if(...) return true. >>> in clone(), you can use the diamond syntax, >>> sjo.chain = new Vector<>(chain); >> Yeah, long story, but I forgot to reset to diamond syntax (will tell you over a beer sometime :-) ) > > sure, now or you have to visit Paris or I have to go to NY :) Or Boston, where I am based or perhaps a JavaOne ;-) > >>> in setWarning(), you can use the diamond syntax as the original source does. >>> and in readObject, you can use the diamond syntax too. >> OK >>> In readObject, you forget to throw an exception if there are some static fields >>> in getClass().getFields() as the constructor does >>> (this code can be moved in a private static method). >> I thought about that, but figured since it was already through that check when the object was created, I did not think it required repeating in the readObject method > > A serialization stream can be forged to encode a SerialJavaObject that references an object that have a static field without creating a SerialJavaObject in memory. True and there are tests in the test suite that basically do that. Anyways, I added that check in the revised webrev that I pushed earlier. > >>> Also, you should add a comment that because you call getClass() on obj, >>> there is an implicit null check. >> Would it be better to put an null check in explicitly? > > As you prefer :) > > [...] > >> Thank you again, will send an update webrev over the weekend >> >> Best >> Lance > > cheers, > R?mi Best Lance -------------- next part -------------- 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 forax at univ-mlv.fr Sat Nov 3 15:34:02 2012 From: forax at univ-mlv.fr (Remi Forax) Date: Sat, 03 Nov 2012 16:34:02 +0100 Subject: Review request 8002212 - adding read/writeObject to additional SerialXXX classes -- Updated In-Reply-To: <33853E0A-C810-4526-BA38-98EE4B08F1FE@oracle.com> References: <50945A7B.6030309@univ-mlv.fr> <33853E0A-C810-4526-BA38-98EE4B08F1FE@oracle.com> Message-ID: <5095396A.2060307@univ-mlv.fr> On 11/03/2012 03:11 PM, Lance Andersen - Oracle wrote: > I revised the webrev, http://cr.openjdk.java.net/~lancea/8002212/webrev.01, taking into account the vast majority of Remi's suggestions. in SerialJavaObject, hasStaticFields doesn't work, the original code doesn't work because it only check for fields that are declared static but not for fields that are by example public static. private static boolean hasStaticFields(Field[] fields) { for (Field field : fields) { if ( Modifier.isStatic(field.getModifiers())) { return true; } } return false; } This may cause compatibility issue because despite the specification, the original code will let objects that have a static field to be serialized. Also, in readObject, if obj is null, the code should throw an IOException because it's not possible to create a SerialJavaObject with null has parameter (because obj.getClass() that implictly checks null in the constructor). All other classes are Ok for me. > > I also added SerialStruct to the webrev. SerialStruct is Ok for me. > > Have a great weekend. Have a nice weekend too. > > Best > Lance cheers, R?mi From Lance.Andersen at oracle.com Sat Nov 3 16:23:21 2012 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Sat, 3 Nov 2012 12:23:21 -0400 Subject: Review request 8002212 - adding read/writeObject to additional SerialXXX classes -- Updated In-Reply-To: <5095396A.2060307@univ-mlv.fr> References: <50945A7B.6030309@univ-mlv.fr> <33853E0A-C810-4526-BA38-98EE4B08F1FE@oracle.com> <5095396A.2060307@univ-mlv.fr> Message-ID: On Nov 3, 2012, at 11:34 AM, Remi Forax wrote: > On 11/03/2012 03:11 PM, Lance Andersen - Oracle wrote: >> I revised the webrev, http://cr.openjdk.java.net/~lancea/8002212/webrev.01, taking into account the vast majority of Remi's suggestions. > > in SerialJavaObject, hasStaticFields doesn't work, the original code doesn't work because > it only check for fields that are declared static but not for fields that are by example public static. > > private static boolean hasStaticFields(Field[] fields) { > for (Field field : fields) { > if ( Modifier.isStatic(field.getModifiers())) { > return true; > } > } > return false; > } > > This may cause compatibility issue because despite the specification, the original code > will let objects that have a static field to be serialized. I cannot make the change above as it breaks too many tests and I would prefer to go with the less is more scenario. As I think I mentioned before, I do not think the original authors really thought through these classes and thankfully they are not used much, if at all. > > Also, in readObject, if obj is null, the code should throw an IOException because > it's not possible to create a SerialJavaObject with null has parameter (because obj.getClass() > that implictly checks null in the constructor). I made the change to readObject. I did not put an explicit check in the constructor but will do that under a separate bug I also added the comment to SerialDataLink and removed the read/writeObject http://cr.openjdk.java.net/~lancea/8002212/webrev.02 Best Lance > > All other classes are Ok for me. > >> >> I also added SerialStruct to the webrev. > > SerialStruct is Ok for me. > >> >> Have a great weekend. > > Have a nice weekend too. > >> >> Best >> Lance > > cheers, > R?mi > -------------- next part -------------- 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 forax at univ-mlv.fr Sat Nov 3 16:36:40 2012 From: forax at univ-mlv.fr (Remi Forax) Date: Sat, 03 Nov 2012 17:36:40 +0100 Subject: Review request 8002212 - adding read/writeObject to additional SerialXXX classes -- Updated In-Reply-To: References: <50945A7B.6030309@univ-mlv.fr> <33853E0A-C810-4526-BA38-98EE4B08F1FE@oracle.com> <5095396A.2060307@univ-mlv.fr> Message-ID: <50954818.9060209@univ-mlv.fr> On 11/03/2012 05:23 PM, Lance Andersen - Oracle wrote: > On Nov 3, 2012, at 11:34 AM, Remi Forax wrote: > >> On 11/03/2012 03:11 PM, Lance Andersen - Oracle wrote: >>> I revised the webrev, http://cr.openjdk.java.net/~lancea/8002212/webrev.01, taking into account the vast majority of Remi's suggestions. >> in SerialJavaObject, hasStaticFields doesn't work, the original code doesn't work because >> it only check for fields that are declared static but not for fields that are by example public static. >> >> private static boolean hasStaticFields(Field[] fields) { >> for (Field field : fields) { >> if ( Modifier.isStatic(field.getModifiers())) { >> return true; >> } >> } >> return false; >> } >> >> This may cause compatibility issue because despite the specification, the original code >> will let objects that have a static field to be serialized. > I cannot make the change above as it breaks too many tests and I would prefer to go with the less is more scenario. As I think I mentioned before, I do not think the original authors really thought through these classes and thankfully they are not used much, if at all. >> Also, in readObject, if obj is null, the code should throw an IOException because >> it's not possible to create a SerialJavaObject with null has parameter (because obj.getClass() >> that implictly checks null in the constructor). > I made the change to readObject. I did not put an explicit check in the constructor but will do that under a separate bug > > I also added the comment to SerialDataLink and removed the read/writeObject > > http://cr.openjdk.java.net/~lancea/8002212/webrev.02 Ok, thumb up. > > Best > Lance cheers, R?mi > >> All other classes are Ok for me. >> >>> I also added SerialStruct to the webrev. >> SerialStruct is Ok for me. >> >>> Have a great weekend. >> Have a nice weekend too. >> >>> Best >>> Lance >> cheers, >> R?mi >> > > > 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 Ulf.Zibis at CoSoCo.de Sat Nov 3 20:33:42 2012 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Sat, 03 Nov 2012 21:33:42 +0100 Subject: Review/comment needed for the new public java.util.Base64 class In-Reply-To: <5090576A.4080709@oracle.com> References: <5075B65D.1020709@oracle.com> <5076F68A.3020501@oracle.com> <1349980256.10396.140661139477733.7A0FEBA3@webmail.messagingengine.com> <5077F75D.2020003@oracle.com> <507F6511.10309@oracle.com> <508695CC.1080408@oracle.com> <508758C7.5030703@oracle.com> <508FFA32.1090206@CoSoCo.de> <5090576A.4080709@oracle.com> Message-ID: <50957FA6.6050806@CoSoCo.de> Am 30.10.2012 23:40, schrieb Xueming Shen: >> I'm "confused" about the order of xxcode() and Xxcoder. >> In other places e.g. charsets, we have de... before en..., which is also true alphabetical >> > should not be an issue. javadoc output should be in alphabetic order. If it is really > concerns you, I can do a copy/paste:-) Yes, it doesn't matter much, but would be a nice conform style, so for me "personally" I would like the copy/paste:-) >> - What (should) happen(s), if lineSeparator.length == 0 ? > do nothing. expected? I would say, empty line separator should not be allowed, so you might check: Objects.requireNonEmpty(lineSeparator); >> 603 static { >> 604 Arrays.fill(fromBase64, -1); >> 605 for (int i = 0; i < Encoder.toBase64.length; i++) >> 606 fromBase64[Encoder.toBase64[i]] = i; >> 607 fromBase64['='] = -2; >> 608 } >> This causes the inner Encoder class to be loaded, even if not needed. So maybe move the toBase64 >> table to the outer class. >> Have you compared performance with fromBase64 as byte[] (including local 'b' in decode() as byte)? > > understood. It seems you have mixed 2 tweaks to one. ;-) See additional paragraph at the end ... > but it appears the hotspot likes it the constant/fixed length lookup > table is inside encoder. Yes, but see my suggestion 12 lines below. > Same as you suggestion in your previous email to use > String in source and expand it during runtime. It saves about 500 bytes but slows > the server vm. Are you really sure? As it only runs once at class init, JIT should not compile this code. Executing the bytecode to init the final int[], value for value, by interpreter should not be faster as expanding a String source in a loop. > Those repeating lines of "isURL? ...." is also supposed to be a > performance tweak to eliminate the array boundary check in loop. Yep, so I was thinking about: 653 private final int[] base64; 654 private final boolean isMIME; 655 656 private Decoder(boolean isURL, boolean isMIME) { 657 base64 = isURL ? fromBase64URL : fromBase64; 658 this.isMIME = isMIME; 659 } ..... 911 private int decodeBuffer(ByteBuffer src, ByteBuffer dst) { 912 int[] base64 = this.base64; // local copy for performance reasons (but maybe superfluous if HotSpot is intelligent enough) or: 911 private int decodeBuffer(ByteBuffer src, ByteBuffer dst, int[] base64) { ..... >> Why you mix the algorithms to check the padding? : >> 824 if (b == -2) { // padding byte >> 890 if (b == '=') { >> > It is supposed reduce one "if" check for normal base64 character inside the > loop. I'm not that sure it really helps though. 925 if (b == '=') { --> causes one additional "if" in the _main_ path of the loop, so should be slower for regular input 859 if (b == -2) { // padding byte --> causes one additional "if" in the _side_ path of the loop, so should only affect irregular input Maybe the following code is little faster as no loading of the constant '-2' is required: 858 if ((b = base64[b]) < 0) { 859 if (++b < 0) { // padding byte '=' Once again (the following was meant for the decode algorithm, not initialisation): Have you compared performance with fromBase64 as byte[] (including local 'b' in decode() as byte)? Retrieving the bytes by b = base64[x] then could be done without address-shift and smaller/faster LoadB operations could be used by JIT. In an int[] table, the index offset must be shifted by 2 before. Maybe this doesn't directly affect the performance on x86/IA64 CPU, but wastes space in CPU cache for other tasks as a side effect. On ARM architectures I imagine, directly addressing a byte-stepped table could be faster than addressing a 4-byte-stepped table. At least the footprint of the table would be smaller. Little nit: You could delete line 641 for conformity with 629. -Ulf From jonathan.gibbons at oracle.com Sun Nov 4 04:07:45 2012 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Sun, 04 Nov 2012 04:07:45 +0000 Subject: hg: jdk8/tl/langtools: 8002146: javadoc doesn't release resources in a timely manner Message-ID: <20121104040759.D3FBD4776A@hg.openjdk.java.net> Changeset: ef3ad754f5c7 Author: jjg Date: 2012-11-03 21:07 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/ef3ad754f5c7 8002146: javadoc doesn't release resources in a timely manner Reviewed-by: darcy ! src/share/classes/com/sun/tools/javadoc/JavadocMemberEnter.java ! src/share/classes/com/sun/tools/javadoc/Start.java From jonathan.gibbons at oracle.com Sun Nov 4 04:10:10 2012 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Sun, 04 Nov 2012 04:10:10 +0000 Subject: hg: jdk8/tl/langtools: 8002168: Cleanup initialization of javadoc Messager Message-ID: <20121104041014.6D4984776B@hg.openjdk.java.net> Changeset: 352d130c47c5 Author: jjg Date: 2012-11-03 21:09 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/352d130c47c5 8002168: Cleanup initialization of javadoc Messager Reviewed-by: darcy ! src/share/classes/com/sun/tools/javadoc/Start.java ! test/tools/javadoc/6958836/Test.java From david.holmes at oracle.com Sun Nov 4 10:04:26 2012 From: david.holmes at oracle.com (David Holmes) Date: Sun, 04 Nov 2012 20:04:26 +1000 Subject: 7197491: update copyright year to match last edit in jdk8 jdk repository In-Reply-To: References: <5093C08A.8060705@oracle.com> <5093F6BC.8040003@oracle.com> <5093F916.4030409@oracle.com> <5093FA2B.9030006@oracle.com> Message-ID: <50963DAA.30403@oracle.com> On 3/11/2012 3:27 AM, Kelly O'Hair wrote: > All changes to JDK sources require a CR, an OpenJDK author name, and a review by a second OpenJDK author. > So although you can automate the preparation of the commit, you cannot fully automate this process. > > There have been many discussions over the years about automating various changes, anything from tag generation, > to whitespace normalization, and this copyright year change issue. > Our policy has been that changesets need human authors, and all changes need a human review. I think that is the tail wagging the dog. A simple change to a year value in a comment by a sanctioned pre/post commit script can easily be accommodated in the changeset for a given CR just as-if the engineer had done it themselves. In the SCCS days we didn't require reviews for sccs tag updates in file headers - I don't see that copyright update should be any different. If we need to tweak the OpenJDK rules then lets tweak them. Personally I don't see why it is so hard to have engineers be responsible for this (if automation is considered so problematic). It only affects one changeset per file per year and a pre-commit script (or jcheck enhancement?) could warn you if you forget to do the update. I find these big periodic changesets far more noisy and problematic. For the general audience: copyright years only get updated when there is a substantive change to the material content of a file. I think we well and truly established that when we went through the Sun to Oracle conversion process. David > -kto > > On Nov 2, 2012, at 9:51 AM, Darryl Mocek wrote: > >> So the 3000+ files Alan is referring to are all files which have been modified but which haven't had their year updated? If we're not worried about files which haven't been modified then a pre/post-commit script will suffice and depending on how we implement it we might not need periodic updates. >> >> Darryl >> >> On 11/02/2012 09:47 AM, Phil Race wrote: >>>> but ultimately there are files which never get touched which will need processing to update the year. >>> >>> The policy has varied over the years, but presently the policy is not to >>> update the year in files that have not been updated code-wise. >>> >>> -phil. >>> >>> On 11/2/2012 9:37 AM, Darryl Mocek wrote: >>>> Alan, >>>> >>>> I was responsible for updating the copyrights for JavaME. I used a Perl script to update the copyright year in the source files. I can point you to the relevant information if you like. There were challenges as there are various copyrights in the source files (Oracle, Oracle + 3rd-party, 3rd party only, and no copyright), all with different formats, and even within the Oracle copyrights, people used subtle differences which caused difficulties. I ended updating all copyrights to a few formats and adding a post-commit script which scrubbed the copyright and notified the committer if the copyright wasn't in the correct format and didn't have an ending year (or sole year) which is the current year. >>>> >>>> There are plenty of options here: >>>> >>>> - Do nothing (policy) >>>> - Pre-commit script which changes the year automatically >>>> - Pre-commit script which rejects commit with wrong year >>>> - Post-commit script which flags a bad copyright, but accepts commit >>>> - Others >>>> >>>> Updating the copyright year as you commit is a good habit to get into, but ultimately there are files which never get touched which will need processing to update the year. I think doing this at the end/beginning of the year is good, we just need to make sure we get the copyright correct when processing. >>>> >>>> Darryl >>>> >>>> On 11/02/2012 05:46 AM, Alan Bateman wrote: >>>>> >>>>> Now for some noise. >>>>> >>>>> The copyright date in the source files needs updating. The man behind the curtain is Steve Sides from the Quality and Release Engineering team in Oracle. Jon pushed, on Steve's behalf, the update to the langtools files recently [1], and Mikael updated hotspot [2]. The elephant is the jdk repository as there are 3000+ files that need their headers updated. >>>>> >>>>> To keep the disruption to a minimum I propose that we do the jdk repository in two steps: non-client area now to jdk8/tl, and then the client-area later in jdk8/awt once the changes get there. I use the term "client-area" loosely to mean the source files for awt, swing, font, java2d, etc. (and I appreciate that there is also a jdk8/2d forest in use). To that end here is the proposed patch for today: >>>>> >>>>> http://cr.openjdk.java.net/~alanb/7197491/copyright.patch >>>>> >>>>> This patch updates the headers on 2370 files. I don't propose to publish a webrev as it's just too big. >>>>> >>>>> This patch was created with: >>>>> >>>>> cd jdk >>>>> sh ../make/scripts/update_copyright_year.sh 2011 >>>>> sh ../make/scripts/update_copyright_year.sh 2012 >>>>> hg revert --no-backup `cat clientdirs.list` >>>>> hg diff -g> copyright.patch >>>>> >>>>> where clientdirs.list is most of the directories corresponding to the client area. >>>>> >>>>> Note that I ran the update_copyright_year.sh script twice, once for 2011 and then a second time for 2012. The reason for this is that there are several hundred files in the jdk repository that were last updated in 2011 but have an older date on the header. >>>>> >>>>> Reviewer welcome but I should say that I don't have cycles to spend on this. Also the patch has an a very short shelf life. >>>>> >>>>> Finally, I think that there needs to be wider discussion as to how to keep the headers from falling behind too much. Some people do update the headers when editing files, some people (including myself) do not. It seems to me that it should be done regularly anyway, perhaps every few months or at integration time every so often. >>>>> >>>>> -Alan. >>>>> >>>>> [1] http://hg.openjdk.java.net/jdk8/tl/langtools/rev/9d47f4850714 >>>>> [2] http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/b9a9ed0f8eeb >>>> >>> >> > From maurizio.cimadamore at oracle.com Sun Nov 4 11:14:50 2012 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Sun, 04 Nov 2012 11:14:50 +0000 Subject: hg: jdk8/tl/langtools: 2 new changesets Message-ID: <20121104111518.E453647770@hg.openjdk.java.net> Changeset: d7d932236fee Author: mcimadamore Date: 2012-11-04 10:59 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/d7d932236fee 7192246: Add type-checking support for default methods Summary: Add type-checking support for default methods as per Featherweight-Defender document Reviewed-by: jjg, dlsmith ! src/share/classes/com/sun/tools/javac/code/Flags.java ! src/share/classes/com/sun/tools/javac/code/Source.java ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/AttrContext.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/Lower.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.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/jvm/Items.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties + test/tools/javac/defaultMethods/ClassReaderTest/ClassReaderTest.java + test/tools/javac/defaultMethods/ClassReaderTest/pkg/Foo.java + test/tools/javac/defaultMethods/Neg01.java + test/tools/javac/defaultMethods/Neg01.out + test/tools/javac/defaultMethods/Neg02.java + test/tools/javac/defaultMethods/Neg02.out + test/tools/javac/defaultMethods/Neg03.java + test/tools/javac/defaultMethods/Neg03.out + test/tools/javac/defaultMethods/Neg04.java + test/tools/javac/defaultMethods/Neg04.out + test/tools/javac/defaultMethods/Neg05.java + test/tools/javac/defaultMethods/Neg05.out + test/tools/javac/defaultMethods/Neg06.java + test/tools/javac/defaultMethods/Neg06.out + test/tools/javac/defaultMethods/Neg07.java + test/tools/javac/defaultMethods/Neg07.out + test/tools/javac/defaultMethods/Neg08.java + test/tools/javac/defaultMethods/Neg08.out + test/tools/javac/defaultMethods/Neg09.java + test/tools/javac/defaultMethods/Neg09.out + test/tools/javac/defaultMethods/Neg10.java + test/tools/javac/defaultMethods/Neg10.out + test/tools/javac/defaultMethods/Neg11.java + test/tools/javac/defaultMethods/Neg11.out + test/tools/javac/defaultMethods/Neg12.java + test/tools/javac/defaultMethods/Neg12.out + test/tools/javac/defaultMethods/Neg13.java + test/tools/javac/defaultMethods/Neg13.out + test/tools/javac/defaultMethods/Neg14.java + test/tools/javac/defaultMethods/Neg14.out + test/tools/javac/defaultMethods/Neg15.java + test/tools/javac/defaultMethods/Neg15.out + test/tools/javac/defaultMethods/Neg16.java + test/tools/javac/defaultMethods/Neg16.out + test/tools/javac/defaultMethods/Pos01.java + test/tools/javac/defaultMethods/Pos02.java + test/tools/javac/defaultMethods/Pos04.java + test/tools/javac/defaultMethods/Pos05.java + test/tools/javac/defaultMethods/Pos06.java + test/tools/javac/defaultMethods/Pos07.java + test/tools/javac/defaultMethods/Pos08.java + test/tools/javac/defaultMethods/Pos10.java + test/tools/javac/defaultMethods/Pos11.java + test/tools/javac/defaultMethods/Pos12.java + test/tools/javac/defaultMethods/Pos13.java + test/tools/javac/defaultMethods/Pos14.java + test/tools/javac/defaultMethods/Pos15.java + test/tools/javac/defaultMethods/Pos16.java + test/tools/javac/defaultMethods/TestDefaultBody.java + test/tools/javac/defaultMethods/TestNoBridgeOnDefaults.java + test/tools/javac/defaultMethods/crossCompile/Clinit.java + test/tools/javac/defaultMethods/crossCompile/CrossCompile.java + test/tools/javac/defaultMethods/fd/FDTest.java + test/tools/javac/defaultMethods/fd/shapegen/ClassCase.java + test/tools/javac/defaultMethods/fd/shapegen/Hierarchy.java + test/tools/javac/defaultMethods/fd/shapegen/HierarchyGenerator.java + test/tools/javac/defaultMethods/fd/shapegen/Rule.java + test/tools/javac/defaultMethods/fd/shapegen/RuleGroup.java + test/tools/javac/defaultMethods/fd/shapegen/TTNode.java + test/tools/javac/defaultMethods/fd/shapegen/TTParser.java + test/tools/javac/defaultMethods/fd/shapegen/TTShape.java + test/tools/javac/defaultMethods/separate/Separate.java + test/tools/javac/defaultMethods/separate/pkg1/A.java + test/tools/javac/defaultMethods/super/TestDefaultSuperCall.java + test/tools/javac/diags/examples/DefaultOverridesObjectMember.java + test/tools/javac/diags/examples/OverriddenDefault.java + test/tools/javac/diags/examples/RedundantSupertype.java + test/tools/javac/diags/examples/TypesIncompatibleAbstractDefault.java + test/tools/javac/diags/examples/TypesIncompatibleUnrelatedDefaults.java ! test/tools/javac/generics/7022054/T7022054pos1.java ! test/tools/javac/generics/7022054/T7022054pos2.java ! test/tools/javac/scope/7046348/EagerInterfaceCompletionTest.java Changeset: dbc94b8363dd Author: mcimadamore Date: 2012-11-04 11:01 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/dbc94b8363dd 8000931: Cleanup Resolve.java Summary: Unify all method resolution routines Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Lower.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! test/tools/javac/7132880/T7132880.out ! test/tools/javac/Diagnostics/6799605/T6799605.out ! test/tools/javac/defaultMethods/Neg12.out ! test/tools/javac/generics/inference/6611449/T6611449.out ! test/tools/javac/generics/inference/7086601/T7086601a.out + test/tools/javac/resolve/tests/AmbiguityPrecedence.java From aleksey.shipilev at oracle.com Sun Nov 4 12:25:29 2012 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Sun, 04 Nov 2012 16:25:29 +0400 Subject: Preliminary review: Adding tracing of I/O calls In-Reply-To: <509437F0.4020409@oracle.com> References: <22767084-EAC2-4D87-800B-3E5E5BFC666A@oracle.com> <50942931.4000001@oracle.com> <08183803-2563-461C-9514-B7FAE1E14C10@oracle.com> <509437F0.4020409@oracle.com> Message-ID: <50965EB9.90509@oracle.com> On 11/03/2012 01:15 AM, Mandy Chung wrote: > On 11/2/2012 1:47 PM, Staffan Larsen wrote: >> On 2 nov 2012, at 21:12, Mandy Chung wrote: >> >>> The *Begin() methods return a "handle" that will be passed to the >>> *End() methods. Have you considered to define a type for it rather >>> than Object? >> Something like an empty interface, just to signal the intent? > > Yes I think so. A marker interface would suffice. > >>> Do you have any performance measurement result that you can share? >> I don't yet have any specific numbers - I'll try to get some. The >> testing I have done indicates that the overhead is negligible. But it >> would be good to confirm this. > > refworkload is easy to run. You probably have talked with the > performance team. You can find out from them which benchmarks, if they > have any, are applicable for IO instrumentation. Performance team here. There are virtually no benchmarks against I/O per se. Looking at the patch, I would think anything doing intensive network I/O would help to quantify the change, which boils down to SPECjbb2012, SPECjEnterprise, and Volano. First two would be hard to run, and the third has terrible run-to-run variance, so you will probably have to quantify the changes with microbenchmarks. It should be easy enough to construct with our micro harness (still not available in OpenJDK). Contact me internally if you want to get that route. General patch review: I do have the preoccupation against interferenced tracing code, and while appreciating the intent for tracing patch, we need to look for performance penalties. The rule of thumb is that HotSpot will optimize away the code guarded by static final flag (or, as Remi points out with jsr292 magic). Doing the calls hoping for HotSpot to inline and figure out the absence of useful work there is not working reliably either. Inline conditionals will cost something if the tracing method is not inlined. Hence, I would rather recommend to switch the uses like this: public int read() throws IOException { Object traceHandle = IoTrace.fileReadBegin(path); int b = read0(); IoTrace.fileReadEnd(traceHandle, b == -1 ? -1 : 1); return b; } ...to something more like: public int read() throws IOException { if (IoTrace.ENABLED) { Object traceHandle = IoTrace.fileReadBegin(path); int b = read0(); IoTrace.fileReadEnd(traceHandle, b == -1 ? -1 : 1); return b; } else { return read0(); } } where class IoTrace { public static final boolean ENABLED = System.getProperty("java.io.trace"); } ...which will demote the flexibility of setListener(), but have much lower runtime overhead. This should be confirmed by microbenchmarking anyway. -Aleksey. From staffan.larsen at oracle.com Sun Nov 4 12:35:14 2012 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Sun, 4 Nov 2012 13:35:14 +0100 Subject: Preliminary review: Adding tracing of I/O calls In-Reply-To: <50965EB9.90509@oracle.com> References: <22767084-EAC2-4D87-800B-3E5E5BFC666A@oracle.com> <50942931.4000001@oracle.com> <08183803-2563-461C-9514-B7FAE1E14C10@oracle.com> <509437F0.4020409@oracle.com> <50965EB9.90509@oracle.com> Message-ID: Aleksey, Thanks for looking at the code. I have been running volano on this, but could not detect any regressions. If that is because there are no regressions, because volano is not the right workload or because the run-to-run variance is so high, I cannot say. I'm going to try to develop microbenchmarks for socket and file i/o to see if there are any regressions. Thanks, /Staffan On 4 nov 2012, at 13:25, Aleksey Shipilev wrote: > On 11/03/2012 01:15 AM, Mandy Chung wrote: >> On 11/2/2012 1:47 PM, Staffan Larsen wrote: >>> On 2 nov 2012, at 21:12, Mandy Chung wrote: >>> >>>> The *Begin() methods return a "handle" that will be passed to the >>>> *End() methods. Have you considered to define a type for it rather >>>> than Object? >>> Something like an empty interface, just to signal the intent? >> >> Yes I think so. A marker interface would suffice. >> >>>> Do you have any performance measurement result that you can share? >>> I don't yet have any specific numbers - I'll try to get some. The >>> testing I have done indicates that the overhead is negligible. But it >>> would be good to confirm this. >> >> refworkload is easy to run. You probably have talked with the >> performance team. You can find out from them which benchmarks, if they >> have any, are applicable for IO instrumentation. > > Performance team here. > > There are virtually no benchmarks against I/O per se. Looking at the > patch, I would think anything doing intensive network I/O would help to > quantify the change, which boils down to SPECjbb2012, SPECjEnterprise, > and Volano. First two would be hard to run, and the third has terrible > run-to-run variance, so you will probably have to quantify the changes > with microbenchmarks. It should be easy enough to construct with our > micro harness (still not available in OpenJDK). Contact me internally if > you want to get that route. > > General patch review: I do have the preoccupation against interferenced > tracing code, and while appreciating the intent for tracing patch, we > need to look for performance penalties. The rule of thumb is that > HotSpot will optimize away the code guarded by static final flag (or, as > Remi points out with jsr292 magic). Doing the calls hoping for HotSpot > to inline and figure out the absence of useful work there is not working > reliably either. Inline conditionals will cost something if the tracing > method is not inlined. > > Hence, I would rather recommend to switch the uses like this: > > public int read() throws IOException { > Object traceHandle = IoTrace.fileReadBegin(path); > int b = read0(); > IoTrace.fileReadEnd(traceHandle, b == -1 ? -1 : 1); > return b; > } > > ...to something more like: > > public int read() throws IOException { > if (IoTrace.ENABLED) { > Object traceHandle = IoTrace.fileReadBegin(path); > int b = read0(); > IoTrace.fileReadEnd(traceHandle, b == -1 ? -1 : 1); > return b; > } else { > return read0(); > } > } > > where > > class IoTrace { > public static final boolean ENABLED = > System.getProperty("java.io.trace"); > } > > ...which will demote the flexibility of setListener(), but have much > lower runtime overhead. This should be confirmed by microbenchmarking > anyway. > > -Aleksey. From staffan.larsen at oracle.com Sun Nov 4 12:50:25 2012 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Sun, 4 Nov 2012 13:50:25 +0100 Subject: Preliminary review: Adding tracing of I/O calls In-Reply-To: <5094476D.3090501@oracle.com> References: <22767084-EAC2-4D87-800B-3E5E5BFC666A@oracle.com> <5094476D.3090501@oracle.com> Message-ID: <63FAA509-60DF-43F0-8A98-8D1B2BA3FA37@oracle.com> Thanks Alan. Some comments inline. On 2 nov 2012, at 23:21, Alan Bateman wrote: > On 02/11/2012 18:36, Staffan Larsen wrote: >> This is a preliminary review request for adding an API for tracing I/O calls. For now, this is an empty infrastructure intended to enable diagnosing/tracing of i/o calls. A user of the API can register a listener and get callbacks for read and write operations on sockets and files. It does not (yet) cover asynchronous i/o calls. When not used, the implementation should add a minimum of overhead. To provide useful information to the user, FileInputStream, FileOutputStream and RandomAccessFile have been modified to keep track of the path they operate on (when available). >> >> Webrev: http://cr.openjdk.java.net/~sla/iotrace/webrev.00/ >> >> Feedback is most welcome, >> /Staffan >> > Part of me is a somewhat disappointed to see hooks going into the I/O paths, but I understand why it needs to be done. I see the mails that getting some performance figures on the overhead and that would be good to have. Yes, it worries me a bit, too. I'll see what the microbenchmarks say. > I think IoTrace/IoTraceListener needs to have some javadoc. I suggest this because it's impossible to implement IoTraceListener (even in the JDK) without some documentation as to how it is used. I see there is a block comment in IoTraceListener but there are other things that an implementer needs to know, particularly as to possible behavior when there is an I/O error. Looking at the usages then it looks like in *End might not be called, in other cases it can be called with 0 when there is an error. Wil fix. > I also see mails about IoTrace.listener needing to be volatile, that would be good to do. > > I also think it would be useful to have a basic sanity test of the hooks. I realize there will be product usage elsewhere but we should have something simple in the jdk repository too. Will fix. > In FileInputStream, FileOutputStream and FileChannelImpl then the comment on path is that it is null "if there is no file" but I think this should say that the stream (or parent stream in the case of a file channel) is created with a file descriptor. Yes. > In SocketChannelImpl then if the channel is configured non-blocking socketReadEnd will be called without a socketReadBegin. If this is intended then it will be something for the IoTrace/IoTraceListener javadoc. This is an error. The socketReadEnd() call should be guarded the same way socketReadBegin() is. > I realize the focus is blocking I/O for now but one thing to know is that timed read operations on socket adapters (the socket obtained by calling SocketChannel's socket method) configures the socket channel to be non-blocking so this means that this I/O will not be observed by the IoTraceListener. I need some help to understand which call path you are referring to here. I see SocketChannelImpl.socket() returning a SocketAdapter, but I don't see how/if this is Socket is configured to be non-blocking. > In both FileChannelImpl and SocketChannelImpl then normalize will now be called twice on each return status, I don't expect this will be observable from a performance perspective. Yes, I would be surprised if this was observable. I could rework the code so it's only called once. > > SolarisUserDefinedFileAttributeView - this is I/O on a file's extended attributes rather than its contents, it might not interesting to the IoTraceListener. Hard to tell if it will be interesting or not. If there is i/o related to the file, it is probably of interest when diagnosing problems. I also don't know how to exclude this information in a simple way. > UnixChannelFactory L137, this line is getting long, might be better to go into a second line. Will fix. > WindowsChannelFactory - one thing to be aware of is newFileChannel will also be called when open named streams so pathForWindows won't be the name of a file that you see on the file system. I don't know if this is interesting here or not, it should be rare. Sounds like the name of the stream would also be of interest to anyone tracing/diagnosing. /Staffan > That's all I have. > > -Alan. From fuyou001 at gmail.com Sun Nov 4 13:19:07 2012 From: fuyou001 at gmail.com (fuyou) Date: Sun, 4 Nov 2012 21:19:07 +0800 Subject: about SuppressWarnings Message-ID: hi all When I use @SuppressWarnings in program. I only know some ,ex @SuppressWarnings("unchecked"), at SuppressWarnings("unused"). what others? -- ============================================= fuyou001 Best Regards From rednaxelafx at gmail.com Sun Nov 4 13:38:19 2012 From: rednaxelafx at gmail.com (Krystal Mok) Date: Sun, 4 Nov 2012 21:38:19 +0800 Subject: about SuppressWarnings In-Reply-To: References: Message-ID: Hi, If you're using javac to compile your Java source code, than you can try running javac -X to see the list of -Xlint options. That'll give you a hint of what warnings can be suppressed. As from the JavaDoc [1], the warning names are vendor specific. So if you're not using javac then youll need to find out what warnings your compiler supports. - Kris [1]: http://docs.oracle.com/javase/7/docs/api/java/lang/SuppressWarnings.html On Sun, Nov 4, 2012 at 9:19 PM, fuyou wrote: > hi > all > When I use @SuppressWarnings in program. > I only know some ,ex > @SuppressWarnings("unchecked"), at SuppressWarnings("unused"). > what others? > > -- > ============================================= > > fuyou001 > Best Regards > From Alan.Bateman at oracle.com Sun Nov 4 14:28:32 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 04 Nov 2012 14:28:32 +0000 Subject: about SuppressWarnings In-Reply-To: References: Message-ID: <50967B90.5030004@oracle.com> On 04/11/2012 13:19, fuyou wrote: > hi > all > When I use @SuppressWarnings in program. > I only know some ,ex > @SuppressWarnings("unchecked"), at SuppressWarnings("unused"). > what others? > The JLS specifies two warning names [2], beyond that it is compiler specific. In the case of javac then you use "java -X" and it output will include possible values for -Xlint that are the warning names you can use with @SupressWarnings. -Alan [1] http://docs.oracle.com/javase/specs/jls/se7/html/jls-9.html#jls-9.6.3.5 From alan.bateman at oracle.com Sun Nov 4 14:11:28 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Sun, 04 Nov 2012 14:11:28 +0000 Subject: hg: jdk8/tl/jdk: 8000330: (fc) FileChannel.truncate issues when given size > file size; ... Message-ID: <20121104141212.BFA3B47771@hg.openjdk.java.net> Changeset: bc09a1591629 Author: alanb Date: 2012-11-04 14:07 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bc09a1591629 8000330: (fc) FileChannel.truncate issues when given size > file size 8002180: (fc) FileChannel.map does not throw NPE if MapMode specified as null Reviewed-by: chegar ! src/share/classes/sun/nio/ch/FileChannelImpl.java ! test/java/nio/channels/FileChannel/MapTest.java ! test/java/nio/channels/FileChannel/Truncate.java From Alan.Bateman at oracle.com Sun Nov 4 15:13:12 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 04 Nov 2012 15:13:12 +0000 Subject: Preliminary review: Adding tracing of I/O calls In-Reply-To: <63FAA509-60DF-43F0-8A98-8D1B2BA3FA37@oracle.com> References: <22767084-EAC2-4D87-800B-3E5E5BFC666A@oracle.com> <5094476D.3090501@oracle.com> <63FAA509-60DF-43F0-8A98-8D1B2BA3FA37@oracle.com> Message-ID: <50968608.3060206@oracle.com> On 04/11/2012 12:50, Staffan Larsen wrote: > : >> I realize the focus is blocking I/O for now but one thing to know is that timed read operations on socket adapters (the socket obtained by calling SocketChannel's socket method) configures the socket channel to be non-blocking so this means that this I/O will not be observed by the IoTraceListener. > I need some help to understand which call path you are referring to here. I see SocketChannelImpl.socket() returning a SocketAdapter, but I don't see how/if this is Socket is configured to be non-blocking. Socket s = sc.socket(); s.setSoTimeout(5*1000); int n = s.getInputStream().read(ba); This read is a blocking read, it's just that the underlying socket channel will be non-blocking so it will not be observed by the IoTraceListener. This shouldn't be too common and might not be a big concern but I just wanted to point it out. > : >> SolarisUserDefinedFileAttributeView - this is I/O on a file's extended attributes rather than its contents, it might not interesting to the IoTraceListener. > Hard to tell if it will be interesting or not. If there is i/o related to the file, it is probably of interest when diagnosing problems. I also don't know how to exclude this information in a simple way. It probably isn't too interesting, I was mostly pointing out the inconsistencies. With the current patch then IoTraceListener will see the events on Solaris and they will look like regular I/O on the file. On Linux then the IoTraceListener will not will be notified. On Windows then the IoTraceListener will be notified, it's just that the file name that it sees will name the named stream in the name. There are bigger fish to fry so this may be something to look at again some time in the future. -Alan. From peter.levart at gmail.com Sun Nov 4 20:27:41 2012 From: peter.levart at gmail.com (Peter Levart) Date: Sun, 04 Nov 2012 21:27:41 +0100 Subject: bottleneck by java.lang.Class.getAnnotations() In-Reply-To: <5093A8D3.4030800@gmail.com> References: <924D06EC-F603-4E6A-A7FE-7A05C77B1217@gmail.com> <23313EDE-3AB7-4E53-8EB1-A6F6CC9383B9@gmail.com> <5093A8D3.4030800@gmail.com> Message-ID: <5096CFBD.2010604@gmail.com> On 11/02/2012 12:04 PM, Peter Levart wrote: > On 11/02/2012 11:03 AM, Alexander Kn?ller wrote: >> Hello there. >> >> (Reposting this request for improvement as suggested in mailing list >> jdk6-dev) >> >> java.lang.Class.getAnnotations() always enters a synchronized-block >> (initAnnotationsIfNecessary() ), slowing down multi core machines >> that heavily make use of Annotations. >> (in our Case we use LoadTimeWeaving in the spring-framework 3.1.2) >> We are using sun-jdk 6u27 on CentOS which has the same >> performance-bottleneck. I could not easily find sources for sunjdk >> (no open source anymore). >> So I do not know if Versions 7 or 8 contain fixes for this. >> openjdk7 and 8 show no fix so far, although it looks like it might be >> possible to build a kind of double-checked locking using local >> variables? >> >> >> I am not very familiar with concurrency while using SoftReferences, >> but I guess using a local Variable for concurrency-avoidance for the >> annotations-field or the target of the SoftReference, then doing a >> nonsynchronized check for the redefinition and a potential null-value >> on the local copy of the annotations-variable should suffice to >> decide that one could leave out the synced call and just returns the >> annotations-value (referenced by the local variable)? >> Also you would need to use a local variable while calculating the >> annotations prior to assigning the result to the annotations-field to >> avoid concurrency-effects on the double-checked locking. >> >> Since Code using getAnnotations() always could get hit by an >> annotations-result not fitting any more to the class because of a >> concurrent thread redefining the class we would not need to take care >> of this (and the current code could cause unexpected behaviour >> already inside "getAnnotations()" after exiting the lock on >> initAnnotationsIfNecessary()). >> >> Regards >> Alex >> >> Anfang der weitergeleiteten E-Mail: >> >>> Von: Alexander Kn?ller >>> Betreff: Re: bottleneck by java.lang.Class.getAnnotations() >>> Datum: 2. November 2012 08:43:06 MEZ >>> An: Joe Darcy >>> Kopie: Alan Bateman , >>> jdk6-dev at openjdk.java.net >>> >>> I know. But there is a usual solution to those kind of problems: >>> double checked locking. >>> This would avoid synchronization for all the cases where no >>> redefinitions take place. >>> (I also put in a bug-report for the sunjdk where I elaborated this a >>> bit more.) >>> I am not so familiar with concurrency while using SoftReferences, >>> but I guess using a local Variable for concurrency-avoidance for the >>> annotations-field or the target of the SoftReference, then doing a >>> nonsynchronized check for the redefinition and a potentially >>> null-value on the local copy of the annotations-variable should >>> suffice to decide that one could leave out the synced call and just >>> returns the annotations-value (in the local variable)? >>> >>> Also you would need to use a local variable while calculating the >>> annotations-Field prior to assigning the result to the field to >>> avoid concurrency-effects on the double-checked locking. >>> >>> Since Code using getAnnotations() always could trap in an >>> annotations-result not fitting any more to the class because of >>> concurrent redefinition we would not need to take care of this (and >>> the current code could cause this already inside "getAnnotations()". >>> >>> -Alex >>> >>> Am 01.11.2012 um 15:56 schrieb Joe Darcy: >>> >>>> On 11/1/2012 7:11 AM, Alan Bateman wrote: >>>>> On 01/11/2012 13:17, Alexander Kn?ller wrote: >>>>>> Hi there. >>>>>> >>>>>> java.lang.Class.getAnnotations() always enters a >>>>>> synchronized-block, slowing down multi core machines that heavily >>>>>> make use of Annotations. >>>>>> (in our Case we use LoadTimeWeaving in the spring-framework 3.1.2) >>>>>> We are using sun-jdk 6 which has the same performance-bottleneck. >>>>>> openjdk7 and 8 show no fix so far, although it looks like it >>>>>> might be possible to build a kind of double-checked locking? >>>>>> >>>>>> Has this issue ever been persued? >>>>>> >>>>>> Special Regards >>>>>> Alex Kn?ller >>>>>> >>>>> If you have a proposal then I suggest bringing it to core-libs-dev >>>>> for discussion. In addition to contention there are other issues >>>>> that need attention there too, particularly the potential to >>>>> deadlock and the overhead per Class when annotations aren't used. >>>>> There's definitely some useful work that could be done there. > > Hi all, > > initAnnotationsIfNecessary() is at least synchronized, so that it > always gets the result right in face of concurrent calls to it and > class redefinitions performed by VM, but other methods, such as for > example: > > private Field[] privateGetDeclaredFields(boolean publicOnly) > > ...and many others are not. Therefore a theoretical race exists that > could install an old version of fields into cached storage > (declaredPublicFields or declaredFields in this case) that was taken > before class was redefined and write it over the new version of fields... I digress. Javadocs say: "The redefinition may change method bodies, the constant pool and attributes. The redefinition must not add, remove or rename fields or methods, change the signatures of methods, or change inheritance. These restrictions maybe be lifted in future versions." So currently there's no problem since redefinition can only change method bodies, so reflecting over old or new version of the class returns the same results. But the synchronization bottleneck of initAnnotationsIfNecessary() could be solved this way. Regrads, Peter > > I suggest redesigning the lazy construction / caching by employing > versioned containers like the following: > > static class VersionedSoftRef extends SoftReference { > final int redefinedCount; > VersionedSoftRef(T referent, int redefinedCount) { > super(referent); > this.redefinedCount = redefinedCount; > } > } > > ...to be used instead of plain SoftReferences in places like > declaredPublicFields and such and using CAS (via Unsafe or > AtomicReferenceFieldUpdater) to optimistically install lazily > constructed data... The versioned containers would serve two > purposes: each access to a part of cached data could be independently > version-checked against current value of classRedefinedCount on a fast > path before returning a cached value. In case of cache-miss (not data > or stale data), a thread could compute the data concurrently with any > other threads doing the same and using CAS at the end, install the > latest version of data into cache. > > For getAnnotations() I would use a similar technique (a versioned > private subclass of HashMap for example). > > If you like, I can prepare a patch and send it for review. > > > Regards, Peter > >>>>> >>>>> >>>> Note that the block in question is synchronized so that >>>> getAnnotations returns the right result if the class has been >>>> redefined at runtime using an API for that purpose. >>>> >>>> -Joe >>>> > From peter.levart at gmail.com Sun Nov 4 23:09:36 2012 From: peter.levart at gmail.com (Peter Levart) Date: Mon, 05 Nov 2012 00:09:36 +0100 Subject: bottleneck by java.lang.Class.getAnnotations() - proposed patch In-Reply-To: <5096CFBD.2010604@gmail.com> References: <924D06EC-F603-4E6A-A7FE-7A05C77B1217@gmail.com> <23313EDE-3AB7-4E53-8EB1-A6F6CC9383B9@gmail.com> <5093A8D3.4030800@gmail.com> <5096CFBD.2010604@gmail.com> Message-ID: <5096F5B0.8070304@gmail.com> Hi, I propose the following patch to java.lang.Class in order to overcome the synchronization bottleneck when accessing annotations from multiple threads. The patch packs the 'annotations' and 'declaredAnnotations' Maps together with an int redefinedCount into a structure: static class Annotations { final Map, Annotation> annotations; final Map, Annotation> declaredAnnotations; final int redefinedCount; which is referenced by a single volatile Class.annotations field. Instead of initAnnotationsIfNecessary() there's a getAnnotationsPrivate() method that uses simple double-checked locking to lazily initialize and return this structure. The slow-path part is still synchronized to ensure that Class.setAnnotationType/getAnnotationType call backs from AnnotationType are only done while holding a lock. Regards, Peter Here's the patch to jdk8 source: diff -r 7ac292e57b5a src/share/classes/java/lang/Class.java --- a/src/share/classes/java/lang/Class.java Thu Nov 01 14:12:21 2012 -0700 +++ b/src/share/classes/java/lang/Class.java Sun Nov 04 23:53:04 2012 +0100 @@ -2237,10 +2237,8 @@ declaredFields = publicFields = declaredPublicFields = null; declaredMethods = publicMethods = declaredPublicMethods = null; declaredConstructors = publicConstructors = null; - annotations = declaredAnnotations = null; - // Use of "volatile" (and synchronization by caller in the case - // of annotations) ensures that no thread sees the update to + // Use of "volatile" ensures that no thread sees the update to // lastRedefinedCount before seeing the caches cleared. // We do not guard against brief windows during which multiple // threads might redundantly work to fill an empty cache. @@ -3049,8 +3047,7 @@ if (annotationClass == null) throw new NullPointerException(); - initAnnotationsIfNecessary(); - return (A) annotations.get(annotationClass); + return (A) getAnnotationsPrivate().annotations.get(annotationClass); } /** @@ -3070,40 +3067,52 @@ * @since 1.5 */ public Annotation[] getAnnotations() { - initAnnotationsIfNecessary(); - return AnnotationParser.toArray(annotations); + return AnnotationParser.toArray(getAnnotationsPrivate().annotations); } /** * @since 1.5 */ public Annotation[] getDeclaredAnnotations() { - initAnnotationsIfNecessary(); - return AnnotationParser.toArray(declaredAnnotations); + return AnnotationParser.toArray(getAnnotationsPrivate().declaredAnnotations); } // Annotations cache - private transient Map, Annotation> annotations; - private transient Map, Annotation> declaredAnnotations; + private transient volatile Annotations annotations; - private synchronized void initAnnotationsIfNecessary() { - clearCachesOnClassRedefinition(); - if (annotations != null) - return; - declaredAnnotations = AnnotationParser.parseAnnotations( - getRawAnnotations(), getConstantPool(), this); - Class superClass = getSuperclass(); - if (superClass == null) { - annotations = declaredAnnotations; - } else { - annotations = new HashMap<>(); - superClass.initAnnotationsIfNecessary(); - for (Map.Entry, Annotation> e : superClass.annotations.entrySet()) { - Class annotationClass = e.getKey(); - if (AnnotationType.getInstance(annotationClass).isInherited()) - annotations.put(annotationClass, e.getValue()); + private Annotations getAnnotationsPrivate() { + // double checked locking + int redefinedCount = classRedefinedCount; + Annotations anns = annotations; + if (anns != null && anns.redefinedCount == redefinedCount) { + return anns; + } + + synchronized (this) { + redefinedCount = classRedefinedCount; + anns = annotations; + if (anns != null && anns.redefinedCount == redefinedCount) { + return anns; } - annotations.putAll(declaredAnnotations); + + Map, Annotation> declAnnMap = AnnotationParser.parseAnnotations( + getRawAnnotations(), getConstantPool(), this); + Map, Annotation> annMap; + Class superClass = getSuperclass(); + if (superClass == null) { + annMap = declAnnMap; + } else { + annMap = new HashMap<>(); + for (Map.Entry, Annotation> e : superClass.getAnnotationsPrivate().annotations.entrySet()) { + Class annotationClass = e.getKey(); + if (AnnotationType.getInstance(annotationClass).isInherited()) + annMap.put(annotationClass, e.getValue()); + } + annMap.putAll(declAnnMap); + } + + annotations = anns = new Annotations(annMap, declAnnMap, redefinedCount); + return anns; } } @@ -3119,6 +3128,18 @@ return annotationType; } + static final class Annotations { + final Map, Annotation> annotations; + final Map, Annotation> declaredAnnotations; + final int redefinedCount; + + Annotations(Map, Annotation> annotations, Map, Annotation> declaredAnnotations, int redefinedCount) { + this.annotations = annotations; + this.declaredAnnotations = declaredAnnotations; + this.redefinedCount = redefinedCount; + } + } + /* Backing store of user-defined values pertaining to this class. * Maintained by the ClassValue class. */ From david.holmes at oracle.com Mon Nov 5 05:23:09 2012 From: david.holmes at oracle.com (David Holmes) Date: Mon, 05 Nov 2012 15:23:09 +1000 Subject: bottleneck by java.lang.Class.getAnnotations() - proposed patch In-Reply-To: <5096F5B0.8070304@gmail.com> References: <924D06EC-F603-4E6A-A7FE-7A05C77B1217@gmail.com> <23313EDE-3AB7-4E53-8EB1-A6F6CC9383B9@gmail.com> <5093A8D3.4030800@gmail.com> <5096CFBD.2010604@gmail.com> <5096F5B0.8070304@gmail.com> Message-ID: <50974D3D.1040502@oracle.com> Hi Peter, Moving the annotations fields into a helper object would tie in with the Class-instance size reduction effort that was investigated as part of "JEP 149: Reduce Core-Library Memory Usage": http://openjdk.java.net/jeps/149 The investigations there to date only looked at relocating the reflection related fields, though the JEP mentions the annotations as well. Any such effort requires extensive benchmarking and performance analysis before being accepted though. David ----- On 5/11/2012 9:09 AM, Peter Levart wrote: > Hi, > > I propose the following patch to java.lang.Class in order to overcome > the synchronization bottleneck when accessing annotations from multiple > threads. The patch packs the 'annotations' and 'declaredAnnotations' > Maps together with an int redefinedCount into a structure: > > static class Annotations { > final Map, Annotation> annotations; > final Map, Annotation> declaredAnnotations; > final int redefinedCount; > > which is referenced by a single volatile Class.annotations field. > Instead of initAnnotationsIfNecessary() there's a > getAnnotationsPrivate() method that uses simple double-checked locking > to lazily initialize and return this structure. The slow-path part is > still synchronized to ensure that > Class.setAnnotationType/getAnnotationType call backs from AnnotationType > are only done while holding a lock. > > Regards, Peter > > Here's the patch to jdk8 source: > > diff -r 7ac292e57b5a src/share/classes/java/lang/Class.java > --- a/src/share/classes/java/lang/Class.java Thu Nov 01 14:12:21 2012 -0700 > +++ b/src/share/classes/java/lang/Class.java Sun Nov 04 23:53:04 2012 +0100 > @@ -2237,10 +2237,8 @@ > declaredFields = publicFields = declaredPublicFields = null; > declaredMethods = publicMethods = declaredPublicMethods = null; > declaredConstructors = publicConstructors = null; > - annotations = declaredAnnotations = null; > > - // Use of "volatile" (and synchronization by caller in the case > - // of annotations) ensures that no thread sees the update to > + // Use of "volatile" ensures that no thread sees the update to > // lastRedefinedCount before seeing the caches cleared. > // We do not guard against brief windows during which multiple > // threads might redundantly work to fill an empty cache. > @@ -3049,8 +3047,7 @@ > if (annotationClass == null) > throw new NullPointerException(); > > - initAnnotationsIfNecessary(); > - return (A) annotations.get(annotationClass); > + return (A) getAnnotationsPrivate().annotations.get(annotationClass); > } > > /** > @@ -3070,40 +3067,52 @@ > * @since 1.5 > */ > public Annotation[] getAnnotations() { > - initAnnotationsIfNecessary(); > - return AnnotationParser.toArray(annotations); > + return AnnotationParser.toArray(getAnnotationsPrivate().annotations); > } > > /** > * @since 1.5 > */ > public Annotation[] getDeclaredAnnotations() { > - initAnnotationsIfNecessary(); > - return AnnotationParser.toArray(declaredAnnotations); > + return > AnnotationParser.toArray(getAnnotationsPrivate().declaredAnnotations); > } > > // Annotations cache > - private transient Map, Annotation> > annotations; > - private transient Map, Annotation> > declaredAnnotations; > + private transient volatile Annotations annotations; > > - private synchronized void initAnnotationsIfNecessary() { > - clearCachesOnClassRedefinition(); > - if (annotations != null) > - return; > - declaredAnnotations = AnnotationParser.parseAnnotations( > - getRawAnnotations(), getConstantPool(), this); > - Class superClass = getSuperclass(); > - if (superClass == null) { > - annotations = declaredAnnotations; > - } else { > - annotations = new HashMap<>(); > - superClass.initAnnotationsIfNecessary(); > - for (Map.Entry, Annotation> e : > superClass.annotations.entrySet()) { > - Class annotationClass = e.getKey(); > - if (AnnotationType.getInstance(annotationClass).isInherited()) > - annotations.put(annotationClass, e.getValue()); > + private Annotations getAnnotationsPrivate() { > + // double checked locking > + int redefinedCount = classRedefinedCount; > + Annotations anns = annotations; > + if (anns != null && anns.redefinedCount == redefinedCount) { > + return anns; > + } > + > + synchronized (this) { > + redefinedCount = classRedefinedCount; > + anns = annotations; > + if (anns != null && anns.redefinedCount == redefinedCount) { > + return anns; > } > - annotations.putAll(declaredAnnotations); > + > + Map, Annotation> declAnnMap = > AnnotationParser.parseAnnotations( > + getRawAnnotations(), getConstantPool(), this); > + Map, Annotation> annMap; > + Class superClass = getSuperclass(); > + if (superClass == null) { > + annMap = declAnnMap; > + } else { > + annMap = new HashMap<>(); > + for (Map.Entry, Annotation> e : > superClass.getAnnotationsPrivate().annotations.entrySet()) { > + Class annotationClass = e.getKey(); > + if (AnnotationType.getInstance(annotationClass).isInherited()) > + annMap.put(annotationClass, e.getValue()); > + } > + annMap.putAll(declAnnMap); > + } > + > + annotations = anns = new Annotations(annMap, declAnnMap, redefinedCount); > + return anns; > } > } > > @@ -3119,6 +3128,18 @@ > return annotationType; > } > > + static final class Annotations { > + final Map, Annotation> annotations; > + final Map, Annotation> declaredAnnotations; > + final int redefinedCount; > + > + Annotations(Map, Annotation> annotations, > Map, Annotation> declaredAnnotations, int > redefinedCount) { > + this.annotations = annotations; > + this.declaredAnnotations = declaredAnnotations; > + this.redefinedCount = redefinedCount; > + } > + } > + > /* Backing store of user-defined values pertaining to this class. > * Maintained by the ClassValue class. > */ > From erik.joelsson at oracle.com Mon Nov 5 08:11:30 2012 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 05 Nov 2012 09:11:30 +0100 Subject: RFR: JDK-8001191: use -source 8 -target 8 when compiling the JDK In-Reply-To: <5094347D.6030101@oracle.COM> References: <5091635A.3010000@oracle.COM> <5091D2A9.7030901@oracle.com> <5091D9DF.8090400@oracle.com> <5091DCD4.2090409@oracle.com> <3F615A55-4238-4AFA-947F-BC1A019BC653@oracle.com> <5094347D.6030101@oracle.COM> Message-ID: <509774B2.2020504@oracle.com> Looks good to me now. /Erik On 2012-11-02 22:00, Kumar Srinivasan wrote: > Hi David, Kelly, Erik, > > as Kelly stated the jdk only build, uses the compiler from the > import JDK, this works with -source 8 -target, which was prepped > by Joe earlier. I also checked with a jdk only jprt build submission, > which exposed another location that needed a bump. > > I have fixed the new infra build as well as Erik suggested, here is > the new > webrev: > http://cr.openjdk.java.net/~ksrini/8001191/webrev.1/ > > The delta webrev ie. changes since the last reviewed: > http://cr.openjdk.java.net/~ksrini/8001191/webrev.1/webrev.delta/index.html > > > Thanks > Kumar > >> If someone is doing a partial build (without langtools) the import >> jdk is used for javac compilation, not the boot jdk javac. >> This has not changed. >> The boot jdk javac is only used to build langtools and the hotspot >> serviceability agent. >> >> -kto >> >> On Oct 31, 2012, at 7:22 PM, David Holmes wrote: >> >>> Hi Jon, >>> >>> On 1/11/2012 12:09 PM, Jonathan Gibbons wrote: >>>> David, >>>> >>>> For a long time now, the JDK 8 langtools repo has accepted -source >>>> 8 and >>>> -target 8, so this should not affect which version of langtools you >>>> need >>>> to use. Of course, you do need to make sure that these options are not >>>> used with the bootstrap javac, which will typically be from JDK 7. >>> That wasn't quite my query/concern - I wasn't very clear. If someone >>> is doing a partial build, ie JDK repo only, they will now have to >>> use a JDK8 boot JDK (or point to suitable langtools import?) - >>> correct? (Where a full build would use the current langtools to >>> build the rest of the JDK.) >>> >>> Just trying to understand if there may be places (JPRT?) where we've >>> so far been able to use a JDK7 boot JDK but will no longer be able to. >>> >>> Thanks, >>> David >>> >>>> -- Jon >>>> >>>> >>>> On 10/31/2012 06:38 PM, David Holmes wrote: >>>>> Hi Kumar, >>>>> >>>>> So after this jdk8 builds will have to use current langtools javac in >>>>> order to work? >>>>> >>>>> The corresponding changes to the new build system will be needed >>>>> as well. >>>>> >>>>> David >>>>> >>>>> On 1/11/2012 3:43 AM, Kumar Srinivasan wrote: >>>>>> Hello, >>>>>> >>>>>> Please review changes to rev up the default -source and -target >>>>>> for jdk >>>>>> compilation, >>>>>> thus producing v52.0 class files. >>>>>> >>>>>> Bug is here: >>>>>> https://jbs.oracle.com/bugs/browse/JDK-8001191 >>>>>> >>>>>> Webrev is here: >>>>>> http://cr.openjdk.java.net/~ksrini/8001191/webrev.0/ >>>>>> >>>>>> Note: this webrev is generated against the master repository but >>>>>> changes >>>>>> will be >>>>>> pushed via tl after the tl-master sync is completed. >>>>>> >>>>>> Thanks >>>>>> Kumar >>>>>> > From Alan.Bateman at oracle.com Mon Nov 5 09:25:11 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 05 Nov 2012 09:25:11 +0000 Subject: bottleneck by java.lang.Class.getAnnotations() In-Reply-To: <5096CFBD.2010604@gmail.com> References: <924D06EC-F603-4E6A-A7FE-7A05C77B1217@gmail.com> <23313EDE-3AB7-4E53-8EB1-A6F6CC9383B9@gmail.com> <5093A8D3.4030800@gmail.com> <5096CFBD.2010604@gmail.com> Message-ID: <509785F7.1090909@oracle.com> On 04/11/2012 20:27, Peter Levart wrote: > : > I digress. Javadocs say: "The redefinition may change method bodies, > the constant pool and attributes. The redefinition must not add, > remove or rename fields or methods, change the signatures of methods, > or change inheritance. These restrictions maybe be lifted in future > versions." > > So currently there's no problem since redefinition can only change > method bodies, so reflecting over old or new version of the class > returns the same results. Here's a good starting place on the interaction of runtime visible attributes and RedefineClasses/RetransformClasses: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5002251 -Alan. From chris.hegarty at oracle.com Mon Nov 5 10:37:16 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 05 Nov 2012 10:37:16 +0000 Subject: Preliminary review: Adding tracing of I/O calls In-Reply-To: <50965EB9.90509@oracle.com> References: <22767084-EAC2-4D87-800B-3E5E5BFC666A@oracle.com> <50942931.4000001@oracle.com> <08183803-2563-461C-9514-B7FAE1E14C10@oracle.com> <509437F0.4020409@oracle.com> <50965EB9.90509@oracle.com> Message-ID: <509796DC.7040606@oracle.com> On 04/11/2012 12:25, Aleksey Shipilev wrote: > ..... > > class IoTrace { > public static final boolean ENABLED = > System.getProperty("java.io.trace"); > } > > ...which will demote the flexibility of setListener(), but have much > lower runtime overhead. This should be confirmed by microbenchmarking > anyway. +1 for this approach, if it provides sufficient functionality. -Chris. > > -Aleksey. From alexander.knoeller at gmail.com Mon Nov 5 13:36:19 2012 From: alexander.knoeller at gmail.com (=?iso-8859-1?Q?Alexander_Kn=F6ller?=) Date: Mon, 5 Nov 2012 14:36:19 +0100 Subject: bottleneck by java.lang.Class.getAnnotations() - proposed patch In-Reply-To: <50974D3D.1040502@oracle.com> References: <924D06EC-F603-4E6A-A7FE-7A05C77B1217@gmail.com> <23313EDE-3AB7-4E53-8EB1-A6F6CC9383B9@gmail.com> <5093A8D3.4030800@gmail.com> <5096CFBD.2010604@gmail.com> <5096F5B0.8070304@gmail.com> <50974D3D.1040502@oracle.com> Message-ID: Hi David. What about my proposal for a simple double-checked-locking for the redefinitions fields and the use of local variables for "annotations" in getAnnotations() and initAnnotationsIfNecessary() ? Are additional local Variables similar "bad habit" for memory usage (although they only affect the stack)? Alex Am 05.11.2012 um 06:23 schrieb David Holmes: > Hi Peter, > > Moving the annotations fields into a helper object would tie in with the Class-instance size reduction effort that was investigated as part of "JEP 149: Reduce Core-Library Memory Usage": > > http://openjdk.java.net/jeps/149 > > The investigations there to date only looked at relocating the reflection related fields, though the JEP mentions the annotations as well. > > Any such effort requires extensive benchmarking and performance analysis before being accepted though. > > David > ----- > > On 5/11/2012 9:09 AM, Peter Levart wrote: >> Hi, >> >> I propose the following patch to java.lang.Class in order to overcome >> the synchronization bottleneck when accessing annotations from multiple >> threads. The patch packs the 'annotations' and 'declaredAnnotations' >> Maps together with an int redefinedCount into a structure: >> >> static class Annotations { >> final Map, Annotation> annotations; >> final Map, Annotation> declaredAnnotations; >> final int redefinedCount; >> >> which is referenced by a single volatile Class.annotations field. >> Instead of initAnnotationsIfNecessary() there's a >> getAnnotationsPrivate() method that uses simple double-checked locking >> to lazily initialize and return this structure. The slow-path part is >> still synchronized to ensure that >> Class.setAnnotationType/getAnnotationType call backs from AnnotationType >> are only done while holding a lock. >> >> Regards, Peter >> >> Here's the patch to jdk8 source: >> >> diff -r 7ac292e57b5a src/share/classes/java/lang/Class.java >> --- a/src/share/classes/java/lang/Class.java Thu Nov 01 14:12:21 2012 -0700 >> +++ b/src/share/classes/java/lang/Class.java Sun Nov 04 23:53:04 2012 +0100 >> @@ -2237,10 +2237,8 @@ >> declaredFields = publicFields = declaredPublicFields = null; >> declaredMethods = publicMethods = declaredPublicMethods = null; >> declaredConstructors = publicConstructors = null; >> - annotations = declaredAnnotations = null; >> >> - // Use of "volatile" (and synchronization by caller in the case >> - // of annotations) ensures that no thread sees the update to >> + // Use of "volatile" ensures that no thread sees the update to >> // lastRedefinedCount before seeing the caches cleared. >> // We do not guard against brief windows during which multiple >> // threads might redundantly work to fill an empty cache. >> @@ -3049,8 +3047,7 @@ >> if (annotationClass == null) >> throw new NullPointerException(); >> >> - initAnnotationsIfNecessary(); >> - return (A) annotations.get(annotationClass); >> + return (A) getAnnotationsPrivate().annotations.get(annotationClass); >> } >> >> /** >> @@ -3070,40 +3067,52 @@ >> * @since 1.5 >> */ >> public Annotation[] getAnnotations() { >> - initAnnotationsIfNecessary(); >> - return AnnotationParser.toArray(annotations); >> + return AnnotationParser.toArray(getAnnotationsPrivate().annotations); >> } >> >> /** >> * @since 1.5 >> */ >> public Annotation[] getDeclaredAnnotations() { >> - initAnnotationsIfNecessary(); >> - return AnnotationParser.toArray(declaredAnnotations); >> + return >> AnnotationParser.toArray(getAnnotationsPrivate().declaredAnnotations); >> } >> >> // Annotations cache >> - private transient Map, Annotation> >> annotations; >> - private transient Map, Annotation> >> declaredAnnotations; >> + private transient volatile Annotations annotations; >> >> - private synchronized void initAnnotationsIfNecessary() { >> - clearCachesOnClassRedefinition(); >> - if (annotations != null) >> - return; >> - declaredAnnotations = AnnotationParser.parseAnnotations( >> - getRawAnnotations(), getConstantPool(), this); >> - Class superClass = getSuperclass(); >> - if (superClass == null) { >> - annotations = declaredAnnotations; >> - } else { >> - annotations = new HashMap<>(); >> - superClass.initAnnotationsIfNecessary(); >> - for (Map.Entry, Annotation> e : >> superClass.annotations.entrySet()) { >> - Class annotationClass = e.getKey(); >> - if (AnnotationType.getInstance(annotationClass).isInherited()) >> - annotations.put(annotationClass, e.getValue()); >> + private Annotations getAnnotationsPrivate() { >> + // double checked locking >> + int redefinedCount = classRedefinedCount; >> + Annotations anns = annotations; >> + if (anns != null && anns.redefinedCount == redefinedCount) { >> + return anns; >> + } >> + >> + synchronized (this) { >> + redefinedCount = classRedefinedCount; >> + anns = annotations; >> + if (anns != null && anns.redefinedCount == redefinedCount) { >> + return anns; >> } >> - annotations.putAll(declaredAnnotations); >> + >> + Map, Annotation> declAnnMap = >> AnnotationParser.parseAnnotations( >> + getRawAnnotations(), getConstantPool(), this); >> + Map, Annotation> annMap; >> + Class superClass = getSuperclass(); >> + if (superClass == null) { >> + annMap = declAnnMap; >> + } else { >> + annMap = new HashMap<>(); >> + for (Map.Entry, Annotation> e : >> superClass.getAnnotationsPrivate().annotations.entrySet()) { >> + Class annotationClass = e.getKey(); >> + if (AnnotationType.getInstance(annotationClass).isInherited()) >> + annMap.put(annotationClass, e.getValue()); >> + } >> + annMap.putAll(declAnnMap); >> + } >> + >> + annotations = anns = new Annotations(annMap, declAnnMap, redefinedCount); >> + return anns; >> } >> } >> >> @@ -3119,6 +3128,18 @@ >> return annotationType; >> } >> >> + static final class Annotations { >> + final Map, Annotation> annotations; >> + final Map, Annotation> declaredAnnotations; >> + final int redefinedCount; >> + >> + Annotations(Map, Annotation> annotations, >> Map, Annotation> declaredAnnotations, int >> redefinedCount) { >> + this.annotations = annotations; >> + this.declaredAnnotations = declaredAnnotations; >> + this.redefinedCount = redefinedCount; >> + } >> + } >> + >> /* Backing store of user-defined values pertaining to this class. >> * Maintained by the ClassValue class. >> */ >> From Thomas.Salter at unisys.com Mon Nov 5 15:02:10 2012 From: Thomas.Salter at unisys.com (Salter, Thomas A) Date: Mon, 5 Nov 2012 09:02:10 -0600 Subject: HashMap / doPrivileged problem Message-ID: <63D5DCACD1E9E34C89C8203C64F521C3013642092DCB@USEA-EXCH7.na.uis.unisys.com> I have encountered a problem with initializing the new HashMap code introduced in Java 7u6. I'm running with 7u9. The problem only shows up running rmid (sun.rmi.server.Activation). It seems that the AccessController needs to call HashMap but the new code in HashMap calls AccessController when reading the property, jdk.map.althashing.threshold. At the end of this message is the stack trace and the output of -verbose:class showing the failure. Here's a synopsis of what I think is happening: 1. AccessControllerContext at 98 caused Policy.isset. 2. Before calling isSet, the class loader initialize Policy by calling 3. Clinit found its way into HashMap init. 4. HashMap init called HashMap$Holder. 5. Which called AccessController 6. Which eventually called isSet. Policy was already loaded and its clinit called, so isSet actually got called. 7. But Policy. had not completed so policy is null, hence NPE. 8. The class loader from #2 caught the exception and wrapped it in the ExceptionInitializationError. I'm running a modified JDK, with modifications primarily in the area of file and socket IO. I'm pretty sure we've modified none of the classes in the stack trace below. The best I can tell, our changes eliminated the loading of WinNTFileSystem and changed the CharSet classes that are called. Apparently that code contains an incidental call to HashMap that gets it initialized before doPrivileged gets called from some other class. I've found an inelegant workaround. In java.lang.System I added a "new HashMap()" immediately following the call to set VM.booted to true. This causes the HashMap$Holder class to be initialized before doPrivileged can call it. The key to the fix is that HashMap needs to be called after isBooted has been set so that it will invoke its Holder class. Since the Holder class invokes doPrivileged, the HashMap needs to have been initialized before anyone calls doPrivileged. The verbose trace and stack trace follow: [Opened /-/JAVA_BOOT/jre/lib/resources.jar] [Opened /-/JAVA_BOOT/jre/lib/mcp.jar] [Opened /-/JAVA_BOOT/jre/lib/xlateebcdic.jar] [Opened /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.lang.Object from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.io.Serializable from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.lang.Comparable from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.lang.CharSequence from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.lang.String from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.lang.reflect.GenericDeclaration from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.lang.reflect.Type from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.lang.reflect.AnnotatedElement from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.lang.Class from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.lang.Cloneable from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.lang.ClassLoader from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.lang.System from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.lang.Throwable from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.lang.Error from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.lang.ThreadDeath from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.lang.Exception from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.lang.RuntimeException from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.security.ProtectionDomain from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.security.AccessControlContext from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.lang.ReflectiveOperationException from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.lang.ClassNotFoundException from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.lang.LinkageError from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.lang.NoClassDefFoundError from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.lang.ClassCastException from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.lang.ArrayStoreException from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.lang.VirtualMachineError from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.lang.OutOfMemoryError from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.lang.StackOverflowError from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.lang.IllegalMonitorStateException from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded com.unisys.mcp.ChannelError from /-/JAVA_BOOT/jre/lib/mcp.jar] [Loaded com.unisys.mcp.InterfaceException from /-/JAVA_BOOT/jre/lib/mcp.jar] [Loaded com.unisys.mcp.ConversionException from /-/JAVA_BOOT/jre/lib/mcp.jar] [Loaded java.lang.ref.Reference from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.lang.ref.SoftReference from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.lang.ref.WeakReference from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.lang.ref.FinalReference from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.lang.ref.PhantomReference from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.lang.ref.Finalizer from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.lang.Runnable from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.lang.Thread from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.lang.Thread$UncaughtExceptionHandler from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.lang.ThreadGroup from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.Map from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.Dictionary from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.Hashtable from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.Properties from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.lang.reflect.AccessibleObject from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.lang.reflect.Member from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.lang.reflect.Field from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.lang.reflect.Method from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.lang.reflect.Constructor from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded sun.reflect.MagicAccessorImpl from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded sun.reflect.MethodAccessor from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded sun.reflect.MethodAccessorImpl from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded sun.reflect.ConstructorAccessor from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded sun.reflect.ConstructorAccessorImpl from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded sun.reflect.DelegatingClassLoader from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded sun.reflect.ConstantPool from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded sun.reflect.FieldAccessor from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded sun.reflect.FieldAccessorImpl from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded sun.reflect.UnsafeFieldAccessorImpl from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded sun.reflect.UnsafeStaticFieldAccessorImpl from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.lang.invoke.MethodHandle from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.lang.invoke.MemberName from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.lang.invoke.MethodHandleNatives from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.lang.invoke.BoundMethodHandle from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.lang.invoke.AdapterMethodHandle from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.lang.invoke.DirectMethodHandle from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.lang.invoke.MethodType from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.lang.invoke.MethodTypeForm from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.lang.BootstrapMethodError from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.lang.invoke.WrongMethodTypeException from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.lang.invoke.CallSite from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.lang.invoke.CountingMethodHandle from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.lang.invoke.ConstantCallSite from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.lang.invoke.MutableCallSite from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.lang.invoke.VolatileCallSite from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.lang.Appendable from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.lang.AbstractStringBuilder from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.lang.StringBuffer from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.lang.StringBuilder from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.lang.StackTraceElement from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.nio.Buffer from /-/JAVA_BOOT/jre/lib/rt.jar] [Opened /-/JAVA_BOOT/jre/lib/jsse.jar] [Opened /-/JAVA_BOOT/jre/lib/jce.jar] [Opened /-/JAVA_BOOT/jre/lib/charsets.jar] [Loaded java.lang.Boolean from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.lang.Character from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.lang.Number from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.lang.Float from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.lang.Double from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.lang.Byte from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.lang.Short from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.lang.Integer from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.lang.Long from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.lang.NullPointerException from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.lang.ArithmeticException from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.io.ObjectStreamField from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.Comparator from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.lang.String$CaseInsensitiveComparator from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.security.Guard from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.security.Permission from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.security.BasicPermission from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.lang.RuntimePermission from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.security.AccessController from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.lang.reflect.ReflectPermission from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.security.PrivilegedAction from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded sun.reflect.ReflectionFactory$GetReflectionFactoryAction from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.security.cert.Certificate from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.lang.Iterable from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.Collection from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.List from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.RandomAccess from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.AbstractCollection from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.AbstractList from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.Vector from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.Stack from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded sun.reflect.ReflectionFactory from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.lang.ref.Reference$Lock from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.lang.ref.Reference$ReferenceHandler from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.lang.ref.ReferenceQueue from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.lang.ref.ReferenceQueue$Null from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.lang.ref.ReferenceQueue$Lock from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.lang.ref.Finalizer$FinalizerThread from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded sun.misc.Unsafe from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.lang.IncompatibleClassChangeError from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.lang.NoSuchMethodError from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.ArrayList from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.Collections from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.Set from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.AbstractSet from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.Collections$EmptySet from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.Collections$EmptyList from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.AbstractMap from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.Collections$EmptyMap from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.Collections$UnmodifiableCollection from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.Collections$UnmodifiableList from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.Collections$UnmodifiableRandomAccessList from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded sun.reflect.Reflection from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.HashMap from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded sun.misc.Hashing from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded sun.misc.VM from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.lang.Runtime from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.Map$Entry from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.Hashtable$Entry from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.lang.Math from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.HashMap$Entry from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.HashMap$EntrySet from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.Iterator from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.HashMap$HashIterator from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.HashMap$EntryIterator from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.lang.Class$3 from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.lang.reflect.Modifier from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded sun.reflect.LangReflectAccess from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.lang.reflect.ReflectAccess from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.nio.charset.Charset from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.nio.charset.spi.CharsetProvider from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded sun.nio.cs.FastCharsetProvider from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded sun.nio.cs.StandardCharsets from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded sun.util.PreHashedMap from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded sun.nio.cs.StandardCharsets$Aliases from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded sun.nio.cs.StandardCharsets$Classes from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded sun.nio.cs.StandardCharsets$Cache from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.lang.ThreadLocal from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.concurrent.atomic.AtomicInteger from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.Arrays from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded sun.nio.cs.HistoricallyNamedCharset from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded sun.nio.cs.Unicode from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded sun.nio.cs.UTF_8 from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.lang.Class$1 from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded sun.reflect.ReflectionFactory$1 from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded sun.reflect.NativeConstructorAccessorImpl from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded sun.reflect.DelegatingConstructorAccessorImpl from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.lang.StringCoding from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.lang.ThreadLocal$ThreadLocalMap from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.lang.ThreadLocal$ThreadLocalMap$Entry from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.lang.StringCoding$StringDecoder from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded sun.nio.cs.ArrayDecoder from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.nio.charset.CharsetDecoder from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded sun.nio.cs.UTF_8$Decoder from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.nio.charset.CodingErrorAction from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.Hashtable$EntrySet from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.Collections$SynchronizedCollection from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.Collections$SynchronizedSet from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.Enumeration from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.Hashtable$Enumerator from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded sun.misc.Version from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.lang.Readable from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.lang.AutoCloseable from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.io.Closeable from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.io.Reader from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.io.BufferedReader from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.io.LineNumberReader from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.io.InputStreamReader from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.io.FileReader from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.io.InputStream from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.io.FileInputStream from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.io.File from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.io.FileSystem from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.io.ClearPathWinFileSystem from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.io.MCPWinFileSystem from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded sun.security.action.GetPropertyAction from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.io.ExpiringCache from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.LinkedHashMap from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.io.ExpiringCache$1 from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.LinkedHashMap$Entry from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.lang.ProcessEnvironment from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.lang.ProcessEnvironment$NameComparator from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.lang.ProcessEnvironment$EntryComparator from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.Collections$UnmodifiableMap from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.SortedMap from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.NavigableMap from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.TreeMap from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.lang.ProcessEnvironment$CheckedEntrySet from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.lang.ProcessEnvironment$CheckedEntrySet$1 from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.lang.ProcessEnvironment$CheckedEntry from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.TreeMap$Entry from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.lang.CharacterData from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.lang.CharacterDataLatin1 from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.ArrayList$SubList from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.ListIterator from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.ArrayList$SubList$1 from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.io.FileDescriptor from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded sun.misc.JavaIOFileDescriptorAccess from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.io.FileDescriptor$1 from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded sun.misc.SharedSecrets from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded sun.nio.cs.StreamDecoder from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded sun.nio.MCPExtmodeHandler from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded sun.nio.MCPExtmodeHandler$1 from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded sun.nio.MCPExtmodeHandler$2 from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.io.Flushable from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.io.OutputStream from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.io.IOException from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded sun.nio.MCPExtmodeHandler$3 from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded sun.reflect.NativeMethodAccessorImpl from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded sun.reflect.DelegatingMethodAccessorImpl from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded sun.reflect.UnsafeFieldAccessorFactory from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded sun.reflect.UnsafeIntegerFieldAccessorImpl from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.nio.ByteBuffer from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.nio.HeapByteBuffer from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.nio.Bits from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.nio.ByteOrder from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded sun.misc.JavaNioAccess from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.nio.Bits$1 from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.nio.CharBuffer from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.nio.HeapCharBuffer from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.nio.charset.CoderResult from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.nio.charset.CoderResult$Cache from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.nio.charset.CoderResult$1 from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.nio.charset.CoderResult$2 from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.regex.Pattern from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.regex.Pattern$Node from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.regex.Pattern$4 from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.regex.Pattern$LastNode from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.regex.Pattern$GroupHead from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.regex.Pattern$CharProperty from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.regex.Pattern$BmpCharProperty from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.regex.Pattern$BitClass from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.regex.Pattern$SliceNode from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.regex.Pattern$Slice from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.regex.Pattern$Begin from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.regex.Pattern$First from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.regex.Pattern$Start from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.regex.Pattern$TreeInfo from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.regex.MatchResult from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.regex.Matcher from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.io.FileOutputStream from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.io.FilterInputStream from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.io.BufferedInputStream from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.concurrent.atomic.AtomicReferenceFieldUpdater from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.concurrent.atomic.AtomicReferenceFieldUpdater$AtomicReferenceFieldUpdaterImpl from / [Loaded sun.reflect.misc.ReflectUtil from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.io.FilterOutputStream from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.io.PrintStream from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.io.BufferedOutputStream from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.io.Writer from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.io.OutputStreamWriter from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded sun.nio.cs.StreamEncoder from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded sun.nio.cs.ArrayEncoder from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.nio.charset.CharsetEncoder from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded sun.nio.cs.UTF_8$Encoder from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.io.BufferedWriter from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.lang.ClassLoader$3 from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.Locale from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded sun.util.locale.LocaleObjectCache from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.Locale$Cache from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.concurrent.ConcurrentMap from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.concurrent.ConcurrentHashMap from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.concurrent.ConcurrentHashMap$HashEntry from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.concurrent.locks.Lock from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.concurrent.locks.ReentrantLock from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.concurrent.ConcurrentHashMap$Segment from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.concurrent.locks.AbstractOwnableSynchronizer from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.concurrent.locks.AbstractQueuedSynchronizer from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.concurrent.locks.ReentrantLock$Sync from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.concurrent.locks.ReentrantLock$NonfairSync from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.concurrent.locks.AbstractQueuedSynchronizer$Node from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded sun.util.locale.BaseLocale from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded sun.util.locale.BaseLocale$Cache from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded sun.util.locale.BaseLocale$Key from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded sun.util.locale.LocaleObjectCache$CacheEntry from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.Locale$LocaleKey from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded sun.util.locale.LocaleUtils from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.io.ExpiringCache$Entry from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.lang.ClassLoader$NativeLibrary from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.lang.StringCoding$StringEncoder from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.lang.Terminator from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded sun.misc.SignalHandler from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.lang.Terminator$1 from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded sun.misc.Signal from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded sun.misc.NativeSignalHandler from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded sun.misc.OSEnvironment from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded sun.io.Win32ErrorMode from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded com.unisys.xlateebcdic.XlateCharsetProvider from /-/JAVA_BOOT/jre/lib/mcp.jar] [Loaded com.unisys.xlateebcdic.XlateCharacterConverter from /-/JAVA_BOOT/jre/lib/xlateebcdic.jar] [Loaded com.unisys.xlateebcdic.XlateAseriesEbcdic from /-/JAVA_BOOT/jre/lib/xlateebcdic.jar] [Loaded com.unisys.xlateebcdic.XlateCCSInfo from /-/JAVA_BOOT/jre/lib/xlateebcdic.jar] [Loaded java.util.HashMap$KeySet from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.HashMap$KeyIterator from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded com.unisys.xlateebcdic.XlateCharacterConverter$1 from /-/JAVA_BOOT/jre/lib/xlateebcdic.jar] [Loaded java.util.Arrays$LegacyMergeSort from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded sun.security.action.GetBooleanAction from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.TimSort from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded sun.misc.Launcher from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.net.URLStreamHandlerFactory from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded sun.misc.Launcher$Factory from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.security.SecureClassLoader from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.net.URLClassLoader from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded sun.misc.Launcher$ExtClassLoader from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded sun.security.util.Debug from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.lang.ClassLoader$ParallelLoaders from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.WeakHashMap from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.WeakHashMap$Entry from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.Collections$SetFromMap from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.WeakHashMap$KeySet from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded sun.misc.JavaNetAccess from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.net.URLClassLoader$7 from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.StringTokenizer from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.security.PrivilegedExceptionAction from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded sun.misc.Launcher$ExtClassLoader$1 from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded sun.misc.MetaIndex from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.lang.reflect.Array from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded sun.net.www.ParseUtil from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.BitSet from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.net.URL from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.net.URL$1 from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.net.Parts from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.net.URLStreamHandler from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded sun.net.www.protocol.file.Handler from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded sun.misc.JavaSecurityAccess from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.security.ProtectionDomain$1 from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded sun.misc.JavaSecurityProtectionDomainAccess from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.security.ProtectionDomain$3 from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.security.CodeSource from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.security.ProtectionDomain$Key from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.security.Principal from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.HashSet from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded sun.misc.URLClassPath from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded sun.net.www.protocol.jar.Handler from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded sun.misc.Launcher$AppClassLoader from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded sun.misc.Launcher$AppClassLoader$1 from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.lang.SystemClassLoaderAction from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded sun.misc.Launcher$BootClassPathHolder from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded sun.misc.Launcher$BootClassPathHolder$1 from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded sun.net.util.URLUtil from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded sun.misc.URLClassPath$3 from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded sun.misc.URLClassPath$Loader from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded sun.misc.URLClassPath$JarLoader from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded sun.misc.URLClassPath$JarLoader$1 from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded sun.misc.FileURLMapper from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.zip.ZipConstants from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.zip.ZipFile from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.jar.JarFile from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded sun.misc.JavaUtilJarAccess from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.jar.JavaUtilJarAccessImpl from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.nio.charset.StandardCharsets from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded sun.nio.cs.US_ASCII from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded sun.nio.cs.ISO_8859_1 from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded sun.nio.cs.UTF_16BE from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded sun.nio.cs.UTF_16LE from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded sun.nio.cs.UTF_16 from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.Queue from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.Deque from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.ArrayDeque from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.zip.ZipCoder from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded sun.misc.PerfCounter from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded sun.misc.Perf$GetPerfAction from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded sun.misc.Perf from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded sun.misc.PerfCounter$CoreCounters from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded sun.nio.ch.DirectBuffer from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.nio.MappedByteBuffer from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.nio.DirectByteBuffer from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.nio.LongBuffer from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.nio.DirectLongBufferU from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded sun.misc.JarIndex from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded sun.misc.ExtensionDependency from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.zip.ZipEntry from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.jar.JarEntry from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.jar.JarFile$JarFileEntry from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.io.DataInput from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.io.DataInputStream from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.zip.ZipFile$ZipFileInputStream from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.zip.Inflater from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.zip.ZStreamRef from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.zip.InflaterInputStream from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.zip.ZipFile$ZipFileInflaterInputStream from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded sun.misc.Resource from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded sun.misc.URLClassPath$JarLoader$2 from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.Formatter from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.regex.Pattern$Single from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.regex.Pattern$GroupTail from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.regex.Pattern$Ctype from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.regex.Pattern$Curly from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.regex.Pattern$Ques from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.regex.Pattern$BranchConn from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.regex.Pattern$Branch from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.regex.Pattern$1 from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.regex.Pattern$5 from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.lang.Enum from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.Locale$Category from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.Locale$1 from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.text.DecimalFormatSymbols from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.spi.LocaleServiceProvider from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.text.spi.DecimalFormatSymbolsProvider from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded sun.util.LocaleServiceProviderPool from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded sun.util.locale.LocaleExtensions from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.lang.Character$CharacterCache from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded sun.util.locale.Extension from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded sun.util.locale.UnicodeLocaleExtension from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.Collections$SingletonMap from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.LinkedHashSet from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded sun.util.LocaleServiceProviderPool$1 from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.ServiceLoader from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.ServiceLoader$LazyIterator from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.ServiceLoader$1 from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.LinkedHashMap$LinkedHashIterator from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.LinkedHashMap$EntryIterator from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded sun.misc.URLClassPath$2 from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.lang.ClassLoader$2 from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded sun.misc.URLClassPath$1 from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.net.URLClassLoader$3 from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded sun.misc.CompoundEnumeration from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.io.FileNotFoundException from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.security.PrivilegedActionException from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.net.URLClassLoader$3$1 from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded sun.util.resources.LocaleData from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded sun.util.resources.LocaleData$1 from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.ResourceBundle$Control from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded sun.util.resources.LocaleData$LocaleDataResourceBundleControl from /-/JAVA_BOOT/jre/lib/rt.jar [Loaded java.util.Arrays$ArrayList from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.ResourceBundle$Control$CandidateListCache from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.ResourceBundle from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.ResourceBundle$1 from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.ResourceBundle$RBClassLoader from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.ResourceBundle$RBClassLoader$1 from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.ResourceBundle$CacheKey from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.ResourceBundle$CacheKeyReference from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.ResourceBundle$LoaderReference from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.ResourceBundle$SingleFormatControl from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.AbstractSequentialList from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.LinkedList from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.LinkedList$Node from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded sun.util.LocaleDataMetaInfo from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.ArrayList$Itr from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.ListResourceBundle from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded sun.text.resources.FormatData from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.ResourceBundle$BundleReference from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded sun.text.resources.FormatData_en from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.Currency from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.Currency$1 from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.regex.ASCII from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.Formatter$FormatString from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.Formatter$FixedString from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.Formatter$FormatSpecifier from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.Formatter$Flags from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.Formatter$Conversion from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.Formattable from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.lang.Integer$IntegerCache from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded com.unisys.xlateebcdic.XlateCharset from /-/JAVA_BOOT/jre/lib/mcp.jar] [Loaded java.net.URLConnection from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.net.JarURLConnection from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded sun.net.www.protocol.jar.JarURLConnection from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded sun.net.www.protocol.jar.URLJarFile$URLJarFileCloseController from /-/JAVA_BOOT/jre/lib/rt.jar [Loaded sun.net.www.protocol.jar.JarFileFactory from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded sun.net.www.URLConnection from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded sun.net.www.protocol.file.FileURLConnection from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded sun.net.www.MessageHeader from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded sun.net.www.protocol.jar.URLJarFile from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded sun.net.www.protocol.jar.URLJarFile$URLJarFileEntry from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded sun.net.www.protocol.jar.JarURLConnection$JarURLInputStream from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.io.FilePermission from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.io.FilePermission$1 from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded com.unisys.xlateebcdic.XlateBasicConverter from /-/JAVA_BOOT/jre/lib/xlateebcdic.jar] [Loaded java.net.URLClassLoader$2 from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded sun.misc.URLClassPath$FileLoader from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded com.unisys.xlateebcdic.XlateNonMixedConverter from /-/JAVA_BOOT/jre/lib/xlateebcdic.jar] [Loaded com.unisys.xlateebcdic.XlateBracketedConverter from /-/JAVA_BOOT/jre/lib/xlateebcdic.jar] [Loaded com.unisys.xlateebcdic.XlateLockShiftedConverter from /-/JAVA_BOOT/jre/lib/xlateebcdic.jar] [Loaded com.unisys.xlateebcdic.XlateNonBracketedConverter from /-/JAVA_BOOT/jre/lib/xlateebcdic.jar] [Loaded sun.nio.MCPExtmodeHandler$4 from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded sun.misc.JavaLangAccess from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.lang.System$2 from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.lang.IllegalArgumentException from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.lang.Compiler from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.lang.Compiler$1 from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded sun.launcher.LauncherHelper from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded sun.rmi.server.Activation from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.lang.Void from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded sun.security.action.GetIntegerAction from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.lang.SecurityManager from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.lang.SecurityManager$1 from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.security.Security from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.security.Security$1 from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded sun.misc.Hashing$Holder from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.Random from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.concurrent.atomic.AtomicLong from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.Hashtable$Holder from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.Properties$LineReader from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.concurrent.ConcurrentHashMap$Holder from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded sun.rmi.server.Activation$2 from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.nio.channels.spi.SelectorProvider from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.nio.channels.spi.SelectorProvider$1 from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.PropertyPermission from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.security.Policy from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.security.PermissionCollection from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.security.Policy$UnsupportedEmptyCollection from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.security.Permissions from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.HashMap$Holder from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.concurrent.atomic.AtomicReference from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.lang.ExceptionInInitializerError from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.lang.Throwable$PrintStreamOrWriter from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.lang.Throwable$WrappedPrintStream from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.IdentityHashMap from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.util.IdentityHashMap$KeySet from /-/JAVA_BOOT/jre/lib/rt.jar] Exception in thread "main" java.lang.ExceptionInInitializerError at java.util.HashMap.(HashMap.java:284) at java.util.HashMap.(HashMap.java:297) at java.security.Permissions.(Permissions.java:103) at java.security.Policy$UnsupportedEmptyCollection.(Policy.java:823) at java.security.Policy.(Policy.java:104) at java.security.AccessControlContext.getDebug(AccessControlContext.java:98) at java.security.AccessController.checkPermission(AccessController.java:537) at java.lang.SecurityManager.checkPermission(SecurityManager.java:549) at java.lang.SecurityManager.checkPropertyAccess(SecurityManager.java:1302) at java.lang.System.getProperty(System.java:706) at java.nio.channels.spi.SelectorProvider.loadProviderFromProperty(SelectorProvider.java:88) at java.nio.channels.spi.SelectorProvider.access$000(SelectorProvider.java:69) at java.nio.channels.spi.SelectorProvider$1.run(SelectorProvider.java:171) at java.nio.channels.spi.SelectorProvider$1.run(SelectorProvider.java:169) at java.security.AccessController.doPrivileged(Native Method) at java.nio.channels.spi.SelectorProvider.provider(SelectorProvider.java:168) at java.lang.System.inheritedChannel(System.java:242) at sun.rmi.server.Activation$2.run(Activation.java:1927) at sun.rmi.server.Activation$2.run(Activation.java:1925) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.server.Activation.main(Activation.java:1924) [Loaded java.util.Objects from /-/JAVA_BOOT/jre/lib/rt.jar] Caused by: java.lang.NullPointerException at java.security.Policy.isSet(Policy.java:132) at java.security.AccessControlContext.getDebug(AccessControlContext.java:98) at java.security.AccessController.checkPermission(AccessController.java:537) at java.lang.SecurityManager.checkPermission(SecurityManager.java:549) at java.lang.SecurityManager.checkPropertyAccess(SecurityManager.java:1302) at java.lang.System.getProperty(System.java:706) at sun.security.action.GetPropertyAction.run(GetPropertyAction.java:84) at sun.security.action.GetPropertyAction.run(GetPropertyAction.java:49) at java.security.AccessController.doPrivileged(Native Method) at java.util.HashMap$Holder.(HashMap.java:212) ... 21 more [Loaded java.lang.Shutdown from /-/JAVA_BOOT/jre/lib/rt.jar] [Loaded java.lang.Shutdown$Lock from /-/JAVA_BOOT/jre/lib/rt.jar] Tom Salter Unisys Corporation From sean.mullan at oracle.com Mon Nov 5 17:12:35 2012 From: sean.mullan at oracle.com (sean.mullan at oracle.com) Date: Mon, 05 Nov 2012 17:12:35 +0000 Subject: hg: jdk8/tl/jdk: 3 new changesets Message-ID: <20121105171320.D7A8647791@hg.openjdk.java.net> Changeset: 46b24eb85b86 Author: mullan Date: 2012-11-05 10:30 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/46b24eb85b86 7171570: JEP 124 Potential API Changes Reviewed-by: vinnie, xuelei ! src/share/classes/java/security/cert/CertPathBuilder.java ! src/share/classes/java/security/cert/CertPathValidator.java ! src/share/classes/java/security/cert/PKIXRevocationChecker.java ! src/share/classes/sun/security/provider/certpath/RevocationChecker.java ! test/java/security/cert/PKIXRevocationChecker/UnitTest.java Changeset: 4770b0a49675 Author: mullan Date: 2012-11-05 10:33 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4770b0a49675 Merge - make/sun/jdbc/Makefile - src/share/classes/sun/net/www/protocol/gopher/GopherClient.java - src/share/classes/sun/net/www/protocol/gopher/Handler.java - src/solaris/native/java/io/FileSystem_md.c - src/windows/native/java/io/FileSystem_md.c Changeset: 510cb3671f14 Author: mullan Date: 2012-11-05 12:08 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/510cb3671f14 Merge From mike.duigou at oracle.com Mon Nov 5 18:45:48 2012 From: mike.duigou at oracle.com (Mike Duigou) Date: Mon, 5 Nov 2012 10:45:48 -0800 Subject: HashMap / doPrivileged problem In-Reply-To: <63D5DCACD1E9E34C89C8203C64F521C3013642092DCB@USEA-EXCH7.na.uis.unisys.com> References: <63D5DCACD1E9E34C89C8203C64F521C3013642092DCB@USEA-EXCH7.na.uis.unisys.com> Message-ID: <14DC6BA9-5014-49B8-BFDF-DA2BB0D763C7@oracle.com> Hello Thomas; I am sorry to hear that you ran in to this problem. The class initialization order was something we found to be surprisingly brittle and tricky with this particular change. You've run across a path we didn't anticipate. I have created a bug for this issue : JDK-8002283 (It should be visible on bugs.sun.com soon). On Nov 5 2012, at 07:02 , Salter, Thomas A wrote: > I have encountered a problem with initializing the new HashMap code introduced in Java 7u6. I'm running with 7u9. The problem only shows up running rmid (sun.rmi.server.Activation). It seems that the AccessController needs to call HashMap but the new code in HashMap calls AccessController when reading the property, jdk.map.althashing.threshold. > > At the end of this message is the stack trace and the output of -verbose:class showing the failure. > > Here's a synopsis of what I think is happening: > 1. AccessControllerContext at 98 caused Policy.isset. > 2. Before calling isSet, the class loader initialize Policy by calling > 3. Clinit found its way into HashMap init. > 4. HashMap init called HashMap$Holder. > 5. Which called AccessController > 6. Which eventually called isSet. Policy was already loaded and its clinit called, so isSet actually got called. > 7. But Policy. had not completed so policy is null, hence NPE. > 8. The class loader from #2 caught the exception and wrapped it in the ExceptionInitializationError. > > I'm running a modified JDK, with modifications primarily in the area of file and socket IO. I'm pretty sure we've modified none of the classes in the stack trace below. The best I can tell, our changes eliminated the loading of WinNTFileSystem and changed the CharSet classes that are called. Apparently that code contains an incidental call to HashMap that gets it initialized before doPrivileged gets called from some other class. > > I've found an inelegant workaround. In java.lang.System I added a "new HashMap()" immediately following the call to set VM.booted to true. I will see if there's an alternative way to accomplish this. There are several other classes that would need the same treatment for full safety and it seems unreasonable to just create throw-away instances to make sure they are initialized. > This causes the HashMap$Holder class to be initialized before doPrivileged can call it. The key to the fix is that HashMap needs to be called after isBooted has been set so that it will invoke its Holder class. Since the Holder class invokes doPrivileged, the HashMap needs to have been initialized before anyone calls doPrivileged. Understood. Thanks, Mike From Thomas.Salter at unisys.com Mon Nov 5 20:09:42 2012 From: Thomas.Salter at unisys.com (Salter, Thomas A) Date: Mon, 5 Nov 2012 14:09:42 -0600 Subject: HashMap / doPrivileged problem In-Reply-To: <14DC6BA9-5014-49B8-BFDF-DA2BB0D763C7@oracle.com> References: <63D5DCACD1E9E34C89C8203C64F521C3013642092DCB@USEA-EXCH7.na.uis.unisys.com> <14DC6BA9-5014-49B8-BFDF-DA2BB0D763C7@oracle.com> Message-ID: <63D5DCACD1E9E34C89C8203C64F521C30136420933AD@USEA-EXCH7.na.uis.unisys.com> Mike, Thanks for responding so promptly. I certainly did not expect my fix to be the best one; I was just happy to find something that worked. I couldn't think of a solution that didn't involve doPrivileged and HashMap knowing a lot about each other, like adding a HashMap option just for doPrivileged that skips the call from HashMap to doPrivileged. Tom -----Original Message----- From: Mike Duigou [mailto:mike.duigou at oracle.com] Sent: Monday, November 05, 2012 1:46 PM To: Salter, Thomas A Cc: core-libs-dev at openjdk.java.net Subject: Re: HashMap / doPrivileged problem Hello Thomas; I am sorry to hear that you ran in to this problem. The class initialization order was something we found to be surprisingly brittle and tricky with this particular change. You've run across a path we didn't anticipate. I have created a bug for this issue : JDK-8002283 (It should be visible on bugs.sun.com soon). On Nov 5 2012, at 07:02 , Salter, Thomas A wrote: > I have encountered a problem with initializing the new HashMap code introduced in Java 7u6. I'm running with 7u9. The problem only shows up running rmid (sun.rmi.server.Activation). It seems that the AccessController needs to call HashMap but the new code in HashMap calls AccessController when reading the property, jdk.map.althashing.threshold. > > At the end of this message is the stack trace and the output of -verbose:class showing the failure. > > Here's a synopsis of what I think is happening: > 1. AccessControllerContext at 98 caused Policy.isset. > 2. Before calling isSet, the class loader initialize Policy by calling > 3. Clinit found its way into HashMap init. > 4. HashMap init called HashMap$Holder. > 5. Which called AccessController > 6. Which eventually called isSet. Policy was already loaded and its clinit called, so isSet actually got called. > 7. But Policy. had not completed so policy is null, hence NPE. > 8. The class loader from #2 caught the exception and wrapped it in the ExceptionInitializationError. > > I'm running a modified JDK, with modifications primarily in the area of file and socket IO. I'm pretty sure we've modified none of the classes in the stack trace below. The best I can tell, our changes eliminated the loading of WinNTFileSystem and changed the CharSet classes that are called. Apparently that code contains an incidental call to HashMap that gets it initialized before doPrivileged gets called from some other class. > > I've found an inelegant workaround. In java.lang.System I added a "new HashMap()" immediately following the call to set VM.booted to true. I will see if there's an alternative way to accomplish this. There are several other classes that would need the same treatment for full safety and it seems unreasonable to just create throw-away instances to make sure they are initialized. > This causes the HashMap$Holder class to be initialized before doPrivileged can call it. The key to the fix is that HashMap needs to be called after isBooted has been set so that it will invoke its Holder class. Since the Holder class invokes doPrivileged, the HashMap needs to have been initialized before anyone calls doPrivileged. Understood. Thanks, Mike From vincent.x.ryan at oracle.com Mon Nov 5 20:21:03 2012 From: vincent.x.ryan at oracle.com (vincent.x.ryan at oracle.com) Date: Mon, 05 Nov 2012 20:21:03 +0000 Subject: hg: jdk8/tl/jdk: 6383200: PBE: need new algorithm support in password based encryption Message-ID: <20121105202138.A29FD47798@hg.openjdk.java.net> Changeset: 519f4c9ebf8d Author: vinnie Date: 2012-11-05 20:18 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/519f4c9ebf8d 6383200: PBE: need new algorithm support in password based encryption Reviewed-by: valeriep ! src/share/classes/com/sun/crypto/provider/PBEKeyFactory.java ! src/share/classes/com/sun/crypto/provider/PBEParameters.java + src/share/classes/com/sun/crypto/provider/PBES1Core.java + src/share/classes/com/sun/crypto/provider/PBES2Core.java + src/share/classes/com/sun/crypto/provider/PBES2Parameters.java ! src/share/classes/com/sun/crypto/provider/PBEWithMD5AndDESCipher.java ! src/share/classes/com/sun/crypto/provider/PBEWithMD5AndTripleDESCipher.java + src/share/classes/com/sun/crypto/provider/PBKDF2Core.java + src/share/classes/com/sun/crypto/provider/PBMAC1Core.java ! src/share/classes/com/sun/crypto/provider/PKCS12PBECipherCore.java ! src/share/classes/com/sun/crypto/provider/SunJCE.java ! src/share/classes/javax/crypto/spec/PBEParameterSpec.java ! test/com/sun/crypto/provider/Cipher/PBE/PBEInvalidParamsTest.java ! test/com/sun/crypto/provider/Cipher/PBE/PBEKeysAlgorithmNames.java ! test/com/sun/crypto/provider/Cipher/PBE/PBEParametersTest.java + test/com/sun/crypto/provider/Cipher/PBE/PBES2Test.java ! test/com/sun/crypto/provider/Cipher/PBE/PKCS12Cipher.java ! test/com/sun/crypto/provider/Cipher/PBE/PKCS12Oid.java ! test/com/sun/crypto/provider/Mac/HmacPBESHA1.java ! test/com/sun/crypto/provider/Mac/HmacSaltLengths.java From kumar.x.srinivasan at oracle.com Tue Nov 6 00:44:42 2012 From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com) Date: Tue, 06 Nov 2012 00:44:42 +0000 Subject: hg: jdk8/tl/langtools: 8001112: Make -target 8 in javac generate version 52.0 classfile Message-ID: <20121106004448.4481B477A3@hg.openjdk.java.net> Changeset: 9bce0c73583d Author: ksrini Date: 2012-10-31 10:21 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/9bce0c73583d 8001112: Make -target 8 in javac generate version 52.0 classfile Reviewed-by: darcy, jjg ! src/share/classes/com/sun/tools/javac/jvm/Target.java ! test/tools/javac/classfiles/ClassVersionChecker.java ! test/tools/javac/versions/check.sh From kumar.x.srinivasan at oracle.com Tue Nov 6 00:51:25 2012 From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com) Date: Tue, 06 Nov 2012 00:51:25 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20121106005202.674E2477A4@hg.openjdk.java.net> Changeset: 798292c71419 Author: ksrini Date: 2012-11-05 14:53 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/798292c71419 8001191: use -source 8 -target 8 when compiling the JDK Reviewed-by: chegar, dholmes, erikj, jgish ! make/common/shared/Defs-control.gmk ! make/common/shared/Defs-java.gmk ! make/java/invoke/Makefile ! makefiles/Setup.gmk ! src/share/classes/sun/tools/java/RuntimeConstants.java ! src/share/native/java/lang/System.c ! test/ProblemList.txt Changeset: 8222e6eac651 Author: ksrini Date: 2012-11-05 15:00 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8222e6eac651 7050936: (pack200) Support version 52.0 class files in langtools Reviewed-by: dholmes ! src/share/classes/com/sun/java/util/jar/pack/Constants.java ! src/share/native/com/sun/java/util/jar/pack/constants.h From david.holmes at oracle.com Tue Nov 6 01:29:44 2012 From: david.holmes at oracle.com (David Holmes) Date: Tue, 06 Nov 2012 11:29:44 +1000 Subject: bottleneck by java.lang.Class.getAnnotations() - proposed patch In-Reply-To: References: <924D06EC-F603-4E6A-A7FE-7A05C77B1217@gmail.com> <23313EDE-3AB7-4E53-8EB1-A6F6CC9383B9@gmail.com> <5093A8D3.4030800@gmail.com> <5096CFBD.2010604@gmail.com> <5096F5B0.8070304@gmail.com> <50974D3D.1040502@oracle.com> Message-ID: <50986808.9060708@oracle.com> Hi Alex, On 5/11/2012 11:36 PM, Alexander Kn?ller wrote: > Hi David. > > What about my proposal for a simple double-checked-locking for the redefinitions fields and the use of local variables for "annotations" in > getAnnotations() and initAnnotationsIfNecessary() ? Sorry I thought Peter's proposed patch was an implementation of your suggestion. Can you provide the code for your suggestion as it is a bit hard to evaluate exactly what you mean from a textual description. > Are additional local Variables similar "bad habit" for memory usage (although they only affect the stack)? Locals (potentially) affect dynamic footprint whereas fields affect static footprint - it was static footprint that was of concern here. Though of course we can't just trade static footprint for dynamic footprint. David > Alex > > Am 05.11.2012 um 06:23 schrieb David Holmes: > >> Hi Peter, >> >> Moving the annotations fields into a helper object would tie in with the Class-instance size reduction effort that was investigated as part of "JEP 149: Reduce Core-Library Memory Usage": >> >> http://openjdk.java.net/jeps/149 >> >> The investigations there to date only looked at relocating the reflection related fields, though the JEP mentions the annotations as well. >> >> Any such effort requires extensive benchmarking and performance analysis before being accepted though. >> >> David >> ----- >> >> On 5/11/2012 9:09 AM, Peter Levart wrote: >>> Hi, >>> >>> I propose the following patch to java.lang.Class in order to overcome >>> the synchronization bottleneck when accessing annotations from multiple >>> threads. The patch packs the 'annotations' and 'declaredAnnotations' >>> Maps together with an int redefinedCount into a structure: >>> >>> static class Annotations { >>> final Map, Annotation> annotations; >>> final Map, Annotation> declaredAnnotations; >>> final int redefinedCount; >>> >>> which is referenced by a single volatile Class.annotations field. >>> Instead of initAnnotationsIfNecessary() there's a >>> getAnnotationsPrivate() method that uses simple double-checked locking >>> to lazily initialize and return this structure. The slow-path part is >>> still synchronized to ensure that >>> Class.setAnnotationType/getAnnotationType call backs from AnnotationType >>> are only done while holding a lock. >>> >>> Regards, Peter >>> >>> Here's the patch to jdk8 source: >>> >>> diff -r 7ac292e57b5a src/share/classes/java/lang/Class.java >>> --- a/src/share/classes/java/lang/Class.java Thu Nov 01 14:12:21 2012 -0700 >>> +++ b/src/share/classes/java/lang/Class.java Sun Nov 04 23:53:04 2012 +0100 >>> @@ -2237,10 +2237,8 @@ >>> declaredFields = publicFields = declaredPublicFields = null; >>> declaredMethods = publicMethods = declaredPublicMethods = null; >>> declaredConstructors = publicConstructors = null; >>> - annotations = declaredAnnotations = null; >>> >>> - // Use of "volatile" (and synchronization by caller in the case >>> - // of annotations) ensures that no thread sees the update to >>> + // Use of "volatile" ensures that no thread sees the update to >>> // lastRedefinedCount before seeing the caches cleared. >>> // We do not guard against brief windows during which multiple >>> // threads might redundantly work to fill an empty cache. >>> @@ -3049,8 +3047,7 @@ >>> if (annotationClass == null) >>> throw new NullPointerException(); >>> >>> - initAnnotationsIfNecessary(); >>> - return (A) annotations.get(annotationClass); >>> + return (A) getAnnotationsPrivate().annotations.get(annotationClass); >>> } >>> >>> /** >>> @@ -3070,40 +3067,52 @@ >>> * @since 1.5 >>> */ >>> public Annotation[] getAnnotations() { >>> - initAnnotationsIfNecessary(); >>> - return AnnotationParser.toArray(annotations); >>> + return AnnotationParser.toArray(getAnnotationsPrivate().annotations); >>> } >>> >>> /** >>> * @since 1.5 >>> */ >>> public Annotation[] getDeclaredAnnotations() { >>> - initAnnotationsIfNecessary(); >>> - return AnnotationParser.toArray(declaredAnnotations); >>> + return >>> AnnotationParser.toArray(getAnnotationsPrivate().declaredAnnotations); >>> } >>> >>> // Annotations cache >>> - private transient Map, Annotation> >>> annotations; >>> - private transient Map, Annotation> >>> declaredAnnotations; >>> + private transient volatile Annotations annotations; >>> >>> - private synchronized void initAnnotationsIfNecessary() { >>> - clearCachesOnClassRedefinition(); >>> - if (annotations != null) >>> - return; >>> - declaredAnnotations = AnnotationParser.parseAnnotations( >>> - getRawAnnotations(), getConstantPool(), this); >>> - Class superClass = getSuperclass(); >>> - if (superClass == null) { >>> - annotations = declaredAnnotations; >>> - } else { >>> - annotations = new HashMap<>(); >>> - superClass.initAnnotationsIfNecessary(); >>> - for (Map.Entry, Annotation> e : >>> superClass.annotations.entrySet()) { >>> - Class annotationClass = e.getKey(); >>> - if (AnnotationType.getInstance(annotationClass).isInherited()) >>> - annotations.put(annotationClass, e.getValue()); >>> + private Annotations getAnnotationsPrivate() { >>> + // double checked locking >>> + int redefinedCount = classRedefinedCount; >>> + Annotations anns = annotations; >>> + if (anns != null&& anns.redefinedCount == redefinedCount) { >>> + return anns; >>> + } >>> + >>> + synchronized (this) { >>> + redefinedCount = classRedefinedCount; >>> + anns = annotations; >>> + if (anns != null&& anns.redefinedCount == redefinedCount) { >>> + return anns; >>> } >>> - annotations.putAll(declaredAnnotations); >>> + >>> + Map, Annotation> declAnnMap = >>> AnnotationParser.parseAnnotations( >>> + getRawAnnotations(), getConstantPool(), this); >>> + Map, Annotation> annMap; >>> + Class superClass = getSuperclass(); >>> + if (superClass == null) { >>> + annMap = declAnnMap; >>> + } else { >>> + annMap = new HashMap<>(); >>> + for (Map.Entry, Annotation> e : >>> superClass.getAnnotationsPrivate().annotations.entrySet()) { >>> + Class annotationClass = e.getKey(); >>> + if (AnnotationType.getInstance(annotationClass).isInherited()) >>> + annMap.put(annotationClass, e.getValue()); >>> + } >>> + annMap.putAll(declAnnMap); >>> + } >>> + >>> + annotations = anns = new Annotations(annMap, declAnnMap, redefinedCount); >>> + return anns; >>> } >>> } >>> >>> @@ -3119,6 +3128,18 @@ >>> return annotationType; >>> } >>> >>> + static final class Annotations { >>> + final Map, Annotation> annotations; >>> + final Map, Annotation> declaredAnnotations; >>> + final int redefinedCount; >>> + >>> + Annotations(Map, Annotation> annotations, >>> Map, Annotation> declaredAnnotations, int >>> redefinedCount) { >>> + this.annotations = annotations; >>> + this.declaredAnnotations = declaredAnnotations; >>> + this.redefinedCount = redefinedCount; >>> + } >>> + } >>> + >>> /* Backing store of user-defined values pertaining to this class. >>> * Maintained by the ClassValue class. >>> */ >>> > From david.holmes at oracle.com Tue Nov 6 04:44:30 2012 From: david.holmes at oracle.com (david.holmes at oracle.com) Date: Tue, 06 Nov 2012 04:44:30 +0000 Subject: hg: jdk8/tl/jdk: 7197210: java/lang/invoke/CallSiteTest.java failing on armsflt. Message-ID: <20121106044450.27F26477A8@hg.openjdk.java.net> Changeset: cb65e3315b27 Author: jiangli Date: 2012-11-05 12:51 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cb65e3315b27 7197210: java/lang/invoke/CallSiteTest.java failing on armsflt. Summary: Reduce work load and set longer timeout for java/lang/invoke tests. Reviewed-by: kvn, twisti ! test/java/lang/invoke/BigArityTest.java ! test/java/lang/invoke/CallSiteTest.java ! test/java/lang/invoke/MethodHandlesTest.java ! test/java/lang/invoke/RicochetTest.java From peter.levart at gmail.com Tue Nov 6 07:37:21 2012 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 6 Nov 2012 08:37:21 +0100 Subject: bottleneck by java.lang.Class.getAnnotations() - proposed patch In-Reply-To: <50986808.9060708@oracle.com> References: <924D06EC-F603-4E6A-A7FE-7A05C77B1217@gmail.com> <23313EDE-3AB7-4E53-8EB1-A6F6CC9383B9@gmail.com> <5093A8D3.4030800@gmail.com> <5096CFBD.2010604@gmail.com> <5096F5B0.8070304@gmail.com> <50974D3D.1040502@oracle.com> <50986808.9060708@oracle.com> Message-ID: Hi all, I have prepared a better patch. It addresses the goals of JEP-149 more seriously. I also have some benchmarks. Stay tuned... Regards, Peter On Nov 6, 2012 2:29 AM, "David Holmes" wrote: > Hi Alex, > > On 5/11/2012 11:36 PM, Alexander Kn?ller wrote: > >> Hi David. >> >> What about my proposal for a simple double-checked-locking for the >> redefinitions fields and the use of local variables for "annotations" in >> getAnnotations() and initAnnotationsIfNecessary() ? >> > > Sorry I thought Peter's proposed patch was an implementation of your > suggestion. Can you provide the code for your suggestion as it is a bit > hard to evaluate exactly what you mean from a textual description. > > Are additional local Variables similar "bad habit" for memory usage >> (although they only affect the stack)? >> > > Locals (potentially) affect dynamic footprint whereas fields affect static > footprint - it was static footprint that was of concern here. Though of > course we can't just trade static footprint for dynamic footprint. > > David > > Alex >> >> Am 05.11.2012 um 06:23 schrieb David Holmes: >> >> Hi Peter, >>> >>> Moving the annotations fields into a helper object would tie in with the >>> Class-instance size reduction effort that was investigated as part of "JEP >>> 149: Reduce Core-Library Memory Usage": >>> >>> http://openjdk.java.net/jeps/**149 >>> >>> The investigations there to date only looked at relocating the >>> reflection related fields, though the JEP mentions the annotations as well. >>> >>> Any such effort requires extensive benchmarking and performance analysis >>> before being accepted though. >>> >>> David >>> ----- >>> >>> On 5/11/2012 9:09 AM, Peter Levart wrote: >>> >>>> Hi, >>>> >>>> I propose the following patch to java.lang.Class in order to overcome >>>> the synchronization bottleneck when accessing annotations from multiple >>>> threads. The patch packs the 'annotations' and 'declaredAnnotations' >>>> Maps together with an int redefinedCount into a structure: >>>> >>>> static class Annotations { >>>> final Map, Annotation> annotations; >>>> final Map, Annotation> declaredAnnotations; >>>> final int redefinedCount; >>>> >>>> which is referenced by a single volatile Class.annotations field. >>>> Instead of initAnnotationsIfNecessary() there's a >>>> getAnnotationsPrivate() method that uses simple double-checked locking >>>> to lazily initialize and return this structure. The slow-path part is >>>> still synchronized to ensure that >>>> Class.setAnnotationType/**getAnnotationType call backs from >>>> AnnotationType >>>> are only done while holding a lock. >>>> >>>> Regards, Peter >>>> >>>> Here's the patch to jdk8 source: >>>> >>>> diff -r 7ac292e57b5a src/share/classes/java/lang/**Class.java >>>> --- a/src/share/classes/java/lang/**Class.java Thu Nov 01 14:12:21 >>>> 2012 -0700 >>>> +++ b/src/share/classes/java/lang/**Class.java Sun Nov 04 23:53:04 >>>> 2012 +0100 >>>> @@ -2237,10 +2237,8 @@ >>>> declaredFields = publicFields = declaredPublicFields = null; >>>> declaredMethods = publicMethods = declaredPublicMethods = null; >>>> declaredConstructors = publicConstructors = null; >>>> - annotations = declaredAnnotations = null; >>>> >>>> - // Use of "volatile" (and synchronization by caller in the case >>>> - // of annotations) ensures that no thread sees the update to >>>> + // Use of "volatile" ensures that no thread sees the update to >>>> // lastRedefinedCount before seeing the caches cleared. >>>> // We do not guard against brief windows during which multiple >>>> // threads might redundantly work to fill an empty cache. >>>> @@ -3049,8 +3047,7 @@ >>>> if (annotationClass == null) >>>> throw new NullPointerException(); >>>> >>>> - initAnnotationsIfNecessary(); >>>> - return (A) annotations.get(**annotationClass); >>>> + return (A) getAnnotationsPrivate().**annotations.get(** >>>> annotationClass); >>>> } >>>> >>>> /** >>>> @@ -3070,40 +3067,52 @@ >>>> * @since 1.5 >>>> */ >>>> public Annotation[] getAnnotations() { >>>> - initAnnotationsIfNecessary(); >>>> - return AnnotationParser.toArray(**annotations); >>>> + return AnnotationParser.toArray(**getAnnotationsPrivate().** >>>> annotations); >>>> } >>>> >>>> /** >>>> * @since 1.5 >>>> */ >>>> public Annotation[] getDeclaredAnnotations() { >>>> - initAnnotationsIfNecessary(); >>>> - return AnnotationParser.toArray(**declaredAnnotations); >>>> + return >>>> AnnotationParser.toArray(**getAnnotationsPrivate().** >>>> declaredAnnotations); >>>> } >>>> >>>> // Annotations cache >>>> - private transient Map, Annotation> >>>> annotations; >>>> - private transient Map, Annotation> >>>> declaredAnnotations; >>>> + private transient volatile Annotations annotations; >>>> >>>> - private synchronized void initAnnotationsIfNecessary() { >>>> - clearCachesOnClassRedefinition**(); >>>> - if (annotations != null) >>>> - return; >>>> - declaredAnnotations = AnnotationParser.**parseAnnotations( >>>> - getRawAnnotations(), getConstantPool(), this); >>>> - Class superClass = getSuperclass(); >>>> - if (superClass == null) { >>>> - annotations = declaredAnnotations; >>>> - } else { >>>> - annotations = new HashMap<>(); >>>> - superClass.**initAnnotationsIfNecessary(); >>>> - for (Map.Entry, Annotation> e : >>>> superClass.annotations.**entrySet()) { >>>> - Class annotationClass = e.getKey(); >>>> - if (AnnotationType.getInstance(**annotationClass).isInherited()**) >>>> - annotations.put(**annotationClass, e.getValue()); >>>> + private Annotations getAnnotationsPrivate() { >>>> + // double checked locking >>>> + int redefinedCount = classRedefinedCount; >>>> + Annotations anns = annotations; >>>> + if (anns != null&& anns.redefinedCount == redefinedCount) { >>>> + return anns; >>>> + } >>>> + >>>> + synchronized (this) { >>>> + redefinedCount = classRedefinedCount; >>>> + anns = annotations; >>>> + if (anns != null&& anns.redefinedCount == redefinedCount) { >>>> + return anns; >>>> } >>>> - annotations.putAll(**declaredAnnotations); >>>> + >>>> + Map, Annotation> declAnnMap = >>>> AnnotationParser.**parseAnnotations( >>>> + getRawAnnotations(), getConstantPool(), this); >>>> + Map, Annotation> annMap; >>>> + Class superClass = getSuperclass(); >>>> + if (superClass == null) { >>>> + annMap = declAnnMap; >>>> + } else { >>>> + annMap = new HashMap<>(); >>>> + for (Map.Entry, Annotation> e : >>>> superClass.**getAnnotationsPrivate().**annotations.entrySet()) { >>>> + Class annotationClass = e.getKey(); >>>> + if (AnnotationType.getInstance(**annotationClass).isInherited()**) >>>> + annMap.put(annotationClass, e.getValue()); >>>> + } >>>> + annMap.putAll(declAnnMap); >>>> + } >>>> + >>>> + annotations = anns = new Annotations(annMap, declAnnMap, >>>> redefinedCount); >>>> + return anns; >>>> } >>>> } >>>> >>>> @@ -3119,6 +3128,18 @@ >>>> return annotationType; >>>> } >>>> >>>> + static final class Annotations { >>>> + final Map, Annotation> annotations; >>>> + final Map, Annotation> >>>> declaredAnnotations; >>>> + final int redefinedCount; >>>> + >>>> + Annotations(Map, Annotation> annotations, >>>> Map, Annotation> declaredAnnotations, int >>>> redefinedCount) { >>>> + this.annotations = annotations; >>>> + this.declaredAnnotations = declaredAnnotations; >>>> + this.redefinedCount = redefinedCount; >>>> + } >>>> + } >>>> + >>>> /* Backing store of user-defined values pertaining to this class. >>>> * Maintained by the ClassValue class. >>>> */ >>>> >>>> >> From Alan.Bateman at oracle.com Tue Nov 6 12:23:15 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 06 Nov 2012 12:23:15 +0000 Subject: Preliminary review: Adding tracing of I/O calls In-Reply-To: References: <22767084-EAC2-4D87-800B-3E5E5BFC666A@oracle.com> <50942931.4000001@oracle.com> <08183803-2563-461C-9514-B7FAE1E14C10@oracle.com> <509437F0.4020409@oracle.com> <50965EB9.90509@oracle.com> Message-ID: <50990133.3050000@oracle.com> Staffan, Has dynamic instrumentation being considered for this project? I realize it would require knowledge of the sites to instrument and I realize that ignoring non-blocking I/O complicates it a bit too, I'm just wondering if you've done any experiments to see if this would be an alternative to the static instrumentation proposed. -Alan From peter.levart at gmail.com Tue Nov 6 13:12:24 2012 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 06 Nov 2012 14:12:24 +0100 Subject: bottleneck by java.lang.Class.getAnnotations() - a better patch In-Reply-To: <50974D3D.1040502@oracle.com> References: <924D06EC-F603-4E6A-A7FE-7A05C77B1217@gmail.com> <23313EDE-3AB7-4E53-8EB1-A6F6CC9383B9@gmail.com> <5093A8D3.4030800@gmail.com> <5096CFBD.2010604@gmail.com> <5096F5B0.8070304@gmail.com> <50974D3D.1040502@oracle.com> Message-ID: <50990CB8.2040400@gmail.com> On 11/05/2012 06:23 AM, David Holmes wrote: > Hi Peter, > > Moving the annotations fields into a helper object would tie in with > the Class-instance size reduction effort that was investigated as part > of "JEP 149: Reduce Core-Library Memory Usage": > > http://openjdk.java.net/jeps/149 > > The investigations there to date only looked at relocating the > reflection related fields, though the JEP mentions the annotations as > well. > > Any such effort requires extensive benchmarking and performance > analysis before being accepted though. > > David > ----- > On 11/05/2012 10:25 AM, Alan Bateman wrote: > Here's a good starting place on the interaction of runtime visible > attributes and RedefineClasses/RetransformClasses: > > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5002251 > > -Alan. Hi all, Presented here is a patch mainly against java.lang.Class and also against java.lang.reflect.[Field,Method,Constructor,Executable] classes. Currently java.lang.Class uses the following fields to maintain caches of reflection data that are invalidated as a result of class or superclass redefinition/re-transformation: private volatile transient SoftReference declaredFields; private volatile transient SoftReference publicFields; private volatile transient SoftReference declaredMethods; private volatile transient SoftReference publicMethods; private volatile transient SoftReference[]> declaredConstructors; private volatile transient SoftReference[]> publicConstructors; private volatile transient SoftReference declaredPublicFields; private volatile transient SoftReference declaredPublicMethods; // Value of classRedefinedCount when we last cleared the cached values // that are sensitive to class redefinition. private volatile transient int lastRedefinedCount = 0; // Annotations cache private transient Map, Annotation> annotations; private transient Map, Annotation> declaredAnnotations; If I understand Alan's references correctly, current VM can redefine the class in a way that changes method bodies. Also new methods can be added. And the set of annotations can also be altered. And future improvements could allow even more. Because annotations are cached on Field/Method/Constructor instances, all the above fields must be invalidated when the class or superclass is redefined. It can also be observed that Field/Method/Constructor caches are maintained using SoftReferences but annotations are hard references. I don't know if this is intentional. I believe that annotations could also be SoftReferenced, so that in the event of memory pressure they get cleared. Many applications retrieve annotations only in the early stages of their life-cycle and then either cache them themselves or forget about them. So I designed the patch to equalize this. If this is undesirable, the patch could be modified to make a distinction again. The patch replaces the above-mentioned java.lang.Class fields with a single field: private volatile transient SoftReference> volatileData; ...which is a SoftReference to the following structure: // volatile data that might get invalid when JVM TI RedefineClasses() is called static class VolatileData { volatile Field[] declaredFields; volatile Field[] publicFields; volatile Method[] declaredMethods; volatile Method[] publicMethods; volatile Constructor[] declaredConstructors; volatile Constructor[] publicConstructors; // Intermediate results for getFields and getMethods volatile Field[] declaredPublicFields; volatile Method[] declaredPublicMethods; // Annotations volatile Map, Annotation> annotations; volatile Map, Annotation> declaredAnnotations; // Value of classRedefinedCount when we created this VolatileData instance final int redefinedCount; So let's look at static overhead differences using 64 bit addressing (useful load - arrays, Maps not counted since the patched code uses the same amount of same types of each). * Fresh java.lang.Class instance: current JDK8 code: 10 OOPs + 1 int = 10*8+4 = 84 bytes in 1 instance vs. patched code : 1 OOP = 8 bytes in 1 instance * Fully loaded java.lang.Class (Fields, Methods, Constructors, annotations): current JDK8 code: 10 OOPs + 1 int = 84 bytes 8 SoftReference instances = 8*(header + 4 OOPs + 1 long) = 8*(24+32+8) = 8*64 = 512 bytes total: 84+512 = 596 bytes in 9 instances vs. patched code : 1 OOP = 8 bytes 1 SoftReference = 64 bytes 1 VolatileData = header + 10 OOPs + 1 int = 24+84 = 108 bytes total: 8+64+108 = 180 bytes in 3 instances So we have 84 vs. 8 (empty) or 596 vs. 180 (fully loaded) byte overheads and 1 vs. 1 (empty) or 9 vs. 3 (fully loaded) instance overheads Other than that, the patch also removes synchronized blocks for lazy initialization of annotations in Class, Field, Method and Constructor and replaces them with volatile fields. In case of Class.volatileData, this field is initialized using a CAS so there is no race which could install an already stale instance over more recent. Although such race would quickly be corrected at next call to any retrieval method, because redefinedCount is now an integral part of the cached structure not an individual volatile field. There is also a change in how annotations are cached in Field, Method and Constructor. Originally they are cached in each copy of the Field/Method/Constructor that is returned to the outside world at each invocation of Class.getFields() etc. Such caching is not very effective if the annotations are only retrieved once per instance. The patch changes this and delegates caching to the "root" instance which is held inside Class so caching becomes more effective in certain usage patterns. There's now a possible hot-spot on the "root" instance but that seems not to be a bottleneck since the fast-path does not involve blocking synchronization (just volatile read). The effects of this change are clearly visible in one of the benchmarks. I have tried to create 3 micro benchmarks which exercise concurrent load on 3 Class instances. Here's the benchmark code: https://raw.github.com/plevart/jdk8-hacks/master/src/test/ReflectionTest.java And here are the results when run on an Intel i7 CPU (4 cores, 2 threads/core) Linux machine using -Xmx4G VM option: https://raw.github.com/plevart/jdk8-hacks/master/benchmark_results.txt The huge difference of Test1 results is a direct consequence of patched code delegating caching of annotations in Field/Method/Constructor to the "root" instance. Test2 results show no noticeable difference between original and patched code. This, I believe, is the most common usage of the API, so another level of indirection does not appear to present any noticeable performance overhead. The Test3 on the other hand shows the synchronization overhead of current jdk8 code in comparison with non-blocking synchronization in patched code. JEP 149 also mentions testing with SPECjbb2005 and SPECjvm98, but that exceeds my possibilities. The patch against jdk8/jdk8/jdk hg repository is here: https://raw.github.com/plevart/jdk8-hacks/master/volatile_class_data_caching.patch You can also browse the changed sources: https://github.com/plevart/jdk8-hacks For completeness I also paste the patch below. Regards, Peter diff -r 7ac292e57b5a src/share/classes/java/lang/Class.java --- a/src/share/classes/java/lang/Class.java Thu Nov 01 14:12:21 2012 -0700 +++ b/src/share/classes/java/lang/Class.java Tue Nov 06 14:11:43 2012 +0100 @@ -2212,39 +2212,72 @@ // Caches for certain reflective results private static boolean useCaches = true; - private volatile transient SoftReference declaredFields; - private volatile transient SoftReference publicFields; - private volatile transient SoftReference declaredMethods; - private volatile transient SoftReference publicMethods; - private volatile transient SoftReference[]> declaredConstructors; - private volatile transient SoftReference[]> publicConstructors; - // Intermediate results for getFields and getMethods - private volatile transient SoftReference declaredPublicFields; - private volatile transient SoftReference declaredPublicMethods; + + // volatile data that might get invalid when JVM TI RedefineClasses() is called + static class VolatileData { + volatile Field[] declaredFields; + volatile Field[] publicFields; + volatile Method[] declaredMethods; + volatile Method[] publicMethods; + volatile Constructor[] declaredConstructors; + volatile Constructor[] publicConstructors; + // Intermediate results for getFields and getMethods + volatile Field[] declaredPublicFields; + volatile Method[] declaredPublicMethods; + // Annotations + volatile Map, Annotation> annotations; + volatile Map, Annotation> declaredAnnotations; + // Value of classRedefinedCount when we created this VolatileData instance + final int redefinedCount; + + VolatileData(int redefinedCount) { + this.redefinedCount = redefinedCount; + } + + // initialize Unsafe machinery here, since we need to call Class.class instance method and would like to avoid + // calling it in the static initializer of the Class class... + private static final Unsafe unsafe; + // offset of Class.volatileData instance field + private static final long volatileDataOffset; + + static { + unsafe = Unsafe.getUnsafe(); + // bypass caches + Field volatileDataField = searchFields(Class.class.getDeclaredFields0(false), "volatileData"); + if (volatileDataField == null) throw new Error("No volatileData field found in java.lang.Class"); + volatileDataOffset = unsafe.objectFieldOffset(volatileDataField); + } + + static boolean compareAndSwap(Class clazz, SoftReference> oldData, SoftReference> newData) { + return unsafe.compareAndSwapObject(clazz, volatileDataOffset, oldData, newData); + } + } + + private volatile transient SoftReference> volatileData; // Incremented by the VM on each call to JVM TI RedefineClasses() // that redefines this class or a superclass. private volatile transient int classRedefinedCount = 0; - // Value of classRedefinedCount when we last cleared the cached values - // that are sensitive to class redefinition. - private volatile transient int lastRedefinedCount = 0; + // Lazily create and cache VolatileData + private VolatileData volatileData() { + if (!useCaches) return null; - // Clears cached values that might possibly have been obsoleted by - // a class redefinition. - private void clearCachesOnClassRedefinition() { - if (lastRedefinedCount != classRedefinedCount) { - declaredFields = publicFields = declaredPublicFields = null; - declaredMethods = publicMethods = declaredPublicMethods = null; - declaredConstructors = publicConstructors = null; - annotations = declaredAnnotations = null; - - // Use of "volatile" (and synchronization by caller in the case - // of annotations) ensures that no thread sees the update to - // lastRedefinedCount before seeing the caches cleared. - // We do not guard against brief windows during which multiple - // threads might redundantly work to fill an empty cache. - lastRedefinedCount = classRedefinedCount; + while (true) + { + SoftReference> volatileData = this.volatileData; + int classRedefinedCount = this.classRedefinedCount; + VolatileData vd; + if (volatileData != null && (vd = volatileData.get()) != null && vd.redefinedCount == classRedefinedCount) { + return vd; + } + // no SoftReference or cleared SoftReference or stale VolatileData + vd = new VolatileData(classRedefinedCount); + // try to CAS it... + if (VolatileData.compareAndSwap(this, volatileData, new SoftReference>(vd))) { + return vd; + } + // else retry } } @@ -2288,26 +2321,18 @@ private Field[] privateGetDeclaredFields(boolean publicOnly) { checkInitted(); Field[] res = null; - if (useCaches) { - clearCachesOnClassRedefinition(); - if (publicOnly) { - if (declaredPublicFields != null) { - res = declaredPublicFields.get(); - } - } else { - if (declaredFields != null) { - res = declaredFields.get(); - } - } + VolatileData vd = volatileData(); + if (vd != null) { + res = publicOnly ? vd.declaredPublicFields : vd.declaredFields; if (res != null) return res; } // No cached value available; request value from VM res = Reflection.filterFields(this, getDeclaredFields0(publicOnly)); - if (useCaches) { + if (vd != null) { if (publicOnly) { - declaredPublicFields = new SoftReference<>(res); + vd.declaredPublicFields = res; } else { - declaredFields = new SoftReference<>(res); + vd.declaredFields = res; } } return res; @@ -2319,11 +2344,9 @@ private Field[] privateGetPublicFields(Set> traversedInterfaces) { checkInitted(); Field[] res = null; - if (useCaches) { - clearCachesOnClassRedefinition(); - if (publicFields != null) { - res = publicFields.get(); - } + VolatileData vd = volatileData(); + if (vd != null) { + res = vd.publicFields; if (res != null) return res; } @@ -2356,8 +2379,8 @@ res = new Field[fields.size()]; fields.toArray(res); - if (useCaches) { - publicFields = new SoftReference<>(res); + if (vd != null) { + vd.publicFields = res; } return res; } @@ -2381,17 +2404,9 @@ private Constructor[] privateGetDeclaredConstructors(boolean publicOnly) { checkInitted(); Constructor[] res = null; - if (useCaches) { - clearCachesOnClassRedefinition(); - if (publicOnly) { - if (publicConstructors != null) { - res = publicConstructors.get(); - } - } else { - if (declaredConstructors != null) { - res = declaredConstructors.get(); - } - } + VolatileData vd = volatileData(); + if (vd != null) { + res = publicOnly ? vd.publicConstructors : vd.declaredConstructors; if (res != null) return res; } // No cached value available; request value from VM @@ -2402,11 +2417,11 @@ } else { res = getDeclaredConstructors0(publicOnly); } - if (useCaches) { + if (vd != null) { if (publicOnly) { - publicConstructors = new SoftReference<>(res); + vd.publicConstructors = res; } else { - declaredConstructors = new SoftReference<>(res); + vd.declaredConstructors = res; } } return res; @@ -2424,26 +2439,18 @@ private Method[] privateGetDeclaredMethods(boolean publicOnly) { checkInitted(); Method[] res = null; - if (useCaches) { - clearCachesOnClassRedefinition(); - if (publicOnly) { - if (declaredPublicMethods != null) { - res = declaredPublicMethods.get(); - } - } else { - if (declaredMethods != null) { - res = declaredMethods.get(); - } - } + VolatileData vd = volatileData(); + if (vd != null) { + res = publicOnly ? vd.declaredPublicMethods : vd.declaredMethods; if (res != null) return res; } // No cached value available; request value from VM res = Reflection.filterMethods(this, getDeclaredMethods0(publicOnly)); if (useCaches) { if (publicOnly) { - declaredPublicMethods = new SoftReference<>(res); + vd.declaredPublicMethods = res; } else { - declaredMethods = new SoftReference<>(res); + vd.declaredMethods = res; } } return res; @@ -2546,11 +2553,9 @@ private Method[] privateGetPublicMethods() { checkInitted(); Method[] res = null; - if (useCaches) { - clearCachesOnClassRedefinition(); - if (publicMethods != null) { - res = publicMethods.get(); - } + VolatileData vd = volatileData(); + if (vd != null) { + res = vd.publicMethods; if (res != null) return res; } @@ -2558,7 +2563,7 @@ // Start by fetching public declared methods MethodArray methods = new MethodArray(); { - Method[] tmp = privateGetDeclaredMethods(true); + Method[] tmp = privateGetDeclaredMethods(true); methods.addAll(tmp); } // Now recur over superclass and direct superinterfaces. @@ -2598,8 +2603,8 @@ methods.addAllIfNotPresent(inheritedMethods); methods.compactAndTrim(); res = methods.getArray(); - if (useCaches) { - publicMethods = new SoftReference<>(res); + if (vd != null) { + vd.publicMethods = res; } return res; } @@ -2609,7 +2614,7 @@ // Helpers for fetchers of one field, method, or constructor // - private Field searchFields(Field[] fields, String name) { + private static Field searchFields(Field[] fields, String name) { String internedName = name.intern(); for (int i = 0; i < fields.length; i++) { if (fields[i].getName() == internedName) { @@ -3049,8 +3054,7 @@ if (annotationClass == null) throw new NullPointerException(); - initAnnotationsIfNecessary(); - return (A) annotations.get(annotationClass); + return (A) privateGetAnnotations(false).get(annotationClass); } /** @@ -3070,41 +3074,45 @@ * @since 1.5 */ public Annotation[] getAnnotations() { - initAnnotationsIfNecessary(); - return AnnotationParser.toArray(annotations); + return AnnotationParser.toArray(privateGetAnnotations(false)); } /** * @since 1.5 */ public Annotation[] getDeclaredAnnotations() { - initAnnotationsIfNecessary(); - return AnnotationParser.toArray(declaredAnnotations); + return AnnotationParser.toArray(privateGetAnnotations(true)); } - // Annotations cache - private transient Map, Annotation> annotations; - private transient Map, Annotation> declaredAnnotations; - private synchronized void initAnnotationsIfNecessary() { - clearCachesOnClassRedefinition(); - if (annotations != null) - return; - declaredAnnotations = AnnotationParser.parseAnnotations( + private Map, Annotation> privateGetAnnotations(boolean declaredOnly) { + Map, Annotation> res; + VolatileData vd = volatileData(); + if (vd != null) { + res = declaredOnly ? vd.declaredAnnotations : vd.annotations; + if (res != null) return res; + } + + Map, Annotation> declaredAnnotations = AnnotationParser.parseAnnotations( getRawAnnotations(), getConstantPool(), this); + Map, Annotation> annotations; Class superClass = getSuperclass(); if (superClass == null) { annotations = declaredAnnotations; } else { annotations = new HashMap<>(); - superClass.initAnnotationsIfNecessary(); - for (Map.Entry, Annotation> e : superClass.annotations.entrySet()) { + for (Map.Entry, Annotation> e : superClass.privateGetAnnotations(false).entrySet()) { Class annotationClass = e.getKey(); if (AnnotationType.getInstance(annotationClass).isInherited()) annotations.put(annotationClass, e.getValue()); } annotations.putAll(declaredAnnotations); } + + vd.annotations = annotations; + vd.declaredAnnotations = declaredAnnotations; + + return declaredOnly ? declaredAnnotations : annotations; } // Annotation types cache their internal (AnnotationType) form diff -r 7ac292e57b5a src/share/classes/java/lang/reflect/Constructor.java --- a/src/share/classes/java/lang/reflect/Constructor.java Thu Nov 01 14:12:21 2012 -0700 +++ b/src/share/classes/java/lang/reflect/Constructor.java Tue Nov 06 14:11:43 2012 +0100 @@ -482,7 +482,10 @@ * @since 1.5 */ public Annotation[] getDeclaredAnnotations() { - return super.getDeclaredAnnotations(); + if (root != null) + return root.getDeclaredAnnotations(); + else + return super.getDeclaredAnnotations(); } /** diff -r 7ac292e57b5a src/share/classes/java/lang/reflect/Executable.java --- a/src/share/classes/java/lang/reflect/Executable.java Thu Nov 01 14:12:21 2012 -0700 +++ b/src/share/classes/java/lang/reflect/Executable.java Tue Nov 06 14:11:43 2012 +0100 @@ -378,11 +378,12 @@ return AnnotationParser.toArray(declaredAnnotations()); } - private transient Map, Annotation> declaredAnnotations; + private volatile transient Map, Annotation> declaredAnnotations; - private synchronized Map, Annotation> declaredAnnotations() { + private Map, Annotation> declaredAnnotations() { + Map, Annotation> declaredAnnotations = this.declaredAnnotations; if (declaredAnnotations == null) { - declaredAnnotations = AnnotationParser.parseAnnotations( + this.declaredAnnotations = declaredAnnotations = AnnotationParser.parseAnnotations( getAnnotationBytes(), sun.misc.SharedSecrets.getJavaLangAccess(). getConstantPool(getDeclaringClass()), diff -r 7ac292e57b5a src/share/classes/java/lang/reflect/Field.java --- a/src/share/classes/java/lang/reflect/Field.java Thu Nov 01 14:12:21 2012 -0700 +++ b/src/share/classes/java/lang/reflect/Field.java Tue Nov 06 14:11:43 2012 +0100 @@ -1027,11 +1027,15 @@ return AnnotationParser.toArray(declaredAnnotations()); } - private transient Map, Annotation> declaredAnnotations; + private volatile transient Map, Annotation> declaredAnnotations; - private synchronized Map, Annotation> declaredAnnotations() { + private Map, Annotation> declaredAnnotations() { + if (root != null) + return root.declaredAnnotations(); + + Map, Annotation> declaredAnnotations = this.declaredAnnotations; if (declaredAnnotations == null) { - declaredAnnotations = AnnotationParser.parseAnnotations( + this.declaredAnnotations = declaredAnnotations = AnnotationParser.parseAnnotations( annotations, sun.misc.SharedSecrets.getJavaLangAccess(). getConstantPool(getDeclaringClass()), getDeclaringClass()); diff -r 7ac292e57b5a src/share/classes/java/lang/reflect/Method.java --- a/src/share/classes/java/lang/reflect/Method.java Thu Nov 01 14:12:21 2012 -0700 +++ b/src/share/classes/java/lang/reflect/Method.java Tue Nov 06 14:11:43 2012 +0100 @@ -583,7 +583,10 @@ * @since 1.5 */ public Annotation[] getDeclaredAnnotations() { - return super.getDeclaredAnnotations(); + if (root != null) + return root.getDeclaredAnnotations(); + else + return super.getDeclaredAnnotations(); } /** From staffan.larsen at oracle.com Tue Nov 6 13:58:22 2012 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 6 Nov 2012 14:58:22 +0100 Subject: Preliminary review: Adding tracing of I/O calls In-Reply-To: <50990133.3050000@oracle.com> References: <22767084-EAC2-4D87-800B-3E5E5BFC666A@oracle.com> <50942931.4000001@oracle.com> <08183803-2563-461C-9514-B7FAE1E14C10@oracle.com> <509437F0.4020409@oracle.com> <50965EB9.90509@oracle.com> <50990133.3050000@oracle.com> Message-ID: <3EA5EC0F-CEA9-4063-8B4E-52F86E4DB998@oracle.com> No, I haven't considered dynamic instrumentation. It would be a lot more work to implement it, and only worth it, I think, if the performance of the static instrumentation is bad. One could do a little of both: leave the static instrumentation in place, but change the IoTrace class to have only empty methods, then do dynamic instrumentation in that class. /Staffan On 6 nov 2012, at 13:23, Alan Bateman wrote: > Staffan, > > Has dynamic instrumentation being considered for this project? I realize it would require knowledge of the sites to instrument and I realize that ignoring non-blocking I/O complicates it a bit too, I'm just wondering if you've done any experiments to see if this would be an alternative to the static instrumentation proposed. > > -Alan From Alan.Bateman at oracle.com Tue Nov 6 14:00:36 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 06 Nov 2012 14:00:36 +0000 Subject: bottleneck by java.lang.Class.getAnnotations() - a better patch In-Reply-To: <50990CB8.2040400@gmail.com> References: <924D06EC-F603-4E6A-A7FE-7A05C77B1217@gmail.com> <23313EDE-3AB7-4E53-8EB1-A6F6CC9383B9@gmail.com> <5093A8D3.4030800@gmail.com> <5096CFBD.2010604@gmail.com> <5096F5B0.8070304@gmail.com> <50974D3D.1040502@oracle.com> <50990CB8.2040400@gmail.com> Message-ID: <50991804.2040502@oracle.com> Peter, I haven't studied your patch yet but moving the fields into a helper class is what was envisaged. Here's another reminder that the initialization has been crying out to be re-worked for some time: http://bugs.sun.com/view_bug.do?bug_id=7122142 -Alan. From peter.levart at gmail.com Tue Nov 6 14:41:36 2012 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 06 Nov 2012 15:41:36 +0100 Subject: bottleneck by java.lang.Class.getAnnotations() - a better patch In-Reply-To: <50991804.2040502@oracle.com> References: <924D06EC-F603-4E6A-A7FE-7A05C77B1217@gmail.com> <23313EDE-3AB7-4E53-8EB1-A6F6CC9383B9@gmail.com> <5093A8D3.4030800@gmail.com> <5096CFBD.2010604@gmail.com> <5096F5B0.8070304@gmail.com> <50974D3D.1040502@oracle.com> <50990CB8.2040400@gmail.com> <50991804.2040502@oracle.com> Message-ID: <509921A0.8060001@gmail.com> On 11/06/2012 03:00 PM, Alan Bateman wrote: > Peter, > > I haven't studied your patch yet but moving the fields into a helper > class is what was envisaged. Here's another reminder that the > initialization has been crying out to be re-worked for some time: > > http://bugs.sun.com/view_bug.do?bug_id=7122142 > > -Alan. > > I noticed the static syncronized AnnotationType.getInstance too. My proposed patch does away with synchronized Class.initAnnotationsIfNecessary and replaces it with plain Class.privateGetAnnotations that doesn't use any locks. Therefore it solves this deadlock. Regards, Peter From maurizio.cimadamore at oracle.com Tue Nov 6 14:46:22 2012 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Tue, 06 Nov 2012 14:46:22 +0000 Subject: hg: jdk8/tl/langtools: 8002286: Regression: Fix for 8000931 causes a JCK test failure Message-ID: <20121106144626.AC542477B6@hg.openjdk.java.net> Changeset: 9b85813d2262 Author: mcimadamore Date: 2012-11-06 14:45 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/9b85813d2262 8002286: Regression: Fix for 8000931 causes a JCK test failure Summary: Wrong type used as 'site' in Resolve.resolveMethod Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Resolve.java + test/tools/javac/8002286/T8002286.java + test/tools/javac/8002286/T8002286.out From kelly.ohair at oracle.com Tue Nov 6 16:11:11 2012 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Tue, 6 Nov 2012 08:11:11 -0800 Subject: 7197491: update copyright year to match last edit in jdk8 jdk repository In-Reply-To: <50963DAA.30403@oracle.com> References: <5093C08A.8060705@oracle.com> <5093F6BC.8040003@oracle.com> <5093F916.4030409@oracle.com> <5093FA2B.9030006@oracle.com> <50963DAA.30403@oracle.com> Message-ID: <5DFCE787-270C-4CEE-A0E4-BBA178BFE557@oracle.com> On Nov 4, 2012, at 2:04 AM, David Holmes wrote: > On 3/11/2012 3:27 AM, Kelly O'Hair wrote: >> All changes to JDK sources require a CR, an OpenJDK author name, and a review by a second OpenJDK author. >> So although you can automate the preparation of the commit, you cannot fully automate this process. >> >> There have been many discussions over the years about automating various changes, anything from tag generation, >> to whitespace normalization, and this copyright year change issue. >> Our policy has been that changesets need human authors, and all changes need a human review. > > I think that is the tail wagging the dog. A simple change to a year value in a comment by a sanctioned pre/post commit script can easily be accommodated in the changeset for a given CR just as-if the engineer had done it themselves. In the SCCS days we didn't require reviews for sccs tag updates in file headers - I don't see that copyright update should be any different. If we need to tweak the OpenJDK rules then lets tweak them. But in SCCS days, you still needed an identity on the change, an informal review, and a human to trigger the putback. It is true that in the SCCS days there was less red tape, but in the SCCS days there was much less tracking of all changes, and identities could be fictitious. The SCCS history was generally worthless. > > Personally I don't see why it is so hard to have engineers be responsible for this (if automation is considered so problematic). It only affects one changeset per file per year and a pre-commit script (or jcheck enhancement?) could warn you if you forget to do the update. I find these big periodic changesets far more noisy and problematic. > The only issue would be that warnings tend to be ignored by most developers, but I could accept this idea. If jcheck blocked the commit when it detected a missing year change, that would force the edit before the changeset would be created, or before the changeset was integrated. However, I'm not exactly sure we could make the copyright year check that concrete, maybe, it's not as cut and dried as the whitespace check jcheck does. > For the general audience: copyright years only get updated when there is a substantive change to the material content of a file. I think we well and truly established that when we went through the Sun to Oracle conversion process. Yes. There are very rare situations where a file can change, and that change should not trigger a year update. So by default, we treat any change to a file as being one that needs a year update. --- Just to clarify it for others: And there are 2 years. The first year is the initial creation, the second year is the year of last change. When they are the same, one year will be listed in the legal notice. It's very important to preserve that first year, or year of creation. -kto > > David > >> -kto >> >> On Nov 2, 2012, at 9:51 AM, Darryl Mocek wrote: >> >>> So the 3000+ files Alan is referring to are all files which have been modified but which haven't had their year updated? If we're not worried about files which haven't been modified then a pre/post-commit script will suffice and depending on how we implement it we might not need periodic updates. >>> >>> Darryl >>> >>> On 11/02/2012 09:47 AM, Phil Race wrote: >>>>> but ultimately there are files which never get touched which will need processing to update the year. >>>> >>>> The policy has varied over the years, but presently the policy is not to >>>> update the year in files that have not been updated code-wise. >>>> >>>> -phil. >>>> >>>> On 11/2/2012 9:37 AM, Darryl Mocek wrote: >>>>> Alan, >>>>> >>>>> I was responsible for updating the copyrights for JavaME. I used a Perl script to update the copyright year in the source files. I can point you to the relevant information if you like. There were challenges as there are various copyrights in the source files (Oracle, Oracle + 3rd-party, 3rd party only, and no copyright), all with different formats, and even within the Oracle copyrights, people used subtle differences which caused difficulties. I ended updating all copyrights to a few formats and adding a post-commit script which scrubbed the copyright and notified the committer if the copyright wasn't in the correct format and didn't have an ending year (or sole year) which is the current year. >>>>> >>>>> There are plenty of options here: >>>>> >>>>> - Do nothing (policy) >>>>> - Pre-commit script which changes the year automatically >>>>> - Pre-commit script which rejects commit with wrong year >>>>> - Post-commit script which flags a bad copyright, but accepts commit >>>>> - Others >>>>> >>>>> Updating the copyright year as you commit is a good habit to get into, but ultimately there are files which never get touched which will need processing to update the year. I think doing this at the end/beginning of the year is good, we just need to make sure we get the copyright correct when processing. >>>>> >>>>> Darryl >>>>> >>>>> On 11/02/2012 05:46 AM, Alan Bateman wrote: >>>>>> >>>>>> Now for some noise. >>>>>> >>>>>> The copyright date in the source files needs updating. The man behind the curtain is Steve Sides from the Quality and Release Engineering team in Oracle. Jon pushed, on Steve's behalf, the update to the langtools files recently [1], and Mikael updated hotspot [2]. The elephant is the jdk repository as there are 3000+ files that need their headers updated. >>>>>> >>>>>> To keep the disruption to a minimum I propose that we do the jdk repository in two steps: non-client area now to jdk8/tl, and then the client-area later in jdk8/awt once the changes get there. I use the term "client-area" loosely to mean the source files for awt, swing, font, java2d, etc. (and I appreciate that there is also a jdk8/2d forest in use). To that end here is the proposed patch for today: >>>>>> >>>>>> http://cr.openjdk.java.net/~alanb/7197491/copyright.patch >>>>>> >>>>>> This patch updates the headers on 2370 files. I don't propose to publish a webrev as it's just too big. >>>>>> >>>>>> This patch was created with: >>>>>> >>>>>> cd jdk >>>>>> sh ../make/scripts/update_copyright_year.sh 2011 >>>>>> sh ../make/scripts/update_copyright_year.sh 2012 >>>>>> hg revert --no-backup `cat clientdirs.list` >>>>>> hg diff -g> copyright.patch >>>>>> >>>>>> where clientdirs.list is most of the directories corresponding to the client area. >>>>>> >>>>>> Note that I ran the update_copyright_year.sh script twice, once for 2011 and then a second time for 2012. The reason for this is that there are several hundred files in the jdk repository that were last updated in 2011 but have an older date on the header. >>>>>> >>>>>> Reviewer welcome but I should say that I don't have cycles to spend on this. Also the patch has an a very short shelf life. >>>>>> >>>>>> Finally, I think that there needs to be wider discussion as to how to keep the headers from falling behind too much. Some people do update the headers when editing files, some people (including myself) do not. It seems to me that it should be done regularly anyway, perhaps every few months or at integration time every so often. >>>>>> >>>>>> -Alan. >>>>>> >>>>>> [1] http://hg.openjdk.java.net/jdk8/tl/langtools/rev/9d47f4850714 >>>>>> [2] http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/b9a9ed0f8eeb >>>>> >>>> >>> >> From lance.andersen at oracle.com Tue Nov 6 20:00:05 2012 From: lance.andersen at oracle.com (lance.andersen at oracle.com) Date: Tue, 06 Nov 2012 20:00:05 +0000 Subject: hg: jdk8/tl/jdk: 8002212: adding read/writeObject to additional SerialXXX classes Message-ID: <20121106200024.22A0F477C0@hg.openjdk.java.net> Changeset: d90714aec287 Author: lancea Date: 2012-11-06 14:59 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d90714aec287 8002212: adding read/writeObject to additional SerialXXX classes Reviewed-by: naoto, forax ! src/share/classes/javax/sql/rowset/serial/SerialArray.java ! src/share/classes/javax/sql/rowset/serial/SerialDatalink.java ! src/share/classes/javax/sql/rowset/serial/SerialJavaObject.java ! src/share/classes/javax/sql/rowset/serial/SerialRef.java ! src/share/classes/javax/sql/rowset/serial/SerialStruct.java From chris.hegarty at oracle.com Tue Nov 6 21:02:35 2012 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Tue, 06 Nov 2012 21:02:35 +0000 Subject: hg: jdk8/tl/jdk: 8002297: sun/net/www/protocol/http/StackTraceTest.java fails intermittently Message-ID: <20121106210248.EA39A477C4@hg.openjdk.java.net> Changeset: 157506182fa7 Author: chegar Date: 2012-11-06 21:01 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/157506182fa7 8002297: sun/net/www/protocol/http/StackTraceTest.java fails intermittently Reviewed-by: alanb, dsamersoff ! test/sun/net/www/protocol/http/StackTraceTest.java From jonathan.gibbons at oracle.com Tue Nov 6 22:33:22 2012 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Tue, 06 Nov 2012 22:33:22 +0000 Subject: hg: jdk8/tl/langtools: 8000612: Discrepancy between resources provided in javadoc resource files and resources required by code Message-ID: <20121106223325.2EC23477C9@hg.openjdk.java.net> Changeset: 8abc56be3131 Author: jjg Date: 2012-11-06 14:32 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/8abc56be3131 8000612: Discrepancy between resources provided in javadoc resource files and resources required by code Reviewed-by: bpatel ! src/share/classes/com/sun/tools/doclets/formats/html/resources/standard.properties ! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclets.properties ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Util.java ! src/share/classes/com/sun/tools/javadoc/SeeTagImpl.java ! src/share/classes/com/sun/tools/javadoc/resources/javadoc.properties ! test/tools/javac/diags/CheckResourceKeys.java + test/tools/javadoc/CheckResourceKeys.java From yuka.kamiya at oracle.com Wed Nov 7 01:00:13 2012 From: yuka.kamiya at oracle.com (yuka.kamiya at oracle.com) Date: Wed, 07 Nov 2012 01:00:13 +0000 Subject: hg: jdk8/tl/jdk: 7198195: Support Unicode 6.2.0 Message-ID: <20121107010025.8AA72477D2@hg.openjdk.java.net> Changeset: bff9db7ca352 Author: peytoia Date: 2012-11-07 09:58 +0900 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bff9db7ca352 7198195: Support Unicode 6.2.0 Reviewed-by: okutsu ! make/tools/GenerateCharacter/CharacterData01.java.template ! make/tools/UnicodeData/PropList.txt ! make/tools/UnicodeData/Scripts.txt ! make/tools/UnicodeData/SpecialCasing.txt ! make/tools/UnicodeData/UnicodeData.txt ! make/tools/UnicodeData/VERSION ! src/share/classes/java/lang/Character.java ! test/java/lang/Character/CheckProp.java ! test/java/lang/Character/CheckScript.java ! test/java/lang/Character/PropList.txt ! test/java/lang/Character/PropertyValueAliases.txt ! test/java/lang/Character/Scripts.txt From weijun.wang at oracle.com Wed Nov 7 01:05:08 2012 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 07 Nov 2012 09:05:08 +0800 Subject: Fake DNS query result inside a test Message-ID: <5099B3C4.90506@oracle.com> Hi Vinnie I want to write a regression test so that Context ctx = NamingManager.getURLContext("dns", new Hashtable<>(0)); Attributes attrs =((DirContext)ctx).getAttributes( "_kerberos._udp.ASDF.COM.", SRV_RR_ATTR); can return some entries without querying a real external server. Is this possible by registering a local name server provider or else? Thanks Max From jonathan.gibbons at oracle.com Wed Nov 7 01:22:50 2012 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Wed, 07 Nov 2012 01:22:50 +0000 Subject: hg: jdk8/tl/langtools: 7198690: missing compiler message Message-ID: <20121107012252.256DE477D3@hg.openjdk.java.net> Changeset: 55a007aaf63d Author: jjg Date: 2012-11-06 17:22 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/55a007aaf63d 7198690: missing compiler message Reviewed-by: jjh ! src/share/classes/com/sun/tools/javac/main/Main.java From david.holmes at oracle.com Wed Nov 7 02:10:02 2012 From: david.holmes at oracle.com (David Holmes) Date: Wed, 07 Nov 2012 12:10:02 +1000 Subject: bottleneck by java.lang.Class.getAnnotations() - a better patch In-Reply-To: <50990CB8.2040400@gmail.com> References: <924D06EC-F603-4E6A-A7FE-7A05C77B1217@gmail.com> <23313EDE-3AB7-4E53-8EB1-A6F6CC9383B9@gmail.com> <5093A8D3.4030800@gmail.com> <5096CFBD.2010604@gmail.com> <5096F5B0.8070304@gmail.com> <50974D3D.1040502@oracle.com> <50990CB8.2040400@gmail.com> Message-ID: <5099C2FA.2020202@oracle.com> Hi Peter, The movement of the reflection caches to a helper object is exactly what I had previously proposed here (some differences in the details of course): http://cr.openjdk.java.net/~dholmes/JEP-149/webrev/ and discussed here: http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-April/009749.html but this did not touch the annotations fields. David On 6/11/2012 11:12 PM, Peter Levart wrote: > On 11/05/2012 06:23 AM, David Holmes wrote: >> Hi Peter, >> >> Moving the annotations fields into a helper object would tie in with >> the Class-instance size reduction effort that was investigated as part >> of "JEP 149: Reduce Core-Library Memory Usage": >> >> http://openjdk.java.net/jeps/149 >> >> The investigations there to date only looked at relocating the >> reflection related fields, though the JEP mentions the annotations as >> well. >> >> Any such effort requires extensive benchmarking and performance >> analysis before being accepted though. >> >> David >> ----- >> > > On 11/05/2012 10:25 AM, Alan Bateman wrote: >> Here's a good starting place on the interaction of runtime visible >> attributes and RedefineClasses/RetransformClasses: >> >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5002251 >> >> -Alan. > > Hi all, > > Presented here is a patch mainly against java.lang.Class and also > against java.lang.reflect.[Field,Method,Constructor,Executable] classes. > > Currently java.lang.Class uses the following fields to maintain caches > of reflection data that are invalidated as a result of class or > superclass redefinition/re-transformation: > > private volatile transient SoftReference declaredFields; > private volatile transient SoftReference publicFields; > private volatile transient SoftReference declaredMethods; > private volatile transient SoftReference publicMethods; > private volatile transient SoftReference[]> > declaredConstructors; > private volatile transient SoftReference[]> > publicConstructors; > private volatile transient SoftReference declaredPublicFields; > private volatile transient SoftReference declaredPublicMethods; > > // Value of classRedefinedCount when we last cleared the cached values > // that are sensitive to class redefinition. > private volatile transient int lastRedefinedCount = 0; > > // Annotations cache > private transient Map, Annotation> annotations; > private transient Map, Annotation> > declaredAnnotations; > > If I understand Alan's references correctly, current VM can redefine the > class in a way that changes method bodies. Also new methods can be > added. And the set of annotations can also be altered. And future > improvements could allow even more. > > Because annotations are cached on Field/Method/Constructor instances, > all the above fields must be invalidated when the class or superclass is > redefined. > > It can also be observed that Field/Method/Constructor caches are > maintained using SoftReferences but annotations are hard references. I > don't know if this is intentional. I believe that annotations could also > be SoftReferenced, so that in the event of memory pressure they get > cleared. Many applications retrieve annotations only in the early stages > of their life-cycle and then either cache them themselves or forget > about them. > > So I designed the patch to equalize this. If this is undesirable, the > patch could be modified to make a distinction again. > > The patch replaces the above-mentioned java.lang.Class fields with a > single field: > > private volatile transient SoftReference> volatileData; > > ...which is a SoftReference to the following structure: > > // volatile data that might get invalid when JVM TI RedefineClasses() is > called > static class VolatileData { > volatile Field[] declaredFields; > volatile Field[] publicFields; > volatile Method[] declaredMethods; > volatile Method[] publicMethods; > volatile Constructor[] declaredConstructors; > volatile Constructor[] publicConstructors; > // Intermediate results for getFields and getMethods > volatile Field[] declaredPublicFields; > volatile Method[] declaredPublicMethods; > // Annotations > volatile Map, Annotation> annotations; > volatile Map, Annotation> declaredAnnotations; > // Value of classRedefinedCount when we created this VolatileData instance > final int redefinedCount; > > So let's look at static overhead differences using 64 bit addressing > (useful load - arrays, Maps not counted since the patched code uses the > same amount of same types of each). > > * Fresh java.lang.Class instance: > > current JDK8 code: > > 10 OOPs + 1 int = 10*8+4 = 84 bytes in 1 instance > > vs. patched code : > > 1 OOP = 8 bytes in 1 instance > > * Fully loaded java.lang.Class (Fields, Methods, Constructors, annotations): > > current JDK8 code: > > 10 OOPs + 1 int = 84 bytes > 8 SoftReference instances = 8*(header + 4 OOPs + 1 long) = 8*(24+32+8) = > 8*64 = 512 bytes > total: 84+512 = 596 bytes in 9 instances > > vs. patched code : > > 1 OOP = 8 bytes > 1 SoftReference = 64 bytes > 1 VolatileData = header + 10 OOPs + 1 int = 24+84 = 108 bytes > total: 8+64+108 = 180 bytes in 3 instances > > So we have 84 vs. 8 (empty) or 596 vs. 180 (fully loaded) byte overheads and > 1 vs. 1 (empty) or 9 vs. 3 (fully loaded) instance overheads > > Other than that, the patch also removes synchronized blocks for lazy > initialization of annotations in Class, Field, Method and Constructor > and replaces them with volatile fields. In case of Class.volatileData, > this field is initialized using a CAS so there is no race which could > install an already stale instance over more recent. Although such race > would quickly be corrected at next call to any retrieval method, because > redefinedCount is now an integral part of the cached structure not an > individual volatile field. > > There is also a change in how annotations are cached in Field, Method > and Constructor. Originally they are cached in each copy of the > Field/Method/Constructor that is returned to the outside world at each > invocation of Class.getFields() etc. Such caching is not very effective > if the annotations are only retrieved once per instance. The patch > changes this and delegates caching to the "root" instance which is held > inside Class so caching becomes more effective in certain usage > patterns. There's now a possible hot-spot on the "root" instance but > that seems not to be a bottleneck since the fast-path does not involve > blocking synchronization (just volatile read). The effects of this > change are clearly visible in one of the benchmarks. > > I have tried to create 3 micro benchmarks which exercise concurrent load > on 3 Class instances. > > Here's the benchmark code: > > https://raw.github.com/plevart/jdk8-hacks/master/src/test/ReflectionTest.java > > And here are the results when run on an Intel i7 CPU (4 cores, 2 > threads/core) Linux machine using -Xmx4G VM option: > > https://raw.github.com/plevart/jdk8-hacks/master/benchmark_results.txt > > > The huge difference of Test1 results is a direct consequence of patched > code delegating caching of annotations in Field/Method/Constructor to > the "root" instance. > > Test2 results show no noticeable difference between original and patched > code. This, I believe, is the most common usage of the API, so another > level of indirection does not appear to present any noticeable > performance overhead. > > The Test3 on the other hand shows the synchronization overhead of > current jdk8 code in comparison with non-blocking synchronization in > patched code. > > JEP 149 also mentions testing with SPECjbb2005 and SPECjvm98, but that > exceeds my possibilities. > > The patch against jdk8/jdk8/jdk hg repository is here: > > https://raw.github.com/plevart/jdk8-hacks/master/volatile_class_data_caching.patch > > You can also browse the changed sources: > > https://github.com/plevart/jdk8-hacks > > For completeness I also paste the patch below. > > Regards, Peter > > > diff -r 7ac292e57b5a src/share/classes/java/lang/Class.java > --- a/src/share/classes/java/lang/Class.java Thu Nov 01 14:12:21 2012 -0700 > +++ b/src/share/classes/java/lang/Class.java Tue Nov 06 14:11:43 2012 +0100 > @@ -2212,39 +2212,72 @@ > > // Caches for certain reflective results > private static boolean useCaches = true; > - private volatile transient SoftReference declaredFields; > - private volatile transient SoftReference publicFields; > - private volatile transient SoftReference declaredMethods; > - private volatile transient SoftReference publicMethods; > - private volatile transient SoftReference[]> > declaredConstructors; > - private volatile transient SoftReference[]> > publicConstructors; > - // Intermediate results for getFields and getMethods > - private volatile transient SoftReference declaredPublicFields; > - private volatile transient SoftReference declaredPublicMethods; > + > + // volatile data that might get invalid when JVM TI RedefineClasses() > is called > + static class VolatileData { > + volatile Field[] declaredFields; > + volatile Field[] publicFields; > + volatile Method[] declaredMethods; > + volatile Method[] publicMethods; > + volatile Constructor[] declaredConstructors; > + volatile Constructor[] publicConstructors; > + // Intermediate results for getFields and getMethods > + volatile Field[] declaredPublicFields; > + volatile Method[] declaredPublicMethods; > + // Annotations > + volatile Map, Annotation> annotations; > + volatile Map, Annotation> declaredAnnotations; > + // Value of classRedefinedCount when we created this VolatileData instance > + final int redefinedCount; > + > + VolatileData(int redefinedCount) { > + this.redefinedCount = redefinedCount; > + } > + > + // initialize Unsafe machinery here, since we need to call Class.class > instance method and would like to avoid > + // calling it in the static initializer of the Class class... > + private static final Unsafe unsafe; > + // offset of Class.volatileData instance field > + private static final long volatileDataOffset; > + > + static { > + unsafe = Unsafe.getUnsafe(); > + // bypass caches > + Field volatileDataField = > searchFields(Class.class.getDeclaredFields0(false), "volatileData"); > + if (volatileDataField == null) throw new Error("No volatileData field > found in java.lang.Class"); > + volatileDataOffset = unsafe.objectFieldOffset(volatileDataField); > + } > + > + static boolean compareAndSwap(Class clazz, > SoftReference> oldData, SoftReference> > newData) { > + return unsafe.compareAndSwapObject(clazz, volatileDataOffset, oldData, > newData); > + } > + } > + > + private volatile transient SoftReference> volatileData; > > // Incremented by the VM on each call to JVM TI RedefineClasses() > // that redefines this class or a superclass. > private volatile transient int classRedefinedCount = 0; > > - // Value of classRedefinedCount when we last cleared the cached values > - // that are sensitive to class redefinition. > - private volatile transient int lastRedefinedCount = 0; > + // Lazily create and cache VolatileData > + private VolatileData volatileData() { > + if (!useCaches) return null; > > - // Clears cached values that might possibly have been obsoleted by > - // a class redefinition. > - private void clearCachesOnClassRedefinition() { > - if (lastRedefinedCount != classRedefinedCount) { > - declaredFields = publicFields = declaredPublicFields = null; > - declaredMethods = publicMethods = declaredPublicMethods = null; > - declaredConstructors = publicConstructors = null; > - annotations = declaredAnnotations = null; > - > - // Use of "volatile" (and synchronization by caller in the case > - // of annotations) ensures that no thread sees the update to > - // lastRedefinedCount before seeing the caches cleared. > - // We do not guard against brief windows during which multiple > - // threads might redundantly work to fill an empty cache. > - lastRedefinedCount = classRedefinedCount; > + while (true) > + { > + SoftReference> volatileData = this.volatileData; > + int classRedefinedCount = this.classRedefinedCount; > + VolatileData vd; > + if (volatileData != null && (vd = volatileData.get()) != null && > vd.redefinedCount == classRedefinedCount) { > + return vd; > + } > + // no SoftReference or cleared SoftReference or stale VolatileData > + vd = new VolatileData(classRedefinedCount); > + // try to CAS it... > + if (VolatileData.compareAndSwap(this, volatileData, new > SoftReference>(vd))) { > + return vd; > + } > + // else retry > } > } > > @@ -2288,26 +2321,18 @@ > private Field[] privateGetDeclaredFields(boolean publicOnly) { > checkInitted(); > Field[] res = null; > - if (useCaches) { > - clearCachesOnClassRedefinition(); > - if (publicOnly) { > - if (declaredPublicFields != null) { > - res = declaredPublicFields.get(); > - } > - } else { > - if (declaredFields != null) { > - res = declaredFields.get(); > - } > - } > + VolatileData vd = volatileData(); > + if (vd != null) { > + res = publicOnly ? vd.declaredPublicFields : vd.declaredFields; > if (res != null) return res; > } > // No cached value available; request value from VM > res = Reflection.filterFields(this, getDeclaredFields0(publicOnly)); > - if (useCaches) { > + if (vd != null) { > if (publicOnly) { > - declaredPublicFields = new SoftReference<>(res); > + vd.declaredPublicFields = res; > } else { > - declaredFields = new SoftReference<>(res); > + vd.declaredFields = res; > } > } > return res; > @@ -2319,11 +2344,9 @@ > private Field[] privateGetPublicFields(Set> traversedInterfaces) { > checkInitted(); > Field[] res = null; > - if (useCaches) { > - clearCachesOnClassRedefinition(); > - if (publicFields != null) { > - res = publicFields.get(); > - } > + VolatileData vd = volatileData(); > + if (vd != null) { > + res = vd.publicFields; > if (res != null) return res; > } > > @@ -2356,8 +2379,8 @@ > > res = new Field[fields.size()]; > fields.toArray(res); > - if (useCaches) { > - publicFields = new SoftReference<>(res); > + if (vd != null) { > + vd.publicFields = res; > } > return res; > } > @@ -2381,17 +2404,9 @@ > private Constructor[] privateGetDeclaredConstructors(boolean > publicOnly) { > checkInitted(); > Constructor[] res = null; > - if (useCaches) { > - clearCachesOnClassRedefinition(); > - if (publicOnly) { > - if (publicConstructors != null) { > - res = publicConstructors.get(); > - } > - } else { > - if (declaredConstructors != null) { > - res = declaredConstructors.get(); > - } > - } > + VolatileData vd = volatileData(); > + if (vd != null) { > + res = publicOnly ? vd.publicConstructors : vd.declaredConstructors; > if (res != null) return res; > } > // No cached value available; request value from VM > @@ -2402,11 +2417,11 @@ > } else { > res = getDeclaredConstructors0(publicOnly); > } > - if (useCaches) { > + if (vd != null) { > if (publicOnly) { > - publicConstructors = new SoftReference<>(res); > + vd.publicConstructors = res; > } else { > - declaredConstructors = new SoftReference<>(res); > + vd.declaredConstructors = res; > } > } > return res; > @@ -2424,26 +2439,18 @@ > private Method[] privateGetDeclaredMethods(boolean publicOnly) { > checkInitted(); > Method[] res = null; > - if (useCaches) { > - clearCachesOnClassRedefinition(); > - if (publicOnly) { > - if (declaredPublicMethods != null) { > - res = declaredPublicMethods.get(); > - } > - } else { > - if (declaredMethods != null) { > - res = declaredMethods.get(); > - } > - } > + VolatileData vd = volatileData(); > + if (vd != null) { > + res = publicOnly ? vd.declaredPublicMethods : vd.declaredMethods; > if (res != null) return res; > } > // No cached value available; request value from VM > res = Reflection.filterMethods(this, getDeclaredMethods0(publicOnly)); > if (useCaches) { > if (publicOnly) { > - declaredPublicMethods = new SoftReference<>(res); > + vd.declaredPublicMethods = res; > } else { > - declaredMethods = new SoftReference<>(res); > + vd.declaredMethods = res; > } > } > return res; > @@ -2546,11 +2553,9 @@ > private Method[] privateGetPublicMethods() { > checkInitted(); > Method[] res = null; > - if (useCaches) { > - clearCachesOnClassRedefinition(); > - if (publicMethods != null) { > - res = publicMethods.get(); > - } > + VolatileData vd = volatileData(); > + if (vd != null) { > + res = vd.publicMethods; > if (res != null) return res; > } > > @@ -2558,7 +2563,7 @@ > // Start by fetching public declared methods > MethodArray methods = new MethodArray(); > { > - Method[] tmp = privateGetDeclaredMethods(true); > + Method[] tmp = privateGetDeclaredMethods(true); > methods.addAll(tmp); > } > // Now recur over superclass and direct superinterfaces. > @@ -2598,8 +2603,8 @@ > methods.addAllIfNotPresent(inheritedMethods); > methods.compactAndTrim(); > res = methods.getArray(); > - if (useCaches) { > - publicMethods = new SoftReference<>(res); > + if (vd != null) { > + vd.publicMethods = res; > } > return res; > } > @@ -2609,7 +2614,7 @@ > // Helpers for fetchers of one field, method, or constructor > // > > - private Field searchFields(Field[] fields, String name) { > + private static Field searchFields(Field[] fields, String name) { > String internedName = name.intern(); > for (int i = 0; i < fields.length; i++) { > if (fields[i].getName() == internedName) { > @@ -3049,8 +3054,7 @@ > if (annotationClass == null) > throw new NullPointerException(); > > - initAnnotationsIfNecessary(); > - return (A) annotations.get(annotationClass); > + return (A) privateGetAnnotations(false).get(annotationClass); > } > > /** > @@ -3070,41 +3074,45 @@ > * @since 1.5 > */ > public Annotation[] getAnnotations() { > - initAnnotationsIfNecessary(); > - return AnnotationParser.toArray(annotations); > + return AnnotationParser.toArray(privateGetAnnotations(false)); > } > > /** > * @since 1.5 > */ > public Annotation[] getDeclaredAnnotations() { > - initAnnotationsIfNecessary(); > - return AnnotationParser.toArray(declaredAnnotations); > + return AnnotationParser.toArray(privateGetAnnotations(true)); > } > > - // Annotations cache > - private transient Map, Annotation> > annotations; > - private transient Map, Annotation> > declaredAnnotations; > > - private synchronized void initAnnotationsIfNecessary() { > - clearCachesOnClassRedefinition(); > - if (annotations != null) > - return; > - declaredAnnotations = AnnotationParser.parseAnnotations( > + private Map, Annotation> > privateGetAnnotations(boolean declaredOnly) { > + Map, Annotation> res; > + VolatileData vd = volatileData(); > + if (vd != null) { > + res = declaredOnly ? vd.declaredAnnotations : vd.annotations; > + if (res != null) return res; > + } > + > + Map, Annotation> declaredAnnotations = > AnnotationParser.parseAnnotations( > getRawAnnotations(), getConstantPool(), this); > + Map, Annotation> annotations; > Class superClass = getSuperclass(); > if (superClass == null) { > annotations = declaredAnnotations; > } else { > annotations = new HashMap<>(); > - superClass.initAnnotationsIfNecessary(); > - for (Map.Entry, Annotation> e : > superClass.annotations.entrySet()) { > + for (Map.Entry, Annotation> e : > superClass.privateGetAnnotations(false).entrySet()) { > Class annotationClass = e.getKey(); > if (AnnotationType.getInstance(annotationClass).isInherited()) > annotations.put(annotationClass, e.getValue()); > } > annotations.putAll(declaredAnnotations); > } > + > + vd.annotations = annotations; > + vd.declaredAnnotations = declaredAnnotations; > + > + return declaredOnly ? declaredAnnotations : annotations; > } > > // Annotation types cache their internal (AnnotationType) form > diff -r 7ac292e57b5a src/share/classes/java/lang/reflect/Constructor.java > --- a/src/share/classes/java/lang/reflect/Constructor.java Thu Nov 01 > 14:12:21 2012 -0700 > +++ b/src/share/classes/java/lang/reflect/Constructor.java Tue Nov 06 > 14:11:43 2012 +0100 > @@ -482,7 +482,10 @@ > * @since 1.5 > */ > public Annotation[] getDeclaredAnnotations() { > - return super.getDeclaredAnnotations(); > + if (root != null) > + return root.getDeclaredAnnotations(); > + else > + return super.getDeclaredAnnotations(); > } > > /** > diff -r 7ac292e57b5a src/share/classes/java/lang/reflect/Executable.java > --- a/src/share/classes/java/lang/reflect/Executable.java Thu Nov 01 > 14:12:21 2012 -0700 > +++ b/src/share/classes/java/lang/reflect/Executable.java Tue Nov 06 > 14:11:43 2012 +0100 > @@ -378,11 +378,12 @@ > return AnnotationParser.toArray(declaredAnnotations()); > } > > - private transient Map, Annotation> > declaredAnnotations; > + private volatile transient Map, > Annotation> declaredAnnotations; > > - private synchronized Map, Annotation> > declaredAnnotations() { > + private Map, Annotation> > declaredAnnotations() { > + Map, Annotation> declaredAnnotations = > this.declaredAnnotations; > if (declaredAnnotations == null) { > - declaredAnnotations = AnnotationParser.parseAnnotations( > + this.declaredAnnotations = declaredAnnotations = > AnnotationParser.parseAnnotations( > getAnnotationBytes(), > sun.misc.SharedSecrets.getJavaLangAccess(). > getConstantPool(getDeclaringClass()), > diff -r 7ac292e57b5a src/share/classes/java/lang/reflect/Field.java > --- a/src/share/classes/java/lang/reflect/Field.java Thu Nov 01 14:12:21 > 2012 -0700 > +++ b/src/share/classes/java/lang/reflect/Field.java Tue Nov 06 14:11:43 > 2012 +0100 > @@ -1027,11 +1027,15 @@ > return AnnotationParser.toArray(declaredAnnotations()); > } > > - private transient Map, Annotation> > declaredAnnotations; > + private volatile transient Map, > Annotation> declaredAnnotations; > > - private synchronized Map, Annotation> > declaredAnnotations() { > + private Map, Annotation> > declaredAnnotations() { > + if (root != null) > + return root.declaredAnnotations(); > + > + Map, Annotation> declaredAnnotations = > this.declaredAnnotations; > if (declaredAnnotations == null) { > - declaredAnnotations = AnnotationParser.parseAnnotations( > + this.declaredAnnotations = declaredAnnotations = > AnnotationParser.parseAnnotations( > annotations, sun.misc.SharedSecrets.getJavaLangAccess(). > getConstantPool(getDeclaringClass()), > getDeclaringClass()); > diff -r 7ac292e57b5a src/share/classes/java/lang/reflect/Method.java > --- a/src/share/classes/java/lang/reflect/Method.java Thu Nov 01 > 14:12:21 2012 -0700 > +++ b/src/share/classes/java/lang/reflect/Method.java Tue Nov 06 > 14:11:43 2012 +0100 > @@ -583,7 +583,10 @@ > * @since 1.5 > */ > public Annotation[] getDeclaredAnnotations() { > - return super.getDeclaredAnnotations(); > + if (root != null) > + return root.getDeclaredAnnotations(); > + else > + return super.getDeclaredAnnotations(); > } > > /** > > From david.holmes at oracle.com Wed Nov 7 02:17:45 2012 From: david.holmes at oracle.com (David Holmes) Date: Wed, 07 Nov 2012 12:17:45 +1000 Subject: 7197491: update copyright year to match last edit in jdk8 jdk repository In-Reply-To: <5DFCE787-270C-4CEE-A0E4-BBA178BFE557@oracle.com> References: <5093C08A.8060705@oracle.com> <5093F6BC.8040003@oracle.com> <5093F916.4030409@oracle.com> <5093FA2B.9030006@oracle.com> <50963DAA.30403@oracle.com> <5DFCE787-270C-4CEE-A0E4-BBA178BFE557@oracle.com> Message-ID: <5099C4C9.3000300@oracle.com> On 7/11/2012 2:11 AM, Kelly O'Hair wrote: > > On Nov 4, 2012, at 2:04 AM, David Holmes wrote: > >> On 3/11/2012 3:27 AM, Kelly O'Hair wrote: >>> All changes to JDK sources require a CR, an OpenJDK author name, and a review by a second OpenJDK author. >>> So although you can automate the preparation of the commit, you cannot fully automate this process. >>> >>> There have been many discussions over the years about automating various changes, anything from tag generation, >>> to whitespace normalization, and this copyright year change issue. >>> Our policy has been that changesets need human authors, and all changes need a human review. >> >> I think that is the tail wagging the dog. A simple change to a year value in a comment by a sanctioned pre/post commit script can easily be accommodated in the changeset for a given CR just as-if the engineer had done it themselves. In the SCCS days we didn't require reviews for sccs tag updates in file headers - I don't see that copyright update should be any different. If we need to tweak the OpenJDK rules then lets tweak them. > > But in SCCS days, you still needed an identity on the change, an informal review, and a human to trigger the putback. It would be no different with hg. In SCCS days you would only see the sccs variable in the code. The update only happens when you "commit". In neither case do the reviewers see the actual change; in both cases there is an identity on the change and a human doing it. Anyway I prefer manual updates with a jcheck check. There are times when a change does not necessitate an update to the copyright year (mainly changes to the copyright notice itself) but these are rare. Cheers, David > It is true that in the SCCS days there was less red tape, but in the SCCS days there was much less tracking of > all changes, and identities could be fictitious. The SCCS history was generally worthless. > >> >> Personally I don't see why it is so hard to have engineers be responsible for this (if automation is considered so problematic). It only affects one changeset per file per year and a pre-commit script (or jcheck enhancement?) could warn you if you forget to do the update. I find these big periodic changesets far more noisy and problematic. >> > > The only issue would be that warnings tend to be ignored by most developers, but I could accept this idea. > If jcheck blocked the commit when it detected a missing year change, that would force the edit before the > changeset would be created, or before the changeset was integrated. > However, I'm not exactly sure we could make the copyright year check that concrete, maybe, it's not as > cut and dried as the whitespace check jcheck does. > >> For the general audience: copyright years only get updated when there is a substantive change to the material content of a file. I think we well and truly established that when we went through the Sun to Oracle conversion process. > > Yes. There are very rare situations where a file can change, and that change should not trigger a year update. > So by default, we treat any change to a file as being one that needs a year update. > > --- > Just to clarify it for others: > And there are 2 years. The first year is the initial creation, the second year is the year of last change. > When they are the same, one year will be listed in the legal notice. > It's very important to preserve that first year, or year of creation. > > -kto > >> >> David >> >>> -kto >>> >>> On Nov 2, 2012, at 9:51 AM, Darryl Mocek wrote: >>> >>>> So the 3000+ files Alan is referring to are all files which have been modified but which haven't had their year updated? If we're not worried about files which haven't been modified then a pre/post-commit script will suffice and depending on how we implement it we might not need periodic updates. >>>> >>>> Darryl >>>> >>>> On 11/02/2012 09:47 AM, Phil Race wrote: >>>>>> but ultimately there are files which never get touched which will need processing to update the year. >>>>> >>>>> The policy has varied over the years, but presently the policy is not to >>>>> update the year in files that have not been updated code-wise. >>>>> >>>>> -phil. >>>>> >>>>> On 11/2/2012 9:37 AM, Darryl Mocek wrote: >>>>>> Alan, >>>>>> >>>>>> I was responsible for updating the copyrights for JavaME. I used a Perl script to update the copyright year in the source files. I can point you to the relevant information if you like. There were challenges as there are various copyrights in the source files (Oracle, Oracle + 3rd-party, 3rd party only, and no copyright), all with different formats, and even within the Oracle copyrights, people used subtle differences which caused difficulties. I ended updating all copyrights to a few formats and adding a post-commit script which scrubbed the copyright and notified the committer if the copyright wasn't in the correct format and didn't have an ending year (or sole year) which is the current year. >>>>>> >>>>>> There are plenty of options here: >>>>>> >>>>>> - Do nothing (policy) >>>>>> - Pre-commit script which changes the year automatically >>>>>> - Pre-commit script which rejects commit with wrong year >>>>>> - Post-commit script which flags a bad copyright, but accepts commit >>>>>> - Others >>>>>> >>>>>> Updating the copyright year as you commit is a good habit to get into, but ultimately there are files which never get touched which will need processing to update the year. I think doing this at the end/beginning of the year is good, we just need to make sure we get the copyright correct when processing. >>>>>> >>>>>> Darryl >>>>>> >>>>>> On 11/02/2012 05:46 AM, Alan Bateman wrote: >>>>>>> >>>>>>> Now for some noise. >>>>>>> >>>>>>> The copyright date in the source files needs updating. The man behind the curtain is Steve Sides from the Quality and Release Engineering team in Oracle. Jon pushed, on Steve's behalf, the update to the langtools files recently [1], and Mikael updated hotspot [2]. The elephant is the jdk repository as there are 3000+ files that need their headers updated. >>>>>>> >>>>>>> To keep the disruption to a minimum I propose that we do the jdk repository in two steps: non-client area now to jdk8/tl, and then the client-area later in jdk8/awt once the changes get there. I use the term "client-area" loosely to mean the source files for awt, swing, font, java2d, etc. (and I appreciate that there is also a jdk8/2d forest in use). To that end here is the proposed patch for today: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~alanb/7197491/copyright.patch >>>>>>> >>>>>>> This patch updates the headers on 2370 files. I don't propose to publish a webrev as it's just too big. >>>>>>> >>>>>>> This patch was created with: >>>>>>> >>>>>>> cd jdk >>>>>>> sh ../make/scripts/update_copyright_year.sh 2011 >>>>>>> sh ../make/scripts/update_copyright_year.sh 2012 >>>>>>> hg revert --no-backup `cat clientdirs.list` >>>>>>> hg diff -g> copyright.patch >>>>>>> >>>>>>> where clientdirs.list is most of the directories corresponding to the client area. >>>>>>> >>>>>>> Note that I ran the update_copyright_year.sh script twice, once for 2011 and then a second time for 2012. The reason for this is that there are several hundred files in the jdk repository that were last updated in 2011 but have an older date on the header. >>>>>>> >>>>>>> Reviewer welcome but I should say that I don't have cycles to spend on this. Also the patch has an a very short shelf life. >>>>>>> >>>>>>> Finally, I think that there needs to be wider discussion as to how to keep the headers from falling behind too much. Some people do update the headers when editing files, some people (including myself) do not. It seems to me that it should be done regularly anyway, perhaps every few months or at integration time every so often. >>>>>>> >>>>>>> -Alan. >>>>>>> >>>>>>> [1] http://hg.openjdk.java.net/jdk8/tl/langtools/rev/9d47f4850714 >>>>>>> [2] http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/b9a9ed0f8eeb >>>>>> >>>>> >>>> >>> > From lana.steuck at oracle.com Wed Nov 7 04:15:53 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 07 Nov 2012 04:15:53 +0000 Subject: hg: jdk8/tl/corba: 4 new changesets Message-ID: <20121107041557.A09FD477DA@hg.openjdk.java.net> Changeset: de2b8def2be5 Author: ohair Date: 2012-10-26 14:24 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/de2b8def2be5 8000992: Update new build-infra makefiles Summary: Build-infra project integration. Multiple authors on this work: erikj and ihse primarily, also changes from ohair, tbell, and dholmes. Special credit to ohstrom for his smartjavac work. Reviewed-by: erikj, ihse, dholmes, tbell + makefiles/BuildCorba.gmk ! makefiles/Makefile Changeset: 6ccbf67b68bf Author: katleman Date: 2012-10-31 18:30 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/6ccbf67b68bf Merge Changeset: b450c07849ab Author: katleman Date: 2012-11-01 14:11 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/b450c07849ab Added tag jdk8-b63 for changeset 6ccbf67b68bf ! .hgtags Changeset: 54d599a5b4aa Author: lana Date: 2012-11-02 17:54 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/54d599a5b4aa Merge From lana.steuck at oracle.com Wed Nov 7 04:15:53 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 07 Nov 2012 04:15:53 +0000 Subject: hg: jdk8/tl: 7 new changesets Message-ID: <20121107041554.6382F477D8@hg.openjdk.java.net> Changeset: e64f2cb57d05 Author: ohair Date: 2012-10-26 14:29 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/e64f2cb57d05 8000992: Update new build-infra makefiles Summary: Build-infra project integration. Multiple authors on this work: erikj and ihse primarily, also changes from ohair, tbell, and dholmes. Special credit to ohstrom for his smartjavac work. Reviewed-by: erikj, ihse, dholmes, tbell ! NewMakefile.gmk ! common/autoconf/autogen.sh ! common/autoconf/basics.m4 + common/autoconf/basics_windows.m4 ! common/autoconf/boot-jdk.m4 ! common/autoconf/build-aux/config.guess ! common/autoconf/build-performance.m4 ! common/autoconf/builddeps.m4 ! common/autoconf/closed.version.numbers ! common/autoconf/compare.sh.in ! common/autoconf/configure ! common/autoconf/configure.ac ! common/autoconf/generated-configure.sh ! common/autoconf/help.m4 ! common/autoconf/hotspot-spec.gmk.in ! common/autoconf/jdk-options.m4 ! common/autoconf/libraries.m4 ! common/autoconf/platform.m4 ! common/autoconf/spec.gmk.in ! common/autoconf/toolchain.m4 + common/autoconf/toolchain_windows.m4 ! common/autoconf/version.numbers + common/bin/compare.sh + common/bin/compare_exceptions.sh.incl - common/bin/compareimage.sh - common/bin/diffexec.sh - common/bin/diffjarzip.sh - common/bin/difflib.sh - common/bin/difftext.sh - common/bin/exception_list_linux - common/bin/extractvcvars.sh ! common/bin/hide_important_warnings_from_javac.sh ! common/bin/logger.sh + common/bin/shell-tracer.sh - common/bin/unicode2x.sed ! common/makefiles/HotspotWrapper.gmk ! common/makefiles/IdlCompilation.gmk ! common/makefiles/JavaCompilation.gmk + common/makefiles/Main.gmk ! common/makefiles/MakeBase.gmk ! common/makefiles/MakeHelpers.gmk ! common/makefiles/Makefile ! common/makefiles/NativeCompilation.gmk ! common/makefiles/RMICompilation.gmk - common/makefiles/compress.post - common/makefiles/compress.pre + common/makefiles/support/ListPathsSafely-post-compress.incl + common/makefiles/support/ListPathsSafely-pre-compress.incl + common/makefiles/support/ListPathsSafely-uncompress.sed + common/makefiles/support/unicode2x.sed - common/makefiles/uncompress.sed + common/src/fixpath.c - common/src/uncygdrive.c + configure Changeset: e3182741ade2 Author: ihse Date: 2012-10-29 14:06 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/e3182741ade2 8001897: build-infra: misc adjustments to configure script Reviewed-by: ohair ! common/autoconf/Makefile.in ! common/autoconf/basics.m4 ! common/autoconf/generated-configure.sh ! common/autoconf/jdk-options.m4 ! common/autoconf/spec.gmk.in ! common/autoconf/toolchain.m4 Changeset: 3229597524ca Author: katleman Date: 2012-10-31 18:30 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/3229597524ca Merge - common/bin/compareimage.sh - common/bin/diffexec.sh - common/bin/diffjarzip.sh - common/bin/difflib.sh - common/bin/difftext.sh - common/bin/exception_list_linux - common/bin/extractvcvars.sh - common/bin/unicode2x.sed - common/makefiles/compress.post - common/makefiles/compress.pre - common/makefiles/uncompress.sed - common/src/uncygdrive.c Changeset: cababb9dfce7 Author: katleman Date: 2012-11-01 14:10 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/cababb9dfce7 Added tag jdk8-b63 for changeset 3229597524ca ! .hgtags Changeset: dd1a80efa7cf Author: anthony Date: 2012-10-30 15:04 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/rev/dd1a80efa7cf 8001764: vsvars.sh should support VS2012 Summary: Update the vsvars.sh script to support VS2012 Reviewed-by: ohair, tbell ! make/scripts/vsvars.sh Changeset: fc61be4ff6ae Author: lana Date: 2012-10-31 09:12 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/fc61be4ff6ae Merge ! make/scripts/vsvars.sh Changeset: 65dca75b2a26 Author: lana Date: 2012-11-02 17:32 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/65dca75b2a26 Merge From lana.steuck at oracle.com Wed Nov 7 04:15:53 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 07 Nov 2012 04:15:53 +0000 Subject: hg: jdk8/tl/hotspot: Added tag jdk8-b63 for changeset acabb5c282f5 Message-ID: <20121107041557.0A911477D9@hg.openjdk.java.net> Changeset: 4d37eb50b9b1 Author: katleman Date: 2012-11-01 14:11 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/4d37eb50b9b1 Added tag jdk8-b63 for changeset acabb5c282f5 ! .hgtags From lana.steuck at oracle.com Wed Nov 7 04:16:00 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 07 Nov 2012 04:16:00 +0000 Subject: hg: jdk8/tl/jaxws: 3 new changesets Message-ID: <20121107041607.B1E46477DC@hg.openjdk.java.net> Changeset: c30a7cb5c587 Author: ohair Date: 2012-10-26 14:25 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/c30a7cb5c587 8000992: Update new build-infra makefiles Summary: Build-infra project integration. Multiple authors on this work: erikj and ihse primarily, also changes from ohair, tbell, and dholmes. Special credit to ohstrom for his smartjavac work. Reviewed-by: erikj, ihse, dholmes, tbell + makefiles/BuildJaxws.gmk ! makefiles/Makefile Changeset: 86989f702267 Author: katleman Date: 2012-10-31 18:30 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/86989f702267 Merge Changeset: 5ded18a14bcc Author: katleman Date: 2012-11-01 14:11 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/5ded18a14bcc Added tag jdk8-b63 for changeset 86989f702267 ! .hgtags From lana.steuck at oracle.com Wed Nov 7 04:15:57 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 07 Nov 2012 04:15:57 +0000 Subject: hg: jdk8/tl/jaxp: 3 new changesets Message-ID: <20121107041605.C6876477DB@hg.openjdk.java.net> Changeset: 121fc928a361 Author: ohair Date: 2012-10-26 14:25 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/121fc928a361 8000992: Update new build-infra makefiles Summary: Build-infra project integration. Multiple authors on this work: erikj and ihse primarily, also changes from ohair, tbell, and dholmes. Special credit to ohstrom for his smartjavac work. Reviewed-by: erikj, ihse, dholmes, tbell + makefiles/BuildJaxp.gmk ! makefiles/Makefile Changeset: 192d8a244bc3 Author: katleman Date: 2012-10-31 18:30 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/192d8a244bc3 Merge Changeset: 27ab79568c34 Author: katleman Date: 2012-11-01 14:11 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/27ab79568c34 Added tag jdk8-b63 for changeset 192d8a244bc3 ! .hgtags From lana.steuck at oracle.com Wed Nov 7 04:16:05 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 07 Nov 2012 04:16:05 +0000 Subject: hg: jdk8/tl/langtools: 5 new changesets Message-ID: <20121107041616.6DD3C477DD@hg.openjdk.java.net> Changeset: 741cce355ba6 Author: ohair Date: 2012-10-26 14:25 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/741cce355ba6 8000992: Update new build-infra makefiles Summary: Build-infra project integration. Multiple authors on this work: erikj and ihse primarily, also changes from ohair, tbell, and dholmes. Special credit to ohstrom for his smartjavac work. Reviewed-by: erikj, ihse, dholmes, tbell + makefiles/BuildLangtools.gmk ! makefiles/Makefile Changeset: 92e6f2190ca0 Author: katleman Date: 2012-10-31 18:36 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/92e6f2190ca0 Merge Changeset: 26831b6fcc4a Author: katleman Date: 2012-11-01 14:13 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/26831b6fcc4a Added tag jdk8-b63 for changeset 92e6f2190ca0 ! .hgtags Changeset: e6ee43b3e247 Author: lana Date: 2012-11-02 17:55 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/e6ee43b3e247 Merge - src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DirectoryManager.java - src/share/classes/com/sun/tools/doclets/internal/toolkit/util/SourcePath.java - src/share/classes/com/sun/tools/javac/code/TypeTags.java Changeset: 6dc8616cea9b Author: lana Date: 2012-11-06 18:41 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/6dc8616cea9b Merge From lana.steuck at oracle.com Wed Nov 7 04:17:37 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 07 Nov 2012 04:17:37 +0000 Subject: hg: jdk8/tl/jdk: 24 new changesets Message-ID: <20121107042216.EB073477DE@hg.openjdk.java.net> Changeset: 64dd2aba6d33 Author: ohair Date: 2012-10-26 14:23 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/64dd2aba6d33 8000992: Update new build-infra makefiles Summary: Build-infra project integration. Multiple authors on this work: erikj and ihse primarily, also changes from ohair, tbell, and dholmes. Special credit to ohstrom for his smartjavac work. Reviewed-by: erikj, ihse, dholmes, tbell + makefiles/BuildJdk.gmk + makefiles/Bundles.gmk ! makefiles/CompileDemos.gmk ! makefiles/CompileJavaClasses.gmk ! makefiles/CompileLaunchers.gmk ! makefiles/CompileNativeLibraries.gmk ! makefiles/CopyFiles.gmk ! makefiles/CopyIntoClasses.gmk ! makefiles/CreateJars.gmk ! makefiles/GendataBreakIterator.gmk ! makefiles/GendataFontConfig.gmk ! makefiles/GendataHtml32dtd.gmk ! makefiles/GenerateClasses.gmk ! makefiles/GenerateJavaSources.gmk ! makefiles/GensrcBuffer.gmk ! makefiles/GensrcCLDR.gmk ! makefiles/GensrcCharacterData.gmk ! makefiles/GensrcCharsetCoder.gmk ! makefiles/GensrcCharsetMapping.gmk ! makefiles/GensrcExceptions.gmk ! makefiles/GensrcIcons.gmk ! makefiles/GensrcJDWP.gmk ! makefiles/GensrcJObjC.gmk ! makefiles/GensrcLocaleDataMetaInfo.gmk ! makefiles/GensrcMisc.gmk ! makefiles/GensrcProperties.gmk ! makefiles/GensrcSwing.gmk ! makefiles/GensrcX11Wrappers.gmk ! makefiles/Images.gmk ! makefiles/Import.gmk ! makefiles/Makefile ! makefiles/Tools.gmk - makefiles/docs/CORE_PKGS.gmk - makefiles/docs/Makefile - makefiles/docs/NON_CORE_PKGS.gmk - makefiles/docs/Notes.html - makefiles/mapfiles/launchers/mapfile-amd64 - makefiles/mapfiles/launchers/mapfile-i586 - makefiles/mapfiles/libawt_headless/reorder-i586 - makefiles/mapfiles/libjava/reorder-i586 - makefiles/mapfiles/libjpeg/reorder-i586 - makefiles/mapfiles/libnio/mapfile-bsd - makefiles/mapfiles/libnio/reorder-i586 - makefiles/mapfiles/libverify/reorder-i586 - makefiles/mapfiles/libzip/reorder-i586 + makefiles/sun/awt/X11/ToBin.java + makefiles/sun/osxapp/ToBin.java - makefiles/sun/xawt/ToBin.java Changeset: 5b29d6157504 Author: erikj Date: 2012-10-29 13:04 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5b29d6157504 8001887: build-infra: Correct mapfiles in build-infra area Reviewed-by: ohair ! makefiles/mapfiles/libnio/mapfile-linux ! makefiles/mapfiles/libnio/mapfile-macosx ! makefiles/mapfiles/libnio/mapfile-solaris Changeset: dcee387cde81 Author: ohrstrom Date: 2012-10-29 13:41 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/dcee387cde81 8001891: build-infra: Adding X_CFLAGS and X_LIBS to lwawt and sizer compilation Reviewed-by: ohair ! makefiles/CompileNativeLibraries.gmk ! makefiles/GensrcX11Wrappers.gmk Changeset: 524d1a705f7b Author: erikj Date: 2012-10-29 13:55 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/524d1a705f7b 8001898: build-infra: correct exclusion lists for mac jar builds 8001896: build-infra: UNLIMITED_CRYPTO changes Reviewed-by: ohair ! makefiles/CreateJars.gmk Changeset: f117a3e06f78 Author: katleman Date: 2012-10-31 18:35 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f117a3e06f78 Merge ! makefiles/CompileLaunchers.gmk ! makefiles/CompileNativeLibraries.gmk ! makefiles/CreateJars.gmk - makefiles/docs/CORE_PKGS.gmk - makefiles/docs/Makefile - makefiles/docs/NON_CORE_PKGS.gmk - makefiles/docs/Notes.html - makefiles/mapfiles/launchers/mapfile-amd64 - makefiles/mapfiles/launchers/mapfile-i586 - makefiles/mapfiles/libawt_headless/reorder-i586 - makefiles/mapfiles/libjava/reorder-i586 - makefiles/mapfiles/libjpeg/reorder-i586 - makefiles/mapfiles/libnio/mapfile-bsd - makefiles/mapfiles/libnio/reorder-i586 - makefiles/mapfiles/libverify/reorder-i586 - makefiles/mapfiles/libzip/reorder-i586 - makefiles/sun/xawt/ToBin.java Changeset: 7ac292e57b5a Author: katleman Date: 2012-11-01 14:12 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7ac292e57b5a Added tag jdk8-b63 for changeset f117a3e06f78 ! .hgtags Changeset: cc998992dc32 Author: bae Date: 2012-10-24 05:30 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cc998992dc32 7053526: Upgrade JDK 8 to use Little CMS 2.4 Reviewed-by: prr, jgodinez ! make/sun/cmm/lcms/FILES_c_unix.gmk ! make/sun/cmm/lcms/FILES_c_windows.gmk ! src/share/native/sun/java2d/cmm/lcms/cmscam02.c ! src/share/native/sun/java2d/cmm/lcms/cmscgats.c ! src/share/native/sun/java2d/cmm/lcms/cmscnvrt.c ! src/share/native/sun/java2d/cmm/lcms/cmserr.c ! src/share/native/sun/java2d/cmm/lcms/cmsgamma.c ! src/share/native/sun/java2d/cmm/lcms/cmsgmt.c + src/share/native/sun/java2d/cmm/lcms/cmshalf.c ! src/share/native/sun/java2d/cmm/lcms/cmsintrp.c ! src/share/native/sun/java2d/cmm/lcms/cmsio0.c ! src/share/native/sun/java2d/cmm/lcms/cmsio1.c ! src/share/native/sun/java2d/cmm/lcms/cmslut.c ! src/share/native/sun/java2d/cmm/lcms/cmsmd5.c ! src/share/native/sun/java2d/cmm/lcms/cmsmtrx.c ! src/share/native/sun/java2d/cmm/lcms/cmsnamed.c ! src/share/native/sun/java2d/cmm/lcms/cmsopt.c ! src/share/native/sun/java2d/cmm/lcms/cmspack.c ! src/share/native/sun/java2d/cmm/lcms/cmspcs.c ! src/share/native/sun/java2d/cmm/lcms/cmsplugin.c ! src/share/native/sun/java2d/cmm/lcms/cmsps2.c ! src/share/native/sun/java2d/cmm/lcms/cmssamp.c ! src/share/native/sun/java2d/cmm/lcms/cmssm.c ! src/share/native/sun/java2d/cmm/lcms/cmstypes.c ! src/share/native/sun/java2d/cmm/lcms/cmsvirt.c ! src/share/native/sun/java2d/cmm/lcms/cmswtpnt.c ! src/share/native/sun/java2d/cmm/lcms/cmsxform.c ! src/share/native/sun/java2d/cmm/lcms/lcms2.h ! src/share/native/sun/java2d/cmm/lcms/lcms2_internal.h ! src/share/native/sun/java2d/cmm/lcms/lcms2_plugin.h Changeset: 00c8ea9ef1cf Author: lana Date: 2012-10-31 09:49 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/00c8ea9ef1cf Merge - src/share/classes/sun/net/www/protocol/gopher/GopherClient.java - src/share/classes/sun/net/www/protocol/gopher/Handler.java - src/share/classes/sun/security/tools/CertAndKeyGen.java - src/share/classes/sun/security/tools/JarSigner.java - src/share/classes/sun/security/tools/JarSignerResources.java - src/share/classes/sun/security/tools/JarSignerResources_ja.java - src/share/classes/sun/security/tools/JarSignerResources_zh_CN.java - src/share/classes/sun/security/tools/KeyTool.java - src/share/classes/sun/security/tools/TimestampedSigner.java - src/windows/classes/java/io/Win32FileSystem.java - src/windows/native/java/io/Win32FileSystem_md.c - test/com/sun/jndi/ldap/LdapsReadTimeoutTest.java - test/com/sun/jndi/ldap/ReadTimeoutTest.java Changeset: c9523d220bc3 Author: lana Date: 2012-11-02 17:32 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c9523d220bc3 Merge Changeset: 3b889d1218f5 Author: alitvinov Date: 2012-10-24 18:27 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3b889d1218f5 7193219: JComboBox serialization fails in JDK 1.7 Reviewed-by: rupashka, anthony ! src/share/classes/javax/swing/AncestorNotifier.java + test/javax/swing/AncestorNotifier/7193219/bug7193219.java Changeset: c27efe7615f8 Author: bagiras Date: 2012-10-25 09:55 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c27efe7615f8 8000486: REGRESSION: Three java2d tests fail since jdk8b58 on Windows 7 with NullPointerException Reviewed-by: flar, art ! src/windows/classes/sun/java2d/ScreenUpdateManager.java Changeset: 9fb5db444365 Author: bagiras Date: 2012-10-25 19:50 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9fb5db444365 7082294: nsk/regression/b4265661 crashes on windows Reviewed-by: art, anthony ! src/windows/native/sun/windows/awt_Font.cpp ! src/windows/native/sun/windows/awt_Toolkit.cpp Changeset: 7ead109417f0 Author: serb Date: 2012-10-29 23:10 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7ead109417f0 7198229: Painting during resizing of the frame should be more smooth Reviewed-by: anthony, denis, skovatch ! src/macosx/classes/sun/lwawt/LWWindowPeer.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/macosx/native/sun/awt/AWTView.m ! src/macosx/native/sun/java2d/opengl/CGLLayer.m Changeset: 884402437aad Author: kshefov Date: 2012-10-30 12:47 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/884402437aad 7072120: No mac os x support in several regression tests Reviewed-by: anthony, serb ! test/java/awt/Toolkit/AutoShutdown/ShowExitTest/ShowExitTest.sh ! test/java/awt/appletviewer/IOExceptionIfEncodedURLTest/IOExceptionIfEncodedURLTest.sh ! test/javax/imageio/stream/StreamCloserLeak/run_test.sh Changeset: 6652efb69459 Author: lana Date: 2012-10-31 09:25 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6652efb69459 Merge - src/share/classes/sun/net/www/protocol/gopher/GopherClient.java - src/share/classes/sun/net/www/protocol/gopher/Handler.java - src/share/classes/sun/security/tools/CertAndKeyGen.java - src/share/classes/sun/security/tools/JarSigner.java - src/share/classes/sun/security/tools/JarSignerResources.java - src/share/classes/sun/security/tools/JarSignerResources_ja.java - src/share/classes/sun/security/tools/JarSignerResources_zh_CN.java - src/share/classes/sun/security/tools/KeyTool.java - src/share/classes/sun/security/tools/TimestampedSigner.java - src/windows/classes/java/io/Win32FileSystem.java - src/windows/native/java/io/Win32FileSystem_md.c - test/com/sun/jndi/ldap/LdapsReadTimeoutTest.java - test/com/sun/jndi/ldap/ReadTimeoutTest.java Changeset: 9b5c596a2920 Author: VKARNAUK Date: 2012-11-02 15:57 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9b5c596a2920 2229575: Swing HTML parser can't properly decode codepoints outside the Unicode Plane 0 into a surrogate pair Reviewed-by: rupashka ! src/share/classes/javax/swing/text/html/parser/Parser.java + test/javax/swing/text/html/parser/Parser/6836089/bug6836089.java Changeset: 3d22bd7d6678 Author: alexp Date: 2012-11-02 16:14 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3d22bd7d6678 8001633: Wrong alt processing during switching between windows. Reviewed-by: ant, leonidr Contributed-by: Mikhail Cherkasov ! src/share/classes/com/sun/java/swing/plaf/windows/WindowsRootPaneUI.java ! src/share/classes/java/awt/event/KeyEvent.java ! src/share/classes/sun/awt/AWTAccessor.java + test/javax/swing/plaf/windows/WindowsRootPaneUI/WrongAltProcessing/WrongAltProcessing.java Changeset: 094c963dca1b Author: leonidr Date: 2012-11-02 19:20 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/094c963dca1b 7124310: [macosx] "opposite" seems always null in focus events Reviewed-by: anthony ! src/macosx/classes/sun/lwawt/LWWindowPeer.java ! src/macosx/classes/sun/lwawt/macosx/CEmbeddedFrame.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformResponder.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java ! src/macosx/native/sun/awt/AWTWindow.h ! src/macosx/native/sun/awt/AWTWindow.m Changeset: f4a11601680b Author: leonidr Date: 2012-11-02 19:47 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f4a11601680b 8002114: fix failed for JDK-7160951: [macosx] ActionListener called twice for JMenuItem using ScreenMenuBar Reviewed-by: serb ! src/macosx/native/sun/awt/CMenuItem.m Changeset: 509b3b4910ef Author: kshefov Date: 2012-11-02 17:05 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/509b3b4910ef 8001808: Create a test for 8000327 Reviewed-by: alexsch, serb + test/javax/swing/JMenuItem/ActionListenerCalledTwice/ActionListenerCalledTwiceTest.java Changeset: 706056a4a6d9 Author: kshefov Date: 2012-11-02 17:07 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/706056a4a6d9 8001876: Create regtest for 8000283 Reviewed-by: alexsch, serb + test/javax/swing/JMenuItem/ShortcutNotDiplayed/ShortcutNotDisplayedTest.java Changeset: ebd8f16bae1b Author: lana Date: 2012-11-02 17:34 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ebd8f16bae1b Merge Changeset: 6ffd64541a6c Author: lana Date: 2012-11-02 17:44 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6ffd64541a6c Merge - make/sun/jdbc/Makefile ! makefiles/CompileJavaClasses.gmk ! makefiles/CompileNativeLibraries.gmk ! makefiles/CopyIntoClasses.gmk ! makefiles/CreateJars.gmk ! makefiles/GendataBreakIterator.gmk ! makefiles/GensrcLocaleDataMetaInfo.gmk ! makefiles/GensrcMisc.gmk ! makefiles/GensrcSwing.gmk ! makefiles/mapfiles/libnio/mapfile-linux ! makefiles/mapfiles/libnio/mapfile-macosx ! makefiles/mapfiles/libnio/mapfile-solaris - src/solaris/native/java/io/FileSystem_md.c - src/windows/native/java/io/FileSystem_md.c ! test/javax/imageio/stream/StreamCloserLeak/run_test.sh Changeset: c9fd61d23dbe Author: lana Date: 2012-11-06 18:41 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c9fd61d23dbe Merge - makefiles/docs/CORE_PKGS.gmk - makefiles/docs/Makefile - makefiles/docs/NON_CORE_PKGS.gmk - makefiles/docs/Notes.html - makefiles/mapfiles/launchers/mapfile-amd64 - makefiles/mapfiles/launchers/mapfile-i586 - makefiles/mapfiles/libawt_headless/reorder-i586 - makefiles/mapfiles/libjava/reorder-i586 - makefiles/mapfiles/libjpeg/reorder-i586 - makefiles/mapfiles/libnio/mapfile-bsd - makefiles/mapfiles/libnio/reorder-i586 - makefiles/mapfiles/libverify/reorder-i586 - makefiles/mapfiles/libzip/reorder-i586 - makefiles/sun/xawt/ToBin.java From david.holmes at oracle.com Wed Nov 7 05:08:26 2012 From: david.holmes at oracle.com (David Holmes) Date: Wed, 07 Nov 2012 15:08:26 +1000 Subject: XS RFR: 8002040 Allow Full Debug Symbols when cross-compiling Message-ID: <5099ECCA.2070901@oracle.com> webrev: http://cr.openjdk.java.net/~dholmes/8002040/webrev/ This is a simplified variant of the change just made to Hotspot. Instead of disabling FDS when cross-compiling we change the default location of objcopy, and just as with native compilation either the default objcopy is found or we try to fallback to ALT_OBJCOPY if set. In other words the only difference between the two cases is the chosen default. (Arguably both cases could just use COMPILER_PATH/objcopy but that might change existing behaviour in some cases - which we do not want to do). I will push this via the build repo. There are no corresponding changes needed to the new build as it handles FDS differently. This only impacts Linux. Thanks, David From weijun.wang at oracle.com Wed Nov 7 06:13:31 2012 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Wed, 07 Nov 2012 06:13:31 +0000 Subject: hg: jdk8/tl/jdk: 6355584: Introduce constrained Kerberos delegation Message-ID: <20121107061342.AAE57477E1@hg.openjdk.java.net> Changeset: a1bbb8805e22 Author: weijun Date: 2012-11-07 14:13 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a1bbb8805e22 6355584: Introduce constrained Kerberos delegation Reviewed-by: valeriep + src/share/classes/com/sun/security/jgss/ExtendedGSSCredential.java ! src/share/classes/sun/security/jgss/GSSCaller.java ! src/share/classes/sun/security/jgss/GSSCredentialImpl.java ! src/share/classes/sun/security/jgss/HttpCaller.java ! src/share/classes/sun/security/jgss/krb5/Krb5AcceptCredential.java ! src/share/classes/sun/security/jgss/krb5/Krb5Context.java ! src/share/classes/sun/security/jgss/krb5/Krb5InitCredential.java + src/share/classes/sun/security/jgss/krb5/Krb5ProxyCredential.java ! src/share/classes/sun/security/jgss/krb5/Krb5Util.java ! src/share/classes/sun/security/jgss/spi/GSSCredentialSpi.java ! src/share/classes/sun/security/jgss/spnego/SpNegoContext.java ! src/share/classes/sun/security/jgss/spnego/SpNegoCredElement.java ! src/share/classes/sun/security/jgss/wrapper/GSSCredElement.java ! src/share/classes/sun/security/krb5/Credentials.java ! src/share/classes/sun/security/krb5/EncryptedData.java ! src/share/classes/sun/security/krb5/KrbApReq.java ! src/share/classes/sun/security/krb5/KrbKdcRep.java ! src/share/classes/sun/security/krb5/KrbTgsRep.java ! src/share/classes/sun/security/krb5/KrbTgsReq.java ! src/share/classes/sun/security/krb5/internal/CredentialsUtil.java ! src/share/classes/sun/security/krb5/internal/EncKDCRepPart.java ! src/share/classes/sun/security/krb5/internal/KDCOptions.java ! src/share/classes/sun/security/krb5/internal/Krb5.java ! src/share/classes/sun/security/krb5/internal/PAData.java + src/share/classes/sun/security/krb5/internal/PAForUserEnc.java ! src/share/classes/sun/security/krb5/internal/crypto/KeyUsage.java ! src/share/classes/sun/security/krb5/internal/ktab/KeyTab.java ! test/sun/security/krb5/auto/Basic.java ! test/sun/security/krb5/auto/Context.java ! test/sun/security/krb5/auto/CrossRealm.java ! test/sun/security/krb5/auto/KDC.java ! test/sun/security/krb5/auto/OkAsDelegate.java + test/sun/security/krb5/auto/S4U2proxy.java + test/sun/security/krb5/auto/S4U2proxyGSS.java + test/sun/security/krb5/auto/S4U2self.java + test/sun/security/krb5/auto/S4U2selfAsServer.java + test/sun/security/krb5/auto/S4U2selfAsServerGSS.java + test/sun/security/krb5/auto/S4U2selfGSS.java From zhouyx at linux.vnet.ibm.com Wed Nov 7 08:31:24 2012 From: zhouyx at linux.vnet.ibm.com (Sean Chou) Date: Wed, 7 Nov 2012 16:31:24 +0800 Subject: Request for review: 7201156 : jar tool fails to convert file separation characters for list and extract Message-ID: Hello, This is the suggested fix described in sun bug 7201156 page. Please take a look. sunbug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7201156 webrev: http://cr.openjdk.java.net/~zhouyx/7201156/webrev.00/ -- Best Regards, Sean Chou From Alan.Bateman at oracle.com Wed Nov 7 10:05:52 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 07 Nov 2012 10:05:52 +0000 Subject: Request for review: 7201156 : jar tool fails to convert file separation characters for list and extract In-Reply-To: References: Message-ID: <509A3280.1010603@oracle.com> On 07/11/2012 08:31, Sean Chou wrote: > Hello, > > This is the suggested fix described in sun bug 7201156 page. Please take a > look. > > sunbug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7201156 > webrev: http://cr.openjdk.java.net/~zhouyx/7201156/webrev.00/ > Looks like this was missed during the review of 6332094 [1]. I think the change is fine, but I think it would be useful to have a test too. -Alan [1] http://hg.openjdk.java.net/jdk7/tl/jdk/rev/13d7e2477737 From chris.hegarty at oracle.com Wed Nov 7 10:16:40 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 07 Nov 2012 10:16:40 +0000 Subject: Request for review: 7201156 : jar tool fails to convert file separation characters for list and extract In-Reply-To: References: Message-ID: <509A3508.3010205@oracle.com> The change looks fine to me. I wonder if it is worth creating an automatic regression test to verify this change ( so an future regression in behavior gets caught early ). You could call sun.tools.jar.Main directly passing suitable streams to check the output. -Chris. On 07/11/2012 08:31, Sean Chou wrote: > Hello, > > This is the suggested fix described in sun bug 7201156 page. Please take a > look. > > sunbug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7201156 > webrev: http://cr.openjdk.java.net/~zhouyx/7201156/webrev.00/ > From peter.levart at gmail.com Wed Nov 7 10:39:31 2012 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 07 Nov 2012 11:39:31 +0100 Subject: bottleneck by java.lang.Class.getAnnotations() - a better patch In-Reply-To: <5099C2FA.2020202@oracle.com> References: <924D06EC-F603-4E6A-A7FE-7A05C77B1217@gmail.com> <23313EDE-3AB7-4E53-8EB1-A6F6CC9383B9@gmail.com> <5093A8D3.4030800@gmail.com> <5096CFBD.2010604@gmail.com> <5096F5B0.8070304@gmail.com> <50974D3D.1040502@oracle.com> <50990CB8.2040400@gmail.com> <5099C2FA.2020202@oracle.com> Message-ID: <509A3A63.5010102@gmail.com> On 11/07/2012 03:10 AM, David Holmes wrote: > Hi Peter, > > The movement of the reflection caches to a helper object is exactly > what I had previously proposed here (some differences in the details > of course): > > http://cr.openjdk.java.net/~dholmes/JEP-149/webrev/ > > and discussed here: > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-April/009749.html > > > but this did not touch the annotations fields. > > David Hi David, Thanks for the pointer. There is a discussion between Brian and you (to quote some of it): On 5/04/2012 1:28 PM, Brian Goetz wrote: >/ Reducing the number of SoftReferences in ReflectionHelper also seems an />/ attractive target for memory reduction. Rather than eight soft />/ references (eight extra objects), maintaining a SoftRef to the entire />/ RH, or at least to the part of the RH that is currently SR'ed if the two />/ non-SR'ed fields can't be recomputed, would save you a whole pile of />/ objects per class (and might also reduce pressure on GC, having 8x fewer />/ SRs to process.) / I'd have to consider the intended semantics of these soft references before considering any change here. It would hard to predict how this might impact runtime performance if we have coarser-grained soft references. The current changes should be semantically null. >/ Finally, you may be able save an extra field per Class by storing the />/ ReflectionHelper in a ClassValue on Java SE 8, rather than a field. / ClassValue is something I'm keeping an eye on, but an entry in ClassValue is going to consume more dynamic memory than a single direct field. Thanks, David ...the 8 SoftReferences refer to arrays which are never hard referenced by the outside world (arrays are always defensively copied), so it's reasonable to expect that all SoftReferences would be cleared at the same time anyway. And if 8 SoftReferences are replaced with 1, the worst case scenario (to quote Hinkmond Wong): Hi Brian, One of the issues we have in the Java Embedded group (as David points out in his summary), is that while on paper the theoretical max savings seems great (as you point out also), in practice as David points out in his note, this might be a wash if there are a lot more reflection using classes vs. non-reflection using classes in "typical" real-world applications, not the low or zero reflection using class ratio that happens in the theoretical "best case". So, a question comes up if we should judge the merit of this change on the theoretical "best case" scenario, or should we judge it on real-world applicability to "typical" apps (such as a finite set of customer surveyed embedded apps that we feel represent a real-world scenario). Thanks, Hinkmond ...actually becomes even more favourable. We reduce huge overhead (each SoftReference is 4 OOPs and 1 long). And if this single SoftReference is ever cleared, more memory is released - the whole structure (ReflectionHelper / VolatileData) Other differences in details between your proposal and mine: In your proposal, the method ReflectionHelper rh() is equivalent to mine VolatileData volatileData() - it lazily constructs the structure and returns it. My implementation also incorporates the logic of clearCachesOnClassRedefinition() by returning and installing a new instance of the structure in case a redefinition is detected. This has a profound impact on the correctness of the cached data in face of races that can occur. In your proposal, even if the VM could atomically publish changes to raw reflection data and the classRedefinitionCount at the same time (we hope that at least the order of publishing is such that classRedefinitionCount is updated last), it can theoretically be that 2 or more redefinitions of the same class happen in close proximity: VM thread: redefines the class to version=1 thread 1: clears the cache and takes version=1 raw data and computes derived data but gets pre-empted before installing it VM thread: redefines the class to version=2 thread 2: clears the cache and takes version=2 raw data and computes derived data and installs it thread 1: ...gets back and installs version=1 derived data over version=2 data ...if there are no more class redefinitions, the stale version of derived data can persist indefinitely. In my proposal, each thread will get it's own copy of the structure in the above scenario and install the derived data into it. It can happen that a particular instance of the structure does not represent a "snapshot" view of the world, but that is not important, since that particular inconsistent instance is only used for the in-flight call and only in that part that is consistent. Other callers will get a fresh instance. There is also one thing I overlooked and you haven't: the cachedConstructor and newInstanceCallerCache fields. I'll have to look at how to incorporate them into my scheme. They are currently neither SoftReferenced nor cleared at class redefinition. As the cachedConstructor is only used to implement the .newInstance() method, I wonder if it is safe not to clear it when the class is redefined. Are old versions of Constructors still valid for invoking in a redefined class? I guess they must be, since user code is free to cache it's own versions and class redefinition should not prevent invoking them... Since cachedConstructor/newInstanceCallerCache are used to optimize .newInstance() method. That alone suggests that calling this method is more common use-case than others. Perhaps leaving this pair of fields out of the game is a better approach space-saving wise. Regards, Peter > > On 6/11/2012 11:12 PM, Peter Levart wrote: >> On 11/05/2012 06:23 AM, David Holmes wrote: >>> Hi Peter, >>> >>> Moving the annotations fields into a helper object would tie in with >>> the Class-instance size reduction effort that was investigated as part >>> of "JEP 149: Reduce Core-Library Memory Usage": >>> >>> http://openjdk.java.net/jeps/149 >>> >>> The investigations there to date only looked at relocating the >>> reflection related fields, though the JEP mentions the annotations as >>> well. >>> >>> Any such effort requires extensive benchmarking and performance >>> analysis before being accepted though. >>> >>> David >>> ----- >>> >> >> On 11/05/2012 10:25 AM, Alan Bateman wrote: >>> Here's a good starting place on the interaction of runtime visible >>> attributes and RedefineClasses/RetransformClasses: >>> >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5002251 >>> >>> -Alan. >> >> Hi all, >> >> Presented here is a patch mainly against java.lang.Class and also >> against java.lang.reflect.[Field,Method,Constructor,Executable] classes. >> >> Currently java.lang.Class uses the following fields to maintain caches >> of reflection data that are invalidated as a result of class or >> superclass redefinition/re-transformation: >> >> private volatile transient SoftReference declaredFields; >> private volatile transient SoftReference publicFields; >> private volatile transient SoftReference declaredMethods; >> private volatile transient SoftReference publicMethods; >> private volatile transient SoftReference[]> >> declaredConstructors; >> private volatile transient SoftReference[]> >> publicConstructors; >> private volatile transient SoftReference declaredPublicFields; >> private volatile transient SoftReference >> declaredPublicMethods; >> >> // Value of classRedefinedCount when we last cleared the cached values >> // that are sensitive to class redefinition. >> private volatile transient int lastRedefinedCount = 0; >> >> // Annotations cache >> private transient Map, Annotation> >> annotations; >> private transient Map, Annotation> >> declaredAnnotations; >> >> If I understand Alan's references correctly, current VM can redefine the >> class in a way that changes method bodies. Also new methods can be >> added. And the set of annotations can also be altered. And future >> improvements could allow even more. >> >> Because annotations are cached on Field/Method/Constructor instances, >> all the above fields must be invalidated when the class or superclass is >> redefined. >> >> It can also be observed that Field/Method/Constructor caches are >> maintained using SoftReferences but annotations are hard references. I >> don't know if this is intentional. I believe that annotations could also >> be SoftReferenced, so that in the event of memory pressure they get >> cleared. Many applications retrieve annotations only in the early stages >> of their life-cycle and then either cache them themselves or forget >> about them. >> >> So I designed the patch to equalize this. If this is undesirable, the >> patch could be modified to make a distinction again. >> >> The patch replaces the above-mentioned java.lang.Class fields with a >> single field: >> >> private volatile transient SoftReference> volatileData; >> >> ...which is a SoftReference to the following structure: >> >> // volatile data that might get invalid when JVM TI RedefineClasses() is >> called >> static class VolatileData { >> volatile Field[] declaredFields; >> volatile Field[] publicFields; >> volatile Method[] declaredMethods; >> volatile Method[] publicMethods; >> volatile Constructor[] declaredConstructors; >> volatile Constructor[] publicConstructors; >> // Intermediate results for getFields and getMethods >> volatile Field[] declaredPublicFields; >> volatile Method[] declaredPublicMethods; >> // Annotations >> volatile Map, Annotation> annotations; >> volatile Map, Annotation> >> declaredAnnotations; >> // Value of classRedefinedCount when we created this VolatileData >> instance >> final int redefinedCount; >> >> So let's look at static overhead differences using 64 bit addressing >> (useful load - arrays, Maps not counted since the patched code uses the >> same amount of same types of each). >> >> * Fresh java.lang.Class instance: >> >> current JDK8 code: >> >> 10 OOPs + 1 int = 10*8+4 = 84 bytes in 1 instance >> >> vs. patched code : >> >> 1 OOP = 8 bytes in 1 instance >> >> * Fully loaded java.lang.Class (Fields, Methods, Constructors, >> annotations): >> >> current JDK8 code: >> >> 10 OOPs + 1 int = 84 bytes >> 8 SoftReference instances = 8*(header + 4 OOPs + 1 long) = 8*(24+32+8) = >> 8*64 = 512 bytes >> total: 84+512 = 596 bytes in 9 instances >> >> vs. patched code : >> >> 1 OOP = 8 bytes >> 1 SoftReference = 64 bytes >> 1 VolatileData = header + 10 OOPs + 1 int = 24+84 = 108 bytes >> total: 8+64+108 = 180 bytes in 3 instances >> >> So we have 84 vs. 8 (empty) or 596 vs. 180 (fully loaded) byte >> overheads and >> 1 vs. 1 (empty) or 9 vs. 3 (fully loaded) instance overheads >> >> Other than that, the patch also removes synchronized blocks for lazy >> initialization of annotations in Class, Field, Method and Constructor >> and replaces them with volatile fields. In case of Class.volatileData, >> this field is initialized using a CAS so there is no race which could >> install an already stale instance over more recent. Although such race >> would quickly be corrected at next call to any retrieval method, because >> redefinedCount is now an integral part of the cached structure not an >> individual volatile field. >> >> There is also a change in how annotations are cached in Field, Method >> and Constructor. Originally they are cached in each copy of the >> Field/Method/Constructor that is returned to the outside world at each >> invocation of Class.getFields() etc. Such caching is not very effective >> if the annotations are only retrieved once per instance. The patch >> changes this and delegates caching to the "root" instance which is held >> inside Class so caching becomes more effective in certain usage >> patterns. There's now a possible hot-spot on the "root" instance but >> that seems not to be a bottleneck since the fast-path does not involve >> blocking synchronization (just volatile read). The effects of this >> change are clearly visible in one of the benchmarks. >> >> I have tried to create 3 micro benchmarks which exercise concurrent load >> on 3 Class instances. >> >> Here's the benchmark code: >> >> https://raw.github.com/plevart/jdk8-hacks/master/src/test/ReflectionTest.java >> >> >> And here are the results when run on an Intel i7 CPU (4 cores, 2 >> threads/core) Linux machine using -Xmx4G VM option: >> >> https://raw.github.com/plevart/jdk8-hacks/master/benchmark_results.txt >> >> >> The huge difference of Test1 results is a direct consequence of patched >> code delegating caching of annotations in Field/Method/Constructor to >> the "root" instance. >> >> Test2 results show no noticeable difference between original and patched >> code. This, I believe, is the most common usage of the API, so another >> level of indirection does not appear to present any noticeable >> performance overhead. >> >> The Test3 on the other hand shows the synchronization overhead of >> current jdk8 code in comparison with non-blocking synchronization in >> patched code. >> >> JEP 149 also mentions testing with SPECjbb2005 and SPECjvm98, but that >> exceeds my possibilities. >> >> The patch against jdk8/jdk8/jdk hg repository is here: >> >> https://raw.github.com/plevart/jdk8-hacks/master/volatile_class_data_caching.patch >> >> >> You can also browse the changed sources: >> >> https://github.com/plevart/jdk8-hacks >> >> >> Regards, Peter >> From chris.hegarty at oracle.com Wed Nov 7 10:50:15 2012 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Wed, 07 Nov 2012 10:50:15 +0000 Subject: hg: jdk8/tl/jdk: 8001579: Cleanup warnings in security native code Message-ID: <20121107105113.6F469477ED@hg.openjdk.java.net> Changeset: 59e88d3b9b17 Author: jzavgren Date: 2012-11-07 10:49 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/59e88d3b9b17 8001579: Cleanup warnings in security native code Reviewed-by: chegar, alanb, vinnie ! src/share/native/sun/security/jgss/wrapper/GSSLibStub.c ! src/share/native/sun/security/jgss/wrapper/NativeUtil.c ! src/share/native/sun/security/pkcs11/wrapper/p11_convert.c ! src/share/native/sun/security/pkcs11/wrapper/p11_crypt.c ! src/share/native/sun/security/pkcs11/wrapper/p11_digest.c ! src/share/native/sun/security/pkcs11/wrapper/p11_general.c ! src/share/native/sun/security/pkcs11/wrapper/p11_sessmgmt.c ! src/share/native/sun/security/pkcs11/wrapper/p11_sign.c ! src/share/native/sun/security/pkcs11/wrapper/p11_util.c ! src/solaris/native/sun/security/pkcs11/j2secmod_md.c ! src/solaris/native/sun/security/pkcs11/wrapper/p11_md.c From weijun.wang at oracle.com Wed Nov 7 10:58:11 2012 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 07 Nov 2012 18:58:11 +0800 Subject: Cannot build jdk7u-dev Message-ID: <509A3EC3.1030009@oracle.com> I've just synced with jdk7u-dev and now it does not build. symbol: class TimedWindowEvent location: class SunToolkit ../../../src/share/classes/sun/awt/SunToolkit.java:472: error: cannot find symbol TimedWindowEvent twe = (TimedWindowEvent)nested; ^ symbol: class TimedWindowEvent location: class SunToolkit It seems there is no class called TimedWindowEvent. I am building the jdk repo only. Thanks Max From chris.hegarty at oracle.com Wed Nov 7 12:06:11 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 07 Nov 2012 12:06:11 +0000 Subject: (Spec Review) 8002356: Add ForkJoin common pool and CountedCompleted Message-ID: <509A4EB3.8080206@oracle.com> I would like to start review discussion of the spec changes to ForkJoinXXX ( add a default common pool, task tags, and other minor updates ), and the addition of CountedCompleter, as part of part of JEP 155 [1]. These changes are of course coming form Doug and the JSR 166 EG members. I have done a quick sanity review, and the changes reflect what is in Doug's CVS. I need to spend more time reviewing myself, others on the list have more experience with these new API already and may have valuable feedback. Depending on how the discussion goes, this thread may have to move/include the concurrency-interest list, but I think we at least need to get things started here. http://cr.openjdk.java.net/~chegar/8002356/specdiff/java/util/concurrent/package-summary.html -Chris. [1] http://openjdk.java.net/jeps/155 From staffan.larsen at oracle.com Wed Nov 7 12:39:25 2012 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 7 Nov 2012 13:39:25 +0100 Subject: Preliminary review: Adding tracing of I/O calls In-Reply-To: <50968608.3060206@oracle.com> References: <22767084-EAC2-4D87-800B-3E5E5BFC666A@oracle.com> <5094476D.3090501@oracle.com> <63FAA509-60DF-43F0-8A98-8D1B2BA3FA37@oracle.com> <50968608.3060206@oracle.com> Message-ID: <9BD4B213-4E29-47BD-BAA3-DEFF4F87D90D@oracle.com> On 4 nov 2012, at 16:13, Alan Bateman wrote: > On 04/11/2012 12:50, Staffan Larsen wrote: >> : >>> I realize the focus is blocking I/O for now but one thing to know is that timed read operations on socket adapters (the socket obtained by calling SocketChannel's socket method) configures the socket channel to be non-blocking so this means that this I/O will not be observed by the IoTraceListener. >> I need some help to understand which call path you are referring to here. I see SocketChannelImpl.socket() returning a SocketAdapter, but I don't see how/if this is Socket is configured to be non-blocking. > Socket s = sc.socket(); > s.setSoTimeout(5*1000); > int n = s.getInputStream().read(ba); > > This read is a blocking read, it's just that the underlying socket channel will be non-blocking so it will not be observed by the IoTraceListener. > > This shouldn't be too common and might not be a big concern but I just wanted to point it out. Ah, now I see what you mean. Tricky code :-) I've added instrumentation to this path as well. Thanks, /Staffan From Vincent.X.Ryan at Oracle.Com Wed Nov 7 12:51:14 2012 From: Vincent.X.Ryan at Oracle.Com (Vincent Ryan) Date: Wed, 7 Nov 2012 12:51:14 +0000 Subject: Fake DNS query result inside a test In-Reply-To: <5099B3C4.90506@oracle.com> References: <5099B3C4.90506@oracle.com> Message-ID: Are you suggesting to run a local DNS server? If so then it is easy to access that via a JNDI context. If you're proposing developing a basic JNDI service provider then that would be more effort. On 7 Nov 2012, at 01:05, Weijun Wang wrote: > Hi Vinnie > > I want to write a regression test so that > > Context ctx = NamingManager.getURLContext("dns", new Hashtable<>(0)); > Attributes attrs =((DirContext)ctx).getAttributes( > "_kerberos._udp.ASDF.COM.", SRV_RR_ATTR); > > can return some entries without querying a real external server. > > Is this possible by registering a local name server provider or else? > > Thanks > Max From staffan.larsen at oracle.com Wed Nov 7 12:55:20 2012 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 7 Nov 2012 13:55:20 +0100 Subject: Preliminary review: Adding tracing of I/O calls In-Reply-To: <50965EB9.90509@oracle.com> References: <22767084-EAC2-4D87-800B-3E5E5BFC666A@oracle.com> <50942931.4000001@oracle.com> <08183803-2563-461C-9514-B7FAE1E14C10@oracle.com> <509437F0.4020409@oracle.com> <50965EB9.90509@oracle.com> Message-ID: <4DA42ED5-601F-4FA1-8378-D3F105D82C31@oracle.com> An update on performance. I have written microbenchmarks for file and socket i/o and compared the results before my suggested changes and after. FileChannelRead -4.06% FileChannelWrite -1.06% FileInputStream 0.92% FileOutputStream 1.32% RandomAccessFileRead 1.66% RandomAccessFileWrite 0.76% SocketChannelReadWrite 0.75% SocketReadWrite 0.89% Negative values means that my changes added a regression. I think most of these values are within the margin of error in the measurements. The one exception is FileChannelRead. I've rerun this many times and it looks fairly consistent around a 4% regression. Why there is only a regression when reading from a FileChannel, I don't know. The 4% number is too high I think and as a result I'm looking at alternative implementations. As a first experiment I tried changing IoTrace.fileReadBegin/End into something like this: public static final boolean ENABLED = Boolean.getProperty("iotrace.enabled"); public static IoTraceContext fileReadBegin(String path) { if (ENABLED) { ... } return null; } This got the regression down to 2%. Still not good. Removing all implementation from fileReadBegin/End gets me on par with the non-instrumented version. It looks like some form of dynamic class redefinition is need here. We could start out with empty implementations of the methods in IoTrace, and redefine the class to one that has implementations when tracing is enabled. /Staffan On 4 nov 2012, at 13:25, Aleksey Shipilev wrote: > On 11/03/2012 01:15 AM, Mandy Chung wrote: >> On 11/2/2012 1:47 PM, Staffan Larsen wrote: >>> On 2 nov 2012, at 21:12, Mandy Chung wrote: >>> >>>> The *Begin() methods return a "handle" that will be passed to the >>>> *End() methods. Have you considered to define a type for it rather >>>> than Object? >>> Something like an empty interface, just to signal the intent? >> >> Yes I think so. A marker interface would suffice. >> >>>> Do you have any performance measurement result that you can share? >>> I don't yet have any specific numbers - I'll try to get some. The >>> testing I have done indicates that the overhead is negligible. But it >>> would be good to confirm this. >> >> refworkload is easy to run. You probably have talked with the >> performance team. You can find out from them which benchmarks, if they >> have any, are applicable for IO instrumentation. > > Performance team here. > > There are virtually no benchmarks against I/O per se. Looking at the > patch, I would think anything doing intensive network I/O would help to > quantify the change, which boils down to SPECjbb2012, SPECjEnterprise, > and Volano. First two would be hard to run, and the third has terrible > run-to-run variance, so you will probably have to quantify the changes > with microbenchmarks. It should be easy enough to construct with our > micro harness (still not available in OpenJDK). Contact me internally if > you want to get that route. > > General patch review: I do have the preoccupation against interferenced > tracing code, and while appreciating the intent for tracing patch, we > need to look for performance penalties. The rule of thumb is that > HotSpot will optimize away the code guarded by static final flag (or, as > Remi points out with jsr292 magic). Doing the calls hoping for HotSpot > to inline and figure out the absence of useful work there is not working > reliably either. Inline conditionals will cost something if the tracing > method is not inlined. > > Hence, I would rather recommend to switch the uses like this: > > public int read() throws IOException { > Object traceHandle = IoTrace.fileReadBegin(path); > int b = read0(); > IoTrace.fileReadEnd(traceHandle, b == -1 ? -1 : 1); > return b; > } > > ...to something more like: > > public int read() throws IOException { > if (IoTrace.ENABLED) { > Object traceHandle = IoTrace.fileReadBegin(path); > int b = read0(); > IoTrace.fileReadEnd(traceHandle, b == -1 ? -1 : 1); > return b; > } else { > return read0(); > } > } > > where > > class IoTrace { > public static final boolean ENABLED = > System.getProperty("java.io.trace"); > } > > ...which will demote the flexibility of setListener(), but have much > lower runtime overhead. This should be confirmed by microbenchmarking > anyway. > > -Aleksey. From dl at cs.oswego.edu Wed Nov 7 13:51:59 2012 From: dl at cs.oswego.edu (Doug Lea) Date: Wed, 07 Nov 2012 08:51:59 -0500 Subject: (Spec Review) 8002356: Add ForkJoin common pool and CountedCompleted In-Reply-To: <509A4EB3.8080206@oracle.com> References: <509A4EB3.8080206@oracle.com> Message-ID: <509A677F.30306@cs.oswego.edu> On 11/07/12 07:06, Chris Hegarty wrote: > I would like to start review discussion of the spec changes to ForkJoinXXX ( add > a default common pool, task tags, and other minor updates ), and the addition of > CountedCompleter, as part of part of JEP 155 [1]. Please hang on a while longer. The common pool updates enabled addressing issues mainly including the very long wakeup times sometimes seen on power-managed, core-fused, and oddly scheduled platforms, but I haven't yet checked in all the corresponding changes because I'm still testing, and will then want Aleksey to help confirm impact on lambda-libs before fully committing. ETA is still about a week. -Doug From vitalyd at gmail.com Wed Nov 7 13:53:57 2012 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Wed, 7 Nov 2012 08:53:57 -0500 Subject: Preliminary review: Adding tracing of I/O calls In-Reply-To: <4DA42ED5-601F-4FA1-8378-D3F105D82C31@oracle.com> References: <22767084-EAC2-4D87-800B-3E5E5BFC666A@oracle.com> <50942931.4000001@oracle.com> <08183803-2563-461C-9514-B7FAE1E14C10@oracle.com> <509437F0.4020409@oracle.com> <50965EB9.90509@oracle.com> <4DA42ED5-601F-4FA1-8378-D3F105D82C31@oracle.com> Message-ID: Staffan, When you say you removed all implementation from fileBeginRead, do you mean you just return null instead of doing the ENABLED check? Does making ENABLED private yield zero-cost? May give JIT more confidence that this field isn't modified via reflection from outside. The other option is to have two separate implementations of the callback mechanism hidden inside IOTrace calls. At static init time, you pick one based on ENABLED. If not enabled you use an empty method that just returns null. The JIT should handle this case well. Sent from my phone On Nov 7, 2012 7:56 AM, "Staffan Larsen" wrote: > An update on performance. I have written microbenchmarks for file and > socket i/o and compared the results before my suggested changes and after. > > FileChannelRead -4.06% > FileChannelWrite -1.06% > FileInputStream 0.92% > FileOutputStream 1.32% > RandomAccessFileRead 1.66% > RandomAccessFileWrite 0.76% > SocketChannelReadWrite 0.75% > SocketReadWrite 0.89% > > Negative values means that my changes added a regression. I think most of > these values are within the margin of error in the measurements. The one > exception is FileChannelRead. I've rerun this many times and it looks > fairly consistent around a 4% regression. Why there is only a regression > when reading from a FileChannel, I don't know. > > The 4% number is too high I think and as a result I'm looking at > alternative implementations. As a first experiment I tried changing > IoTrace.fileReadBegin/End into something like this: > > public static final boolean ENABLED = > Boolean.getProperty("iotrace.enabled"); > > public static IoTraceContext fileReadBegin(String path) { > if (ENABLED) { > ... > } > return null; > } > > This got the regression down to 2%. Still not good. > > Removing all implementation from fileReadBegin/End gets me on par with the > non-instrumented version. > > It looks like some form of dynamic class redefinition is need here. We > could start out with empty implementations of the methods in IoTrace, and > redefine the class to one that has implementations when tracing is enabled. > > > /Staffan > > On 4 nov 2012, at 13:25, Aleksey Shipilev > wrote: > > > On 11/03/2012 01:15 AM, Mandy Chung wrote: > >> On 11/2/2012 1:47 PM, Staffan Larsen wrote: > >>> On 2 nov 2012, at 21:12, Mandy Chung wrote: > >>> > >>>> The *Begin() methods return a "handle" that will be passed to the > >>>> *End() methods. Have you considered to define a type for it rather > >>>> than Object? > >>> Something like an empty interface, just to signal the intent? > >> > >> Yes I think so. A marker interface would suffice. > >> > >>>> Do you have any performance measurement result that you can share? > >>> I don't yet have any specific numbers - I'll try to get some. The > >>> testing I have done indicates that the overhead is negligible. But it > >>> would be good to confirm this. > >> > >> refworkload is easy to run. You probably have talked with the > >> performance team. You can find out from them which benchmarks, if they > >> have any, are applicable for IO instrumentation. > > > > Performance team here. > > > > There are virtually no benchmarks against I/O per se. Looking at the > > patch, I would think anything doing intensive network I/O would help to > > quantify the change, which boils down to SPECjbb2012, SPECjEnterprise, > > and Volano. First two would be hard to run, and the third has terrible > > run-to-run variance, so you will probably have to quantify the changes > > with microbenchmarks. It should be easy enough to construct with our > > micro harness (still not available in OpenJDK). Contact me internally if > > you want to get that route. > > > > General patch review: I do have the preoccupation against interferenced > > tracing code, and while appreciating the intent for tracing patch, we > > need to look for performance penalties. The rule of thumb is that > > HotSpot will optimize away the code guarded by static final flag (or, as > > Remi points out with jsr292 magic). Doing the calls hoping for HotSpot > > to inline and figure out the absence of useful work there is not working > > reliably either. Inline conditionals will cost something if the tracing > > method is not inlined. > > > > Hence, I would rather recommend to switch the uses like this: > > > > public int read() throws IOException { > > Object traceHandle = IoTrace.fileReadBegin(path); > > int b = read0(); > > IoTrace.fileReadEnd(traceHandle, b == -1 ? -1 : 1); > > return b; > > } > > > > ...to something more like: > > > > public int read() throws IOException { > > if (IoTrace.ENABLED) { > > Object traceHandle = IoTrace.fileReadBegin(path); > > int b = read0(); > > IoTrace.fileReadEnd(traceHandle, b == -1 ? -1 : 1); > > return b; > > } else { > > return read0(); > > } > > } > > > > where > > > > class IoTrace { > > public static final boolean ENABLED = > > System.getProperty("java.io.trace"); > > } > > > > ...which will demote the flexibility of setListener(), but have much > > lower runtime overhead. This should be confirmed by microbenchmarking > > anyway. > > > > -Aleksey. > > From staffan.larsen at oracle.com Wed Nov 7 13:57:19 2012 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 7 Nov 2012 14:57:19 +0100 Subject: Preliminary review: Adding tracing of I/O calls In-Reply-To: References: <22767084-EAC2-4D87-800B-3E5E5BFC666A@oracle.com> <50942931.4000001@oracle.com> <08183803-2563-461C-9514-B7FAE1E14C10@oracle.com> <509437F0.4020409@oracle.com> <50965EB9.90509@oracle.com> <4DA42ED5-601F-4FA1-8378-D3F105D82C31@oracle.com> Message-ID: <0BDC1398-D644-4D49-9308-A5705D610CF7@oracle.com> On 7 nov 2012, at 14:53, Vitaly Davidovich wrote: > Staffan, > > When you say you removed all implementation from fileBeginRead, do you mean you just return null instead of doing the ENABLED check? > Yes. > Does making ENABLED private yield zero-cost? May give JIT more confidence that this field isn't modified via reflection from outside. > Sorry, that was a typo in my email, the field was private in my tests. /Staffan > The other option is to have two separate implementations of the callback mechanism hidden inside IOTrace calls. At static init time, you pick one based on ENABLED. If not enabled you use an empty method that just returns null. The JIT should handle this case well. > > > Sent from my phone > > On Nov 7, 2012 7:56 AM, "Staffan Larsen" wrote: > An update on performance. I have written microbenchmarks for file and socket i/o and compared the results before my suggested changes and after. > > FileChannelRead -4.06% > FileChannelWrite -1.06% > FileInputStream 0.92% > FileOutputStream 1.32% > RandomAccessFileRead 1.66% > RandomAccessFileWrite 0.76% > SocketChannelReadWrite 0.75% > SocketReadWrite 0.89% > > Negative values means that my changes added a regression. I think most of these values are within the margin of error in the measurements. The one exception is FileChannelRead. I've rerun this many times and it looks fairly consistent around a 4% regression. Why there is only a regression when reading from a FileChannel, I don't know. > > The 4% number is too high I think and as a result I'm looking at alternative implementations. As a first experiment I tried changing IoTrace.fileReadBegin/End into something like this: > > public static final boolean ENABLED = Boolean.getProperty("iotrace.enabled"); > > public static IoTraceContext fileReadBegin(String path) { > if (ENABLED) { > ... > } > return null; > } > > This got the regression down to 2%. Still not good. > > Removing all implementation from fileReadBegin/End gets me on par with the non-instrumented version. > > It looks like some form of dynamic class redefinition is need here. We could start out with empty implementations of the methods in IoTrace, and redefine the class to one that has implementations when tracing is enabled. > > > /Staffan > > On 4 nov 2012, at 13:25, Aleksey Shipilev wrote: > > > On 11/03/2012 01:15 AM, Mandy Chung wrote: > >> On 11/2/2012 1:47 PM, Staffan Larsen wrote: > >>> On 2 nov 2012, at 21:12, Mandy Chung wrote: > >>> > >>>> The *Begin() methods return a "handle" that will be passed to the > >>>> *End() methods. Have you considered to define a type for it rather > >>>> than Object? > >>> Something like an empty interface, just to signal the intent? > >> > >> Yes I think so. A marker interface would suffice. > >> > >>>> Do you have any performance measurement result that you can share? > >>> I don't yet have any specific numbers - I'll try to get some. The > >>> testing I have done indicates that the overhead is negligible. But it > >>> would be good to confirm this. > >> > >> refworkload is easy to run. You probably have talked with the > >> performance team. You can find out from them which benchmarks, if they > >> have any, are applicable for IO instrumentation. > > > > Performance team here. > > > > There are virtually no benchmarks against I/O per se. Looking at the > > patch, I would think anything doing intensive network I/O would help to > > quantify the change, which boils down to SPECjbb2012, SPECjEnterprise, > > and Volano. First two would be hard to run, and the third has terrible > > run-to-run variance, so you will probably have to quantify the changes > > with microbenchmarks. It should be easy enough to construct with our > > micro harness (still not available in OpenJDK). Contact me internally if > > you want to get that route. > > > > General patch review: I do have the preoccupation against interferenced > > tracing code, and while appreciating the intent for tracing patch, we > > need to look for performance penalties. The rule of thumb is that > > HotSpot will optimize away the code guarded by static final flag (or, as > > Remi points out with jsr292 magic). Doing the calls hoping for HotSpot > > to inline and figure out the absence of useful work there is not working > > reliably either. Inline conditionals will cost something if the tracing > > method is not inlined. > > > > Hence, I would rather recommend to switch the uses like this: > > > > public int read() throws IOException { > > Object traceHandle = IoTrace.fileReadBegin(path); > > int b = read0(); > > IoTrace.fileReadEnd(traceHandle, b == -1 ? -1 : 1); > > return b; > > } > > > > ...to something more like: > > > > public int read() throws IOException { > > if (IoTrace.ENABLED) { > > Object traceHandle = IoTrace.fileReadBegin(path); > > int b = read0(); > > IoTrace.fileReadEnd(traceHandle, b == -1 ? -1 : 1); > > return b; > > } else { > > return read0(); > > } > > } > > > > where > > > > class IoTrace { > > public static final boolean ENABLED = > > System.getProperty("java.io.trace"); > > } > > > > ...which will demote the flexibility of setListener(), but have much > > lower runtime overhead. This should be confirmed by microbenchmarking > > anyway. > > > > -Aleksey. > From chris.hegarty at oracle.com Wed Nov 7 13:59:11 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 07 Nov 2012 13:59:11 +0000 Subject: (Spec Review) 8002356: Add ForkJoin common pool and CountedCompleted In-Reply-To: <509A677F.30306@cs.oswego.edu> References: <509A4EB3.8080206@oracle.com> <509A677F.30306@cs.oswego.edu> Message-ID: <509A692F.4040402@oracle.com> On 07/11/2012 13:51, Doug Lea wrote: > On 11/07/12 07:06, Chris Hegarty wrote: >> I would like to start review discussion of the spec changes to >> ForkJoinXXX ( add >> a default common pool, task tags, and other minor updates ), and the >> addition of >> CountedCompleter, as part of part of JEP 155 [1]. > > Please hang on a while longer. The common pool updates enabled addressing > issues mainly including the very long wakeup times sometimes seen on > power-managed, core-fused, and oddly scheduled platforms, but I haven't > yet checked in all the corresponding changes because I'm still testing, > and will then want Aleksey to help confirm impact on lambda-libs > before fully committing. ETA is still about a week. No problem. I just wanted to start the discussion around the spec changes. Let's postpone this for a week or so. -Chris. > > -Doug > > From vitalyd at gmail.com Wed Nov 7 14:02:13 2012 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Wed, 7 Nov 2012 09:02:13 -0500 Subject: Preliminary review: Adding tracing of I/O calls In-Reply-To: <0BDC1398-D644-4D49-9308-A5705D610CF7@oracle.com> References: <22767084-EAC2-4D87-800B-3E5E5BFC666A@oracle.com> <50942931.4000001@oracle.com> <08183803-2563-461C-9514-B7FAE1E14C10@oracle.com> <509437F0.4020409@oracle.com> <50965EB9.90509@oracle.com> <4DA42ED5-601F-4FA1-8378-D3F105D82C31@oracle.com> <0BDC1398-D644-4D49-9308-A5705D610CF7@oracle.com> Message-ID: OK, just after I sent the email I realized public/private won't really give JIT more confidence. I'd try the two different impls approach though. It does introduce more types to load but if that's not an issue, I think perf should be good. At least worth trying for curiosity's sake. :) Sent from my phone On Nov 7, 2012 8:57 AM, "Staffan Larsen" wrote: > > On 7 nov 2012, at 14:53, Vitaly Davidovich wrote: > > Staffan, > > When you say you removed all implementation from fileBeginRead, do you > mean you just return null instead of doing the ENABLED check? > > Yes. > > Does making ENABLED private yield zero-cost? May give JIT more confidence > that this field isn't modified via reflection from outside. > > Sorry, that was a typo in my email, the field was private in my tests. > > /Staffan > > The other option is to have two separate implementations of the callback > mechanism hidden inside IOTrace calls. At static init time, you pick one > based on ENABLED. If not enabled you use an empty method that just returns > null. The JIT should handle this case well. > > Sent from my phone > On Nov 7, 2012 7:56 AM, "Staffan Larsen" > wrote: > >> An update on performance. I have written microbenchmarks for file and >> socket i/o and compared the results before my suggested changes and after. >> >> FileChannelRead -4.06% >> FileChannelWrite -1.06% >> FileInputStream 0.92% >> FileOutputStream 1.32% >> RandomAccessFileRead 1.66% >> RandomAccessFileWrite 0.76% >> SocketChannelReadWrite 0.75% >> SocketReadWrite 0.89% >> >> Negative values means that my changes added a regression. I think most of >> these values are within the margin of error in the measurements. The one >> exception is FileChannelRead. I've rerun this many times and it looks >> fairly consistent around a 4% regression. Why there is only a regression >> when reading from a FileChannel, I don't know. >> >> The 4% number is too high I think and as a result I'm looking at >> alternative implementations. As a first experiment I tried changing >> IoTrace.fileReadBegin/End into something like this: >> >> public static final boolean ENABLED = >> Boolean.getProperty("iotrace.enabled"); >> >> public static IoTraceContext fileReadBegin(String path) { >> if (ENABLED) { >> ... >> } >> return null; >> } >> >> This got the regression down to 2%. Still not good. >> >> Removing all implementation from fileReadBegin/End gets me on par with >> the non-instrumented version. >> >> It looks like some form of dynamic class redefinition is need here. We >> could start out with empty implementations of the methods in IoTrace, and >> redefine the class to one that has implementations when tracing is enabled. >> >> >> /Staffan >> >> On 4 nov 2012, at 13:25, Aleksey Shipilev >> wrote: >> >> > On 11/03/2012 01:15 AM, Mandy Chung wrote: >> >> On 11/2/2012 1:47 PM, Staffan Larsen wrote: >> >>> On 2 nov 2012, at 21:12, Mandy Chung wrote: >> >>> >> >>>> The *Begin() methods return a "handle" that will be passed to the >> >>>> *End() methods. Have you considered to define a type for it rather >> >>>> than Object? >> >>> Something like an empty interface, just to signal the intent? >> >> >> >> Yes I think so. A marker interface would suffice. >> >> >> >>>> Do you have any performance measurement result that you can share? >> >>> I don't yet have any specific numbers - I'll try to get some. The >> >>> testing I have done indicates that the overhead is negligible. But it >> >>> would be good to confirm this. >> >> >> >> refworkload is easy to run. You probably have talked with the >> >> performance team. You can find out from them which benchmarks, if they >> >> have any, are applicable for IO instrumentation. >> > >> > Performance team here. >> > >> > There are virtually no benchmarks against I/O per se. Looking at the >> > patch, I would think anything doing intensive network I/O would help to >> > quantify the change, which boils down to SPECjbb2012, SPECjEnterprise, >> > and Volano. First two would be hard to run, and the third has terrible >> > run-to-run variance, so you will probably have to quantify the changes >> > with microbenchmarks. It should be easy enough to construct with our >> > micro harness (still not available in OpenJDK). Contact me internally if >> > you want to get that route. >> > >> > General patch review: I do have the preoccupation against interferenced >> > tracing code, and while appreciating the intent for tracing patch, we >> > need to look for performance penalties. The rule of thumb is that >> > HotSpot will optimize away the code guarded by static final flag (or, as >> > Remi points out with jsr292 magic). Doing the calls hoping for HotSpot >> > to inline and figure out the absence of useful work there is not working >> > reliably either. Inline conditionals will cost something if the tracing >> > method is not inlined. >> > >> > Hence, I would rather recommend to switch the uses like this: >> > >> > public int read() throws IOException { >> > Object traceHandle = IoTrace.fileReadBegin(path); >> > int b = read0(); >> > IoTrace.fileReadEnd(traceHandle, b == -1 ? -1 : 1); >> > return b; >> > } >> > >> > ...to something more like: >> > >> > public int read() throws IOException { >> > if (IoTrace.ENABLED) { >> > Object traceHandle = IoTrace.fileReadBegin(path); >> > int b = read0(); >> > IoTrace.fileReadEnd(traceHandle, b == -1 ? -1 : 1); >> > return b; >> > } else { >> > return read0(); >> > } >> > } >> > >> > where >> > >> > class IoTrace { >> > public static final boolean ENABLED = >> > System.getProperty("java.io.trace"); >> > } >> > >> > ...which will demote the flexibility of setListener(), but have much >> > lower runtime overhead. This should be confirmed by microbenchmarking >> > anyway. >> > >> > -Aleksey. >> >> > From aleksey.shipilev at oracle.com Wed Nov 7 14:04:00 2012 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Wed, 07 Nov 2012 09:04:00 -0500 Subject: Preliminary review: Adding tracing of I/O calls In-Reply-To: <4DA42ED5-601F-4FA1-8378-D3F105D82C31@oracle.com> References: <22767084-EAC2-4D87-800B-3E5E5BFC666A@oracle.com> <50942931.4000001@oracle.com> <08183803-2563-461C-9514-B7FAE1E14C10@oracle.com> <509437F0.4020409@oracle.com> <50965EB9.90509@oracle.com> <4DA42ED5-601F-4FA1-8378-D3F105D82C31@oracle.com> Message-ID: <509A6A50.5070203@oracle.com> On 11/07/2012 07:55 AM, Staffan Larsen wrote: > An update on performance. I have written microbenchmarks for file and > socket i/o and compared the results before my suggested changes and > after. > > FileChannelRead -4.06% FileChannelWrite -1.06% > FileInputStream 0.92% FileOutputStream 1.32% > RandomAccessFileRead 1.66% RandomAccessFileWrite 0.76% > SocketChannelReadWrite 0.75% SocketReadWrite 0.89% Good. I think next time you better publish the mean values along with the errors to actually see if the difference is significant or not. -Aleksey. From Alan.Bateman at oracle.com Wed Nov 7 14:15:24 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 07 Nov 2012 14:15:24 +0000 Subject: Preliminary review: Adding tracing of I/O calls In-Reply-To: <4DA42ED5-601F-4FA1-8378-D3F105D82C31@oracle.com> References: <22767084-EAC2-4D87-800B-3E5E5BFC666A@oracle.com> <50942931.4000001@oracle.com> <08183803-2563-461C-9514-B7FAE1E14C10@oracle.com> <509437F0.4020409@oracle.com> <50965EB9.90509@oracle.com> <4DA42ED5-601F-4FA1-8378-D3F105D82C31@oracle.com> Message-ID: <509A6CFC.30109@oracle.com> On 07/11/2012 12:55, Staffan Larsen wrote: > : > > Negative values means that my changes added a regression. I think most of these values are within the margin of error in the measurements. The one exception is FileChannelRead. I've rerun this many times and it looks fairly consistent around a 4% regression. Why there is only a regression when reading from a FileChannel, I don't know. > It's possible that the additional instructions cause a threshold for inlining to be exceeded, would require looking at the compiler diagnostic output or generated code to see. I'll bet it is only obvious on the read because the it's already in the file cache, if there was actual disk access involved then its unlikely to be observable. -Alan From daniel.daugherty at oracle.com Wed Nov 7 14:58:31 2012 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 07 Nov 2012 07:58:31 -0700 Subject: XS RFR: 8002040 Allow Full Debug Symbols when cross-compiling In-Reply-To: <5099ECCA.2070901@oracle.com> References: <5099ECCA.2070901@oracle.com> Message-ID: <509A7717.9030603@oracle.com> On 11/6/12 10:08 PM, David Holmes wrote: > webrev: > > http://cr.openjdk.java.net/~dholmes/8002040/webrev/ Thumbs up. make/common/Defs-linux.gmk No comments. > This is a simplified variant of the change just made to Hotspot. > Instead of disabling FDS when cross-compiling we change the default > location of objcopy, and just as with native compilation either the > default objcopy is found or we try to fallback to ALT_OBJCOPY if set. I would phrase it a little differently: - you changed the default location of objcopy when cross compiling is enabled which potentially enables FDS for cross compiling - if ALT_OBJCOPY is set, then that value is used (even if it does not refer to an executable program) Setting ALT_OBJCOPY to some non-existent value is the means by which FDS can be completely disabled for all build configs on both Linux and Solaris. Note: there isn't a means to disable FDS on all build configs on Windows. Dan > In other words the only difference between the two cases is the chosen > default. (Arguably both cases could just use COMPILER_PATH/objcopy but > that might change existing behaviour in some cases - which we do not > want to do). > > I will push this via the build repo. There are no corresponding > changes needed to the new build as it handles FDS differently. > > This only impacts Linux. > > Thanks, > David > From weijun.wang at oracle.com Wed Nov 7 15:15:12 2012 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 07 Nov 2012 23:15:12 +0800 Subject: Fake DNS query result inside a test In-Reply-To: References: <5099B3C4.90506@oracle.com> Message-ID: <509A7B00.3020004@oracle.com> Hi Vinnie As you know, krb5 can read KDC info from DNS and I want to write a regression test on it. However, the test must be independent and it should not access any server not inside the test suite. Java uses those 2 lines to read the KDC info. Surely it would work if I write my own DNS server and embed it into the test, but as you said, that's too complicated. So I was thinking about how to trick it to return something without querying a real server. My current solution is to provide my own javax.naming.spi.NamingManager and make sure it shadows the original one by setting the path to -Xbootclasspath/p:. It is quite ugly and I feel shame to go this way. Thanks Max On 11/07/2012 08:51 PM, Vincent Ryan wrote: > Are you suggesting to run a local DNS server? If so then it is easy to access that > via a JNDI context. > > If you're proposing developing a basic JNDI service provider then that would be > more effort. > > > On 7 Nov 2012, at 01:05, Weijun Wang wrote: > >> Hi Vinnie >> >> I want to write a regression test so that >> >> Context ctx = NamingManager.getURLContext("dns", new Hashtable<>(0)); >> Attributes attrs =((DirContext)ctx).getAttributes( >> "_kerberos._udp.ASDF.COM.", SRV_RR_ATTR); >> >> can return some entries without querying a real external server. >> >> Is this possible by registering a local name server provider or else? >> >> Thanks >> Max > From xueming.shen at oracle.com Wed Nov 7 15:55:49 2012 From: xueming.shen at oracle.com (Xueming Shen) Date: Wed, 07 Nov 2012 07:55:49 -0800 Subject: Request for review: 7201156 : jar tool fails to convert file separation characters for list and extract In-Reply-To: References: Message-ID: <509A8485.90505@oracle.com> Change looks fine. -Sherman On 11/7/2012 12:31 AM, Sean Chou wrote: > Hello, > > This is the suggested fix described in sun bug 7201156 page. Please take a > look. > > sunbug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7201156 > webrev: http://cr.openjdk.java.net/~zhouyx/7201156/webrev.00/ > From daniel.fuchs at oracle.com Wed Nov 7 16:20:09 2012 From: daniel.fuchs at oracle.com (daniel.fuchs at oracle.com) Date: Wed, 07 Nov 2012 16:20:09 +0000 Subject: hg: jdk8/tl/jdk: 6720349: (ch) Channels tests depending on hosts inside Sun Message-ID: <20121107162021.F2BA2477F8@hg.openjdk.java.net> Changeset: 9e013ce42dd7 Author: dfuchs Date: 2012-11-07 13:24 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9e013ce42dd7 6720349: (ch) Channels tests depending on hosts inside Sun Summary: This changeset make the nio tests start small TCP or UDP servers from within the tests, instead of relying on external services. Reviewed-by: alanb ! test/java/nio/channels/DatagramChannel/AdaptDatagramSocket.java ! test/java/nio/channels/DatagramChannel/IsBound.java ! test/java/nio/channels/DatagramChannel/IsConnected.java ! test/java/nio/channels/Selector/Alias.java ! test/java/nio/channels/Selector/BasicConnect.java ! test/java/nio/channels/Selector/Connect.java ! test/java/nio/channels/Selector/ConnectWrite.java ! test/java/nio/channels/Selector/KeysReady.java ! test/java/nio/channels/SocketChannel/AdaptSocket.java ! test/java/nio/channels/SocketChannel/Basic.java ! test/java/nio/channels/SocketChannel/BufferSize.java ! test/java/nio/channels/SocketChannel/Connect.java ! test/java/nio/channels/SocketChannel/ConnectState.java ! test/java/nio/channels/SocketChannel/FinishConnect.java ! test/java/nio/channels/SocketChannel/IsConnectable.java ! test/java/nio/channels/SocketChannel/LocalAddress.java ! test/java/nio/channels/SocketChannel/Stream.java ! test/java/nio/channels/SocketChannel/VectorParams.java + test/java/nio/channels/TestServers.java ! test/java/nio/channels/TestUtil.java From peter.levart at gmail.com Wed Nov 7 17:11:26 2012 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 07 Nov 2012 18:11:26 +0100 Subject: bottleneck by java.lang.Class.getAnnotations() - proposed patch In-Reply-To: References: <924D06EC-F603-4E6A-A7FE-7A05C77B1217@gmail.com> <23313EDE-3AB7-4E53-8EB1-A6F6CC9383B9@gmail.com> <5093A8D3.4030800@gmail.com> <5096CFBD.2010604@gmail.com> <5096F5B0.8070304@gmail.com> <50974D3D.1040502@oracle.com> <50986808.9060708@oracle.com> Message-ID: <509A963E.70209@gmail.com> On 11/06/2012 08:37 AM, Peter Levart wrote: > > Hi all, > > I have prepared a better patch. It addresses the goals of JEP-149 more > seriously. I also have some benchmarks. Stay tuned... > > Regards, Peter > > For easier viewing, here's also a webrev: http://dl.dropbox.com/u/101777488/jdk8-hacks/JEP-149/webrev/index.html Regards, Peter From martinrb at google.com Wed Nov 7 17:59:39 2012 From: martinrb at google.com (Martin Buchholz) Date: Wed, 7 Nov 2012 09:59:39 -0800 Subject: bottleneck by java.lang.Class.getAnnotations() - proposed patch In-Reply-To: <509A963E.70209@gmail.com> References: <924D06EC-F603-4E6A-A7FE-7A05C77B1217@gmail.com> <23313EDE-3AB7-4E53-8EB1-A6F6CC9383B9@gmail.com> <5093A8D3.4030800@gmail.com> <5096CFBD.2010604@gmail.com> <5096F5B0.8070304@gmail.com> <50974D3D.1040502@oracle.com> <50986808.9060708@oracle.com> <509A963E.70209@gmail.com> Message-ID: We've also seen deadlocks in accessing annotations in the wild. So, many thanks for working on this (both performance improvements and deadlock removal). We don't have a test case to contribute, but here's a stacktrace: sun.reflect.annotation.AnnotationType.getInstance(AnnotationType.java:80) sun.reflect.annotation.AnnotationParser.parseAnnotation (AnnotationParser.java:220) sun.reflect.annotation.AnnotationParser.parseAnnotations2 (AnnotationParser.java:87) sun.reflect.annotation.AnnotationParser.parseAnnotations (AnnotationParser.java:70) java.lang.Class.initAnnotationsIfNecessary(Class.java:3093) java.lang.Class.getAnnotation(Class.java:3050) sun.reflect.annotation.AnnotationType.(AnnotationType.java:130) sun.reflect.annotation.AnnotationType.getInstance(Annotation Type.java:83) sun.reflect.annotation.AnnotationParser.parseAnnotation (AnnotationParser.java:220) sun.reflect.annotation.AnnotationParser.parseAnnotations2 (AnnotationParser.java:87) sun.reflect.annotation.AnnotationParser.parseAnnotations (AnnotationParser.java:70) java.lang.Class.initAnnotationsIfNecessary(Class.java:3093) java.lang.Class.getAnnotation(Class.java:3050) sun.reflect.annotation.AnnotationType.(AnnotationType.java:130) sun.reflect.annotation.AnnotationType.getInstance(Annotation Type.java:83) sun.reflect.annotation.AnnotationParser.parseAnnotation (AnnotationParser.java:220) sun.reflect.annotation.AnnotationParser.parseAnnotations2 (AnnotationParser.java:87) sun.reflect.annotation.AnnotationParser.parseAnnotations (AnnotationParser.java:70) java.lang.Class.initAnnotationsIfNecessary(Class.java:3093) java.lang.Class.getAnnotation(Class.java:3050) Martin On Wed, Nov 7, 2012 at 9:11 AM, Peter Levart wrote: > On 11/06/2012 08:37 AM, Peter Levart wrote: > >> >> Hi all, >> >> I have prepared a better patch. It addresses the goals of JEP-149 more >> seriously. I also have some benchmarks. Stay tuned... >> >> Regards, Peter >> >> >> > For easier viewing, here's also a webrev: > > http://dl.dropbox.com/u/**101777488/jdk8-hacks/JEP-149/**webrev/index.html > > Regards, Peter > > From sean.coffey at oracle.com Wed Nov 7 18:45:16 2012 From: sean.coffey at oracle.com (sean.coffey at oracle.com) Date: Wed, 07 Nov 2012 18:45:16 +0000 Subject: hg: jdk8/tl/jdk: 8002227: (tz) Support tzdata2012i Message-ID: <20121107184529.CFED64780B@hg.openjdk.java.net> Changeset: 7d50ff0e2d44 Author: coffeys Date: 2012-11-07 18:48 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7d50ff0e2d44 8002227: (tz) Support tzdata2012i Reviewed-by: peytoia, asaha ! make/sun/javazic/tzdata/VERSION ! make/sun/javazic/tzdata/africa ! make/sun/javazic/tzdata/asia ! make/sun/javazic/tzdata/australasia ! make/sun/javazic/tzdata/europe ! make/sun/javazic/tzdata/leapseconds ! make/sun/javazic/tzdata/northamerica ! make/sun/javazic/tzdata/southamerica ! makefiles/GendataTimeZone.gmk From peter.levart at gmail.com Wed Nov 7 19:02:00 2012 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 07 Nov 2012 20:02:00 +0100 Subject: bottleneck by java.lang.Class.getAnnotations() - proposed patch In-Reply-To: References: <924D06EC-F603-4E6A-A7FE-7A05C77B1217@gmail.com> <23313EDE-3AB7-4E53-8EB1-A6F6CC9383B9@gmail.com> <5093A8D3.4030800@gmail.com> <5096CFBD.2010604@gmail.com> <5096F5B0.8070304@gmail.com> <50974D3D.1040502@oracle.com> <50986808.9060708@oracle.com> <509A963E.70209@gmail.com> Message-ID: <509AB028.5090301@gmail.com> On 11/07/2012 06:59 PM, Martin Buchholz wrote: > We've also seen deadlocks in accessing annotations in the wild. > So, many thanks for working on this (both performance improvements and > deadlock removal). > We don't have a test case to contribute, but here's a stacktrace: That's one thread. What about the other(s)? I guess this is similar to http://bugs.sun.com/view_bug.do?bug_id=7122142 Various locks are involved: - AnnotationType.getInstance is a static synchronized method (locks on AnnotationType.class) - Class.initAnnotationsIfNecessary is an instance synchronized method (locks on various .class instances) lazy initialization sequence can take various ordering combinations among threads (recursing on loading annotations on annotations - the meta annotations - when requested by the AnnotationType init). The proposed patch removes blocking synchronization on Class.initAnnotationsIfNecessary (replacing this method with another one that has no blocking synchronization). Therefore just one lock remains in such scenarios (AnnotationType.getInstance) and there's no dead-lock with just one lock ;-) Regards, Peter > > sun.reflect.annotation.AnnotationType.getInstance(AnnotationType.java:80) > > sun.reflect.annotation.AnnotationParser.parseAnnotation(AnnotationParser.java:220) > > sun.reflect.annotation.AnnotationParser.parseAnnotations2(AnnotationParser.java:87) > > sun.reflect.annotation.AnnotationParser.parseAnnotations(AnnotationParser.java:70) > java.lang.Class.initAnnotationsIfNecessary(Class.java:3093) > java.lang.Class.getAnnotation(Class.java:3050) > sun.reflect.annotation.AnnotationType.(AnnotationType.java:130) > > sun.reflect.annotation.AnnotationType.getInstance(AnnotationType.java:83) > > sun.reflect.annotation.AnnotationParser.parseAnnotation(AnnotationParser.java:220) > > sun.reflect.annotation.AnnotationParser.parseAnnotations2(AnnotationParser.java:87) > > sun.reflect.annotation.AnnotationParser.parseAnnotations(AnnotationParser.java:70) > java.lang.Class.initAnnotationsIfNecessary(Class.java:3093) > java.lang.Class.getAnnotation(Class.java:3050) > sun.reflect.annotation.AnnotationType.(AnnotationType.java:130) > > sun.reflect.annotation.AnnotationType.getInstance(AnnotationType.java:83) > > sun.reflect.annotation.AnnotationParser.parseAnnotation(AnnotationParser.java:220) > > sun.reflect.annotation.AnnotationParser.parseAnnotations2(AnnotationParser.java:87) > > sun.reflect.annotation.AnnotationParser.parseAnnotations(AnnotationParser.java:70) > java.lang.Class.initAnnotationsIfNecessary(Class.java:3093) > java.lang.Class.getAnnotation(Class.java:3050) > > Martin > > On Wed, Nov 7, 2012 at 9:11 AM, Peter Levart > wrote: > > On 11/06/2012 08:37 AM, Peter Levart wrote: > > > Hi all, > > I have prepared a better patch. It addresses the goals of > JEP-149 more seriously. I also have some benchmarks. Stay tuned... > > Regards, Peter > > > > For easier viewing, here's also a webrev: > > http://dl.dropbox.com/u/101777488/jdk8-hacks/JEP-149/webrev/index.html > > Regards, Peter > > From martinrb at google.com Wed Nov 7 19:13:07 2012 From: martinrb at google.com (Martin Buchholz) Date: Wed, 7 Nov 2012 11:13:07 -0800 Subject: bottleneck by java.lang.Class.getAnnotations() - proposed patch In-Reply-To: <509AB028.5090301@gmail.com> References: <924D06EC-F603-4E6A-A7FE-7A05C77B1217@gmail.com> <23313EDE-3AB7-4E53-8EB1-A6F6CC9383B9@gmail.com> <5093A8D3.4030800@gmail.com> <5096CFBD.2010604@gmail.com> <5096F5B0.8070304@gmail.com> <50974D3D.1040502@oracle.com> <50986808.9060708@oracle.com> <509A963E.70209@gmail.com> <509AB028.5090301@gmail.com> Message-ID: On Wed, Nov 7, 2012 at 11:02 AM, Peter Levart wrote: > On 11/07/2012 06:59 PM, Martin Buchholz wrote: > > We've also seen deadlocks in accessing annotations in the wild. > So, many thanks for working on this (both performance improvements and > deadlock removal). > We don't have a test case to contribute, but here's a stacktrace: > > That's one thread. What about the other(s)? > > sun.reflect.annotation.AnnotationType.getInstance(Annotation Type.java:80) sun.reflect.annotation.AnnotationParser.parseAnnotation (AnnotationParser.java:220) sun.reflect.annotation.AnnotationParser.parseAnnotations2 (AnnotationParser.java:87) sun.reflect.annotation.AnnotationParser.parseAnnotations (AnnotationParser.java:70) java.lang.Class.initAnnotationsIfNecessary(Class.java:3093) java.lang.Class.getAnnotation(Class.java:3050) sun.reflect.annotation.AnnotationType.(AnnotationType.java:130) sun.reflect.annotation.AnnotationType.getInstance(Annotation Type.java:83) sun.reflect.annotation.AnnotationParser.parseAnnotation (AnnotationParser.java:220) sun.reflect.annotation.AnnotationParser.parseAnnotations2 (AnnotationParser.java:87) sun.reflect.annotation.AnnotationParser.parseAnnotations (AnnotationParser.java:70) java.lang.Class.initAnnotationsIfNecessary(Class.java:3093) java.lang.Class.getAnnotation(Class.java:3050) sun.reflect.annotation.AnnotationType.(AnnotationType.java:130) sun.reflect.annotation.AnnotationType.getInstance(Annotation Type.java:83) sun.reflect.annotation.AnnotationParser.parseAnnotation (AnnotationParser.java:220) sun.reflect.annotation.AnnotationParser.parseAnnotations2 (AnnotationParser.java:87) sun.reflect.annotation.AnnotationParser.parseAnnotations (AnnotationParser.java:70) java.lang.reflect.Field.declaredAnnotations(Field.java:1034) java.lang.reflect.Field.getAnnotation(Field.java:1018) > I guess this is similar to http://bugs.sun.com/view_bug.do?bug_id=7122142 > > Various locks are involved: > > - AnnotationType.getInstance is a static synchronized method (locks on > AnnotationType.class) > > - Class.initAnnotationsIfNecessary is an instance synchronized method > (locks on various .class instances) > > lazy initialization sequence can take various ordering combinations among > threads (recursing on loading annotations on annotations - the meta > annotations - when requested by the AnnotationType init). > > The proposed patch removes blocking synchronization on > Class.initAnnotationsIfNecessary (replacing this method with another one > that has no blocking synchronization). Therefore just one lock remains in > such scenarios (AnnotationType.getInstance) and there's no dead-lock with > just one lock ;-) > I haven't actually tried to fix it, but I've thought about it, also thinking about replacing locks with lazy lock-free initialization, probably using Unsafe to cas class metadata. From aleksey.shipilev at oracle.com Wed Nov 7 20:15:44 2012 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Wed, 07 Nov 2012 15:15:44 -0500 Subject: Preliminary review: Adding tracing of I/O calls In-Reply-To: References: <22767084-EAC2-4D87-800B-3E5E5BFC666A@oracle.com> <50942931.4000001@oracle.com> <08183803-2563-461C-9514-B7FAE1E14C10@oracle.com> <509437F0.4020409@oracle.com> <50965EB9.90509@oracle.com> <4DA42ED5-601F-4FA1-8378-D3F105D82C31@oracle.com> <0BDC1398-D644-4D49-9308-A5705D610CF7@oracle.com> Message-ID: <509AC170.4070603@oracle.com> On 11/07/2012 09:02 AM, Vitaly Davidovich wrote: > I'd try the two different impls approach though. It does introduce more > types to load but if that's not an issue, I think perf should be good. At > least worth trying for curiosity's sake. :) I wonder if this intersects with the dynamic tracing JFR is about to introduce in HotSpot. Would Staffan's work duplicate that? -Aleksey. From ahughes at redhat.com Wed Nov 7 20:30:18 2012 From: ahughes at redhat.com (Andrew Hughes) Date: Wed, 7 Nov 2012 15:30:18 -0500 (EST) Subject: [PATCH FOR REVIEW] ResourceManager.getApplicationResources() does not close InputStreams In-Reply-To: <1843388604.6780329.1352319687725.JavaMail.root@redhat.com> Message-ID: <688525702.6784445.1352320218435.JavaMail.root@redhat.com> IcedTea bug: http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=1197 com.sun.naming.internal.ResourceManager.getApplicationResources() does not close the input streams it gets from helper.getResources() and helper.getJavaHomeLibStream(). This patch: http://cr.openjdk.java.net/~andrew/pr1197/webrev.01/ adds finally blocks to close these streams. As noted in the original bug report, this has been tested on a J2EE server (JBoss) without issue. I realise that there's a possibility that try-with-resources could be used here, but the patch as posted is the one that was tested and I don't want to negate that testing by changing it. Ok for tl? If so, can I have a bug ID for this? 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 Lance.Andersen at oracle.com Wed Nov 7 20:45:26 2012 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Wed, 7 Nov 2012 15:45:26 -0500 Subject: [PATCH FOR REVIEW] ResourceManager.getApplicationResources() does not close InputStreams In-Reply-To: <688525702.6784445.1352320218435.JavaMail.root@redhat.com> References: <688525702.6784445.1352320218435.JavaMail.root@redhat.com> Message-ID: <5A4408B8-C1B6-4E5A-996E-60E29FE6D4D4@oracle.com> Is there a reason the patch was not created originally leveraging try-with-resoruces as it seems like the perfect candidate from the webrev? I can create a bug for it, but I think I would prefer to see the patch take advantage of try-with-resoruces Best Lance On Nov 7, 2012, at 3:30 PM, Andrew Hughes wrote: > IcedTea bug: http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=1197 > > com.sun.naming.internal.ResourceManager.getApplicationResources() does not close the input streams it gets from helper.getResources() and helper.getJavaHomeLibStream(). This patch: > > http://cr.openjdk.java.net/~andrew/pr1197/webrev.01/ > > adds finally blocks to close these streams. As noted in the original bug report, this has been tested on a J2EE > server (JBoss) without issue. > > I realise that there's a possibility that try-with-resources could be used here, but the patch as posted > is the one that was tested and I don't want to negate that testing by changing it. > > Ok for tl? If so, can I have a bug ID for this? > > 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 > -------------- next part -------------- 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 peter.levart at gmail.com Wed Nov 7 20:49:31 2012 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 07 Nov 2012 21:49:31 +0100 Subject: bottleneck by java.lang.Class.getAnnotations() - a better patch In-Reply-To: <509A3A63.5010102@gmail.com> References: <924D06EC-F603-4E6A-A7FE-7A05C77B1217@gmail.com> <23313EDE-3AB7-4E53-8EB1-A6F6CC9383B9@gmail.com> <5093A8D3.4030800@gmail.com> <5096CFBD.2010604@gmail.com> <5096F5B0.8070304@gmail.com> <50974D3D.1040502@oracle.com> <50990CB8.2040400@gmail.com> <5099C2FA.2020202@oracle.com> <509A3A63.5010102@gmail.com> Message-ID: <509AC95B.1050801@gmail.com> Hi all, I have redone the static memory footprint comparison calculations (taking correct object headers and padding into account) and I hope this time I've done it right. Here's what I got: 64bit addressing (16 byte object header): patched Class uses 76 bytes less than original Class when empty patched Class uses 360 bytes less than original Class when fully loaded patched Class uses 32 bytes more than original Class when just one of fields is loaded 32bit addressing (8 byte object header): patched Class uses 40 bytes less than original Class when empty patched Class uses 208 bytes less than original Class when fully loaded patched Class uses 16 bytes more than original Class when just one of fields is loaded object instance counts: patched Class uses the same number of object instances as original Class when empty patched Class uses 6 object instances less than original Class when fully loaded patched Class uses 1 object instance more than original Class when just one of fields is loaded The calculations are here: https://raw.github.com/plevart/jdk8-hacks/master/volatile_class_data_caching.txt The "worst case" scenario for patched code vs. original code is when just one of the fields in the structure is loaded. For example if only Class.getDeclaredMethods() or such is ever called on a Class instance. In all other cases (when Class is fresh or there are 2 or more fields loaded) the patched code is better. The question remains how frequent the "worst case" scenario is in real-world code. Regards, Peter On 11/07/2012 11:39 AM, Peter Levart wrote: > On 11/07/2012 03:10 AM, David Holmes wrote: >> Hi Peter, >> >> The movement of the reflection caches to a helper object is exactly >> what I had previously proposed here (some differences in the details >> of course): >> >> http://cr.openjdk.java.net/~dholmes/JEP-149/webrev/ >> >> and discussed here: >> >> http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-April/009749.html >> >> >> but this did not touch the annotations fields. >> >> David > > Hi David, > > Thanks for the pointer. There is a discussion between Brian and you > (to quote some of it): > > On 5/04/2012 1:28 PM, Brian Goetz wrote: > >/ Reducing the number of SoftReferences in ReflectionHelper also seems an > />/ attractive target for memory reduction. Rather than eight soft > />/ references (eight extra objects), maintaining a SoftRef to the entire > />/ RH, or at least to the part of the RH that is currently SR'ed if the two > />/ non-SR'ed fields can't be recomputed, would save you a whole pile of > />/ objects per class (and might also reduce pressure on GC, having 8x fewer > />/ SRs to process.) > / > I'd have to consider the intended semantics of these soft references > before considering any change here. It would hard to predict how this > might impact runtime performance if we have coarser-grained soft > references. The current changes should be semantically null. > > >/ Finally, you may be able save an extra field per Class by storing the > />/ ReflectionHelper in a ClassValue on Java SE 8, rather than a field. > / > ClassValue is something I'm keeping an eye on, but an entry in > ClassValue is going to consume more dynamic memory than a single direct > field. > > Thanks, > David > > > ...the 8 SoftReferences refer to arrays which are never hard > referenced by the outside world (arrays are always defensively > copied), so it's reasonable to expect that all SoftReferences would be > cleared at the same time anyway. And if 8 SoftReferences are replaced > with 1, the worst case scenario (to quote Hinkmond Wong): > > Hi Brian, > > One of the issues we have in the Java Embedded group (as David points > out in his summary), is that while on paper the theoretical max savings > seems great (as you point out also), in practice as David points out in > his note, this might be a wash if there are a lot more reflection using > classes vs. non-reflection using classes in "typical" real-world > applications, not the low or zero reflection using class ratio that > happens in the theoretical "best case". > > So, a question comes up if we should judge the merit of this change on > the theoretical "best case" scenario, or should we judge it on > real-world applicability to "typical" apps (such as a finite set of > customer surveyed embedded apps that we feel represent a real-world > scenario). > > > Thanks, > Hinkmond > > > ...actually becomes even more favourable. We reduce huge overhead > (each SoftReference is 4 OOPs and 1 long). And if this single > SoftReference is ever cleared, more memory is released - the whole > structure (ReflectionHelper / VolatileData) > > Other differences in details between your proposal and mine: > > In your proposal, the method ReflectionHelper rh() is equivalent to > mine VolatileData volatileData() - it lazily constructs the structure > and returns it. My implementation also incorporates the logic of > clearCachesOnClassRedefinition() by returning and installing a new > instance of the structure in case a redefinition is detected. This has > a profound impact on the correctness of the cached data in face of > races that can occur. > > In your proposal, even if the VM could atomically publish changes to > raw reflection data and the classRedefinitionCount at the same time > (we hope that at least the order of publishing is such that > classRedefinitionCount is updated last), it can theoretically be that > 2 or more redefinitions of the same class happen in close proximity: > > VM thread: redefines the class to version=1 > thread 1: clears the cache and takes version=1 raw data and computes > derived data but gets pre-empted before installing it > VM thread: redefines the class to version=2 > thread 2: clears the cache and takes version=2 raw data and computes > derived data and installs it > thread 1: ...gets back and installs version=1 derived data over > version=2 data > > ...if there are no more class redefinitions, the stale version of > derived data can persist indefinitely. > > In my proposal, each thread will get it's own copy of the structure in > the above scenario and install the derived data into it. It can happen > that a particular instance of the structure does not represent a > "snapshot" view of the world, but that is not important, since that > particular inconsistent instance is only used for the in-flight call > and only in that part that is consistent. Other callers will get a > fresh instance. > > There is also one thing I overlooked and you haven't: the > cachedConstructor and newInstanceCallerCache fields. > > I'll have to look at how to incorporate them into my scheme. They are > currently neither SoftReferenced nor cleared at class redefinition. As > the cachedConstructor is only used to implement the .newInstance() > method, I wonder if it is safe not to clear it when the class is > redefined. Are old versions of Constructors still valid for invoking > in a redefined class? I guess they must be, since user code is free to > cache it's own versions and class redefinition should not prevent > invoking them... > > Since cachedConstructor/newInstanceCallerCache are used to optimize > .newInstance() method. That alone suggests that calling this method is > more common use-case than others. Perhaps leaving this pair of fields > out of the game is a better approach space-saving wise. > > Regards, Peter > >> >> On 6/11/2012 11:12 PM, Peter Levart wrote: >>> On 11/05/2012 06:23 AM, David Holmes wrote: >>>> Hi Peter, >>>> >>>> Moving the annotations fields into a helper object would tie in with >>>> the Class-instance size reduction effort that was investigated as part >>>> of "JEP 149: Reduce Core-Library Memory Usage": >>>> >>>> http://openjdk.java.net/jeps/149 >>>> >>>> The investigations there to date only looked at relocating the >>>> reflection related fields, though the JEP mentions the annotations as >>>> well. >>>> >>>> Any such effort requires extensive benchmarking and performance >>>> analysis before being accepted though. >>>> >>>> David >>>> ----- >>>> >>> >>> On 11/05/2012 10:25 AM, Alan Bateman wrote: >>>> Here's a good starting place on the interaction of runtime visible >>>> attributes and RedefineClasses/RetransformClasses: >>>> >>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5002251 >>>> >>>> -Alan. >>> >>> Hi all, >>> >>> Presented here is a patch mainly against java.lang.Class and also >>> against java.lang.reflect.[Field,Method,Constructor,Executable] >>> classes. >>> >>> Currently java.lang.Class uses the following fields to maintain caches >>> of reflection data that are invalidated as a result of class or >>> superclass redefinition/re-transformation: >>> >>> private volatile transient SoftReference declaredFields; >>> private volatile transient SoftReference publicFields; >>> private volatile transient SoftReference declaredMethods; >>> private volatile transient SoftReference publicMethods; >>> private volatile transient SoftReference[]> >>> declaredConstructors; >>> private volatile transient SoftReference[]> >>> publicConstructors; >>> private volatile transient SoftReference declaredPublicFields; >>> private volatile transient SoftReference >>> declaredPublicMethods; >>> >>> // Value of classRedefinedCount when we last cleared the cached values >>> // that are sensitive to class redefinition. >>> private volatile transient int lastRedefinedCount = 0; >>> >>> // Annotations cache >>> private transient Map, Annotation> >>> annotations; >>> private transient Map, Annotation> >>> declaredAnnotations; >>> >>> If I understand Alan's references correctly, current VM can redefine >>> the >>> class in a way that changes method bodies. Also new methods can be >>> added. And the set of annotations can also be altered. And future >>> improvements could allow even more. >>> >>> Because annotations are cached on Field/Method/Constructor instances, >>> all the above fields must be invalidated when the class or >>> superclass is >>> redefined. >>> >>> It can also be observed that Field/Method/Constructor caches are >>> maintained using SoftReferences but annotations are hard references. I >>> don't know if this is intentional. I believe that annotations could >>> also >>> be SoftReferenced, so that in the event of memory pressure they get >>> cleared. Many applications retrieve annotations only in the early >>> stages >>> of their life-cycle and then either cache them themselves or forget >>> about them. >>> >>> So I designed the patch to equalize this. If this is undesirable, the >>> patch could be modified to make a distinction again. >>> >>> The patch replaces the above-mentioned java.lang.Class fields with a >>> single field: >>> >>> private volatile transient SoftReference> volatileData; >>> >>> ...which is a SoftReference to the following structure: >>> >>> // volatile data that might get invalid when JVM TI >>> RedefineClasses() is >>> called >>> static class VolatileData { >>> volatile Field[] declaredFields; >>> volatile Field[] publicFields; >>> volatile Method[] declaredMethods; >>> volatile Method[] publicMethods; >>> volatile Constructor[] declaredConstructors; >>> volatile Constructor[] publicConstructors; >>> // Intermediate results for getFields and getMethods >>> volatile Field[] declaredPublicFields; >>> volatile Method[] declaredPublicMethods; >>> // Annotations >>> volatile Map, Annotation> annotations; >>> volatile Map, Annotation> >>> declaredAnnotations; >>> // Value of classRedefinedCount when we created this VolatileData >>> instance >>> final int redefinedCount; >>> >>> So let's look at static overhead differences using 64 bit addressing >>> (useful load - arrays, Maps not counted since the patched code uses the >>> same amount of same types of each). >>> >>> * Fresh java.lang.Class instance: >>> >>> current JDK8 code: >>> >>> 10 OOPs + 1 int = 10*8+4 = 84 bytes in 1 instance >>> >>> vs. patched code : >>> >>> 1 OOP = 8 bytes in 1 instance >>> >>> * Fully loaded java.lang.Class (Fields, Methods, Constructors, >>> annotations): >>> >>> current JDK8 code: >>> >>> 10 OOPs + 1 int = 84 bytes >>> 8 SoftReference instances = 8*(header + 4 OOPs + 1 long) = >>> 8*(24+32+8) = >>> 8*64 = 512 bytes >>> total: 84+512 = 596 bytes in 9 instances >>> >>> vs. patched code : >>> >>> 1 OOP = 8 bytes >>> 1 SoftReference = 64 bytes >>> 1 VolatileData = header + 10 OOPs + 1 int = 24+84 = 108 bytes >>> total: 8+64+108 = 180 bytes in 3 instances >>> >>> So we have 84 vs. 8 (empty) or 596 vs. 180 (fully loaded) byte >>> overheads and >>> 1 vs. 1 (empty) or 9 vs. 3 (fully loaded) instance overheads >>> >>> Other than that, the patch also removes synchronized blocks for lazy >>> initialization of annotations in Class, Field, Method and Constructor >>> and replaces them with volatile fields. In case of Class.volatileData, >>> this field is initialized using a CAS so there is no race which could >>> install an already stale instance over more recent. Although such race >>> would quickly be corrected at next call to any retrieval method, >>> because >>> redefinedCount is now an integral part of the cached structure not an >>> individual volatile field. >>> >>> There is also a change in how annotations are cached in Field, Method >>> and Constructor. Originally they are cached in each copy of the >>> Field/Method/Constructor that is returned to the outside world at each >>> invocation of Class.getFields() etc. Such caching is not very effective >>> if the annotations are only retrieved once per instance. The patch >>> changes this and delegates caching to the "root" instance which is held >>> inside Class so caching becomes more effective in certain usage >>> patterns. There's now a possible hot-spot on the "root" instance but >>> that seems not to be a bottleneck since the fast-path does not involve >>> blocking synchronization (just volatile read). The effects of this >>> change are clearly visible in one of the benchmarks. >>> >>> I have tried to create 3 micro benchmarks which exercise concurrent >>> load >>> on 3 Class instances. >>> >>> Here's the benchmark code: >>> >>> https://raw.github.com/plevart/jdk8-hacks/master/src/test/ReflectionTest.java >>> >>> >>> And here are the results when run on an Intel i7 CPU (4 cores, 2 >>> threads/core) Linux machine using -Xmx4G VM option: >>> >>> https://raw.github.com/plevart/jdk8-hacks/master/benchmark_results.txt >>> >>> >>> The huge difference of Test1 results is a direct consequence of patched >>> code delegating caching of annotations in Field/Method/Constructor to >>> the "root" instance. >>> >>> Test2 results show no noticeable difference between original and >>> patched >>> code. This, I believe, is the most common usage of the API, so another >>> level of indirection does not appear to present any noticeable >>> performance overhead. >>> >>> The Test3 on the other hand shows the synchronization overhead of >>> current jdk8 code in comparison with non-blocking synchronization in >>> patched code. >>> >>> JEP 149 also mentions testing with SPECjbb2005 and SPECjvm98, but that >>> exceeds my possibilities. >>> >>> The patch against jdk8/jdk8/jdk hg repository is here: >>> >>> https://raw.github.com/plevart/jdk8-hacks/master/volatile_class_data_caching.patch >>> >>> >>> You can also browse the changed sources: >>> >>> https://github.com/plevart/jdk8-hacks >>> >>> >>> Regards, Peter >>> From Lance.Andersen at oracle.com Wed Nov 7 20:50:16 2012 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Wed, 7 Nov 2012 15:50:16 -0500 Subject: [PATCH FOR REVIEW] ResourceManager.getApplicationResources() does not close InputStreams In-Reply-To: <688525702.6784445.1352320218435.JavaMail.root@redhat.com> References: <688525702.6784445.1352320218435.JavaMail.root@redhat.com> Message-ID: The bug number is 8003120 Best Lance On Nov 7, 2012, at 3:30 PM, Andrew Hughes wrote: > IcedTea bug: http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=1197 > > com.sun.naming.internal.ResourceManager.getApplicationResources() does not close the input streams it gets from helper.getResources() and helper.getJavaHomeLibStream(). This patch: > > http://cr.openjdk.java.net/~andrew/pr1197/webrev.01/ > > adds finally blocks to close these streams. As noted in the original bug report, this has been tested on a J2EE > server (JBoss) without issue. > > I realise that there's a possibility that try-with-resources could be used here, but the patch as posted > is the one that was tested and I don't want to negate that testing by changing it. > > Ok for tl? If so, can I have a bug ID for this? > > 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 > -------------- next part -------------- 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 gnu.andrew at redhat.com Wed Nov 7 20:51:14 2012 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 7 Nov 2012 15:51:14 -0500 (EST) Subject: [PATCH FOR REVIEW] ResourceManager.getApplicationResources() does not close InputStreams In-Reply-To: <5A4408B8-C1B6-4E5A-996E-60E29FE6D4D4@oracle.com> Message-ID: <61857660.6790276.1352321474076.JavaMail.root@redhat.com> ----- Original Message ----- > Is there a reason the patch was not created originally leveraging > try-with-resources as it seems like the perfect candidate from the > webrev? > > I can create a bug for it, but I think I would prefer to see the > patch take advantage of try-with-resoruces > As you can see on the IcedTea bug, I've asked the same question. I'd have preferred it to use try-with-resources myself (easier to follow for one thing), but given the patch is as it is, I'm now wary about changing it and negating the existing testing that's already been done. > Best > Lance > On Nov 7, 2012, at 3:30 PM, Andrew Hughes wrote: > > > IcedTea bug: > > http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=1197 > > > > com.sun.naming.internal.ResourceManager.getApplicationResources() > > does not close the input streams it gets from > > helper.getResources() and helper.getJavaHomeLibStream(). This > > patch: > > > > http://cr.openjdk.java.net/~andrew/pr1197/webrev.01/ > > > > adds finally blocks to close these streams. As noted in the > > original bug report, this has been tested on a J2EE > > server (JBoss) without issue. > > > > I realise that there's a possibility that try-with-resources could > > be used here, but the patch as posted > > is the one that was tested and I don't want to negate that testing > > by changing it. > > > > Ok for tl? If so, can I have a bug ID for this? > > > > 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 > > > > > > [image/gif:oracle_sig_logo.gif] > > > 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 > > -- 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 ahughes at redhat.com Wed Nov 7 21:15:58 2012 From: ahughes at redhat.com (ahughes at redhat.com) Date: Wed, 07 Nov 2012 21:15:58 +0000 Subject: hg: jdk8/tl/jdk: 8003120: ResourceManager.getApplicationResources() does not close InputStreams Message-ID: <20121107211622.99F0947824@hg.openjdk.java.net> Changeset: f51943263267 Author: andrew Date: 2012-11-07 16:07 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f51943263267 8003120: ResourceManager.getApplicationResources() does not close InputStreams Summary: Add finally blocks to close the InputStream instances Reviewed-by: lancea ! src/share/classes/com/sun/naming/internal/ResourceManager.java From gnu.andrew at redhat.com Wed Nov 7 21:17:47 2012 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 7 Nov 2012 16:17:47 -0500 (EST) Subject: [PATCH FOR REVIEW] ResourceManager.getApplicationResources() does not close InputStreams In-Reply-To: Message-ID: <381508571.6800833.1352323067975.JavaMail.root@redhat.com> ----- Original Message ----- > The bug number is 8003120 > Thanks. Pushed to tl: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f51943263267 > Best > Lance > On Nov 7, 2012, at 3:30 PM, Andrew Hughes wrote: > > > IcedTea bug: > > http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=1197 > > > > com.sun.naming.internal.ResourceManager.getApplicationResources() > > does not close the input streams it gets from > > helper.getResources() and helper.getJavaHomeLibStream(). This > > patch: > > > > http://cr.openjdk.java.net/~andrew/pr1197/webrev.01/ > > > > adds finally blocks to close these streams. As noted in the > > original bug report, this has been tested on a J2EE > > server (JBoss) without issue. > > > > I realise that there's a possibility that try-with-resources could > > be used here, but the patch as posted > > is the one that was tested and I don't want to negate that testing > > by changing it. > > > > Ok for tl? If so, can I have a bug ID for this? > > > > 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 > > > > > > 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 > > -- 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 mark.reinhold at oracle.com Wed Nov 7 22:22:10 2012 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 07 Nov 2012 14:22:10 -0800 Subject: Preliminary review: Adding tracing of I/O calls In-Reply-To: staffan.larsen@oracle.com; Fri, 02 Nov 2012 11:36:44 PDT; <22767084-EAC2-4D87-800B-3E5E5BFC666A@oracle.com> Message-ID: <20121107222210.19310AA9@eggemoggin.niobe.net> 2012/11/2 11:36 -0700, staffan.larsen at oracle.com: > Webrev: http://cr.openjdk.java.net/~sla/iotrace/webrev.00/ Who (or what) is the intended consumer of the sun.misc.IoTrace and IoTraceListener APIs? In other words, are these meant to be stable external interfaces that we're going to support for use by arbitrary code over the long term? The reason I ask is that sun.misc is likely to go away in JDK 9, as part of the modularization work. If these APIs are meant to be used by any code outside of the JDK then we should probably put them in a more appropriate package now in order to avoid pain later on. - Mark From mike.duigou at oracle.com Wed Nov 7 23:08:52 2012 From: mike.duigou at oracle.com (Mike Duigou) Date: Wed, 7 Nov 2012 15:08:52 -0800 Subject: Re-Request for Re-Review : 7088952 : Add "BYTES" constant to primitive wrapper classes Message-ID: <8E520A9F-7BCD-4665-B19E-9FF4D6841EE8@oracle.com> Hello all; A long time ago [1] this patch was put forward for review. Though the request was approved the patch was never committed because some of the followup questions were not answered. The summary motivation for this issue is that measuring the size of the primitive types in bytes is more frequently used than bits because bytes are the minimum unit of allocation in Java. The proposed BYTES constant is a convenience to avoid many repetitions of Integer.SIZE / Byte.SIZE where the size in bytes is desired. There are many of these cases already in the JDK that are currently using locally defined constants or manifest constants ("magic" numbers) [2] that could benefit from this change to improve clarity. Many other external usages could take advantage of these constants as well. Unless there are objections I will go forward with pushing this change on Nov 9th, 2012 as originally reviewed with the original reviewers. http://cr.openjdk.java.net/~mduigou/7088952/0/webrev/ Mike [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-September/007753.html [2] http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/00cd9dc3c2b5/src/share/classes/java/io/DataOutputStream.java From naoto.sato at oracle.com Wed Nov 7 23:09:15 2012 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Wed, 07 Nov 2012 23:09:15 +0000 Subject: hg: jdk8/tl/jdk: 8001205: Calendar.getDisplayName(...): Returns null when provider is SPI but there is no SPI implementation; ... Message-ID: <20121107230927.3608B47826@hg.openjdk.java.net> Changeset: cc325832469c Author: naoto Date: 2012-11-07 15:08 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cc325832469c 8001205: Calendar.getDisplayName(...): Returns null when provider is SPI but there is no SPI implementation 8001562: Collator.getAvailableLocales() doesn't return all locales for which localized instances are available Reviewed-by: okutsu ! src/share/classes/sun/util/locale/provider/JRELocaleProviderAdapter.java ! src/share/classes/sun/util/locale/provider/LocaleServiceProviderPool.java + test/java/util/Locale/Bug8001562.java ! test/java/util/PluggableLocale/BreakIteratorProviderTest.java ! test/java/util/PluggableLocale/CollatorProviderTest.java ! test/java/util/PluggableLocale/DateFormatProviderTest.java ! test/java/util/PluggableLocale/DateFormatSymbolsProviderTest.java ! test/java/util/PluggableLocale/DecimalFormatSymbolsProviderTest.java ! test/java/util/PluggableLocale/GenericTest.java ! test/java/util/PluggableLocale/NumberFormatProviderTest.java From Ulf.Zibis at CoSoCo.de Wed Nov 7 23:30:30 2012 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Thu, 08 Nov 2012 00:30:30 +0100 Subject: Re-Request for Re-Review : 7088952 : Add "BYTES" constant to primitive wrapper classes In-Reply-To: <8E520A9F-7BCD-4665-B19E-9FF4D6841EE8@oracle.com> References: <8E520A9F-7BCD-4665-B19E-9FF4D6841EE8@oracle.com> Message-ID: <509AEF16.8070609@CoSoCo.de> I think, it would be more intuitive, to calculate the SIZE from the BYTES, e.g. SIZE = BYTES * 8. Ulf Am 08.11.2012 00:08, schrieb Mike Duigou: > Hello all; > > A long time ago [1] this patch was put forward for review. Though the request was approved the patch was never committed because some of the followup questions were not answered. > > The summary motivation for this issue is that measuring the size of the primitive types in bytes is more frequently used than bits because bytes are the minimum unit of allocation in Java. The proposed BYTES constant is a convenience to avoid many repetitions of Integer.SIZE / Byte.SIZE where the size in bytes is desired. There are many of these cases already in the JDK that are currently using locally defined constants or manifest constants ("magic" numbers) [2] that could benefit from this change to improve clarity. Many other external usages could take advantage of these constants as well. > > Unless there are objections I will go forward with pushing this change on Nov 9th, 2012 as originally reviewed with the original reviewers. > > http://cr.openjdk.java.net/~mduigou/7088952/0/webrev/ > > Mike > > [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-September/007753.html > [2] http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/00cd9dc3c2b5/src/share/classes/java/io/DataOutputStream.java From jonathan.gibbons at oracle.com Wed Nov 7 23:31:19 2012 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Wed, 07 Nov 2012 23:31:19 +0000 Subject: hg: jdk8/tl/langtools: 8000484: Bad error recovery when 'catch' without 'try' is found Message-ID: <20121107233121.3772C47827@hg.openjdk.java.net> Changeset: 19d6ba779759 Author: vromero Date: 2012-11-05 16:26 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/19d6ba779759 8000484: Bad error recovery when 'catch' without 'try' is found Reviewed-by: jjg, mcimadamore ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! test/tools/javac/diags/examples/CatchWithoutTry.java + test/tools/javac/incompleteStatements/T8000484.java + test/tools/javac/incompleteStatements/T8000484.out From lana.steuck at oracle.com Thu Nov 8 00:56:24 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Thu, 08 Nov 2012 00:56:24 +0000 Subject: hg: jdk8/tl/hotspot: 15 new changesets Message-ID: <20121108005653.89EFA47829@hg.openjdk.java.net> Changeset: a516debe2cee Author: amurillo Date: 2012-10-26 14:18 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a516debe2cee 8001663: new hotspot build - hs25-b08 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 5ec0c42da025 Author: coleenp Date: 2012-10-25 16:33 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5ec0c42da025 7188234: Deprecate VM command line options Summary: Remove support for the UseVectoredExceptions flag Reviewed-by: jcoomes, kamg Contributed-by: harold.seigel at oracle.com ! src/os/windows/vm/os_windows.cpp ! src/os_cpu/bsd_x86/vm/globals_bsd_x86.hpp ! src/os_cpu/bsd_zero/vm/globals_bsd_zero.hpp ! src/os_cpu/linux_sparc/vm/globals_linux_sparc.hpp ! src/os_cpu/linux_x86/vm/globals_linux_x86.hpp ! src/os_cpu/linux_zero/vm/globals_linux_zero.hpp ! src/os_cpu/solaris_sparc/vm/globals_solaris_sparc.hpp ! src/os_cpu/solaris_x86/vm/globals_solaris_x86.hpp ! src/os_cpu/windows_x86/vm/globals_windows_x86.hpp ! src/os_cpu/windows_x86/vm/os_windows_x86.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: e81fbc04a942 Author: coleenp Date: 2012-10-25 16:33 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e81fbc04a942 7191817: -XX:+UseSerialGC -XX:+UseLargePages crashes with SIGFPE on MacOS X Summary: Disable -XX:+UseLargePages for MacOS X Reviewed-by: dholmes, coleenp, sla Contributed-by: harold.seigel at oracle.com ! src/share/vm/runtime/arguments.cpp Changeset: 0af5da0c9d9d Author: sla Date: 2012-10-29 21:04 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/0af5da0c9d9d 8001619: Remove usage of _ALLBSD_SOURCE in bsd files Reviewed-by: coleenp, dholmes ! src/os/bsd/vm/attachListener_bsd.cpp ! src/os/bsd/vm/osThread_bsd.hpp ! src/os/bsd/vm/os_bsd.cpp ! src/os/bsd/vm/os_bsd.hpp ! src/os_cpu/bsd_x86/vm/bytes_bsd_x86.inline.hpp ! src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp ! src/os_cpu/bsd_zero/vm/os_bsd_zero.cpp Changeset: 39556eae08af Author: sspitsyn Date: 2012-10-29 11:35 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/39556eae08af 6533010: SPEC: A few broken links in jvmti.html Summary: Fix the incorrect links in jvmti.html reported by the LinkCheck tool Reviewed-by: jjh, dholmes Contributed-by: serguei.spitsyn at oracle.com ! src/share/vm/prims/jvmti.xml ! src/share/vm/prims/jvmtiEnvBase.hpp Changeset: 845129b692f6 Author: minqi Date: 2012-10-29 16:39 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/845129b692f6 Merge Changeset: a1b8cf9cf970 Author: sla Date: 2012-11-01 13:05 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a1b8cf9cf970 8002078: hs_err_pid file should report full JDK version string Reviewed-by: dholmes, sspitsyn, kmo ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/runtime/java.cpp ! src/share/vm/runtime/java.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/utilities/vmError.cpp Changeset: cae17c597196 Author: coleenp Date: 2012-11-01 11:57 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/cae17c597196 Merge ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/runtime/globals.hpp Changeset: 3fadc0e8cffe Author: jmasa Date: 2012-10-30 10:23 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3fadc0e8cffe 8000988: VM deadlock when running btree006 on windows-i586 Reviewed-by: johnc, jcoomes, ysr ! src/share/vm/memory/collectorPolicy.cpp Changeset: 3dfffc8b9722 Author: brutisso Date: 2012-10-30 20:26 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3dfffc8b9722 8001564: The load balancing function steal_1_random in taskqueue is not random Summary: Removes the two unused functions GenericTaskQueueSet::steal_1_random and GenericTaskQueueSet::steal_best_of_all Reviewed-by: brutisso, stefank Contributed-by: erik.x.helin at oracle.com ! src/share/vm/utilities/taskqueue.hpp Changeset: ca6d147ed881 Author: jcoomes Date: 2012-11-01 23:08 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ca6d147ed881 Merge Changeset: a3e2f723f2a5 Author: twisti Date: 2012-10-29 11:08 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a3e2f723f2a5 8000780: make Zero build and run with JDK8 Reviewed-by: coleenp, dholmes, twisti Contributed-by: Roman Kennke ! make/Makefile ! src/cpu/zero/vm/cppInterpreterGenerator_zero.hpp ! src/cpu/zero/vm/cppInterpreter_zero.cpp ! src/cpu/zero/vm/cppInterpreter_zero.hpp ! src/cpu/zero/vm/frame_zero.cpp ! src/cpu/zero/vm/frame_zero.inline.hpp ! src/cpu/zero/vm/icBuffer_zero.cpp ! src/cpu/zero/vm/methodHandles_zero.cpp ! src/cpu/zero/vm/methodHandles_zero.hpp ! src/cpu/zero/vm/register_zero.hpp ! src/cpu/zero/vm/relocInfo_zero.cpp ! src/cpu/zero/vm/sharedRuntime_zero.cpp ! src/share/vm/asm/codeBuffer.cpp ! src/share/vm/interpreter/abstractInterpreter.hpp ! src/share/vm/interpreter/bytecodeInterpreter.cpp ! src/share/vm/interpreter/bytecodeInterpreter.hpp ! src/share/vm/interpreter/cppInterpreter.cpp ! src/share/vm/interpreter/interpreter.cpp ! src/share/vm/interpreter/templateInterpreter.cpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/utilities/macros.hpp Changeset: d8f9034920f6 Author: amurillo Date: 2012-11-02 04:06 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d8f9034920f6 Merge Changeset: 8cb93eadfb6d Author: amurillo Date: 2012-11-02 07:35 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8cb93eadfb6d Merge ! src/share/vm/runtime/arguments.cpp Changeset: 5920f72e799c Author: amurillo Date: 2012-11-02 07:35 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5920f72e799c Added tag hs25-b08 for changeset 8cb93eadfb6d ! .hgtags From jonathan.gibbons at oracle.com Thu Nov 8 01:01:23 2012 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Thu, 08 Nov 2012 01:01:23 +0000 Subject: hg: jdk8/tl/langtools: 8002157: Write combo compiler tests for repeating annotations for JDK8 Message-ID: <20121108010125.2E30A4782A@hg.openjdk.java.net> Changeset: 2986e7052952 Author: jjg Date: 2012-11-07 17:01 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/2986e7052952 8002157: Write combo compiler tests for repeating annotations for JDK8 Reviewed-by: darcy, jjg Contributed-by: sonali.goel at oracle.com + test/tools/javac/annotations/repeatingAnnotations/combo/BasicSyntaxCombo.java + test/tools/javac/annotations/repeatingAnnotations/combo/DeprecatedAnnoCombo.java + test/tools/javac/annotations/repeatingAnnotations/combo/DocumentedAnnoCombo.java + test/tools/javac/annotations/repeatingAnnotations/combo/Helper.java + test/tools/javac/annotations/repeatingAnnotations/combo/InheritedAnnoCombo.java + test/tools/javac/annotations/repeatingAnnotations/combo/RetentionAnnoCombo.java From jonathan.gibbons at oracle.com Thu Nov 8 01:20:43 2012 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Thu, 08 Nov 2012 01:20:43 +0000 Subject: hg: jdk8/tl/langtools: 8003134: CheckResourceKeys issues Message-ID: <20121108012045.C66C94782B@hg.openjdk.java.net> Changeset: a1dc543483fc Author: jjg Date: 2012-11-07 17:20 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/a1dc543483fc 8003134: CheckResourceKeys issues Reviewed-by: jjh, bpatel ! src/share/classes/com/sun/tools/doclets/formats/html/resources/standard.properties ! test/tools/javac/diags/CheckResourceKeys.java ! test/tools/javadoc/CheckResourceKeys.java From jonathan.gibbons at oracle.com Thu Nov 8 01:40:23 2012 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Thu, 08 Nov 2012 01:40:23 +0000 Subject: hg: jdk8/tl/jdk: 8001598: Augment ElementType enum for JSR 308 Message-ID: <20121108014034.BB01D47831@hg.openjdk.java.net> Changeset: 599f231cba97 Author: jfranck Date: 2012-11-07 17:39 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/599f231cba97 8001598: Augment ElementType enum for JSR 308 Reviewed-by: darcy ! src/share/classes/java/lang/annotation/ElementType.java From david.holmes at oracle.com Thu Nov 8 03:47:25 2012 From: david.holmes at oracle.com (David Holmes) Date: Thu, 08 Nov 2012 13:47:25 +1000 Subject: [PATCH FOR REVIEW] ResourceManager.getApplicationResources() does not close InputStreams In-Reply-To: <381508571.6800833.1352323067975.JavaMail.root@redhat.com> References: <381508571.6800833.1352323067975.JavaMail.root@redhat.com> Message-ID: <509B2B4D.5040508@oracle.com> On 8/11/2012 7:17 AM, Andrew Hughes wrote: > ----- Original Message ----- >> The bug number is 8003120 >> > > Thanks. Pushed to tl: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f51943263267 I did not construe Lance's mail to indicate an approval to push. The turnaround on this was just a bit too quick in my opinion. David >> Best >> Lance >> On Nov 7, 2012, at 3:30 PM, Andrew Hughes wrote: >> >>> IcedTea bug: >>> http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=1197 >>> >>> com.sun.naming.internal.ResourceManager.getApplicationResources() >>> does not close the input streams it gets from >>> helper.getResources() and helper.getJavaHomeLibStream(). This >>> patch: >>> >>> http://cr.openjdk.java.net/~andrew/pr1197/webrev.01/ >>> >>> adds finally blocks to close these streams. As noted in the >>> original bug report, this has been tested on a J2EE >>> server (JBoss) without issue. >>> >>> I realise that there's a possibility that try-with-resources could >>> be used here, but the patch as posted >>> is the one that was tested and I don't want to negate that testing >>> by changing it. >>> >>> Ok for tl? If so, can I have a bug ID for this? >>> >>> 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 >>> >> >> >> >> 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 xueming.shen at oracle.com Thu Nov 8 04:36:30 2012 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Thu, 08 Nov 2012 04:36:30 +0000 Subject: hg: jdk8/tl/jdk: 6282196: There should be Math.mod(number, modulo) methods Message-ID: <20121108043642.2EE4E47839@hg.openjdk.java.net> Changeset: cdf02b372956 Author: sherman Date: 2012-11-07 20:50 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cdf02b372956 6282196: There should be Math.mod(number, modulo) methods Summary: added the requested methods Reviewed-by: darcy, emcmanus, alanb Contributed-by: roger.riggs at oracle.com ! src/share/classes/java/lang/Math.java ! src/share/classes/java/lang/StrictMath.java + test/java/lang/Math/DivModTests.java From Alan.Bateman at oracle.com Thu Nov 8 07:02:22 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 08 Nov 2012 07:02:22 +0000 Subject: [PATCH FOR REVIEW] ResourceManager.getApplicationResources() does not close InputStreams In-Reply-To: <61857660.6790276.1352321474076.JavaMail.root@redhat.com> References: <61857660.6790276.1352321474076.JavaMail.root@redhat.com> Message-ID: <509B58FE.1030808@oracle.com> On 07/11/2012 20:51, Andrew Hughes wrote: > : > > As you can see on the IcedTea bug, I've asked the same question. > I'd have preferred it to use try-with-resources myself (easier to > follow for one thing), but given the patch is as it is, I'm now > wary about changing it and negating the existing testing that's > already been done. > I see you've pushed this already but I think we need to open a follow-on bug on this as it looks like there is additional work to do. Particularly the case where there are several streams and close fails (looks to me that it will not attempt to close all streams in that case). Also, given that the target is jdk8 then it seems reasonable to see if try-with-resources could be used for the second case, I assume the testing you mentioned was with a different release. The other thing is that we try to include a regression test with all fixes where possible, I don't know how feasible it for this case. -Alan. From staffan.larsen at oracle.com Thu Nov 8 08:44:48 2012 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 8 Nov 2012 09:44:48 +0100 Subject: Preliminary review: Adding tracing of I/O calls In-Reply-To: <20121107222210.19310AA9@eggemoggin.niobe.net> References: <20121107222210.19310AA9@eggemoggin.niobe.net> Message-ID: On 7 nov 2012, at 23:22, mark.reinhold at oracle.com wrote: > 2012/11/2 11:36 -0700, staffan.larsen at oracle.com: >> Webrev: http://cr.openjdk.java.net/~sla/iotrace/webrev.00/ > > Who (or what) is the intended consumer of the sun.misc.IoTrace and > IoTraceListener APIs? In other words, are these meant to be stable > external interfaces that we're going to support for use by arbitrary > code over the long term? The primary intended consumer is Java Flight Recorder which is JDK internal. > The reason I ask is that sun.misc is likely to go away in JDK 9, as > part of the modularization work. If these APIs are meant to be used > by any code outside of the JDK then we should probably put them in > a more appropriate package now in order to avoid pain later on. I don't have any preferences. Can you suggest a better package? Thanks, /Staffan From jvanalte at redhat.com Thu Nov 8 17:37:39 2012 From: jvanalte at redhat.com (Jon VanAlten) Date: Thu, 8 Nov 2012 12:37:39 -0500 (EST) Subject: Preliminary review: Adding tracing of I/O calls In-Reply-To: Message-ID: <1036761529.8258279.1352396259583.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Staffan Larsen" > To: "mark reinhold" > Cc: core-libs-dev at openjdk.java.net > Sent: Thursday, November 8, 2012 3:44:48 AM > Subject: Re: Preliminary review: Adding tracing of I/O calls > > > On 7 nov 2012, at 23:22, mark.reinhold at oracle.com wrote: > > > 2012/11/2 11:36 -0700, staffan.larsen at oracle.com: > >> Webrev: http://cr.openjdk.java.net/~sla/iotrace/webrev.00/ > > > > Who (or what) is the intended consumer of the sun.misc.IoTrace and > > IoTraceListener APIs? In other words, are these meant to be stable > > external interfaces that we're going to support for use by > > arbitrary > > code over the long term? > > The primary intended consumer is Java Flight Recorder which is JDK > internal. > > > The reason I ask is that sun.misc is likely to go away in JDK 9, as > > part of the modularization work. If these APIs are meant to be > > used > > by any code outside of the JDK then we should probably put them in > > a more appropriate package now in order to avoid pain later on. > > I don't have any preferences. Can you suggest a better package? > I don't have a particular suggestion, but would like to just chime in and say that there is interest in API such as this being public and stable and available for use in tools targeting OpenJDK at some point. (My understanding is that Java Flight Recorder is not part of OpenJDK) thanks, jon From sean.mullan at oracle.com Thu Nov 8 17:56:43 2012 From: sean.mullan at oracle.com (sean.mullan at oracle.com) Date: Thu, 08 Nov 2012 17:56:43 +0000 Subject: hg: jdk8/tl/jdk: 7198416: CertificateIssuerName and CertificateSubjectName are redundant Message-ID: <20121108175709.3EE794785E@hg.openjdk.java.net> Changeset: 1e7dd9e05ce2 Author: mullan Date: 2012-11-08 12:51 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1e7dd9e05ce2 7198416: CertificateIssuerName and CertificateSubjectName are redundant Reviewed-by: mullan Contributed-by: jason.uh at oracle.com ! src/share/classes/sun/security/pkcs/PKCS7.java ! src/share/classes/sun/security/tools/jarsigner/Main.java ! src/share/classes/sun/security/tools/keytool/CertAndKeyGen.java ! src/share/classes/sun/security/tools/keytool/Main.java ! src/share/classes/sun/security/x509/X509CertImpl.java ! src/share/classes/sun/security/x509/X509CertInfo.java ! src/share/classes/sun/security/x509/certAttributes.html ! test/sun/security/pkcs11/rsa/GenKeyStore.java ! test/sun/security/provider/X509Factory/BigCRL.java ! test/sun/security/rsa/GenKeyStore.java From mark.reinhold at oracle.com Thu Nov 8 23:33:08 2012 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 08 Nov 2012 15:33:08 -0800 Subject: Discussion list for revisions to the JDBC specification Message-ID: <20121108233308.40F53B54@eggemoggin.niobe.net> With Alan's blessing I've created an additional list under the purview of the Core Libraries Group, jdbc-spec-discuss [1]. This list is intended to host discussions of revisions to the JDBC specification (JSR 221). Lance Andersen, the JDBC Spec Lead, is the list moderator. - Mark [1] http://mail.openjdk.java.net/mailman/listinfo/jdbc-spec-discuss From dingxmin at linux.vnet.ibm.com Fri Nov 9 03:01:44 2012 From: dingxmin at linux.vnet.ibm.com (Frank Ding) Date: Fri, 09 Nov 2012 11:01:44 +0800 Subject: JDBC bug: Incorrect number of conflicts is reported by CachedRowSetWriter.writeData Message-ID: <509C7218.4020807@linux.vnet.ibm.com> Hi guys, We discovered a bug in CachedRowSetWriter.writeData method where incorrect number of conflicts is reported. I searched in Oracle bug database and no similar record was found. So I submitted a new one whose internal review ID is 2376620. A test case with code is illustrated in the bug submission that leverages PostgreSQL server but the issue is platform independent and easy to reproduce. I provided a patch review, available @ http://cr.openjdk.java.net/~dingxmin/2376620/webrev.01/ Is there anybody who is interested in patch and can also review bug 2376620? Your reply is appreciated. Best regards, Frank From zhouyx at linux.vnet.ibm.com Fri Nov 9 04:31:39 2012 From: zhouyx at linux.vnet.ibm.com (Sean Chou) Date: Fri, 9 Nov 2012 12:31:39 +0800 Subject: Request for review: 7201156 : jar tool fails to convert file separation characters for list and extract In-Reply-To: <509A3508.3010205@oracle.com> References: <509A3508.3010205@oracle.com> Message-ID: Hello Chris, Alan, and Xueming, I added the testcase, please take a look. webrev: http://cr.openjdk.java.net/~zhouyx/7201156/webrev.01/ On Wed, Nov 7, 2012 at 6:16 PM, Chris Hegarty wrote: > The change looks fine to me. > > I wonder if it is worth creating an automatic regression test to verify > this change ( so an future regression in behavior gets caught early ). You > could call sun.tools.jar.Main directly passing suitable streams to check > the output. > > -Chris. > > > On 07/11/2012 08:31, Sean Chou wrote: > >> Hello, >> >> This is the suggested fix described in sun bug 7201156 page. Please take a >> look. >> >> sunbug: http://bugs.sun.com/**bugdatabase/view_bug.do?bug_**id=7201156 >> webrev: http://cr.openjdk.java.net/~**zhouyx/7201156/webrev.00/ >> >> -- Best Regards, Sean Chou From xuelei.fan at oracle.com Fri Nov 9 09:16:11 2012 From: xuelei.fan at oracle.com (xuelei.fan at oracle.com) Date: Fri, 09 Nov 2012 09:16:11 +0000 Subject: hg: jdk8/tl/jdk: 8001569: Regression test GetPeerHost uses static port number Message-ID: <20121109091637.AFF6A47888@hg.openjdk.java.net> Changeset: 9edfa0e761b9 Author: xuelei Date: 2012-11-09 01:15 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9edfa0e761b9 8001569: Regression test GetPeerHost uses static port number Reviewed-by: weijun ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/ServerHandshaker/GetPeerHost.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/ServerHandshaker/GetPeerHostClient.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/ServerHandshaker/GetPeerHostServer.java From chris.hegarty at oracle.com Fri Nov 9 09:57:03 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 09 Nov 2012 09:57:03 +0000 Subject: Request for review: 7201156 : jar tool fails to convert file separation characters for list and extract In-Reply-To: References: <509A3508.3010205@oracle.com> Message-ID: <509CD36F.8060605@oracle.com> Sean, Thank you for adding a test. Rather than creating a dependency on rt.jar it may be best to have the test use the java.util.jar API to create a small temporary jar file. The problem with the dependency on rt.jar is that the test will fail if run against a development build where the images have not been created ( run against an exploded classes directory ). -Chris. On 09/11/2012 04:31, Sean Chou wrote: > Hello Chris, Alan, and Xueming, > > I added the testcase, please take a look. > > webrev: http://cr.openjdk.java.net/~zhouyx/7201156/webrev.01/ > > > > > On Wed, Nov 7, 2012 at 6:16 PM, Chris Hegarty > wrote: > > The change looks fine to me. > > I wonder if it is worth creating an automatic regression test to > verify this change ( so an future regression in behavior gets caught > early ). You could call sun.tools.jar.Main directly passing suitable > streams to check the output. > > -Chris. > > > On 07/11/2012 08:31, Sean Chou wrote: > > Hello, > > This is the suggested fix described in sun bug 7201156 page. > Please take a > look. > > sunbug: > http://bugs.sun.com/__bugdatabase/view_bug.do?bug___id=7201156 > > webrev: http://cr.openjdk.java.net/~__zhouyx/7201156/webrev.00/ > > > > > > -- > Best Regards, > Sean Chou > From Lance.Andersen at oracle.com Fri Nov 9 11:41:56 2012 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Fri, 9 Nov 2012 06:41:56 -0500 Subject: JDBC bug: Incorrect number of conflicts is reported by CachedRowSetWriter.writeData In-Reply-To: <509C7218.4020807@linux.vnet.ibm.com> References: <509C7218.4020807@linux.vnet.ibm.com> Message-ID: Frank, If you can please post the bug info here, I will take a look at your patch Best Lance On Nov 8, 2012, at 10:01 PM, Frank Ding wrote: > Hi guys, > We discovered a bug in CachedRowSetWriter.writeData method where incorrect number of conflicts is reported. I searched in Oracle bug database and no similar record was found. So I submitted a new one whose internal review ID is 2376620. A test case with code is illustrated in the bug submission that leverages PostgreSQL server but the issue is platform independent and easy to reproduce. > I provided a patch review, available @ > http://cr.openjdk.java.net/~dingxmin/2376620/webrev.01/ > Is there anybody who is interested in patch and can also review bug 2376620? Your reply is appreciated. > > Best regards, > Frank > > -------------- next part -------------- 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 Alan.Bateman at oracle.com Fri Nov 9 14:13:30 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 09 Nov 2012 14:13:30 +0000 Subject: Request for review: 7201156 : jar tool fails to convert file separation characters for list and extract In-Reply-To: References: <509A3508.3010205@oracle.com> Message-ID: <509D0F8A.4030909@oracle.com> On 09/11/2012 04:31, Sean Chou wrote: > Hello Chris, Alan, and Xueming, > > I added the testcase, please take a look. > > webrev: http://cr.openjdk.java.net/~zhouyx/7201156/webrev.01/ > Thanks for adding a test, I agree with Chris that it would be great if the test didn't use rt.jar. As Chris mentions, rt.jar is only created for images builds and most of it working on the JDK doesn't bother with images. Also rt.jar will go away once we move to modules. One other comment on the test is that it only exercises the "t" option, I think the issue that is being fixed also impacts the extract ("x") option. -Alan From jim.gish at oracle.com Fri Nov 9 21:37:02 2012 From: jim.gish at oracle.com (Jim Gish) Date: Fri, 09 Nov 2012 16:37:02 -0500 Subject: RFR: 6244047: impossible to specify directories to logging FileHandler unless they exist Message-ID: <509D777E.9020603@oracle.com> Please review http://cr.openjdk.java.net/~jgish/Bug6244047-FileHandler-CheckLockLocation/ This updates the logging FileHandler to actually check the directory passed to it via the pattern to ensure that it exists and is writable. It does this before going into the loop to create lock files there which will fail repeatedly if the directory specified is invalid. If the file specified does not exist, or is not a directory or not writable, an IOException with a precise message is thrown. Note that this fix does not do as some users would like, which is to go ahead and create directories that don't exist. 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 jason_mehrens at hotmail.com Fri Nov 9 22:41:22 2012 From: jason_mehrens at hotmail.com (Jason Mehrens) Date: Fri, 9 Nov 2012 16:41:22 -0600 Subject: RFR: 6244047: impossible to specify directories to logging FileHandler unless they exist In-Reply-To: <509D777E.9020603@oracle.com> References: <509D777E.9020603@oracle.com> Message-ID: Jim, You might just want to change the code to create and close a FileOutputStream in a way that doesn't truncate or damage the target file. Or maybe use the NIO file code if that is possible. See BUG ID 4420020. Jason > Date: Fri, 9 Nov 2012 16:37:02 -0500 > From: jim.gish at oracle.com > To: core-libs-dev at openjdk.java.net > Subject: RFR: 6244047: impossible to specify directories to logging FileHandler unless they exist > > Please review > http://cr.openjdk.java.net/~jgish/Bug6244047-FileHandler-CheckLockLocation/ > > > This updates the logging FileHandler to actually check the directory > passed to it via the pattern to ensure that it exists and is writable. > It does this before going into the loop to create lock files there which > will fail repeatedly if the directory specified is invalid. If the file > specified does not exist, or is not a directory or not writable, an > IOException with a precise message is thrown. > > Note that this fix does not do as some users would like, which is to go > ahead and create directories that don't exist. > > 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 Alan.Bateman at oracle.com Sat Nov 10 10:54:47 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 10 Nov 2012 10:54:47 +0000 Subject: RFR: 6244047: impossible to specify directories to logging FileHandler unless they exist In-Reply-To: References: <509D777E.9020603@oracle.com> Message-ID: <509E3277.7010607@oracle.com> On 09/11/2012 22:41, Jason Mehrens wrote: > Jim, > > You might just want to change the code to create and close a FileOutputStream in a way that doesn't truncate or damage the target file. Or maybe use the NIO file code if that is possible. See BUG ID 4420020. > > Jason I think so too. As it needs a FileChannel anyway, then it may be simpler to just use FileChannel.open(lf, WRITE), that won't truncate the file and will also throw a useful IOException in the event that it fails. As there are specific IOException thrown for specific cases then it may be possible to eliminate the loop completely for I/O error cases. -Alan From alan.bateman at oracle.com Sun Nov 11 10:07:13 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Sun, 11 Nov 2012 10:07:13 +0000 Subject: hg: jdk8/tl/jdk: 8003253: TEST_BUG: java/nio/channels/AsynchronousChannelGroup/Unbounded.java hang intermittently [win] Message-ID: <20121111100804.8CEDB478D8@hg.openjdk.java.net> Changeset: c3e7ceb22d37 Author: alanb Date: 2012-11-11 10:05 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c3e7ceb22d37 8003253: TEST_BUG: java/nio/channels/AsynchronousChannelGroup/Unbounded.java hang intermittently [win] Reviewed-by: chegar ! test/java/nio/channels/AsynchronousChannelGroup/Unbounded.java From masayoshi.okutsu at oracle.com Mon Nov 12 04:13:57 2012 From: masayoshi.okutsu at oracle.com (masayoshi.okutsu at oracle.com) Date: Mon, 12 Nov 2012 04:13:57 +0000 Subject: hg: jdk8/tl/jdk: 8000986: Split java.util.spi.CalendarDataProvider into week parameters and field names portions Message-ID: <20121112041415.7B2E7478E0@hg.openjdk.java.net> Changeset: 5d3f8f9e6c58 Author: okutsu Date: 2012-11-12 11:12 +0900 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5d3f8f9e6c58 8000986: Split java.util.spi.CalendarDataProvider into week parameters and field names portions Reviewed-by: naoto ! make/java/java/FILES_java.gmk ! src/macosx/classes/sun/util/locale/provider/HostLocaleProviderAdapterImpl.java ! src/share/classes/java/util/Calendar.java ! src/share/classes/java/util/spi/CalendarDataProvider.java + src/share/classes/java/util/spi/CalendarNameProvider.java ! src/share/classes/sun/util/locale/provider/AuxLocaleProviderAdapter.java ! src/share/classes/sun/util/locale/provider/CalendarDataProviderImpl.java ! src/share/classes/sun/util/locale/provider/CalendarDataUtility.java + src/share/classes/sun/util/locale/provider/CalendarNameProviderImpl.java ! src/share/classes/sun/util/locale/provider/JRELocaleProviderAdapter.java ! src/share/classes/sun/util/locale/provider/LocaleProviderAdapter.java ! src/share/classes/sun/util/locale/provider/SPILocaleProviderAdapter.java ! src/windows/classes/sun/util/locale/provider/HostLocaleProviderAdapterImpl.java ! test/java/util/PluggableLocale/CalendarDataProviderTest.java ! test/java/util/PluggableLocale/CalendarDataProviderTest.sh + test/java/util/PluggableLocale/CalendarNameProviderTest.java + test/java/util/PluggableLocale/CalendarNameProviderTest.sh ! test/java/util/PluggableLocale/GenericTest.java ! test/java/util/PluggableLocale/barprovider.jar ! test/java/util/PluggableLocale/fooprovider.jar ! test/java/util/PluggableLocale/providersrc/CalendarDataProviderImpl.java + test/java/util/PluggableLocale/providersrc/CalendarNameProviderImpl.java ! test/java/util/PluggableLocale/providersrc/Makefile + test/java/util/PluggableLocale/providersrc/java.util.spi.CalendarNameProvider From weijun.wang at oracle.com Mon Nov 12 08:43:26 2012 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 12 Nov 2012 16:43:26 +0800 Subject: Code review request: 8003263: redundant cast build failure after 8003120 Message-ID: <50A0B6AE.9020401@oracle.com> A small webrev: http://cr.openjdk.java.net/~weijun/8003263/webrev.00/ The reason is that 8003120 added a new line InputStream istream = (InputStream)resources.next(); but resources is already of type NamingEnumeration. Building now shows ../../../src/share/classes/com/sun/naming/internal/ResourceManager.java:563: warning: [cast] redundant cast to InputStream InputStream istream = (InputStream)resources.next(); Noreg-trivial. Thanks Max From zhouyx at linux.vnet.ibm.com Mon Nov 12 09:08:59 2012 From: zhouyx at linux.vnet.ibm.com (Sean Chou) Date: Mon, 12 Nov 2012 17:08:59 +0800 Subject: Request for review: 7201156 : jar tool fails to convert file separation characters for list and extract In-Reply-To: <509D0F8A.4030909@oracle.com> References: <509A3508.3010205@oracle.com> <509D0F8A.4030909@oracle.com> Message-ID: Hi , I didn't realize that rt.jar would miss before. The testcase is updated to create a temp file as well as test the extract option. However, extract testing will create a directory if it passes, I just deleted it in testcase. Please take a look. webrev: http://cr.openjdk.java.net/~zhouyx/7201156/webrev.02/ . On Fri, Nov 9, 2012 at 10:13 PM, Alan Bateman wrote: > On 09/11/2012 04:31, Sean Chou wrote: > >> Hello Chris, Alan, and Xueming, >> >> I added the testcase, please take a look. >> >> webrev: http://cr.openjdk.java.net/~**zhouyx/7201156/webrev.01/ >> >> Thanks for adding a test, I agree with Chris that it would be great if > the test didn't use rt.jar. As Chris mentions, rt.jar is only created for > images builds and most of it working on the JDK doesn't bother with images. > Also rt.jar will go away once we move to modules. > > One other comment on the test is that it only exercises the "t" option, I > think the issue that is being fixed also impacts the extract ("x") option. > > -Alan > -- Best Regards, Sean Chou From Alan.Bateman at oracle.com Mon Nov 12 09:42:42 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 12 Nov 2012 09:42:42 +0000 Subject: Code review request: 8003263: redundant cast build failure after 8003120 In-Reply-To: <50A0B6AE.9020401@oracle.com> References: <50A0B6AE.9020401@oracle.com> Message-ID: <50A0C492.6070500@oracle.com> On 12/11/2012 08:43, Weijun Wang wrote: > A small webrev: > > http://cr.openjdk.java.net/~weijun/8003263/webrev.00/ > > The reason is that 8003120 added a new line > > InputStream istream = (InputStream)resources.next(); > > but resources is already of type NamingEnumeration. > > Building now shows > > ../../../src/share/classes/com/sun/naming/internal/ResourceManager.java:563: > warning: [cast] redundant cast to InputStream > InputStream istream = > (InputStream)resources.next(); > > Noreg-trivial. Looks okay to me, just wondering if we should do a more complete fix for 8003120 while you are there (meaning it should attempt to close all resources even if there is an IOException is thrown during close). -Alan From Alan.Bateman at oracle.com Mon Nov 12 10:00:52 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 12 Nov 2012 10:00:52 +0000 Subject: Request for review: 7201156 : jar tool fails to convert file separation characters for list and extract In-Reply-To: References: <509A3508.3010205@oracle.com> <509D0F8A.4030909@oracle.com> Message-ID: <50A0C8D4.6080901@oracle.com> On 12/11/2012 09:08, Sean Chou wrote: > Hi , > > I didn't realize that rt.jar would miss before. The testcase is > updated to create a temp file as well as test the extract option. > However, extract testing will create a directory if it passes, I just > deleted it in testcase. Please take a look. > > webrev: http://cr.openjdk.java.net/~zhouyx/7201156/webrev.02/ > . > Thanks for removing the dependency on rt.jar. A couple of comments on the updated test: - in main then it still has "pathRtJar" so I assume you just forgot to rename that. - it would be good to change createJarFile to use try-with-resources so that an error doesn't cause it to terminate with an open file. - testJarExact, I assume you intended to name this testJarExtract. - L114-117, the "./" is not needed. It would be okay to leave those files there if you want, jtreg will clean them up too. -Alan. From weijun.wang at oracle.com Mon Nov 12 10:22:52 2012 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 12 Nov 2012 18:22:52 +0800 Subject: Code review request: 8003263: redundant cast build failure after 8003120 In-Reply-To: <50A0C492.6070500@oracle.com> References: <50A0B6AE.9020401@oracle.com> <50A0C492.6070500@oracle.com> Message-ID: <50A0CDFC.50302@oracle.com> In fact, it looks like the resources object here is of type InputStreamEnumeration (in com/sun/naming/internal/VersionHelper12.java), with an open-on-nextElement style. This means we can completely remove the while (resources.hasMore()) block. Lance and Andrew added for confirmation. Thanks Max On 11/12/2012 05:42 PM, Alan Bateman wrote: > On 12/11/2012 08:43, Weijun Wang wrote: >> A small webrev: >> >> http://cr.openjdk.java.net/~weijun/8003263/webrev.00/ >> >> The reason is that 8003120 added a new line >> >> InputStream istream = (InputStream)resources.next(); >> >> but resources is already of type NamingEnumeration. >> >> Building now shows >> >> ../../../src/share/classes/com/sun/naming/internal/ResourceManager.java:563: >> warning: [cast] redundant cast to InputStream >> InputStream istream = >> (InputStream)resources.next(); >> >> Noreg-trivial. > Looks okay to me, just wondering if we should do a more complete fix for > 8003120 while you are there (meaning it should attempt to close all > resources even if there is an IOException is thrown during close). > > -Alan From Ulf.Zibis at CoSoCo.de Mon Nov 12 10:49:07 2012 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Mon, 12 Nov 2012 11:49:07 +0100 Subject: Code review request: 8003263: redundant cast build failure after 8003120 In-Reply-To: <50A0CDFC.50302@oracle.com> References: <50A0B6AE.9020401@oracle.com> <50A0C492.6070500@oracle.com> <50A0CDFC.50302@oracle.com> Message-ID: <50A0D423.4000300@CoSoCo.de> Hi, anyway you could use a one-liner: resources.next().close(); -Ulf Am 12.11.2012 11:22, schrieb Weijun Wang: > In fact, it looks like the resources object here is of type InputStreamEnumeration (in > com/sun/naming/internal/VersionHelper12.java), with an open-on-nextElement style. This means we > can completely remove the while (resources.hasMore()) block. > > Lance and Andrew added for confirmation. > > Thanks > Max > > On 11/12/2012 05:42 PM, Alan Bateman wrote: >> On 12/11/2012 08:43, Weijun Wang wrote: >>> A small webrev: >>> >>> http://cr.openjdk.java.net/~weijun/8003263/webrev.00/ >>> >>> The reason is that 8003120 added a new line >>> >>> InputStream istream = (InputStream)resources.next(); >>> >>> but resources is already of type NamingEnumeration. >>> >>> Building now shows >>> >>> ../../../src/share/classes/com/sun/naming/internal/ResourceManager.java:563: >>> warning: [cast] redundant cast to InputStream >>> InputStream istream = >>> (InputStream)resources.next(); >>> >>> Noreg-trivial. >> Looks okay to me, just wondering if we should do a more complete fix for >> 8003120 while you are there (meaning it should attempt to close all >> resources even if there is an IOException is thrown during close). >> >> -Alan > From jim.gish at oracle.com Mon Nov 12 23:22:47 2012 From: jim.gish at oracle.com (Jim Gish) Date: Mon, 12 Nov 2012 18:22:47 -0500 Subject: RFR: 6244047: impossible to specify directories to logging FileHandler unless they exist In-Reply-To: <509E3277.7010607@oracle.com> References: <509D777E.9020603@oracle.com> <509E3277.7010607@oracle.com> Message-ID: <50A184C7.4050706@oracle.com> Which file(s) are you concerned about truncating/damaging? The code I'm impacting is for creating a new lock file. Where is the potential for truncating/damaging that you both are referring to? Is this sufficient (plus the proper exception handling of course) ? //lockStream = new FileOutputStream(lockFileName); fc = FileChannel.open(new File(lockFileName).toPath(), CREATE_NEW, WRITE); //fc = lockStream.getChannel(); Thanks, Jim On 11/10/2012 05:54 AM, Alan Bateman wrote: > On 09/11/2012 22:41, Jason Mehrens wrote: >> Jim, >> >> You might just want to change the code to create and close a >> FileOutputStream in a way that doesn't truncate or damage the target >> file. Or maybe use the NIO file code if that is possible. See BUG >> ID 4420020. >> >> Jason > I think so too. As it needs a FileChannel anyway, then it may be > simpler to just use FileChannel.open(lf, WRITE), that won't truncate > the file and will also throw a useful IOException in the event that it > fails. As there are specific IOException thrown for specific cases > then it may be possible to eliminate the loop completely for I/O error > cases. > > -Alan -- 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 dingxmin at linux.vnet.ibm.com Tue Nov 13 02:25:42 2012 From: dingxmin at linux.vnet.ibm.com (Frank Ding) Date: Tue, 13 Nov 2012 10:25:42 +0800 Subject: JDBC bug: Incorrect number of conflicts is reported by CachedRowSetWriter.writeData In-Reply-To: References: <509C7218.4020807@linux.vnet.ibm.com> Message-ID: <50A1AFA6.8010905@linux.vnet.ibm.com> Hi Lance Thanks for your quick response. Please find the bug info below. The problem: When CachedRowSetImpl.acceptChanges() is called, incorrect number of conflicts, if any, is reported. The number of conflicts is the actual number of existing rows in database, which is the size of variable 'status' defined in CachedRowSetWriter.writeData(). It's not the conflict number that is supposed to be. Test case: The bug can be easily manifested in all SQL server environment. Here take PostgreSQL for example. 1. The sql script to create a table CREATE TABLE ressystem.roomdescription ( roomdescription_id serial NOT NULL, roomdescription character varying NOT NULL, CONSTRAINT roomdescription_pkey PRIMARY KEY (roomdescription_id) ) 2. Manually insert 3 rows (1, "Test 1") (2, "Test 2") (3, "Test 3") 3. Create a Java class that connects the established database and then execute the following code snippet. String query = "select roomdescription_id, roomdescription from ressystem.roomdescription"; Object[] values = {2, "Test2"}; rs.setCommand(query); rs.execute(conn); rs.moveToInsertRow(); for(int i=0; i Frank, > > If you can please post the bug info here, I will take a look at your patch > > Best > Lance > On Nov 8, 2012, at 10:01 PM, Frank Ding wrote: > >> Hi guys, >> We discovered a bug in CachedRowSetWriter.writeData method where incorrect number of conflicts is reported. I searched in Oracle bug database and no similar record was found. So I submitted a new one whose internal review ID is 2376620. A test case with code is illustrated in the bug submission that leverages PostgreSQL server but the issue is platform independent and easy to reproduce. >> I provided a patch review, available @ >> http://cr.openjdk.java.net/~dingxmin/2376620/webrev.01/ >> Is there anybody who is interested in patch and can also review bug 2376620? Your reply is appreciated. >> >> Best regards, >> Frank >> >> > > > 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 zhouyx at linux.vnet.ibm.com Tue Nov 13 03:17:58 2012 From: zhouyx at linux.vnet.ibm.com (Sean Chou) Date: Tue, 13 Nov 2012 11:17:58 +0800 Subject: Request for review: 7201156 : jar tool fails to convert file separation characters for list and extract In-Reply-To: <50A0C8D4.6080901@oracle.com> References: <509A3508.3010205@oracle.com> <509D0F8A.4030909@oracle.com> <50A0C8D4.6080901@oracle.com> Message-ID: Hi Alan, Here is the updated webrev: http://cr.openjdk.java.net/~zhouyx/7201156/webrev.03/ . On Mon, Nov 12, 2012 at 6:00 PM, Alan Bateman wrote: > On 12/11/2012 09:08, Sean Chou wrote: > >> Hi , >> >> I didn't realize that rt.jar would miss before. The testcase is updated >> to create a temp file as well as test the extract option. However, extract >> testing will create a directory if it passes, I just deleted it in >> testcase. Please take a look. >> >> webrev: http://cr.openjdk.java.net/~**zhouyx/7201156/webrev.02/< >> http://cr.openjdk.java.net/%**7Ezhouyx/7201156/webrev.02/> >> . >> >> Thanks for removing the dependency on rt.jar. > > A couple of comments on the updated test: > > - in main then it still has "pathRtJar" so I assume you just forgot to > rename that. > I forgot the name had its meaning. > > - it would be good to change createJarFile to use try-with-resources so > that an error doesn't cause it to terminate with an open file. > Changed. > > - testJarExact, I assume you intended to name this testJarExtract. > Yes! > > - L114-117, the "./" is not needed. It would be okay to leave those files > there if you want, jtreg will clean them up too. Thanks for the hint. I removed these lines, so the testcase looks tidy. > > > -Alan. > > > -- Best Regards, Sean Chou From staffan.larsen at oracle.com Tue Nov 13 10:16:57 2012 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 13 Nov 2012 11:16:57 +0100 Subject: RFR: 8003322: Add instrumentation points for tracing of I/O calls Message-ID: This is a request for review for adding tracing to I/O calls. For now, this is an empty infrastructure intended to enable diagnosing/tracing of i/o calls. A user of the API can register a callback for read and write operations on sockets and files. It does not (yet) cover asynchronous i/o calls. When not used, the implementation should add a minimum of overhead. To provide useful information to the user, FileInputStream, FileOutputStream and RandomAccessFile have been modified to keep track of the path they operate on (when available). Webrev: http://cr.openjdk.java.net/~sla/8003322/webrev.00/ Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8003322 I believe all comments from the preliminary review [1] have been addressed. In particular: - To minimize the overhead, the instrumentation calls now end up in _empty_ static methods in the IoTrace class. To enable instrumentation this class has to be redefined by an agent. To see how this work have a look at the tests. With this new design, I have not been able to measure any overhead of the disabled instrumentation. - Tests have been added that do basic sanity testing of the instrumentation points and the data in the instrumentation. - Javadoc has been added to the IoTrace class and the instrumentation has been updated to conform to this documentation (especially in the face of exceptions). - The previous Object "handles" are now called "contexts" and have a marker interface called IoTraceContext. - SocketAdapter has been instrumented. There is one remaining issue: IoTrace and IoTraceContext are now in sun.misc, but concerns where raised that this would be a problem with jigsaw. Suggestions are welcome if this is still a problem. Thanks, /Staffan [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-November/012066.html From Alan.Bateman at oracle.com Tue Nov 13 11:12:11 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 13 Nov 2012 11:12:11 +0000 Subject: Request for review: 7201156 : jar tool fails to convert file separation characters for list and extract In-Reply-To: References: <509A3508.3010205@oracle.com> <509D0F8A.4030909@oracle.com> <50A0C8D4.6080901@oracle.com> Message-ID: <50A22B0B.3000403@oracle.com> On 13/11/2012 03:17, Sean Chou wrote: > Hi Alan, > > Here is the updated webrev: > http://cr.openjdk.java.net/~zhouyx/7201156/webrev.03/ > . I think this looks much better. One final comment, in createJarFile it looks like you forgot to remove the close when you changed it to use try-with-resources. It's harmless, just would be good to remove it before you push the change (no need to generate a new webrev for this). -Alan. From chris.hegarty at oracle.com Tue Nov 13 11:21:39 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 13 Nov 2012 11:21:39 +0000 Subject: Request for review: 7201156 : jar tool fails to convert file separation characters for list and extract In-Reply-To: References: <509A3508.3010205@oracle.com> <509D0F8A.4030909@oracle.com> <50A0C8D4.6080901@oracle.com> Message-ID: <50A22D43.50308@oracle.com> Sean, Looks good to me. Thanks for updating the test. -Chris. On 11/13/2012 03:17 AM, Sean Chou wrote: > Hi Alan, > > Here is the updated webrev: > http://cr.openjdk.java.net/~zhouyx/7201156/webrev.03/ . > > > On Mon, Nov 12, 2012 at 6:00 PM, Alan Bateman wrote: > >> On 12/11/2012 09:08, Sean Chou wrote: >> >>> Hi , >>> >>> I didn't realize that rt.jar would miss before. The testcase is updated >>> to create a temp file as well as test the extract option. However, extract >>> testing will create a directory if it passes, I just deleted it in >>> testcase. Please take a look. >>> >>> webrev: http://cr.openjdk.java.net/~**zhouyx/7201156/webrev.02/< >>> http://cr.openjdk.java.net/%**7Ezhouyx/7201156/webrev.02/> >>> . >>> >>> Thanks for removing the dependency on rt.jar. >> >> A couple of comments on the updated test: >> >> - in main then it still has "pathRtJar" so I assume you just forgot to >> rename that. >> > I forgot the name had its meaning. > >> >> - it would be good to change createJarFile to use try-with-resources so >> that an error doesn't cause it to terminate with an open file. >> > Changed. > >> >> - testJarExact, I assume you intended to name this testJarExtract. >> > Yes! > >> >> - L114-117, the "./" is not needed. It would be okay to leave those files >> there if you want, jtreg will clean them up too. > > Thanks for the hint. I removed these lines, so the testcase looks tidy. > >> >> >> -Alan. >> >> >> > > From Alan.Bateman at oracle.com Tue Nov 13 12:08:24 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 13 Nov 2012 12:08:24 +0000 Subject: RFR: 6244047: impossible to specify directories to logging FileHandler unless they exist In-Reply-To: <50A184C7.4050706@oracle.com> References: <509D777E.9020603@oracle.com> <509E3277.7010607@oracle.com> <50A184C7.4050706@oracle.com> Message-ID: <50A23838.9020501@oracle.com> On 12/11/2012 23:22, Jim Gish wrote: > Which file(s) are you concerned about truncating/damaging? The code > I'm impacting is for creating a new lock file. Where is the potential > for truncating/damaging that you both are referring to? > > Is this sufficient (plus the proper exception handling of course) ? > > //lockStream = new FileOutputStream(lockFileName); > fc = FileChannel.open(new > File(lockFileName).toPath(), CREATE_NEW, WRITE); > //fc = lockStream.getChannel(); CREATE rather than CREATE_NEW so that it doesn't fail if the lock file already exists. Although it's just a lock file then I think it would be impolite to truncate it. You could use Paths.get(lockFileName)rather than new File(lockFileName).toPath() here but either is fine. -Alan. From Lance.Andersen at oracle.com Tue Nov 13 14:13:51 2012 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Tue, 13 Nov 2012 09:13:51 -0500 Subject: JDBC bug: Incorrect number of conflicts is reported by CachedRowSetWriter.writeData In-Reply-To: <50A1AFA6.8010905@linux.vnet.ibm.com> References: <509C7218.4020807@linux.vnet.ibm.com> <50A1AFA6.8010905@linux.vnet.ibm.com> Message-ID: Hi Frank, Thank you for the note If you could in the future, please provide a complete test program to repro the issue as it would save time with the reviews. Ideally if the issue is not database specific it would be good to leverage Java DB as it is included within Oracle JDK I will look at this sometime this week Best Lance On Nov 12, 2012, at 9:25 PM, Frank Ding wrote: > Hi Lance > Thanks for your quick response. Please find the bug info below. > > The problem: > When CachedRowSetImpl.acceptChanges() is called, incorrect number of conflicts, if any, is reported. The number of conflicts is the actual number of existing rows in database, which is the size of variable 'status' defined in CachedRowSetWriter.writeData(). It's not the conflict number that is supposed to be. > > Test case: > The bug can be easily manifested in all SQL server environment. Here take PostgreSQL for example. > 1. The sql script to create a table > CREATE TABLE ressystem.roomdescription > ( > roomdescription_id serial NOT NULL, > roomdescription character varying NOT NULL, > CONSTRAINT roomdescription_pkey PRIMARY KEY (roomdescription_id) > ) > > 2. Manually insert 3 rows > (1, "Test 1") > (2, "Test 2") > (3, "Test 3") > > 3. Create a Java class that connects the established database and then execute the following code snippet. > String query = "select roomdescription_id, roomdescription from ressystem.roomdescription"; > Object[] values = {2, "Test2"}; > rs.setCommand(query); > rs.execute(conn); > rs.moveToInsertRow(); > for(int i=0; i rs.updateObject(i+1,values[i]); > } > rs.insertRow(); > rs.moveToCurrentRow(); > rs.acceptChanges(conn); > > 4. An exception occurs with following output. > javax.sql.rowset.spi.SyncProviderException: 4conflicts while synchronizing > at com.sun.rowset.internal.CachedRowSetWriter.writeData(CachedRowSetWriter.java:412) > at com.sun.rowset.CachedRowSetImpl.acceptChanges(CachedRowSetImpl.java:880) > > 5. In fact, there is only one conflicting row but 4 were reported. > > Best regards, > Frank > > On 11/9/2012 7:41 PM, Lance Andersen - Oracle wrote: >> Frank, >> >> If you can please post the bug info here, I will take a look at your patch >> >> Best >> Lance >> On Nov 8, 2012, at 10:01 PM, Frank Ding wrote: >> >>> Hi guys, >>> We discovered a bug in CachedRowSetWriter.writeData method where incorrect number of conflicts is reported. I searched in Oracle bug database and no similar record was found. So I submitted a new one whose internal review ID is 2376620. A test case with code is illustrated in the bug submission that leverages PostgreSQL server but the issue is platform independent and easy to reproduce. >>> I provided a patch review, available @ >>> http://cr.openjdk.java.net/~dingxmin/2376620/webrev.01/ >>> Is there anybody who is interested in patch and can also review bug 2376620? Your reply is appreciated. >>> >>> Best regards, >>> Frank >>> >>> >> >> >> 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 >> > -------------- next part -------------- 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 gnu.andrew at redhat.com Tue Nov 13 17:28:29 2012 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Tue, 13 Nov 2012 12:28:29 -0500 (EST) Subject: [PATCH FOR REVIEW] ResourceManager.getApplicationResources() does not close InputStreams In-Reply-To: <509B2B4D.5040508@oracle.com> Message-ID: <12138496.134265.1352827709010.JavaMail.root@redhat.com> ----- Original Message ----- > On 8/11/2012 7:17 AM, Andrew Hughes wrote: > > ----- Original Message ----- > >> The bug number is 8003120 > >> > > > > Thanks. Pushed to tl: > > http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f51943263267 > > I did not construe Lance's mail to indicate an approval to push. Ok, sorry, I did. I did explicitly say "Ok for tl? If so, can I have a bug ID for this?". In future, it would be better if people were explicit about whether they expected the push to take place or not. As I said in both e-mails, I don't really want to change the well-tested original. We can make the syntactic changes Lance suggested in a separate fix, which then means the two fixes aren't muddled together. > The turnaround on this was just a bit too quick in my opinion. At least there was public review. I still see patches just being committed without any public review. > > David > > >> Best > >> Lance > >> On Nov 7, 2012, at 3:30 PM, Andrew Hughes wrote: > >> > >>> IcedTea bug: > >>> http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=1197 > >>> > >>> com.sun.naming.internal.ResourceManager.getApplicationResources() > >>> does not close the input streams it gets from > >>> helper.getResources() and helper.getJavaHomeLibStream(). This > >>> patch: > >>> > >>> http://cr.openjdk.java.net/~andrew/pr1197/webrev.01/ > >>> > >>> adds finally blocks to close these streams. As noted in the > >>> original bug report, this has been tested on a J2EE > >>> server (JBoss) without issue. > >>> > >>> I realise that there's a possibility that try-with-resources > >>> could > >>> be used here, but the patch as posted > >>> is the one that was tested and I don't want to negate that > >>> testing > >>> by changing it. > >>> > >>> Ok for tl? If so, can I have a bug ID for this? > >>> > >>> 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 > >>> > >> > >> > >> > >> 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 > >> > >> > > > -- 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 Tue Nov 13 17:29:38 2012 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Tue, 13 Nov 2012 12:29:38 -0500 (EST) Subject: [PATCH FOR REVIEW] ResourceManager.getApplicationResources() does not close InputStreams In-Reply-To: <509B58FE.1030808@oracle.com> Message-ID: <1612580981.134645.1352827778607.JavaMail.root@redhat.com> ----- Original Message ----- > On 07/11/2012 20:51, Andrew Hughes wrote: > > : > > > > As you can see on the IcedTea bug, I've asked the same question. > > I'd have preferred it to use try-with-resources myself (easier to > > follow for one thing), but given the patch is as it is, I'm now > > wary about changing it and negating the existing testing that's > > already been done. > > > I see you've pushed this already but I think we need to open a > follow-on > bug on this as it looks like there is additional work to do. > Particularly the case where there are several streams and close fails > (looks to me that it will not attempt to close all streams in that > case). Also, given that the target is jdk8 then it seems reasonable > to > see if try-with-resources could be used for the second case, I assume > the testing you mentioned was with a different release. The other > thing > is that we try to include a regression test with all fixes where > possible, I don't know how feasible it for this case. > The testing was on 7u as there isn't an 8 release yet. I'm not sure how you'd test this either. > -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 jim.gish at oracle.com Tue Nov 13 18:25:27 2012 From: jim.gish at oracle.com (Jim Gish) Date: Tue, 13 Nov 2012 13:25:27 -0500 Subject: RFR: 6244047: impossible to specify directories to logging FileHandler unless they exist In-Reply-To: <50A23838.9020501@oracle.com> References: <509D777E.9020603@oracle.com> <509E3277.7010607@oracle.com> <50A184C7.4050706@oracle.com> <50A23838.9020501@oracle.com> Message-ID: <50A29097.5020607@oracle.com> On 11/13/2012 07:08 AM, Alan Bateman wrote: > On 12/11/2012 23:22, Jim Gish wrote: >> Which file(s) are you concerned about truncating/damaging? The code >> I'm impacting is for creating a new lock file. Where is the >> potential for truncating/damaging that you both are referring to? >> >> Is this sufficient (plus the proper exception handling of course) ? >> >> //lockStream = new FileOutputStream(lockFileName); >> fc = FileChannel.open(new >> File(lockFileName).toPath(), CREATE_NEW, WRITE); >> //fc = lockStream.getChannel(); > CREATE rather than CREATE_NEW so that it doesn't fail if the lock file > already exists. Although it's just a lock file then I think it would > be impolite to truncate it. > > You could use Paths.get(lockFileName)rather than new > File(lockFileName).toPath() here but either is fine. > > -Alan. I think we want it to fail if the lock file already exists. That's why I used CREATE_NEW. At least the way the logic is now, is that it attempts to create a new file and if it fails it tries again until it can create a new one. It may be the case that the lockFileName is not in the locks map, and thus we don't own it, but it's possible that another JVM/app is logging in the same location. It, of course, would be bad practice, but not disallowed. We shouldn't be grabbing a lock file that might otherwise be in use. 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 mike.duigou at oracle.com Tue Nov 13 19:05:04 2012 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 13 Nov 2012 11:05:04 -0800 Subject: Request for Review (#2) : CR#8001634 : Initial set of lambda functional interfaces Message-ID: Hello all; I've updated the webrev for the first set of lambda functional interfaces (JSR-335) with the feedback from the first review round. The updated webrev is: http://cr.openjdk.java.net/~mduigou/8001634/3/webrev/ This update includes: - Mapper.map becomes Function.apply - Factory.make becomes Supplier.get - Specializations of Supplier for int, long, double - Reorder type variables to put result last - Fixes many javadoc and stylistic comments. What didn't change: - Block was not renamed to Action or Procedure. The name Block.apply currently conflicts with Function.apply and should be renamed. Block.accept? Block.perform? - Combiner will be part of the full API but it's only present in this patch as a comment. - No default methods. Unless there are sustained and persuasive objections this will be committed to the jdk8/tl workspace at the end of this week or early next week. (Hence "core-libs-dev" being the primary review list) Mike From brian.goetz at oracle.com Tue Nov 13 20:14:00 2012 From: brian.goetz at oracle.com (Brian Goetz) Date: Tue, 13 Nov 2012 15:14:00 -0500 Subject: Request for Review (#2) : CR#8001634 : Initial set of lambda functional interfaces In-Reply-To: References: Message-ID: <50A2AA08.6060203@oracle.com> > I've updated the webrev for the first set of lambda functional interfaces (JSR-335) with the feedback from the first review round. The updated webrev is: > > http://cr.openjdk.java.net/~mduigou/8001634/3/webrev/ > > This update includes: > > - Mapper.map becomes Function.apply > - Factory.make becomes Supplier.get > - Specializations of Supplier for int, long, double > - Reorder type variables to put result last > - Fixes many javadoc and stylistic comments. > > What didn't change: > - Block was not renamed to Action or Procedure. The name Block.apply currently conflicts with Function.apply and should be renamed. Block.accept? Block.perform? Block.accept. Also, to allow IntFunction to implement Function, need to adjust the method names. Propose applyAs{Int,Long,Double} for specializations. Similarly, need to do the same for Supplier: getAs{Int,Long,Double} with appropriate defaults for the specialized versions. From jason_mehrens at hotmail.com Tue Nov 13 20:36:08 2012 From: jason_mehrens at hotmail.com (Jason Mehrens) Date: Tue, 13 Nov 2012 14:36:08 -0600 Subject: RFR: 6244047: impossible to specify directories to logging FileHandler unless they exist In-Reply-To: <50A29097.5020607@oracle.com> References: <509D777E.9020603@oracle.com> <509E3277.7010607@oracle.com> <50A184C7.4050706@oracle.com> <50A23838.9020501@oracle.com>,<50A29097.5020607@oracle.com> Message-ID: Jim, Looking at the webrev again I think I tricked myself into thinking that 'parentFile' was a file that could be opened with a stream when it actually is a directory. I think the best fix would be to add a check in the catch block (around line 432) and only continue if the directory of the generated file java.nio.file.Files.isWritable/isDirectory otherwise throw the original exception. If the running JVM terminates abnormally won't the lock file fail to be deleted? On restart, the lock file will exist to protect a dead process. Jason Date: Tue, 13 Nov 2012 13:25:27 -0500 From: jim.gish at oracle.com To: Alan.Bateman at oracle.com CC: jason_mehrens at hotmail.com; core-libs-dev at openjdk.java.net Subject: Re: RFR: 6244047: impossible to specify directories to logging FileHandler unless they exist On 11/13/2012 07:08 AM, Alan Bateman wrote: On 12/11/2012 23:22, Jim Gish wrote: Which file(s) are you concerned about truncating/damaging? The code I'm impacting is for creating a new lock file. Where is the potential for truncating/damaging that you both are referring to? Is this sufficient (plus the proper exception handling of course) ? //lockStream = new FileOutputStream(lockFileName); fc = FileChannel.open(new File(lockFileName).toPath(), CREATE_NEW, WRITE); //fc = lockStream.getChannel(); CREATE rather than CREATE_NEW so that it doesn't fail if the lock file already exists. Although it's just a lock file then I think it would be impolite to truncate it. You could use Paths.get(lockFileName)rather than new File(lockFileName).toPath() here but either is fine. -Alan. I think we want it to fail if the lock file already exists. That's why I used CREATE_NEW. At least the way the logic is now, is that it attempts to create a new file and if it fails it tries again until it can create a new one. It may be the case that the lockFileName is not in the locks map, and thus we don't own it, but it's possible that another JVM/app is logging in the same location. It, of course, would be bad practice, but not disallowed. We shouldn't be grabbing a lock file that might otherwise be in use. 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 jim.gish at oracle.com Tue Nov 13 20:52:38 2012 From: jim.gish at oracle.com (Jim Gish) Date: Tue, 13 Nov 2012 15:52:38 -0500 Subject: RFR: 6244047: impossible to specify directories to logging FileHandler unless they exist In-Reply-To: References: <509D777E.9020603@oracle.com> <509E3277.7010607@oracle.com> <50A184C7.4050706@oracle.com> <50A23838.9020501@oracle.com>, <50A29097.5020607@oracle.com> Message-ID: <50A2B316.3050805@oracle.com> On 11/13/2012 03:36 PM, Jason Mehrens wrote: > Jim, > > Looking at the webrev again I think I tricked myself into thinking > that 'parentFile' was a file that could be opened with a stream when > it actually is a directory. I think the best fix would be to add > a check in the catch block (around line 432) and only continue if the > directory of the generated > file java.nio.file.Files.isWritable/isDirectory otherwise throw the > original exception. I have a variant, which I think may do the trick which I'll post shortly. The catch block on 432 is for when the tryLock fails. I think it's best to check the IOException around 420. > > If the running JVM terminates abnormally won't the lock file fail to > be deleted? On restart, the lock file will exist to protect a dead > process. Yes, except that you can't really distinguish between that and another JVM using the lock file. It's safer just to grab another file -- which is what the logic is already setup to do. > > Jason > > > ------------------------------------------------------------------------ > Date: Tue, 13 Nov 2012 13:25:27 -0500 > From: jim.gish at oracle.com > To: Alan.Bateman at oracle.com > CC: jason_mehrens at hotmail.com; core-libs-dev at openjdk.java.net > Subject: Re: RFR: 6244047: impossible to specify directories to > logging FileHandler unless they exist > > > On 11/13/2012 07:08 AM, Alan Bateman wrote: > > On 12/11/2012 23:22, Jim Gish wrote: > > Which file(s) are you concerned about truncating/damaging? > The code I'm impacting is for creating a new lock file. Where > is the potential for truncating/damaging that you both are > referring to? > > Is this sufficient (plus the proper exception handling of > course) ? > > //lockStream = new > FileOutputStream(lockFileName); > fc = FileChannel.open(new > File(lockFileName).toPath(), CREATE_NEW, WRITE); > //fc = lockStream.getChannel(); > > CREATE rather than CREATE_NEW so that it doesn't fail if the lock > file already exists. Although it's just a lock file then I think > it would be impolite to truncate it. > > You could use Paths.get(lockFileName)rather than new > File(lockFileName).toPath() here but either is fine. > > -Alan. > > I think we want it to fail if the lock file already exists. That's why > I used CREATE_NEW. At least the way the logic is now, is that it > attempts to create a new file and if it fails it tries again until it > can create a new one. It may be the case that the lockFileName is not > in the locks map, and thus we don't own it, but it's possible that > another JVM/app is logging in the same location. It, of course, would > be bad practice, but not disallowed. We shouldn't be grabbing a lock > file that might otherwise be in use. > > 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 -- 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 jim.gish at oracle.com Tue Nov 13 21:30:18 2012 From: jim.gish at oracle.com (Jim Gish) Date: Tue, 13 Nov 2012 16:30:18 -0500 Subject: RFR: 6244047: impossible to specify directories to logging FileHandler unless they exist In-Reply-To: <50A2B316.3050805@oracle.com> References: <509D777E.9020603@oracle.com> <509E3277.7010607@oracle.com> <50A184C7.4050706@oracle.com> <50A23838.9020501@oracle.com>, <50A29097.5020607@oracle.com> <50A2B316.3050805@oracle.com> Message-ID: <50A2BBEA.1080101@oracle.com> Here's a new webrev with my latest changes for your reviewing pleasure :-) http://cr.openjdk.java.net/~jgish/Bug6244047-FileHandler-CheckLockLocation/ Main changes: - Using the file channel directly as suggested. - Instead of checking up front for a valid directory I check the IOException on the channel open and process it accordingly. (BTW, I much prefer my previous proposed fix because I like to ensure pre-conditions for an operation are met prior to it rather than attempting the op, failing, and then recovering), - Eliminated the stream, which really isn't needed, and just use the file channel Just for the purposes of my enlightenment, assuming this is what you were after (Jason & Alan), what was your issue with checking for a valid directory up-front? Thanks, Jim On 11/13/2012 03:52 PM, Jim Gish wrote: > > On 11/13/2012 03:36 PM, Jason Mehrens wrote: >> Jim, >> >> Looking at the webrev again I think I tricked myself into thinking >> that 'parentFile' was a file that could be opened with a stream when >> it actually is a directory. I think the best fix would be to add a >> check in the catch block (around line 432) and only continue if the >> directory of the generated file >> java.nio.file.Files.isWritable/isDirectory otherwise throw the >> original exception. > I have a variant, which I think may do the trick which I'll post > shortly. The catch block on 432 is for when the tryLock fails. I > think it's best to check the IOException around 420. >> >> If the running JVM terminates abnormally won't the lock file fail to >> be deleted? On restart, the lock file will exist to protect a dead >> process. > Yes, except that you can't really distinguish between that and another > JVM using the lock file. It's safer just to grab another file -- > which is what the logic is already setup to do. >> >> Jason >> >> >> ------------------------------------------------------------------------ >> Date: Tue, 13 Nov 2012 13:25:27 -0500 >> From: jim.gish at oracle.com >> To: Alan.Bateman at oracle.com >> CC: jason_mehrens at hotmail.com; core-libs-dev at openjdk.java.net >> Subject: Re: RFR: 6244047: impossible to specify directories to >> logging FileHandler unless they exist >> >> >> On 11/13/2012 07:08 AM, Alan Bateman wrote: >> >> On 12/11/2012 23:22, Jim Gish wrote: >> >> Which file(s) are you concerned about truncating/damaging? >> The code I'm impacting is for creating a new lock file. Where >> is the potential for truncating/damaging that you both are >> referring to? >> >> Is this sufficient (plus the proper exception handling of >> course) ? >> >> //lockStream = new >> FileOutputStream(lockFileName); >> fc = FileChannel.open(new >> File(lockFileName).toPath(), CREATE_NEW, WRITE); >> //fc = lockStream.getChannel(); >> >> CREATE rather than CREATE_NEW so that it doesn't fail if the lock >> file already exists. Although it's just a lock file then I think >> it would be impolite to truncate it. >> >> You could use Paths.get(lockFileName)rather than new >> File(lockFileName).toPath() here but either is fine. >> >> -Alan. >> >> I think we want it to fail if the lock file already exists. That's >> why I used CREATE_NEW. At least the way the logic is now, is that it >> attempts to create a new file and if it fails it tries again until it >> can create a new one. It may be the case that the lockFileName is >> not in the locks map, and thus we don't own it, but it's possible >> that another JVM/app is logging in the same location. It, of course, >> would be bad practice, but not disallowed. We shouldn't be grabbing >> a lock file that might otherwise be in use. >> >> 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 > -- 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 brent.christian at oracle.com Tue Nov 13 22:50:59 2012 From: brent.christian at oracle.com (Brent Christian) Date: Tue, 13 Nov 2012 14:50:59 -0800 Subject: RFR: 7178922 : (props) re-visit how os.name is determined on Mac Message-ID: <50A2CED3.3080701@oracle.com> At present, the JDK port for OS X gets its value for os.name from a JRS function exported by the Apple Java Runtime Support framework. Historically this has either been "Mac OS X", or "Mac OS X Server", but there have been reports that this could change at any time, e.g. to just "OS X". This would break any app that relies on this property to detect the Mac platform using something like: System.getProperty("os.name").startsWith("Mac"). To ensure compatibility going forward, the os.name System property on Mac should be hard-coded to the value that is expected, "Mac OS X". (FWIW, as of 10.7 Mac OS X Server is no longer a separate edition of the OS). Webrev is here: http://cr.openjdk.java.net/~bchristi/7178922/webrev.0/ Note: the setUnknownOSAndVersion() function is unused following my change, so I went ahead and removed it. Thanks, -Brent From jonathan.gibbons at oracle.com Tue Nov 13 23:09:43 2012 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Tue, 13 Nov 2012 23:09:43 +0000 Subject: hg: jdk8/tl/langtools: 8003299: Cleanup javac Log support for deferred diagnostics Message-ID: <20121113230948.60D0F47947@hg.openjdk.java.net> Changeset: 2901c7b5339e Author: jjg Date: 2012-11-13 15:09 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/2901c7b5339e 8003299: Cleanup javac Log support for deferred diagnostics Reviewed-by: mcimadamore, jfranck ! 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/Flow.java ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java ! src/share/classes/com/sun/tools/javac/util/Log.java From mike.duigou at oracle.com Wed Nov 14 01:19:19 2012 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 13 Nov 2012 17:19:19 -0800 Subject: Request for Review (#3) : CR#8001634 : Initial set of lambda functional interfaces Message-ID: Hello all; I apologize for the quick turnaround from the second review request [1] but I've updated the webrev again: http://cr.openjdk.java.net/~mduigou/8001634/4/webrev/ Blame a busy Paul Sandoz who his making significant progress on the primitive specializations implementation. ;-) This update includes: - Block.apply renamed to Block.accept - {Int|Long|Double}Block specializations added. - Commented out "extends Combiner" in BinaryOperator was removed for now since Combiner is out of scope for this review. - The {Int|Long|Double} specializations of BinaryOperator and UnaryOperator now show commented out extends of the generic version along with commented out default methods. This change will not be part of the commit but is meant to show where the implementation will be going. - The {Int|Long|Double} specializations of Supplier now extend generic Supplier, have getAs{Int|Long|Double} as their abstract method and provide a commented out default get() method to satisfy the need for a get implementation. - The {Int|Long|Double} specializations of Function now extend generic Function, have applyAs{Int|Long|Double} as their abstract method and provide a commented out default apply() method to satisfy the need for an apply implementation. Mike [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-November/012225.html From zhouyx at linux.vnet.ibm.com Wed Nov 14 02:23:44 2012 From: zhouyx at linux.vnet.ibm.com (Sean Chou) Date: Wed, 14 Nov 2012 10:23:44 +0800 Subject: Request for review: 7201156 : jar tool fails to convert file separation characters for list and extract In-Reply-To: <50A22D43.50308@oracle.com> References: <509A3508.3010205@oracle.com> <509D0F8A.4030909@oracle.com> <50A0C8D4.6080901@oracle.com> <50A22D43.50308@oracle.com> Message-ID: Thanks Alan and Chris. On Tue, Nov 13, 2012 at 7:21 PM, Chris Hegarty wrote: > Sean, > > Looks good to me. Thanks for updating the test. > > -Chris. > > > On 11/13/2012 03:17 AM, Sean Chou wrote: > >> Hi Alan, >> >> Here is the updated webrev: >> http://cr.openjdk.java.net/~**zhouyx/7201156/webrev.03/ . >> >> >> On Mon, Nov 12, 2012 at 6:00 PM, Alan Bateman ** >> wrote: >> >> On 12/11/2012 09:08, Sean Chou wrote: >>> >>> Hi , >>>> >>>> I didn't realize that rt.jar would miss before. The testcase is updated >>>> to create a temp file as well as test the extract option. However, >>>> extract >>>> testing will create a directory if it passes, I just deleted it in >>>> testcase. Please take a look. >>>> >>>> webrev: http://cr.openjdk.java.net/~****zhouyx/7201156/webrev.02/ >>>> >>>> >< >>>> http://cr.openjdk.java.net/%****7Ezhouyx/7201156/webrev.02/>>> tp://cr.openjdk.java.net/%**7Ezhouyx/7201156/webrev.02/ >>>> >> >>>> >>>> . >>>> >>>> Thanks for removing the dependency on rt.jar. >>>> >>> >>> A couple of comments on the updated test: >>> >>> - in main then it still has "pathRtJar" so I assume you just forgot to >>> rename that. >>> >>> I forgot the name had its meaning. >> >> >>> - it would be good to change createJarFile to use try-with-resources so >>> that an error doesn't cause it to terminate with an open file. >>> >>> Changed. >> >> >>> - testJarExact, I assume you intended to name this testJarExtract. >>> >>> Yes! >> >> >>> - L114-117, the "./" is not needed. It would be okay to leave those files >>> there if you want, jtreg will clean them up too. >>> >> >> Thanks for the hint. I removed these lines, so the testcase looks tidy. >> >> >>> >>> -Alan. >>> >>> >>> >>> >> >> -- Best Regards, Sean Chou From henry.jen at oracle.com Wed Nov 14 04:09:23 2012 From: henry.jen at oracle.com (Henry Jen) Date: Tue, 13 Nov 2012 20:09:23 -0800 Subject: Request for Review: CR#8001667: Comparators class and Comparator extension method Message-ID: <50A31973.3080307@oracle.com> Hi, This is a change set regarding Comparator already in lambda repo, it depends on the CR#8001634, particularly the Function SAMs. It implements proposed extension methods on Comparator (reverse and compose) as well as static combinator methods in Comparators for things like turning a T -> {Comparable,int,long,double} into a Comparator. This allows things like: people.sort(Comparators.comparing(Person::getName)) Comparator byLastFirst = Comparators.comparing(Person::getLastName) .compose(Comparators.comparing(Person::getFirstName)) Please review and comment on the webrev[1]. [1] http://cr.openjdk.java.net/~henryjen/webrevs/8001667.0/ Cheers, Henry From mike.duigou at oracle.com Wed Nov 14 04:19:42 2012 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Wed, 14 Nov 2012 04:19:42 +0000 Subject: hg: jdk8/tl/jdk: 7088913: Add compatible static hashCode(primitive) to primitive wrapper classes Message-ID: <20121114042003.4B1264795B@hg.openjdk.java.net> Changeset: be1fb42ef696 Author: mduigou Date: 2012-11-13 20:02 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/be1fb42ef696 7088913: Add compatible static hashCode(primitive) to primitive wrapper classes Summary: Adds static utility methods to each primitive wrapper class to allow calculation of a hashCode value from an unboxed primitive. Reviewed-by: darcy, smarks, dholmes ! src/share/classes/java/lang/Boolean.java ! src/share/classes/java/lang/Byte.java ! src/share/classes/java/lang/Character.java ! src/share/classes/java/lang/Double.java ! src/share/classes/java/lang/Float.java ! src/share/classes/java/lang/Integer.java ! src/share/classes/java/lang/Long.java ! src/share/classes/java/lang/Short.java ! test/java/lang/HashCode.java From jonathan.gibbons at oracle.com Wed Nov 14 05:26:28 2012 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 13 Nov 2012 21:26:28 -0800 Subject: RFR: 8000404 java.lang.annotation.Native Message-ID: <50A32B84.8080605@oracle.com> See http://cr.openjdk.java.net/~jjg/8000404/webrev/ A while back, we added a new annotation javax.tools.GenerateNativeHeader, to mark classes that contained constants of interest to native code, such that tools, like javac with the -h option, could generate know to generate native header files. Based on our experience in using the new annotation, we have decided to change to using a different annotation, with the same purpose: java.lang.annotation.Native, to be used to annotate the constants themselves. This review is for step 1 of a 3 step process to replace javax.tools.GenerateNativeHeader with java.lang.annotation.Native. This first step is to add the new annotation. Separately, the goal is to replacing existing uses of @GenerateNativeHeader with @Native. Then, we will remove javax.tools.GenerateNativeHeader. -- Jon From luchsh at linux.vnet.ibm.com Wed Nov 14 05:27:42 2012 From: luchsh at linux.vnet.ibm.com (luchsh at linux.vnet.ibm.com) Date: Wed, 14 Nov 2012 05:27:42 +0000 Subject: hg: jdk8/tl/jdk: 7201156: jar tool fails to convert file separation characters for list and extract Message-ID: <20121114052802.8ED804795C@hg.openjdk.java.net> Changeset: 83765e82cacb Author: zhouyx Date: 2012-11-14 13:26 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/83765e82cacb 7201156: jar tool fails to convert file separation characters for list and extract Reviewed-by: alanb, chegar, sherman ! src/share/classes/sun/tools/jar/Main.java + test/tools/jar/JarBackSlash.java From luchsh at linux.vnet.ibm.com Wed Nov 14 05:34:44 2012 From: luchsh at linux.vnet.ibm.com (Jonathan Lu) Date: Wed, 14 Nov 2012 13:34:44 +0800 Subject: Request for review: 7201156 : jar tool fails to convert file separation characters for list and extract In-Reply-To: References: <509A3508.3010205@oracle.com> <509D0F8A.4030909@oracle.com> <50A0C8D4.6080901@oracle.com> <50A22D43.50308@oracle.com> Message-ID: <50A32D74.3090703@linux.vnet.ibm.com> Hi Sean, Patch pushed @ http://hg.openjdk.java.net/jdk8/tl/jdk/rev/83765e82cacb Could you please verify? Thanks & regards Jonathan On 11/14/2012 10:23 AM, Sean Chou wrote: > Thanks Alan and Chris. > > > On Tue, Nov 13, 2012 at 7:21 PM, Chris Hegarty wrote: > >> Sean, >> >> Looks good to me. Thanks for updating the test. >> >> -Chris. >> >> >> On 11/13/2012 03:17 AM, Sean Chou wrote: >> >>> Hi Alan, >>> >>> Here is the updated webrev: >>> http://cr.openjdk.java.net/~**zhouyx/7201156/webrev.03/ . >>> >>> >>> On Mon, Nov 12, 2012 at 6:00 PM, Alan Bateman ** >>> wrote: >>> >>> On 12/11/2012 09:08, Sean Chou wrote: >>>> Hi , >>>>> I didn't realize that rt.jar would miss before. The testcase is updated >>>>> to create a temp file as well as test the extract option. However, >>>>> extract >>>>> testing will create a directory if it passes, I just deleted it in >>>>> testcase. Please take a look. >>>>> >>>>> webrev: http://cr.openjdk.java.net/~****zhouyx/7201156/webrev.02/ >>>>> >>>>>> < >>>>> http://cr.openjdk.java.net/%****7Ezhouyx/7201156/webrev.02/>>>> tp://cr.openjdk.java.net/%**7Ezhouyx/7201156/webrev.02/ >>>>> . >>>>> >>>>> Thanks for removing the dependency on rt.jar. >>>>> >>>> A couple of comments on the updated test: >>>> >>>> - in main then it still has "pathRtJar" so I assume you just forgot to >>>> rename that. >>>> >>>> I forgot the name had its meaning. >>> >>>> - it would be good to change createJarFile to use try-with-resources so >>>> that an error doesn't cause it to terminate with an open file. >>>> >>>> Changed. >>> >>>> - testJarExact, I assume you intended to name this testJarExtract. >>>> >>>> Yes! >>> >>>> - L114-117, the "./" is not needed. It would be okay to leave those files >>>> there if you want, jtreg will clean them up too. >>>> >>> Thanks for the hint. I removed these lines, so the testcase looks tidy. >>> >>> >>>> -Alan. >>>> >>>> >>>> >>>> >>> > From david.holmes at oracle.com Wed Nov 14 05:46:04 2012 From: david.holmes at oracle.com (David Holmes) Date: Wed, 14 Nov 2012 15:46:04 +1000 Subject: Re-Request for Re-Review : 7088952 : Add "BYTES" constant to primitive wrapper classes In-Reply-To: <8E520A9F-7BCD-4665-B19E-9FF4D6841EE8@oracle.com> References: <8E520A9F-7BCD-4665-B19E-9FF4D6841EE8@oracle.com> Message-ID: <50A3301C.1040500@oracle.com> Hi Mike, This seems fine without Boolean. David On 8/11/2012 9:08 AM, Mike Duigou wrote: > Hello all; > > A long time ago [1] this patch was put forward for review. Though the request was approved the patch was never committed because some of the followup questions were not answered. > > The summary motivation for this issue is that measuring the size of the primitive types in bytes is more frequently used than bits because bytes are the minimum unit of allocation in Java. The proposed BYTES constant is a convenience to avoid many repetitions of Integer.SIZE / Byte.SIZE where the size in bytes is desired. There are many of these cases already in the JDK that are currently using locally defined constants or manifest constants ("magic" numbers) [2] that could benefit from this change to improve clarity. Many other external usages could take advantage of these constants as well. > > Unless there are objections I will go forward with pushing this change on Nov 9th, 2012 as originally reviewed with the original reviewers. > > http://cr.openjdk.java.net/~mduigou/7088952/0/webrev/ > > Mike > > [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-September/007753.html > [2] http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/00cd9dc3c2b5/src/share/classes/java/io/DataOutputStream.java From Alan.Bateman at oracle.com Wed Nov 14 08:31:42 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 14 Nov 2012 08:31:42 +0000 Subject: RFR: 8000404 java.lang.annotation.Native In-Reply-To: <50A32B84.8080605@oracle.com> References: <50A32B84.8080605@oracle.com> Message-ID: <50A356EE.4030406@oracle.com> On 14/11/2012 05:26, Jonathan Gibbons wrote: > See http://cr.openjdk.java.net/~jjg/8000404/webrev/ > > A while back, we added a new annotation > javax.tools.GenerateNativeHeader, to mark classes that contained > constants of interest to native code, such that tools, like javac with > the -h option, could generate know to generate native header files. > Based on our experience in using the new annotation, we have decided > to change to using a different annotation, with the same purpose: > java.lang.annotation.Native, to be used to annotate the constants > themselves. > > This review is for step 1 of a 3 step process to replace > javax.tools.GenerateNativeHeader with java.lang.annotation.Native. > > This first step is to add the new annotation. > > Separately, the goal is to replacing existing uses of > @GenerateNativeHeader with @Native. Then, we will remove > javax.tools.GenerateNativeHeader. > > -- Jon I'm very happy to see @GenerateNativeHeader been replaced with @Native. The addition looks good, thumbs up from me. -Alan. From paul.sandoz at oracle.com Wed Nov 14 08:36:05 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 14 Nov 2012 09:36:05 +0100 Subject: Request for Review (#3) : CR#8001634 : Initial set of lambda functional interfaces In-Reply-To: References: Message-ID: On Nov 14, 2012, at 2:19 AM, Mike Duigou wrote: > Hello all; > > I apologize for the quick turnaround from the second review request [1] but I've updated the webrev again: > > http://cr.openjdk.java.net/~mduigou/8001634/4/webrev/ > Looks good to me. > Blame a busy Paul Sandoz who his making significant progress on the primitive specializations implementation. ;-) > :-) code drop to lambda repo imminent... Paul. > This update includes: > > - Block.apply renamed to Block.accept > - {Int|Long|Double}Block specializations added. > - Commented out "extends Combiner" in BinaryOperator was removed for now since Combiner is out of scope for this review. > - The {Int|Long|Double} specializations of BinaryOperator and UnaryOperator now show commented out extends of the generic version along with commented out default methods. This change will not be part of the commit but is meant to show where the implementation will be going. > - The {Int|Long|Double} specializations of Supplier now extend generic Supplier, have getAs{Int|Long|Double} as their abstract method and provide a commented out default get() method to satisfy the need for a get implementation. > - The {Int|Long|Double} specializations of Function now extend generic Function, have applyAs{Int|Long|Double} as their abstract method and provide a commented out default apply() method to satisfy the need for an apply implementation. > > Mike > > [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-November/012225.html > From chris.hegarty at oracle.com Wed Nov 14 09:27:55 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 14 Nov 2012 09:27:55 +0000 Subject: Request for review: 7201156 : jar tool fails to convert file separation characters for list and extract In-Reply-To: <50A32D74.3090703@linux.vnet.ibm.com> References: <509A3508.3010205@oracle.com> <509D0F8A.4030909@oracle.com> <50A0C8D4.6080901@oracle.com> <50A22D43.50308@oracle.com> <50A32D74.3090703@linux.vnet.ibm.com> Message-ID: <50A3641B.7040208@oracle.com> On 11/14/2012 05:34 AM, Jonathan Lu wrote: > Hi Sean, > > Patch pushed @ http://hg.openjdk.java.net/jdk8/tl/jdk/rev/83765e82cacb > Could you please verify? Looks fine to me. -Chris. > > Thanks & regards > Jonathan > > On 11/14/2012 10:23 AM, Sean Chou wrote: >> Thanks Alan and Chris. >> >> >> On Tue, Nov 13, 2012 at 7:21 PM, Chris Hegarty >> wrote: >> >>> Sean, >>> >>> Looks good to me. Thanks for updating the test. >>> >>> -Chris. >>> >>> >>> On 11/13/2012 03:17 AM, Sean Chou wrote: >>> >>>> Hi Alan, >>>> >>>> Here is the updated webrev: >>>> http://cr.openjdk.java.net/~**zhouyx/7201156/webrev.03/ >>>> . >>>> >>>> >>>> On Mon, Nov 12, 2012 at 6:00 PM, Alan Bateman >>>> ** >>>> wrote: >>>> >>>> On 12/11/2012 09:08, Sean Chou wrote: >>>>> Hi , >>>>>> I didn't realize that rt.jar would miss before. The testcase is >>>>>> updated >>>>>> to create a temp file as well as test the extract option. However, >>>>>> extract >>>>>> testing will create a directory if it passes, I just deleted it in >>>>>> testcase. Please take a look. >>>>>> >>>>>> webrev: >>>>>> http://cr.openjdk.java.net/~****zhouyx/7201156/webrev.02/ >>>>>> >>>>>> >>>>>> >>>>>>> < >>>>>> http://cr.openjdk.java.net/%****7Ezhouyx/7201156/webrev.02/>>>>> tp://cr.openjdk.java.net/%**7Ezhouyx/7201156/webrev.02/ >>>>>> >>>>>> . >>>>>> >>>>>> Thanks for removing the dependency on rt.jar. >>>>>> >>>>> A couple of comments on the updated test: >>>>> >>>>> - in main then it still has "pathRtJar" so I assume you just forgot to >>>>> rename that. >>>>> >>>>> I forgot the name had its meaning. >>>> >>>>> - it would be good to change createJarFile to use >>>>> try-with-resources so >>>>> that an error doesn't cause it to terminate with an open file. >>>>> >>>>> Changed. >>>> >>>>> - testJarExact, I assume you intended to name this testJarExtract. >>>>> >>>>> Yes! >>>> >>>>> - L114-117, the "./" is not needed. It would be okay to leave those >>>>> files >>>>> there if you want, jtreg will clean them up too. >>>>> >>>> Thanks for the hint. I removed these lines, so the testcase looks tidy. >>>> >>>> >>>>> -Alan. >>>>> >>>>> >>>>> >>>>> >>>> >> > From Alan.Bateman at oracle.com Wed Nov 14 09:59:34 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 14 Nov 2012 09:59:34 +0000 Subject: RFR: 7178922 : (props) re-visit how os.name is determined on Mac In-Reply-To: <50A2CED3.3080701@oracle.com> References: <50A2CED3.3080701@oracle.com> Message-ID: <50A36B86.3010709@oracle.com> On 13/11/2012 22:50, Brent Christian wrote: > At present, the JDK port for OS X gets its value for os.name from a > JRS function exported by the Apple Java Runtime Support framework. > > Historically this has either been "Mac OS X", or "Mac OS X Server", > but there have been reports that this could change at any time, e.g. > to just "OS X". This would break any app that relies on this property > to detect the Mac platform using something like: > > System.getProperty("os.name").startsWith("Mac"). > > To ensure compatibility going forward, the os.name System property on > Mac should be hard-coded to the value that is expected, "Mac OS X". > (FWIW, as of 10.7 Mac OS X Server is no longer a separate edition of > the OS). > > Webrev is here: > http://cr.openjdk.java.net/~bchristi/7178922/webrev.0/ > > Note: the setUnknownOSAndVersion() function is unused following my > change, so I went ahead and removed it. > > Thanks, > -Brent This might be a question for the MacOSX folks but is it safe to continue to depend on JavaRuntimeSupport period? I'm just wondering if we really need to use it to determine the OS version and locale? -Alan. From scolebourne at joda.org Wed Nov 14 10:36:48 2012 From: scolebourne at joda.org (Stephen Colebourne) Date: Wed, 14 Nov 2012 10:36:48 +0000 Subject: Request for Review: CR#8001667: Comparators class and Comparator extension method In-Reply-To: <50A31973.3080307@oracle.com> References: <50A31973.3080307@oracle.com> Message-ID: On 14 November 2012 04:09, Henry Jen wrote: > This is a change set regarding Comparator already in lambda repo, it > depends on the CR#8001634, particularly the Function SAMs. > > It implements proposed extension methods on Comparator > (reverse and compose) as well as static combinator methods in > Comparators for things like turning a T -> {Comparable,int,long,double} > into a Comparator. > > This allows things like: > > people.sort(Comparators.comparing(Person::getName)) > Comparator byLastFirst > = Comparators.comparing(Person::getLastName) > .compose(Comparators.comparing(Person::getFirstName)) > > Please review and comment on the webrev[1]. Comparators declares a static serializable inner class NaturalOrderComparator which is a singleton. Would it be worth declaring this as an enum with a single instance? (as per Effective Java version 2) Comparators line 77 could do with a

Comparators line 86: declaration about null that is covered in class level Javadoc Comparators line 92: who's -> whose Comparators general: I'd like to see @code around types, such as Comparable and Map.Entry While "compose" feels like the right name for Comparators, it feels like the wrong name for the equivalent method on Comparator (given the example below). "andThen" or "then" would be fluent alternatives. "composedWith" would be a more boring alternative. byLastName.compose(byFirstName) byLastName.andThen(byFirstName) byLastName.then(byFirstName) byLastName.composedWith(byFirstName) Stephen From scolebourne at joda.org Wed Nov 14 10:48:24 2012 From: scolebourne at joda.org (Stephen Colebourne) Date: Wed, 14 Nov 2012 10:48:24 +0000 Subject: Request for Review (#2) : CR#8001634 : Initial set of lambda functional interfaces In-Reply-To: References: Message-ID: On 13 November 2012 19:05, Mike Duigou wrote: > - Mapper.map becomes Function.apply > - Factory.make becomes Supplier.get > - Specializations of Supplier for int, long, double > - Reorder type variables to put result last > - Fixes many javadoc and stylistic comments. > > What didn't change: > - Block was not renamed to Action or Procedure. The name Block.apply currently conflicts with Function.apply and should be renamed. Block.accept? Block.perform? > - Combiner will be part of the full API but it's only present in this patch as a comment. > - No default methods. > > Unless there are sustained and persuasive objections this will be committed to the jdk8/tl workspace at the end of this week or early next week. (Hence "core-libs-dev" being the primary review list) The interface definitions say nothing about null. I'd like to see something in there, even if it is to say "null handling behaviour is defined by the implementation". I still find Block confusing. A code block is a block of code delimited by { }. It takes no arguments and returns nothing. "Receiver" was suggested as the interface name to match Supplier, and that made sense to me (and is better than Sink, which is very IO). I also find Predicate.test to be a non-optimal method name. "test" is a method name I only see in test cases. Commons collections used "evaluate". "is" would be a possible short option. I'm sure the EG can think of others. Stephen From Alan.Bateman at oracle.com Wed Nov 14 11:08:25 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 14 Nov 2012 11:08:25 +0000 Subject: RFR: 6244047: impossible to specify directories to logging FileHandler unless they exist In-Reply-To: <50A2BBEA.1080101@oracle.com> References: <509D777E.9020603@oracle.com> <509E3277.7010607@oracle.com> <50A184C7.4050706@oracle.com> <50A23838.9020501@oracle.com>, <50A29097.5020607@oracle.com> <50A2B316.3050805@oracle.com> <50A2BBEA.1080101@oracle.com> Message-ID: <50A37BA9.2000605@oracle.com> On 13/11/2012 21:30, Jim Gish wrote: > Here's a new webrev with my latest changes for your reviewing pleasure :-) > > http://cr.openjdk.java.net/~jgish/Bug6244047-FileHandler-CheckLockLocation/ > > > Main changes: > - Using the file channel directly as suggested. > - Instead of checking up front for a valid directory I check the > IOException on the channel open and process it accordingly. (BTW, I > much prefer my previous proposed fix because I like to ensure > pre-conditions for an operation are met prior to it rather than > attempting the op, failing, and then recovering), > - Eliminated the stream, which really isn't needed, and just use the > file channel > > Just for the purposes of my enlightenment, assuming this is what you > were after (Jason & Alan), what was your issue with checking for a > valid directory up-front? > > Thanks, > Jim I get it now (I missed this on the first round), this code is using lock files and not really using file-locking as intended. I think the FileChannel.open usage is fine, I'm just not sure about the exception handling. For starters, FileSystemException is a super type of AccessDeniedException and NoSuchFileSystem so I don't think you need to catch them specifically. Would I be correct to say that the only reason that you would have to recover and try the next file is if the lock file exist? In that case then maybe it just needs to be: try { lockFileChannel = FileChannel.open(...); } catch (FileAlreadyExistsException ignore) { continue; } -Alan. From Alan.Bateman at oracle.com Wed Nov 14 12:50:16 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 14 Nov 2012 12:50:16 +0000 Subject: RFR: 8003322: Add instrumentation points for tracing of I/O calls In-Reply-To: References: Message-ID: <50A39388.8060502@oracle.com> On 13/11/2012 10:16, Staffan Larsen wrote: > This is a request for review for adding tracing to I/O calls. For now, this is an empty infrastructure intended to enable diagnosing/tracing of i/o calls. A user of the API can register a callback for read and write operations on sockets and files. It does not (yet) cover asynchronous i/o calls. When not used, the implementation should add a minimum of overhead. To provide useful information to the user, FileInputStream, FileOutputStream and RandomAccessFile have been modified to keep track of the path they operate on (when available). > > Webrev: http://cr.openjdk.java.net/~sla/8003322/webrev.00/ Thanks for the update. Do you have any updated performance data to share (just to confirm that the updated implementation doesn't have any real impact)? Anyway, I took a pass over the new webrev. I'm not sure that passing a value of 0 for errors to xxEnd is the best approach, particularly if this is ever extended to non-blocking I/O. Also I think there are a few inconsistencies with respect to EOF -- eg: in FileInputStream then read() will call the hook with 0 at EOF whereas the other read methods will call the hook with -1 at EOF. In FileChannelImpl then some places use normalize, some not. I guess the main question is whether the agent needs to distinguish I/O errors from EOF and 0 bytes (the latter is assuming this may be extended to non-blocking I/O). It may be that you need to use -2 or anything < -1 to distinguish all cases. Minor nit but there is a bit of inconsistency with the variables names, usage of "v" in RandomAccessFile for example whereas FIS/FOS have bytesRead and bytesWritten. Thanks for adding javadoc to IoTrace. One suggestion is to include a big warning that the hooks may be called while holding low-level locks in the implementation and so great care must be taken, any synchronization or interaction with other threads could easily deadlock the VM. I skimmed over the tests (not a detailed review) and they look reasonable. You might need to check the copyright headers as it looks like at least one of the tests has the GPL+Classpath exception whereas we normally use just the GPL header on tests. Also good to ensure that there is @bug tag on the tests to link it to 8003322. In ioTraceTest.sh I see "cd ${PWD}" that I didn't quite get. Do you think these tests will be reliable when running without an images build (meaning raw classes files on the system)? Just wondering if expectFileRead might fail due to I/O caused by class loading. That's all I have on the detailed review. As you mentioned there is still have the substantive issue as to whether it's open season on sun.misc.IoTrace*. Ignoring Unsafe (we know this needs to be standardized or a standard alternative introduced), then nothing outside of the JDK should be using sun.* classes directly. -Alan From alan.bateman at oracle.com Wed Nov 14 12:56:29 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Wed, 14 Nov 2012 12:56:29 +0000 Subject: hg: jdk8/tl/jdk: 8003285: TEST_BUG: java/nio/channels/AsynchronousChannelGroup/Unbounded.java fails again [macosx] Message-ID: <20121114125713.C789C4796B@hg.openjdk.java.net> Changeset: 0f54a98f9bc9 Author: alanb Date: 2012-11-14 12:56 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0f54a98f9bc9 8003285: TEST_BUG: java/nio/channels/AsynchronousChannelGroup/Unbounded.java fails again [macosx] Reviewed-by: chegar ! test/java/nio/channels/AsynchronousChannelGroup/Unbounded.java From jonathan.gibbons at oracle.com Wed Nov 14 15:09:31 2012 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Wed, 14 Nov 2012 15:09:31 +0000 Subject: hg: jdk8/tl/jdk: 8000404: rename javax.tools.GenerateNativeHeader to java.lang.annotation.Native Message-ID: <20121114150942.C78784796E@hg.openjdk.java.net> Changeset: 369709a13823 Author: jjg Date: 2012-11-14 07:08 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/369709a13823 8000404: rename javax.tools.GenerateNativeHeader to java.lang.annotation.Native Reviewed-by: alanb + src/share/classes/java/lang/annotation/Native.java From zhong.j.yu at gmail.com Wed Nov 14 15:14:42 2012 From: zhong.j.yu at gmail.com (Zhong Yu) Date: Wed, 14 Nov 2012 09:14:42 -0600 Subject: hg: jdk8/tl/jdk: 6924259: Remove offset and count fields from java.lang.String Message-ID: Changing String.substring() from O(1) to O(n) is a big deal; we may say it breaks compatibility. Any code that intends to work across JDK versions before and after 7u6 cannot use the method, since its behavior is so different in different versions. Any deployment that upgrades JDK to 7u6 and later needs to review all its usages of substring(). That's a ton of work. A quick workaround might be to refactor all substring() usages to some `old_substring()` method that preserves O(1). Unfortunately `old_substring()` cannot exist, so there's no quick workaround possible. The memory leak problem of the old substring() method is well-known among Java programmers, it's not really a big problem today. For the uninitiated, they might expect that substring() is leak-free; but they might also expect that substring() is O(1). There's no apparent reason why favoring one is better than favoring the other. In the old implementation, there's a workaround to achieve leak-free, by `new String(String)`. In the new implementation, there is no workaround to achieve O(1), unless the developer uses something other than String. It is basically impossible to change String to another type if it's part of a method signature. With all these problems, please reconsider this change and see if you should roll it back. Thanks. Zhong Yu From zhong.j.yu at gmail.com Wed Nov 14 15:32:44 2012 From: zhong.j.yu at gmail.com (Zhong Yu) Date: Wed, 14 Nov 2012 09:32:44 -0600 Subject: hg: jdk8/tl/jdk: 6924259: Remove offset and count fields from java.lang.String In-Reply-To: References: Message-ID: The new implementation also introduces a new form of memory leak. Previously N substrings take O(N) space. Now it takes O(N*m) space where m is the average length of substrings. Some applications may be double penalized by the new implementation - both CPU and memory go up. On Wed, Nov 14, 2012 at 9:14 AM, Zhong Yu wrote: > Changing String.substring() from O(1) to O(n) is a big deal; we may > say it breaks compatibility. > > Any code that intends to work across JDK versions before and after 7u6 > cannot use the method, since its behavior is so different in different > versions. > > Any deployment that upgrades JDK to 7u6 and later needs to review all > its usages of substring(). That's a ton of work. A quick workaround > might be to refactor all substring() usages to some `old_substring()` > method that preserves O(1). Unfortunately `old_substring()` cannot > exist, so there's no quick workaround possible. > > The memory leak problem of the old substring() method is well-known > among Java programmers, it's not really a big problem today. > > For the uninitiated, they might expect that substring() is leak-free; > but they might also expect that substring() is O(1). There's no > apparent reason why favoring one is better than favoring the other. > > In the old implementation, there's a workaround to achieve leak-free, > by `new String(String)`. > > In the new implementation, there is no workaround to achieve O(1), > unless the developer uses something other than String. It is basically > impossible to change String to another type if it's part of a method > signature. > > With all these problems, please reconsider this change and see if you > should roll it back. Thanks. > > Zhong Yu From Alan.Bateman at oracle.com Wed Nov 14 15:41:32 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 14 Nov 2012 15:41:32 +0000 Subject: Request for Review (#3) : CR#8001634 : Initial set of lambda functional interfaces In-Reply-To: References: Message-ID: <50A3BBAC.2070907@oracle.com> On 14/11/2012 01:19, Mike Duigou wrote: > Hello all; > > I apologize for the quick turnaround from the second review request [1] but I've updated the webrev again: > > http://cr.openjdk.java.net/~mduigou/8001634/4/webrev/ > > Blame a busy Paul Sandoz who his making significant progress on the primitive specializations implementation. ;-) > > This update includes: > > - Block.apply renamed to Block.accept > - {Int|Long|Double}Block specializations added. > - Commented out "extends Combiner" in BinaryOperator was removed for now since Combiner is out of scope for this review. > - The {Int|Long|Double} specializations of BinaryOperator and UnaryOperator now show commented out extends of the generic version along with commented out default methods. This change will not be part of the commit but is meant to show where the implementation will be going. > - The {Int|Long|Double} specializations of Supplier now extend generic Supplier, have getAs{Int|Long|Double} as their abstract method and provide a commented out default get() method to satisfy the need for a get implementation. > - The {Int|Long|Double} specializations of Function now extend generic Function, have applyAs{Int|Long|Double} as their abstract method and provide a commented out default apply() method to satisfy the need for an apply implementation. > > Mike > > [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-November/012225.html > Just a few incy wincy comments on the latest webrev: - Don't forget functions->function in make/java/java/Makefile. - The @return in Predicate - it might read a bit better if there were a comma before "otherwise". - In the package description it reads "All functional interface implementations are expected to" but this doesn't flow well into the bullet point. It may be better to re-word this sentence to something like "Implementators of functional interfaces should keep in mind:". -Alan. From forax at univ-mlv.fr Wed Nov 14 16:06:10 2012 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 14 Nov 2012 17:06:10 +0100 Subject: hg: jdk8/tl/jdk: 6924259: Remove offset and count fields from java.lang.String In-Reply-To: References: Message-ID: <50A3C172.4080702@univ-mlv.fr> Hi Zhong Yu, I agree with you that changing the implementation of something like String.substring which is widely used is something that is always a little hairy. The memory leak you mention is one side of the problem, the other is that we want the VM to do memory collocation of String (i.e. allocate the array of char and the String as one object to avoid the double indirection). For that the creation of the char array and the creation of the String must be done in the constructor of String. So this change is a way to look to the bright future instead of looking to the dark past :) Now, I don't know why this change was backported to a jdk update, but it's more a question to the jdk7 update mailing list. R?mi On 11/14/2012 04:14 PM, Zhong Yu wrote: > Changing String.substring() from O(1) to O(n) is a big deal; we may > say it breaks compatibility. > > Any code that intends to work across JDK versions before and after 7u6 > cannot use the method, since its behavior is so different in different > versions. > > Any deployment that upgrades JDK to 7u6 and later needs to review all > its usages of substring(). That's a ton of work. A quick workaround > might be to refactor all substring() usages to some `old_substring()` > method that preserves O(1). Unfortunately `old_substring()` cannot > exist, so there's no quick workaround possible. > > The memory leak problem of the old substring() method is well-known > among Java programmers, it's not really a big problem today. > > For the uninitiated, they might expect that substring() is leak-free; > but they might also expect that substring() is O(1). There's no > apparent reason why favoring one is better than favoring the other. > > In the old implementation, there's a workaround to achieve leak-free, > by `new String(String)`. > > In the new implementation, there is no workaround to achieve O(1), > unless the developer uses something other than String. It is basically > impossible to change String to another type if it's part of a method > signature. > > With all these problems, please reconsider this change and see if you > should roll it back. Thanks. > > Zhong Yu From Alan.Bateman at oracle.com Wed Nov 14 16:48:55 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 14 Nov 2012 16:48:55 +0000 Subject: hg: jdk8/tl/jdk: 6924259: Remove offset and count fields from java.lang.String In-Reply-To: <50A3C172.4080702@univ-mlv.fr> References: <50A3C172.4080702@univ-mlv.fr> Message-ID: <50A3CB77.6020800@oracle.com> On 14/11/2012 16:06, Remi Forax wrote: > > Now, I don't know why this change was backported to a jdk update, > but it's more a question to the jdk7 update mailing list. It was to offset the addition of the hash32 field. -Alan. From mike.duigou at oracle.com Wed Nov 14 17:12:04 2012 From: mike.duigou at oracle.com (Mike Duigou) Date: Wed, 14 Nov 2012 09:12:04 -0800 Subject: Request for Review (#2) : CR#8001634 : Initial set of lambda functional interfaces In-Reply-To: References: Message-ID: <60A42ABE-35F7-4C58-BCB0-834B68BF06E0@oracle.com> The issue is primarily when one class wants to implement more than one functional interface. If the names collide then the class will only be able to implement one of the interfaces. Mike On Nov 14 2012, at 07:12 , Craig P. Motlin wrote: > What's the issue with both methods being named apply? > > On Tue, Nov 13, 2012 at 2:05 PM, Mike Duigou wrote: > The name Block.apply currently conflicts with Function.apply and should be renamed. > From mike.duigou at oracle.com Wed Nov 14 17:16:55 2012 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Wed, 14 Nov 2012 17:16:55 +0000 Subject: hg: jdk8/tl/jdk: 7088952: Add size in bytes constant "BYTES" to primitive type wrapper types Message-ID: <20121114171717.87C4147970@hg.openjdk.java.net> Changeset: e24123de581c Author: mduigou Date: 2012-11-13 20:02 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e24123de581c 7088952: Add size in bytes constant "BYTES" to primitive type wrapper types Summary: Adds a constant BYTES to each of the primitive wrapper classes (Byte, Character, Double, Float, Integer, Long, Short) with the calculation Primitive.SIZE / Byte.SIZE already made. Reviewed-by: dholmes ! src/share/classes/java/lang/Byte.java ! src/share/classes/java/lang/Character.java ! src/share/classes/java/lang/Double.java ! src/share/classes/java/lang/Float.java ! src/share/classes/java/lang/Integer.java ! src/share/classes/java/lang/Long.java ! src/share/classes/java/lang/Short.java From kelly.ohair at oracle.com Wed Nov 14 17:29:36 2012 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Wed, 14 Nov 2012 09:29:36 -0800 Subject: RFR: 8000404 java.lang.annotation.Native In-Reply-To: <50A32B84.8080605@oracle.com> References: <50A32B84.8080605@oracle.com> Message-ID: <00020AB3-D13C-4CFC-B118-E14A66D52DC1@oracle.com> Looks good to me. -kto On Nov 13, 2012, at 9:26 PM, Jonathan Gibbons wrote: > See http://cr.openjdk.java.net/~jjg/8000404/webrev/ > > A while back, we added a new annotation javax.tools.GenerateNativeHeader, to mark classes that contained constants of interest to native code, such that tools, like javac with the -h option, could generate know to generate native header files. Based on our experience in using the new annotation, we have decided to change to using a different annotation, with the same purpose: java.lang.annotation.Native, to be used to annotate the constants themselves. > > This review is for step 1 of a 3 step process to replace javax.tools.GenerateNativeHeader with java.lang.annotation.Native. > > This first step is to add the new annotation. > > Separately, the goal is to replacing existing uses of @GenerateNativeHeader with @Native. Then, we will remove javax.tools.GenerateNativeHeader. > > -- Jon From staffan.larsen at oracle.com Wed Nov 14 17:35:27 2012 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 14 Nov 2012 18:35:27 +0100 Subject: RFR: 8003322: Add instrumentation points for tracing of I/O calls In-Reply-To: <50A39388.8060502@oracle.com> References: <50A39388.8060502@oracle.com> Message-ID: Thanks for the detailed review, Alan. Comments inline. On 14 nov 2012, at 13:50, Alan Bateman wrote: > On 13/11/2012 10:16, Staffan Larsen wrote: >> This is a request for review for adding tracing to I/O calls. For now, this is an empty infrastructure intended to enable diagnosing/tracing of i/o calls. A user of the API can register a callback for read and write operations on sockets and files. It does not (yet) cover asynchronous i/o calls. When not used, the implementation should add a minimum of overhead. To provide useful information to the user, FileInputStream, FileOutputStream and RandomAccessFile have been modified to keep track of the path they operate on (when available). >> >> Webrev: http://cr.openjdk.java.net/~sla/8003322/webrev.00/ > Thanks for the update. Do you have any updated performance data to share (just to confirm that the updated implementation doesn't have any real impact)? While I haven't been able to measure an impact myself, I want to confirm this with runs from the performance team. I'll get back as soon as I have something to share. > Anyway, I took a pass over the new webrev. > > I'm not sure that passing a value of 0 for errors to xxEnd is the best approach, particularly if this is ever extended to non-blocking I/O. Also I think there are a few inconsistencies with respect to EOF -- eg: in FileInputStream then read() will call the hook with 0 at EOF whereas the other read methods will call the hook with -1 at EOF. In FileChannelImpl then some places use normalize, some not. Thanks for catching these inconsistencies, I have fixed them. > I guess the main question is whether the agent needs to distinguish I/O errors from EOF and 0 bytes (the latter is assuming this may be extended to non-blocking I/O). It may be that you need to use -2 or anything < -1 to distinguish all cases. This one is hard. As you say, it would be great to differentiate between 0 bytes, EOF and Exceptions. The first two are quite easy as I could make -1 mean EOF. Exceptions are harder since I don't really know if there was an exception from where the xxEnd() method is called now (typically a finally clause). Adding a catch clause and calling xxEnd() from there would solve it, but make the code more complicated. Hard to tell if the extra code complexity is worth it. > Minor nit but there is a bit of inconsistency with the variables names, usage of "v" in RandomAccessFile for example whereas FIS/FOS have bytesRead and bytesWritten. I change v to bytesRead or bytesWritten as appropriate. > Thanks for adding javadoc to IoTrace. One suggestion is to include a big warning that the hooks may be called while holding low-level locks in the implementation and so great care must be taken, any synchronization or interaction with other threads could easily deadlock the VM. I have added this. > I skimmed over the tests (not a detailed review) and they look reasonable. You might need to check the copyright headers as it looks like at least one of the tests has the GPL+Classpath exception whereas we normally use just the GPL header on tests. Fixed. > Also good to ensure that there is @bug tag on the tests to link it to 8003322. Added. > In ioTraceTest.sh I see "cd ${PWD}" that I didn't quite get. I do a few "cd" to different places to compile and create the jar, I then wanted to go back to the original directory to execute the test. > Do you think these tests will be reliable when running without an images build (meaning raw classes files on the system)? Just wondering if expectFileRead might fail due to I/O caused by class loading. I have been running them without an image build with no problem, but I see what you mean. If this turns out to be a problem, then some classes may have to be pre-loaded (such as FileInputStream, FileOutputStream, FileChannel*, ByteBuffer). > That's all I have on the detailed review. Thanks! /Staffan > As you mentioned there is still have the substantive issue as to whether it's open season on sun.misc.IoTrace*. Ignoring Unsafe (we know this needs to be standardized or a standard alternative introduced), then nothing outside of the JDK should be using sun.* classes directly. > > -Alan > > > > From david.dehaven at oracle.com Wed Nov 14 17:43:12 2012 From: david.dehaven at oracle.com (David DeHaven) Date: Wed, 14 Nov 2012 09:43:12 -0800 Subject: Review Request: 8001533: Java launcher must launch JavaFX applications Message-ID: Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8001533 Webrev: http://cr.openjdk.java.net/~ddehaven/8001533/webrev.0/ This change adds support in the Java launcher to launch JavaFX applications directly (without the aid of launcher code injected by javafxpackager). This is accomplished by first checking if the JavaFX-Application-Class field is present in the jar manifest and if so (and a valid class) then that class is launched, otherwise Main-Class is used. Additionally, since JavaFX applications may not necessarily have a main method, if no main method is found then the main class (however specified or discovered) is checked to determine if it (eventually) extends javafx.application.Application and if so is launched via a helper class. -DrD- From mike.duigou at oracle.com Wed Nov 14 17:49:42 2012 From: mike.duigou at oracle.com (Mike Duigou) Date: Wed, 14 Nov 2012 09:49:42 -0800 Subject: Request for Review : 7175464 : entrySetView field is never updated in NavigableSubMap Message-ID: Hello all; A small but useful performance fix for sub-maps of TreeMap: http://cr.openjdk.java.net/~mduigou/7175464/0/webrev/ The entrySetView was not being cached. There is no unit test because either implementation is permissible under the specification. The fix only has the effect of improving performance and reducing duplicate objects. Mike From mandy.chung at oracle.com Wed Nov 14 18:06:37 2012 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 14 Nov 2012 10:06:37 -0800 Subject: RFR: 8000404 java.lang.annotation.Native In-Reply-To: <50A32B84.8080605@oracle.com> References: <50A32B84.8080605@oracle.com> Message-ID: <50A3DDAD.7080106@oracle.com> Looks good to me. Mandy On 11/13/2012 9:26 PM, Jonathan Gibbons wrote: > See http://cr.openjdk.java.net/~jjg/8000404/webrev/ > > A while back, we added a new annotation > javax.tools.GenerateNativeHeader, to mark classes that contained > constants of interest to native code, such that tools, like javac with > the -h option, could generate know to generate native header files. > Based on our experience in using the new annotation, we have decided > to change to using a different annotation, with the same purpose: > java.lang.annotation.Native, to be used to annotate the constants > themselves. > > This review is for step 1 of a 3 step process to replace > javax.tools.GenerateNativeHeader with java.lang.annotation.Native. > > This first step is to add the new annotation. > > Separately, the goal is to replacing existing uses of > @GenerateNativeHeader with @Native. Then, we will remove > javax.tools.GenerateNativeHeader. > > -- Jon From jonathan.gibbons at oracle.com Wed Nov 14 18:08:04 2012 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Wed, 14 Nov 2012 18:08:04 +0000 Subject: hg: jdk8/tl/langtools: 8003412: javac needs to understand java.lang.annotation.Native Message-ID: <20121114180808.6E0AF47974@hg.openjdk.java.net> Changeset: f14c693a0e48 Author: jjg Date: 2012-11-14 10:07 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/f14c693a0e48 8003412: javac needs to understand java.lang.annotation.Native Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/code/Symtab.java ! src/share/classes/com/sun/tools/javac/jvm/JNIWriter.java ! test/tools/javac/nativeHeaders/NativeHeaderTest.java ! test/tools/javac/nativeHeaders/javahComparison/CompareTest.java + test/tools/javac/nativeHeaders/javahComparison/TestClass4.java + test/tools/javac/nativeHeaders/javahComparison/TestClass5.java From naoto.sato at oracle.com Wed Nov 14 18:08:33 2012 From: naoto.sato at oracle.com (Naoto Sato) Date: Wed, 14 Nov 2012 10:08:33 -0800 Subject: RFR: 7178922 : (props) re-visit how os.name is determined on Mac In-Reply-To: <50A36B86.3010709@oracle.com> References: <50A2CED3.3080701@oracle.com> <50A36B86.3010709@oracle.com> Message-ID: <50A3DE21.8050406@oracle.com> As to the default locale detection, we need to call JavaRuntimeSupport. MacOSX's POSIX calls do not return user's preferred language/format settings. Naoto On 11/14/12 1:59 AM, Alan Bateman wrote: > On 13/11/2012 22:50, Brent Christian wrote: >> At present, the JDK port for OS X gets its value for os.name from a >> JRS function exported by the Apple Java Runtime Support framework. >> >> Historically this has either been "Mac OS X", or "Mac OS X Server", >> but there have been reports that this could change at any time, e.g. >> to just "OS X". This would break any app that relies on this property >> to detect the Mac platform using something like: >> >> System.getProperty("os.name").startsWith("Mac"). >> >> To ensure compatibility going forward, the os.name System property on >> Mac should be hard-coded to the value that is expected, "Mac OS X". >> (FWIW, as of 10.7 Mac OS X Server is no longer a separate edition of >> the OS). >> >> Webrev is here: >> http://cr.openjdk.java.net/~bchristi/7178922/webrev.0/ >> >> Note: the setUnknownOSAndVersion() function is unused following my >> change, so I went ahead and removed it. >> >> Thanks, >> -Brent > This might be a question for the MacOSX folks but is it safe to continue > to depend on JavaRuntimeSupport period? I'm just wondering if we really > need to use it to determine the OS version and locale? > > -Alan. From brian.goetz at oracle.com Wed Nov 14 18:14:27 2012 From: brian.goetz at oracle.com (Brian Goetz) Date: Wed, 14 Nov 2012 13:14:27 -0500 Subject: Request for Review (#2) : CR#8001634 : Initial set of lambda functional interfaces In-Reply-To: <60A42ABE-35F7-4C58-BCB0-834B68BF06E0@oracle.com> References: <60A42ABE-35F7-4C58-BCB0-834B68BF06E0@oracle.com> Message-ID: <50A3DF83.1030900@oracle.com> Or when one functional interface wants to extend another, such as IntBlock extends Block On 11/14/2012 12:12 PM, Mike Duigou wrote: > The issue is primarily when one class wants to implement more than one functional interface. If the names collide then the class will only be able to implement one of the interfaces. > > Mike > > On Nov 14 2012, at 07:12 , Craig P. Motlin wrote: > >> What's the issue with both methods being named apply? >> >> On Tue, Nov 13, 2012 at 2:05 PM, Mike Duigou wrote: >> The name Block.apply currently conflicts with Function.apply and should be renamed. >> > > From david.dehaven at oracle.com Wed Nov 14 18:21:01 2012 From: david.dehaven at oracle.com (David DeHaven) Date: Wed, 14 Nov 2012 10:21:01 -0800 Subject: RFR: 7178922 : (props) re-visit how os.name is determined on Mac In-Reply-To: <50A3DE21.8050406@oracle.com> References: <50A2CED3.3080701@oracle.com> <50A36B86.3010709@oracle.com> <50A3DE21.8050406@oracle.com> Message-ID: <4AB803E2-DEA0-420A-A321-78F2B90332EF@oracle.com> Why not just use CFLocale and call CFLocaleCopyCurrent? https://developer.apple.com/library/mac/#documentation/CoreFoundation/Reference/CFLocaleRef/Reference/reference.html#//apple_ref/c/func/CFLocaleCopyCurrent -DrD- > As to the default locale detection, we need to call JavaRuntimeSupport. MacOSX's POSIX calls do not return user's preferred language/format settings. > > Naoto > > On 11/14/12 1:59 AM, Alan Bateman wrote: >> On 13/11/2012 22:50, Brent Christian wrote: >>> At present, the JDK port for OS X gets its value for os.name from a >>> JRS function exported by the Apple Java Runtime Support framework. >>> >>> Historically this has either been "Mac OS X", or "Mac OS X Server", >>> but there have been reports that this could change at any time, e.g. >>> to just "OS X". This would break any app that relies on this property >>> to detect the Mac platform using something like: >>> >>> System.getProperty("os.name").startsWith("Mac"). >>> >>> To ensure compatibility going forward, the os.name System property on >>> Mac should be hard-coded to the value that is expected, "Mac OS X". >>> (FWIW, as of 10.7 Mac OS X Server is no longer a separate edition of >>> the OS). >>> >>> Webrev is here: >>> http://cr.openjdk.java.net/~bchristi/7178922/webrev.0/ >>> >>> Note: the setUnknownOSAndVersion() function is unused following my >>> change, so I went ahead and removed it. >>> >>> Thanks, >>> -Brent >> This might be a question for the MacOSX folks but is it safe to continue >> to depend on JavaRuntimeSupport period? I'm just wondering if we really >> need to use it to determine the OS version and locale? >> >> -Alan. > From mike.duigou at oracle.com Wed Nov 14 18:27:43 2012 From: mike.duigou at oracle.com (Mike Duigou) Date: Wed, 14 Nov 2012 10:27:43 -0800 Subject: Request for Review : 6553074 : String{Buffer, Builder}.indexOf(Str, int) contains unnecessary allocation Message-ID: <69BAB031-C94A-4D2D-A5C4-11A42F168C44@oracle.com> Hello all; This patch causes the indexOf and lastIndexOf implementation in AbstractStringBuilder to directly compare the character arrays rather than making a copy of the substring before comparing. http://cr.openjdk.java.net/~mduigou/6553074/0/webrev/ From swingler at apple.com Wed Nov 14 18:26:17 2012 From: swingler at apple.com (Mike Swingler) Date: Wed, 14 Nov 2012 10:26:17 -0800 Subject: RFR: 7178922 : (props) re-visit how os.name is determined on Mac In-Reply-To: <50A36B86.3010709@oracle.com> References: <50A2CED3.3080701@oracle.com> <50A36B86.3010709@oracle.com> Message-ID: On Nov 14, 2012, at 1:59 AM, Alan Bateman wrote: > On 13/11/2012 22:50, Brent Christian wrote: >> At present, the JDK port for OS X gets its value for os.name from a JRS function exported by the Apple Java Runtime Support framework. >> >> Historically this has either been "Mac OS X", or "Mac OS X Server", but there have been reports that this could change at any time, e.g. >> to just "OS X". This would break any app that relies on this property >> to detect the Mac platform using something like: >> >> System.getProperty("os.name").startsWith("Mac"). >> >> To ensure compatibility going forward, the os.name System property on Mac should be hard-coded to the value that is expected, "Mac OS X". (FWIW, as of 10.7 Mac OS X Server is no longer a separate edition of the OS). >> >> Webrev is here: >> http://cr.openjdk.java.net/~bchristi/7178922/webrev.0/ >> >> Note: the setUnknownOSAndVersion() function is unused following my change, so I went ahead and removed it. >> >> Thanks, >> -Brent > This might be a question for the MacOSX folks but is it safe to continue to depend on JavaRuntimeSupport period? I'm just wondering if we really need to use it to determine the OS version and locale? JavaRuntimeSupport.framework was explicitly created to make API for OpenJDK and 3rd party JVMs to do everything that the Apple Java SE 6 did using private SPI. To prove that it worked, we re-implemented Java SE 6 on top of it. It's purpose is to expose a stable API for functionality that is generally inappropriate for Cocoa applications, but is necessary for the Java to cooperate with the OS X graphical environment. We currently have no plans to expand JavaRuntimeSupport, and no plans to deprecate it. Regards, Mike Swingler Apple Inc. From naoto.sato at oracle.com Wed Nov 14 18:30:09 2012 From: naoto.sato at oracle.com (Naoto Sato) Date: Wed, 14 Nov 2012 10:30:09 -0800 Subject: RFR: 7178922 : (props) re-visit how os.name is determined on Mac In-Reply-To: <4AB803E2-DEA0-420A-A321-78F2B90332EF@oracle.com> References: <50A2CED3.3080701@oracle.com> <50A36B86.3010709@oracle.com> <50A3DE21.8050406@oracle.com> <4AB803E2-DEA0-420A-A321-78F2B90332EF@oracle.com> Message-ID: <50A3E331.40209@oracle.com> We do use CFLocale for the default format locale detection, which is used for formatting Date/Time/Number etc. Users can specify different language from it for the UI language, such as menu/button/etc, which can (I think) only be retrieved with that JRS function. Naoto On 11/14/12 10:21 AM, David DeHaven wrote: > > Why not just use CFLocale and call CFLocaleCopyCurrent? > > https://developer.apple.com/library/mac/#documentation/CoreFoundation/Reference/CFLocaleRef/Reference/reference.html#//apple_ref/c/func/CFLocaleCopyCurrent > > -DrD- > >> As to the default locale detection, we need to call JavaRuntimeSupport. MacOSX's POSIX calls do not return user's preferred language/format settings. >> >> Naoto >> >> On 11/14/12 1:59 AM, Alan Bateman wrote: >>> On 13/11/2012 22:50, Brent Christian wrote: >>>> At present, the JDK port for OS X gets its value for os.name from a >>>> JRS function exported by the Apple Java Runtime Support framework. >>>> >>>> Historically this has either been "Mac OS X", or "Mac OS X Server", >>>> but there have been reports that this could change at any time, e.g. >>>> to just "OS X". This would break any app that relies on this property >>>> to detect the Mac platform using something like: >>>> >>>> System.getProperty("os.name").startsWith("Mac"). >>>> >>>> To ensure compatibility going forward, the os.name System property on >>>> Mac should be hard-coded to the value that is expected, "Mac OS X". >>>> (FWIW, as of 10.7 Mac OS X Server is no longer a separate edition of >>>> the OS). >>>> >>>> Webrev is here: >>>> http://cr.openjdk.java.net/~bchristi/7178922/webrev.0/ >>>> >>>> Note: the setUnknownOSAndVersion() function is unused following my >>>> change, so I went ahead and removed it. >>>> >>>> Thanks, >>>> -Brent >>> This might be a question for the MacOSX folks but is it safe to continue >>> to depend on JavaRuntimeSupport period? I'm just wondering if we really >>> need to use it to determine the OS version and locale? >>> >>> -Alan. >> > From jim.gish at oracle.com Wed Nov 14 20:56:27 2012 From: jim.gish at oracle.com (Jim Gish) Date: Wed, 14 Nov 2012 15:56:27 -0500 Subject: RFR: 6244047: impossible to specify directories to logging FileHandler unless they exist In-Reply-To: <50A37BA9.2000605@oracle.com> References: <509D777E.9020603@oracle.com> <509E3277.7010607@oracle.com> <50A184C7.4050706@oracle.com> <50A23838.9020501@oracle.com>, <50A29097.5020607@oracle.com> <50A2B316.3050805@oracle.com> <50A2BBEA.1080101@oracle.com> <50A37BA9.2000605@oracle.com> Message-ID: <50A4057B.3020006@oracle.com> Check out the latest, please -- http://cr.openjdk.java.net/~jgish/Bug6244047-FileHandler-CheckLockLocation/ -- If it's ok, please push it or let me know who to have do it? Thanks, Jim BTW I was expecting that NotDirectoryException would be thrown. However, sun.nio.fs.UnixException does not translate an error code 20 (UnixConstants.ENOTDIR) to NotDirectoryException, even though it could. Perhaps we should fix that, unless you see a reason not to. I'll check the history, bug reports, etc. and bring it up on nio-dev unless you know off the top of your head why we're not checking for ENOTDIR error code. On 11/14/2012 06:08 AM, Alan Bateman wrote: > On 13/11/2012 21:30, Jim Gish wrote: >> Here's a new webrev with my latest changes for your reviewing >> pleasure :-) >> >> http://cr.openjdk.java.net/~jgish/Bug6244047-FileHandler-CheckLockLocation/ >> >> >> Main changes: >> - Using the file channel directly as suggested. >> - Instead of checking up front for a valid directory I check the >> IOException on the channel open and process it accordingly. (BTW, I >> much prefer my previous proposed fix because I like to ensure >> pre-conditions for an operation are met prior to it rather than >> attempting the op, failing, and then recovering), >> - Eliminated the stream, which really isn't needed, and just use the >> file channel >> >> Just for the purposes of my enlightenment, assuming this is what you >> were after (Jason & Alan), what was your issue with checking for a >> valid directory up-front? >> >> Thanks, >> Jim > I get it now (I missed this on the first round), this code is using > lock files and not really using file-locking as intended. > > I think the FileChannel.open usage is fine, I'm just not sure about > the exception handling. For starters, FileSystemException is a super > type of AccessDeniedException and NoSuchFileSystem so I don't think > you need to catch them specifically. Would I be correct to say that > the only reason that you would have to recover and try the next file > is if the lock file exist? In that case then maybe it just needs to be: > > try { > lockFileChannel = FileChannel.open(...); > } catch (FileAlreadyExistsException ignore) { > continue; > } > > -Alan. > > > > -- 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 jim.gish at oracle.com Wed Nov 14 21:15:44 2012 From: jim.gish at oracle.com (Jim Gish) Date: Wed, 14 Nov 2012 16:15:44 -0500 Subject: RFR: 8003380 - Compiler warnings in logging test code Message-ID: <50A40A00.8060106@oracle.com> Please review http://cr.openjdk.java.net/~jgish/Bug8003380-logging-test-warnings/ These are simple changes to eliminate compiler warnings from java.util.logging test code. 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 brent.christian at oracle.com Wed Nov 14 21:23:58 2012 From: brent.christian at oracle.com (Brent Christian) Date: Wed, 14 Nov 2012 13:23:58 -0800 Subject: RFR: 7178922 : (props) re-visit how os.name is determined on Mac In-Reply-To: <50A2EE52.1020604@oracle.com> References: <50A2CED3.3080701@oracle.com> <50A2EE52.1020604@oracle.com> Message-ID: <50A40BEE.2030205@oracle.com> Thanks, Sergey. It's good that we standardized on the recommended usage within the JDK in order to stay ahead of a possible change to the value of ProductName in /System/Library/CoreServices/SystemVersion.plist But we can expect that Java application developers use the same variety of OS platform checks. Which is why we should maintain the current value (versus risking apps breaking in the event of a change in ProductName used by OS X), especially considering that it works fine with the recommended osName.contains("OS X"). As is suggested in the bug report, if the Mac's OS changes so radically that we should be reporting a new os.name ("Mac OS XI", or who knows what), we will almost certainly need to update the JDK to run on it, at which time we can also change the value of os.name. Thanks, -Brent On 11/13/12 5:05 PM, Sergey Bylokhov wrote: > So many efforts was done to unify this style across the jdk > http://monaco.sfbay.sun.com/detail.jsf?cr=7147461 > http://monaco.sfbay.sun.com/detail.jsf?cr=7130404 > changesets > http://hg.openjdk.java.net/jdk8/awt/jdk/rev/77b35c5c4b95 > http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/970cbbba54b0 > http://closedjdk.us.oracle.com/hsx/hotspot-rt/hotspot/test/closed/rev/40505e5a55e8 > > > Note that official documentation from apple suggest: contains("OS X") > https://developer.apple.com/library/mac/#technotes/tn2002/tn2110.html > > 14.11.2012 2:50, Brent Christian wrote: >> At present, the JDK port for OS X gets its value for os.name from a >> JRS function exported by the Apple Java Runtime Support framework. >> >> Historically this has either been "Mac OS X", or "Mac OS X Server", >> but there have been reports that this could change at any time, e.g. >> to just "OS X". This would break any app that relies on this property >> to detect the Mac platform using something like: >> >> System.getProperty("os.name").startsWith("Mac"). >> >> To ensure compatibility going forward, the os.name System property on >> Mac should be hard-coded to the value that is expected, "Mac OS X". >> (FWIW, as of 10.7 Mac OS X Server is no longer a separate edition of >> the OS). >> >> Webrev is here: >> http://cr.openjdk.java.net/~bchristi/7178922/webrev.0/ >> >> Note: the setUnknownOSAndVersion() function is unused following my >> change, so I went ahead and removed it. >> >> Thanks, >> -Brent > > From jim.gish at oracle.com Wed Nov 14 21:24:09 2012 From: jim.gish at oracle.com (Jim Gish) Date: Wed, 14 Nov 2012 16:24:09 -0500 Subject: Request for Review : 6553074 : String{Buffer, Builder}.indexOf(Str, int) contains unnecessary allocation In-Reply-To: <69BAB031-C94A-4D2D-A5C4-11A42F168C44@oracle.com> References: <69BAB031-C94A-4D2D-A5C4-11A42F168C44@oracle.com> Message-ID: <50A40BF9.3090208@oracle.com> Mike, In String.java, with the new methods you're adding, should we make those String target parameters a CharSequence instead? Thanks, Jim On 11/14/2012 01:27 PM, Mike Duigou wrote: > Hello all; > > This patch causes the indexOf and lastIndexOf implementation in AbstractStringBuilder to directly compare the character arrays rather than making a copy of the substring before comparing. > > http://cr.openjdk.java.net/~mduigou/6553074/0/webrev/ > > -- 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 Lance.Andersen at oracle.com Wed Nov 14 21:35:09 2012 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Wed, 14 Nov 2012 16:35:09 -0500 Subject: RFR: 8003380 - Compiler warnings in logging test code In-Reply-To: <50A40A00.8060106@oracle.com> References: <50A40A00.8060106@oracle.com> Message-ID: <80DC459D-AB14-49EE-8C38-E8196E3D1AF0@oracle.com> looks Ok. On Nov 14, 2012, at 4:15 PM, Jim Gish wrote: > Please review http://cr.openjdk.java.net/~jgish/Bug8003380-logging-test-warnings/ > > These are simple changes to eliminate compiler warnings from java.util.logging test code. > > 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 > -------------- next part -------------- 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 Alan.Bateman at oracle.com Wed Nov 14 21:38:22 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 14 Nov 2012 21:38:22 +0000 Subject: RFR: 6244047: impossible to specify directories to logging FileHandler unless they exist In-Reply-To: <50A4057B.3020006@oracle.com> References: <509D777E.9020603@oracle.com> <509E3277.7010607@oracle.com> <50A184C7.4050706@oracle.com> <50A23838.9020501@oracle.com>, <50A29097.5020607@oracle.com> <50A2B316.3050805@oracle.com> <50A2BBEA.1080101@oracle.com> <50A37BA9.2000605@oracle.com> <50A4057B.3020006@oracle.com> Message-ID: <50A40F4E.4000807@oracle.com> On 14/11/2012 20:56, Jim Gish wrote: > Check out the latest, please -- > http://cr.openjdk.java.net/~jgish/Bug6244047-FileHandler-CheckLockLocation/ > > -- If it's ok, please push it or let me know who to have do it? I think it's okay except that you don't need to catch IOException, simply catching FileAlreadyExistsException exception should do it. If you agree then update the patch and I can push it for you. > : > > BTW I was expecting that NotDirectoryException would be thrown. > However, sun.nio.fs.UnixException does not translate an error code 20 > (UnixConstants.ENOTDIR) to NotDirectoryException, even though it > could. Perhaps we should fix that, unless you see a reason not to. > I'll check the history, bug reports, etc. and bring it up on nio-dev > unless you know off the top of your head why we're not checking for > ENOTDIR error code. NotDirectoryException is for the case where you attempt do something specific to a directory but the file isn't a directory. There is special handing in newDirectoryStream for this. -Alan. From jim.gish at oracle.com Wed Nov 14 21:54:48 2012 From: jim.gish at oracle.com (Jim Gish) Date: Wed, 14 Nov 2012 16:54:48 -0500 Subject: RFR: 6244047: impossible to specify directories to logging FileHandler unless they exist In-Reply-To: <50A40F4E.4000807@oracle.com> References: <509D777E.9020603@oracle.com> <509E3277.7010607@oracle.com> <50A184C7.4050706@oracle.com> <50A23838.9020501@oracle.com>, <50A29097.5020607@oracle.com> <50A2B316.3050805@oracle.com> <50A2BBEA.1080101@oracle.com> <50A37BA9.2000605@oracle.com> <50A4057B.3020006@oracle.com> <50A40F4E.4000807@oracle.com> Message-ID: <50A41328.7040503@oracle.com> On 11/14/2012 04:38 PM, Alan Bateman wrote: > On 14/11/2012 20:56, Jim Gish wrote: >> Check out the latest, please -- >> http://cr.openjdk.java.net/~jgish/Bug6244047-FileHandler-CheckLockLocation/ >> >> -- If it's ok, please push it or let me know who to have do it? > I think it's okay except that you don't need to catch IOException, > simply catching FileAlreadyExistsException exception should do it. If > you agree then update the patch and I can push it for you. But of course. Sorry I missed the obvious. Just peeling the onion when I could have taken a bite :-) Fixed, and updated. > >> : >> >> BTW I was expecting that NotDirectoryException would be thrown. >> However, sun.nio.fs.UnixException does not translate an error code 20 >> (UnixConstants.ENOTDIR) to NotDirectoryException, even though it >> could. Perhaps we should fix that, unless you see a reason not to. >> I'll check the history, bug reports, etc. and bring it up on nio-dev >> unless you know off the top of your head why we're not checking for >> ENOTDIR error code. > NotDirectoryException is for the case where you attempt do something > specific to a directory but the file isn't a directory. There is > special handing in newDirectoryStream for this. > Exactly -- that's my point. This is one of those cases. You're trying to create a new file in a directory, but the file you specified isn't a directory - it's a plain file. The error code coming back is ENOTDIR and so what you get is the more general FileSystemException with "Not a directory" as the error message, when in fact, we could throw NotDirectoryException if we'd simply check for errno of ENOTDIR in the first place along with the other checks being done in UnixException translateToIOException(File,String). > -Alan. -- 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 Alan.Bateman at oracle.com Wed Nov 14 22:06:17 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 14 Nov 2012 22:06:17 +0000 Subject: RFR: 7178922 : (props) re-visit how os.name is determined on Mac In-Reply-To: References: <50A2CED3.3080701@oracle.com> <50A36B86.3010709@oracle.com> Message-ID: <50A415D9.9070903@oracle.com> On 14/11/2012 18:26, Mike Swingler wrote: > : > JavaRuntimeSupport.framework was explicitly created to make API for OpenJDK and 3rd party JVMs to do everything that the Apple Java SE 6 did using private SPI. To prove that it worked, we re-implemented Java SE 6 on top of it. It's purpose is to expose a stable API for functionality that is generally inappropriate for Cocoa applications, but is necessary for the Java to cooperate with the OS X graphical environment. > > We currently have no plans to expand JavaRuntimeSupport, and no plans to deprecate it. > > Regards, > Mike Swingler > Apple Inc. Thank you for the clear statement, this is exactly what we needed as the status of JavaRuntimeSupport.framework was not clear (at least not to me). -Alan From jiangli.zhou at oracle.com Thu Nov 1 02:03:32 2012 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Wed, 31 Oct 2012 19:03:32 -0700 Subject: Review request:7197210: java/lang/invoke/CallSiteTest.java failing on armsflt In-Reply-To: <50901EC1.3080506@oracle.com> References: <5089C7E1.2040206@oracle.com> <7EC5973C-0E05-4DC1-AC64-143698B6D027@oracle.com> <5089D6D0.3070909@oracle.com> <5565E56D-0131-4A77-9C4D-D70B4B9F1FD0@oracle.com> <50901EC1.3080506@oracle.com> Message-ID: <5091D874.5070905@oracle.com> Redirecting the review request to core-libs-dev at openjdk.java.net mail list... Here is the webrev based on the jdk8/tl/jdk repository: http://cr.openjdk.java.net/~jiangli/7197210/webrev.02/ The '-XX:+IgnoreUnrecognizedVMOptions -XX:-VerifyDependencies' options are added to following tests to reduce workload. Timeout settings are also added to each test. The '-esa' option is added to BigArityTest and MethodHandlesTest to enable asserts. java.lang.invoke.BigArityTest java.lang.invoke.MethodHandlesTest java.lang.invoke.CallSiteTest Thanks, Jiangli On 10/30/2012 11:38 AM, Jiangli Zhou wrote: > Hi Chris, > > Here is the updated webrev with added > '-XX:+IgnoreUnrecognizedVMOptions -XX:-VerifyDependencies' options and > timeout setting for the following tests: > > test.java.lang.invoke.RicochetTest > test.java.lang.invoke.BigArityTest > test.java.lang.invoke.MethodHandlesTest > test.java.lang.invoke.CallSiteTest > > http://cr.openjdk.java.net/~jiangli/7197210/webrev.01/ > > Thanks, > > Jiangli From howard.lovatt at gmail.com Thu Nov 1 04:53:47 2012 From: howard.lovatt at gmail.com (Howard Lovatt) Date: Thu, 1 Nov 2012 15:53:47 +1100 Subject: Review Request: CR#8001634 : Initial set of lambda functional interfaces In-Reply-To: <0A5D3B62-5D32-47ED-AF1E-5D6BF269B1E8@oracle.com> References: <0A5D3B62-5D32-47ED-AF1E-5D6BF269B1E8@oracle.com> Message-ID: <16E65D5F-3F4C-45F1-A437-ABE30EF4C062@gmail.com> General Comment ============= For the collections framework there is a description of the whole framework (http://docs.oracle.com/javase/7/docs/technotes/guides/collections/index.html); why not do the same for the lambda framework and put a reference to the description in all the interfaces' and classes' Javadoc. This description would be a good place to talk about concurrency and side effects and to show suggested usage idioms. Overall Structure ============= I will preface this comment saying that you might be considering doing this suggestion; but it isn't included at this stage because you are previewing a subset that excludes default methods etc. With the Collections Framework there are root interfaces, Collection and Map, and progressively there are more specific interfaces. This structure is very handy because it allows collections to be treated abstractly. Likewise it would be handy if the functions had Combiner at the top of the hierarchy. In particular: public interface Combiner { V operate(L left, R right); } public interface BinaryOperator extends Combiner { T operate(T left, T right); } public interface UnaryOperator extends Combiner { default T operate(T left, Void notUsed) { return operate(left); } T operate(T operand); } public interface ZerothOperator extends Combiner { default T operate(Void notUsed1, Void notUsed2) { return operate(); } T operate(); } public interface IntBinaryOperator extends BinaryOperator { default Integer operate(Integer left, Integer right) { return intOperate(left, right); } int intOperate(int left, int right); } Similarly long and double versions. public interface IntUnaryOperator extends UnaryOperator { default Integer operate(Integer operand) { return intOperate(operand); } int intOperate(int operand); } Similarly long and double versions. public interface Mapper extends Combiner { default R operate(T t, Void notUsed) { return map(T t); } R map(T t); } public interface IntMapper extends Mapper { default Integer map(T t) { return intMap(t); } int intMap(T t); } Similarly long and double versions. public interface Predicate extends Mapper { default Boolean map(T t) { return test(t); } boolean test(T t); } public interface Block extends Mapper { default Void map(T t) { apply(t); return null; } void apply(T t); } public interface Factory extend ZerothOperator { default T operate() { return make(); } T make(); } Float Variation =========== There are int, long, and double specialisations; float specialisations would also be useful (particularly for graphics). Also, some day maybe the JVM will use the graphics co-processor (which are much faster for float than double). Typo ==== The last section of package-info "All functional interface implementations are expected to:" seems to be a typo. Presumably this file was only partially completed. Keep up the good work, -- Howard. Sent from my iPad On 01/11/2012, at 7:16 AM, Mike Duigou wrote: > There's a large set of library changes that will be coming with Lambda. We're getting near the end of the runway and there's lots left to do so we want to start the process of getting some of the more stable pieces put back to the JDK8 repositories. We've spent a some time slicing things into manageable chunks. This is the first bunch. We'd like to time-box this review at one week, since there are many more pieces to follow. > > The first chunk is the basic set of functional interface types. While this set is not complete, it is enough to be able to proceed on some other pieces. This set contains no extension methods (we'll do those separately) and does not contain all the specializations we may eventually need. > > The specification is limited; most of the interesting restrictions (side-effect-freedom, idempotency, stability) would really be imposed not by the SAM itself by by how the SAM is used in a calculation. However, some common doc for "how to write good SAMs" that we can stick in the package doc would be helpful. Suggestions welcome. > > Elements of this naming scheme include: > - Each SAM type has a unique (arity, method name) pair. This allows SAMs to implement other SAMs without collision. > - The argument lists are structured so that specializations act on the first argument(s), so IntMapper is a specialization of Mapper, and IntBinaryOperator is a specialization of BinaryOperator. > > In order to get the most useful feedback out of this review, we'd like to ask you follow the following guidelines for the review: > > - We are time-boxed at one week. (until Nov. 7th) > > - Please review the whole bunch in a single message if possible, rather than in bits and pieces. It is far easier to extract useful feedback from one complete review than from a dozen partial ones. > > - Please wait a few days before replying to other people's reviews! We want to keep the discussion on-topic to maximize the useful review content. It is far too easy for the discussion to spiral off into minutia and lose sight of the goal -- which is to provide useful feedback on the API we're asking for feedback on. > > http://cr.openjdk.java.net/~mduigou/8001634/2/webrev/ > From anthony.petrov at oracle.com Wed Nov 7 12:07:17 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Wed, 07 Nov 2012 16:07:17 +0400 Subject: Cannot build jdk7u-dev In-Reply-To: <509A3EC3.1030009@oracle.com> References: <509A3EC3.1030009@oracle.com> Message-ID: <509A4EF5.5020205@oracle.com> (bcc'ing core-libs-dev@) Looks like this is related to 6981400. I'm CC'ing Anton to take a look at it. -- best regards, Anthony On 11/7/2012 2:58 PM, Weijun Wang wrote: > I've just synced with jdk7u-dev and now it does not build. > > symbol: class TimedWindowEvent > location: class SunToolkit > ../../../src/share/classes/sun/awt/SunToolkit.java:472: error: cannot > find symbol > TimedWindowEvent twe = (TimedWindowEvent)nested; > ^ > symbol: class TimedWindowEvent > location: class SunToolkit > > It seems there is no class called TimedWindowEvent. > > I am building the jdk repo only. > > Thanks > Max From zhong.j.yu at gmail.com Thu Nov 8 17:22:03 2012 From: zhong.j.yu at gmail.com (Zhong Yu) Date: Thu, 8 Nov 2012 11:22:03 -0600 Subject: hg: jdk8/tl/jdk: 6924259: Remove offset and count fields from java.lang.String Message-ID: On 06/03/2012 11:35 PM, Mike Duigou wrote: > [I trimmed the distribution list] > > On Jun 3 2012, at 13:44 , Peter Levart wrote: > >> On Thursday, May 31, 2012 03:22:35 AM mike.duigou at oracle.com wrote: >>> Changeset: 2c773daa825d >>> Author: mduigou >>> Date: 2012-05-17 10:06 -0700 >>> URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2c773daa825d >>> >>> 6924259: Remove offset and count fields from java.lang.String >>> Summary: Removes the use of shared character array buffers by String along >>> with the two fields needed to support the use of shared buffers. >> Wow, that's quite a change. > Indeed. It was a long time in development. It is a change which is expected to be overall beneficial though and in the general case a positive win. Wow! If the previous behavior of substring() was once a bug, by now it has become a well known feature. People know about it, and people depend on it. This change is a big surprise. Changing O(1) to O(n) is a breach of contract. It'll break lots of old code; and meanwhile lots of new code are still being written based on the old assumption. After people learned about the new behavior, they need to comb through and rewrite their code. The worst part is the same code performs very differently on different versions of JDK. What's a programmer supposed to do if his code targets JDK6 and above? If the cost of strings are no longer certain, what else can we believe in? Is there any chance in hell to roll it back? Maybe add a new method for the new behavior? Zhong Yu From robert.field at oracle.com Tue Nov 13 16:06:52 2012 From: robert.field at oracle.com (robert.field at oracle.com) Date: Tue, 13 Nov 2012 16:06:52 +0000 Subject: hg: jdk8/tl/langtools: 8003306: Compiler crash: calculation of inner class access modifier Message-ID: <20121113160654.DCFAB4792B@hg.openjdk.java.net> Changeset: e6b1abdc11ca Author: rfield Date: 2012-11-13 08:06 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/e6b1abdc11ca 8003306: Compiler crash: calculation of inner class access modifier Summary: Fix binary sense lost in transition to hasTag Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java + test/tools/javac/lambda/InnerConstructor.java From howard.lovatt at gmail.com Wed Nov 14 08:05:52 2012 From: howard.lovatt at gmail.com (Howard Lovatt) Date: Wed, 14 Nov 2012 08:05:52 +0000 Subject: Request for Review (#3) : CR#8001634 : Initial set of lambda functional interfaces In-Reply-To: References: Message-ID: Great rate of progress on this - well done. The package Javadoc still needs some work. Sent from my iPad On 14/11/2012, at 1:19 AM, Mike Duigou wrote: > Hello all; > > I apologize for the quick turnaround from the second review request [1] but I've updated the webrev again: > > http://cr.openjdk.java.net/~mduigou/8001634/4/webrev/ > > Blame a busy Paul Sandoz who his making significant progress on the primitive specializations implementation. ;-) > > This update includes: > > - Block.apply renamed to Block.accept > - {Int|Long|Double}Block specializations added. > - Commented out "extends Combiner" in BinaryOperator was removed for now since Combiner is out of scope for this review. > - The {Int|Long|Double} specializations of BinaryOperator and UnaryOperator now show commented out extends of the generic version along with commented out default methods. This change will not be part of the commit but is meant to show where the implementation will be going. > - The {Int|Long|Double} specializations of Supplier now extend generic Supplier, have getAs{Int|Long|Double} as their abstract method and provide a commented out default get() method to satisfy the need for a get implementation. > - The {Int|Long|Double} specializations of Function now extend generic Function, have applyAs{Int|Long|Double} as their abstract method and provide a commented out default apply() method to satisfy the need for an apply implementation. > > Mike > > [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-November/012225.html From david.buck at oracle.com Wed Nov 14 13:38:53 2012 From: david.buck at oracle.com (David Buck) Date: Wed, 14 Nov 2012 22:38:53 +0900 Subject: code review request: Test case for JDK-7198904 TreeMap.clone issue Message-ID: <50A39EED.9050902@oracle.com> Hi! This is a review request to add only the test case for the following OracleJDK issue: [ 7198904 : (alt-rt) TreeMap.clone is broken ] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7198904 The issue (root cause) is not in OpenJDK (i.e. the problem was OracleJDK specific), but the test case is valid for both so it should go into OpenJDK so we can prevent a similar issue from ever happening in both releases moving forward. webrev: [ Code Review for jdk ] http://cr.openjdk.java.net/~dbuck/7198904/webrev.00/ The OracleJDK fix (closed source) is ready and has already passed code review. I intend to push both the OracleJDK fix and this test case into their respective repositories at the same time once this review is done. Regards, -Buck From cmotlin at gmail.com Wed Nov 14 15:12:31 2012 From: cmotlin at gmail.com (Craig P. Motlin) Date: Wed, 14 Nov 2012 10:12:31 -0500 Subject: Request for Review (#2) : CR#8001634 : Initial set of lambda functional interfaces In-Reply-To: References: Message-ID: What's the issue with both methods being named apply? On Tue, Nov 13, 2012 at 2:05 PM, Mike Duigou wrote: > The name Block.apply currently conflicts with Function.apply and should be > renamed. From tim at peierls.net Wed Nov 14 17:29:09 2012 From: tim at peierls.net (Tim Peierls) Date: Wed, 14 Nov 2012 12:29:09 -0500 Subject: Request for Review (#2) : CR#8001634 : Initial set of lambda functional interfaces In-Reply-To: <60A42ABE-35F7-4C58-BCB0-834B68BF06E0@oracle.com> References: <60A42ABE-35F7-4C58-BCB0-834B68BF06E0@oracle.com> Message-ID: Implementing more than one of the functional interfaces sounds like a bad idea; making it difficult or impossible to do is a *good *thing. Use apply everywhere to prevent things like Shimmer implements FloorWax, DessertTopping. Does anyone have any compelling example of why you actually might want to implement multiple functional interfaces that isn't satisfied by using asFunction, asPredicate, asProcedure, etc. methods? --tim On Wed, Nov 14, 2012 at 12:12 PM, Mike Duigou wrote: > The issue is primarily when one class wants to implement more than one > functional interface. If the names collide then the class will only be able > to implement one of the interfaces. > > Mike > > On Nov 14 2012, at 07:12 , Craig P. Motlin wrote: > > What's the issue with both methods being named apply? > > > On Tue, Nov 13, 2012 at 2:05 PM, Mike Duigou wrote: > >> The name Block.apply currently conflicts with Function.apply and should >> be renamed. > > > > From chris.hegarty at oracle.com Wed Nov 14 22:44:10 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 14 Nov 2012 22:44:10 +0000 Subject: RFR: 8003380 - Compiler warnings in logging test code In-Reply-To: <50A40A00.8060106@oracle.com> References: <50A40A00.8060106@oracle.com> Message-ID: Interesting... fixing warnings in tests. A few comments. - LoggingMXBeanTest2.java ListIterator -> ListIterator and remove redundant cast ? - @SuppressWarnings("unused") Eclipse??? Do we have precedent for adding these suppressions?? - ClassLoaderLeakTest Why the change to use toURI().toURL() ?? -Chris On 14 Nov 2012, at 21:15, Jim Gish wrote: > Please review http://cr.openjdk.java.net/~jgish/Bug8003380-logging-test-warnings/ > > These are simple changes to eliminate compiler warnings from java.util.logging test code. > > 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 jim.gish at oracle.com Wed Nov 14 22:48:00 2012 From: jim.gish at oracle.com (Jim Gish) Date: Wed, 14 Nov 2012 17:48:00 -0500 Subject: RFR: 8003380 - Compiler warnings in logging test code In-Reply-To: References: <50A40A00.8060106@oracle.com> Message-ID: <50A41FA0.7030908@oracle.com> On 11/14/2012 05:44 PM, Chris Hegarty wrote: > Interesting... fixing warnings in tests. A few comments. Right -- one might consider it overkill sine the warnings don't show up in normal testing, but they do show up in Eclipse. Just plain annoying. > > - LoggingMXBeanTest2.java > ListIterator -> ListIterator and remove redundant cast ? ok. > - @SuppressWarnings("unused") Eclipse??? > Do we have precedent for adding these suppressions?? Not that I know of. > - ClassLoaderLeakTest > Why the change to use toURI().toURL() ?? Because directly applying .toURL() unless it is on a URI is deprecated. ...Jim > -Chris > > On 14 Nov 2012, at 21:15, Jim Gish > wrote: > >> Please review >> http://cr.openjdk.java.net/~jgish/Bug8003380-logging-test-warnings/ >> >> >> >> These are simple changes to eliminate compiler warnings from >> java.util.logging test code. >> >> 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 >> -- 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 jim.gish at oracle.com Wed Nov 14 23:13:56 2012 From: jim.gish at oracle.com (Jim Gish) Date: Wed, 14 Nov 2012 18:13:56 -0500 Subject: RFR: 8003380 - Compiler warnings in logging test code In-Reply-To: <50A41FA0.7030908@oracle.com> References: <50A40A00.8060106@oracle.com> <50A41FA0.7030908@oracle.com> Message-ID: <50A425B4.20909@oracle.com> I've updated the webrev with your suggestion. Here it is: http://cr.openjdk.java.net/~jgish/Bug8003380-logging-test-warnings/ Could someone please push it? Thanks, Jim On 11/14/2012 05:48 PM, Jim Gish wrote: > > On 11/14/2012 05:44 PM, Chris Hegarty wrote: >> Interesting... fixing warnings in tests. A few comments. > Right -- one might consider it overkill sine the warnings don't show > up in normal testing, but they do show up in Eclipse. Just plain > annoying. >> >> - LoggingMXBeanTest2.java >> ListIterator -> ListIterator and remove redundant cast ? > ok. >> - @SuppressWarnings("unused") Eclipse??? >> Do we have precedent for adding these suppressions?? > Not that I know of. >> - ClassLoaderLeakTest >> Why the change to use toURI().toURL() ?? > Because directly applying .toURL() unless it is on a URI is deprecated. > > ...Jim >> -Chris >> >> On 14 Nov 2012, at 21:15, Jim Gish > > wrote: >> >>> Please review >>> http://cr.openjdk.java.net/~jgish/Bug8003380-logging-test-warnings/ >>> >>> >>> >>> These are simple changes to eliminate compiler warnings from >>> java.util.logging test code. >>> >>> 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 >>> > -- 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 vitalyd at gmail.com Thu Nov 15 00:58:47 2012 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Wed, 14 Nov 2012 19:58:47 -0500 Subject: hg: jdk8/tl/jdk: 6924259: Remove offset and count fields from java.lang.String In-Reply-To: References: Message-ID: Personally, I feel like the concern is a bit overstated: 1) the n in O(n) is likely actually fairly small in practice (at least in what I'd consider sane code) 2) I think a lot of people that worry about perf probably aren't using substring() anyway 3) copying char[] is optimized by jit - this is basically a memcpy()-like call, which modern machines handle well 4) the upside is strings are 8 bytes smaller 5) .NET substring() has always allocated new storage (via an optimized internal VM call) and never shared the char[] and I haven't come across any complaints or seen serious perf problems myself (granted I seldom use substring) So I don't know if this is anything to worry about in practice. Sent from my phone On Nov 14, 2012 5:26 PM, "Zhong Yu" wrote: > On 06/03/2012 11:35 PM, Mike Duigou wrote: > > [I trimmed the distribution list] > > > > On Jun 3 2012, at 13:44 , Peter Levart wrote: > > > >> On Thursday, May 31, 2012 03:22:35 AM mike.duigou at oracle.com wrote: > >>> Changeset: 2c773daa825d > >>> Author: mduigou > >>> Date: 2012-05-17 10:06 -0700 > >>> URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2c773daa825d > >>> > >>> 6924259: Remove offset and count fields from java.lang.String > >>> Summary: Removes the use of shared character array buffers by String > along > >>> with the two fields needed to support the use of shared buffers. > >> Wow, that's quite a change. > > Indeed. It was a long time in development. It is a change which is > expected to be overall beneficial though and in the general case a positive > win. > > Wow! > > If the previous behavior of substring() was once a bug, by now it has > become a well known feature. People know about it, and people depend > on it. > > This change is a big surprise. Changing O(1) to O(n) is a breach of > contract. It'll break lots of old code; and meanwhile lots of new code > are still being written based on the old assumption. After people > learned about the new behavior, they need to comb through and rewrite > their code. > > The worst part is the same code performs very differently on different > versions of JDK. What's a programmer supposed to do if his code > targets JDK6 and above? If the cost of strings are no longer certain, > what else can we believe in? > > Is there any chance in hell to roll it back? Maybe add a new method > for the new behavior? > > Zhong Yu > From lana.steuck at oracle.com Thu Nov 15 01:00:49 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Thu, 15 Nov 2012 01:00:49 +0000 Subject: hg: jdk8/tl: 8 new changesets Message-ID: <20121115010049.A29C54798F@hg.openjdk.java.net> Changeset: e20ffc02e437 Author: erikj Date: 2012-11-03 16:15 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/e20ffc02e437 8002183: Increased max number of paths to list in ListPathsSafely to 16000. Reviewed-by: ohair ! common/makefiles/MakeBase.gmk Changeset: ed9e5635fc80 Author: erikj Date: 2012-11-03 16:28 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/ed9e5635fc80 8002220: build-infra: update for mac, solaris 11 issues 8002184: Fixed exclude and includes for jarsigner in new build Reviewed-by: ohair ! common/autoconf/basics.m4 ! common/autoconf/basics_windows.m4 ! common/autoconf/compare.sh.in ! common/autoconf/generated-configure.sh ! common/autoconf/libraries.m4 ! common/bin/compare.sh ! common/bin/compare_exceptions.sh.incl ! common/makefiles/JavaCompilation.gmk Changeset: 1c8370a55b30 Author: katleman Date: 2012-11-07 15:32 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/1c8370a55b30 Merge Changeset: 838a64965131 Author: katleman Date: 2012-11-08 11:50 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/838a64965131 Added tag jdk8-b64 for changeset 1c8370a55b30 ! .hgtags Changeset: 8bbc72864a41 Author: ohrstrom Date: 2012-11-08 12:24 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/rev/8bbc72864a41 8003161: small fixes to re-enable new build system Reviewed-by: dholmes, alanb, erikj ! common/makefiles/JavaCompilation.gmk Changeset: 78bb27faf889 Author: tbell Date: 2012-11-12 12:34 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/78bb27faf889 8002028: build-infra: need no-hotspot partial build Summary: Added configure option --with-import-hotspot=/path/to/j2sdkimage Reviewed-by: dholmes, tbell Contributed-by: erik.joelsson at oracle.com ! common/autoconf/generated-configure.sh ! common/autoconf/source-dirs.m4 ! common/autoconf/spec.gmk.in ! common/makefiles/Main.gmk Changeset: f2ac4d0edaae Author: tbell Date: 2012-11-13 15:54 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/f2ac4d0edaae 8003274: build-infra: Makefile changes needed for sjavac Summary: changes left in build-infra that are related to sjavac Reviewed-by: ohair, tbell Contributed-by: erik.joelsson at oracle.com, fredrik.ohrstrom at oracle.com ! common/autoconf/spec.gmk.in ! common/makefiles/JavaCompilation.gmk ! common/makefiles/MakeHelpers.gmk Changeset: b772de306dc2 Author: katleman Date: 2012-11-14 12:28 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/b772de306dc2 Merge From lana.steuck at oracle.com Thu Nov 15 01:00:56 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Thu, 15 Nov 2012 01:00:56 +0000 Subject: hg: jdk8/tl/jaxp: Added tag jdk8-b64 for changeset 27ab79568c34 Message-ID: <20121115010058.C808647991@hg.openjdk.java.net> Changeset: 5cf3c69a93d6 Author: katleman Date: 2012-11-08 11:51 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/5cf3c69a93d6 Added tag jdk8-b64 for changeset 27ab79568c34 ! .hgtags From lana.steuck at oracle.com Thu Nov 15 01:00:49 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Thu, 15 Nov 2012 01:00:49 +0000 Subject: hg: jdk8/tl/corba: Added tag jdk8-b64 for changeset 54d599a5b4aa Message-ID: <20121115010050.25AA847990@hg.openjdk.java.net> Changeset: 5132f7900a8f Author: katleman Date: 2012-11-08 11:50 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/5132f7900a8f Added tag jdk8-b64 for changeset 54d599a5b4aa ! .hgtags From lana.steuck at oracle.com Thu Nov 15 01:01:09 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Thu, 15 Nov 2012 01:01:09 +0000 Subject: hg: jdk8/tl/hotspot: 18 new changesets Message-ID: <20121115010144.3BB9F47994@hg.openjdk.java.net> Changeset: 49bc14aaadcc Author: katleman Date: 2012-11-08 11:51 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/49bc14aaadcc Added tag jdk8-b64 for changeset 5920f72e799c ! .hgtags Changeset: ca8168203393 Author: amurillo Date: 2012-11-02 07:44 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ca8168203393 8002181: new hotspot build - hs25-b09 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 857f3ce858dd Author: dholmes Date: 2012-11-05 19:33 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/857f3ce858dd 8002034: Allow Full Debug Symbols when cross-compiling 8001756: Hotspot makefiles report missing OBJCOPY command in the wrong circumstances Reviewed-by: dcubed, dsamersoff, erikj, collins ! make/linux/makefiles/defs.make ! make/linux/makefiles/vm.make ! make/solaris/makefiles/defs.make ! make/windows/makefiles/defs.make Changeset: 3d701c802d01 Author: minqi Date: 2012-11-02 13:30 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3d701c802d01 8000489: older builds of hsdis don't work anymore after 6879063 Summary: The old function not defined properly, need a definition for export in dll. Also changes made to let new jvm work with old hsdis. Reviewed-by: jrose, sspitsyn, kmo Contributed-by: yumin.qi at oracle.com ! src/share/tools/hsdis/hsdis-demo.c ! src/share/tools/hsdis/hsdis.c ! src/share/tools/hsdis/hsdis.h ! src/share/vm/compiler/disassembler.cpp ! src/share/vm/compiler/disassembler.hpp Changeset: 4735d2c84362 Author: kamg Date: 2012-10-11 12:25 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/4735d2c84362 7200776: Implement default methods in interfaces Summary: Add generic type analysis and default method selection algorithms Reviewed-by: coleenp, acorn + src/share/vm/classfile/bytecodeAssembler.cpp + src/share/vm/classfile/bytecodeAssembler.hpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp + src/share/vm/classfile/defaultMethods.cpp + src/share/vm/classfile/defaultMethods.hpp + src/share/vm/classfile/genericSignatures.cpp + src/share/vm/classfile/genericSignatures.hpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/verifier.cpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/code/dependencies.cpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/oops/constMethod.cpp ! src/share/vm/oops/constMethod.hpp ! src/share/vm/oops/constantPool.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/klassVtable.cpp ! src/share/vm/oops/klassVtable.hpp ! src/share/vm/oops/method.cpp ! src/share/vm/oops/method.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/reflection.cpp ! src/share/vm/utilities/growableArray.hpp + src/share/vm/utilities/pair.hpp + src/share/vm/utilities/resourceHash.hpp Changeset: ec204374e626 Author: kamg Date: 2012-11-02 16:09 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ec204374e626 Merge ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/oops/method.cpp ! src/share/vm/runtime/globals.hpp - test/runtime/7158800/BadUtf8.java - test/runtime/7158800/InternTest.java - test/runtime/7158800/Test7158800.sh - test/runtime/7158800/badstrings.txt Changeset: 9cc901118f6b Author: kamg Date: 2012-11-02 17:18 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9cc901118f6b Merge Changeset: 69ad7823b1ca Author: zgu Date: 2012-11-05 15:30 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/69ad7823b1ca 8001591: NMT: assertion failed: assert(rec->addr() + rec->size() <= cur->base()) failed: Can not overlap in memSnapshot.cpp Summary: NMT should allow overlapping committed regions as long as they belong to the same reserved region Reviewed-by: dholmes, coleenp ! src/share/vm/services/memPtr.hpp ! src/share/vm/services/memSnapshot.cpp Changeset: 8940ddc1036f Author: zgu Date: 2012-11-05 13:55 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8940ddc1036f Merge - test/runtime/7158800/BadUtf8.java - test/runtime/7158800/InternTest.java - test/runtime/7158800/Test7158800.sh - test/runtime/7158800/badstrings.txt Changeset: c284cf4781f0 Author: rbackman Date: 2012-10-04 14:55 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c284cf4781f0 7127792: Add the ability to change an existing PeriodicTask's execution interval Summary: Enables dynamic enrollment / disenrollment from the PeriodicTasks in WatcherThread. Reviewed-by: dholmes, mgronlun ! src/share/vm/runtime/mutexLocker.cpp ! src/share/vm/runtime/mutexLocker.hpp ! src/share/vm/runtime/task.cpp ! src/share/vm/runtime/task.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp Changeset: 18fb7da42534 Author: coleenp Date: 2012-11-06 15:09 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/18fb7da42534 8000725: NPG: method_holder() and pool_holder() and pool_holder field should be InstanceKlass Summary: Change types of above methods and field to InstanceKlass and remove unneeded casts from the source files. Reviewed-by: dholmes, coleenp, zgu Contributed-by: harold.seigel at oracle.com ! agent/src/share/classes/sun/jvm/hotspot/oops/ConstantPool.java ! agent/src/share/classes/sun/jvm/hotspot/oops/Method.java ! src/cpu/sparc/vm/sharedRuntime_sparc.cpp ! src/cpu/x86/vm/sharedRuntime_x86_32.cpp ! src/cpu/x86/vm/sharedRuntime_x86_64.cpp ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/verifier.cpp ! src/share/vm/classfile/vmSymbols.cpp ! src/share/vm/code/compiledIC.cpp ! src/share/vm/code/dependencies.cpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/compiler/compilerOracle.cpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/oops/constMethod.cpp ! src/share/vm/oops/constantPool.cpp ! src/share/vm/oops/constantPool.hpp ! src/share/vm/oops/cpCache.cpp ! src/share/vm/oops/klassVtable.cpp ! src/share/vm/oops/method.cpp ! src/share/vm/oops/method.hpp ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvmtiClassFileReconstituter.cpp ! src/share/vm/prims/jvmtiEnv.cpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/nativeLookup.cpp ! src/share/vm/runtime/compilationPolicy.cpp ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/runtime/fieldDescriptor.cpp ! src/share/vm/runtime/fieldDescriptor.hpp ! src/share/vm/runtime/javaCalls.cpp ! src/share/vm/runtime/reflection.cpp ! src/share/vm/runtime/vframe.cpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/services/heapDumper.cpp Changeset: ead8852dd4ef Author: coleenp Date: 2012-11-07 16:09 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ead8852dd4ef Merge Changeset: 64672b22ef05 Author: twisti Date: 2012-11-02 12:30 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/64672b22ef05 8001658: No need to pass resolved_references as argument to ConstantPoolCacheEntry::set_method_handle_common Reviewed-by: twisti Contributed-by: Bharadwaj Yadavalli ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/oops/cpCache.cpp ! src/share/vm/oops/cpCache.hpp Changeset: dbeaeee28bc2 Author: kvn Date: 2012-11-06 09:22 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/dbeaeee28bc2 8002294: assert(VM_Version::supports_ssse3()) failed Summary: Add missing UseSSE check for AES intrinsics. Reviewed-by: roland, twisti ! src/cpu/x86/vm/vm_version_x86.cpp Changeset: f3da5ff1514c Author: kvn Date: 2012-11-06 15:16 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f3da5ff1514c 8002069: Assert failed in C2: assert(field->edge_count() > 0) failed: sanity Summary: Added missed type check of initializing store in ConnectionGraph::find_init_values(). Reviewed-by: roland, twisti, vlivanov ! src/share/vm/opto/escape.cpp + test/compiler/8002069/Test8002069.java Changeset: a4e1bd941ded Author: neliasso Date: 2012-11-08 22:39 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a4e1bd941ded Merge ! src/share/vm/oops/cpCache.cpp Changeset: b4ee7b773144 Author: amurillo Date: 2012-11-09 08:20 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b4ee7b773144 Merge Changeset: 0f7290a03b24 Author: amurillo Date: 2012-11-09 08:20 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/0f7290a03b24 Added tag hs25-b09 for changeset b4ee7b773144 ! .hgtags From lana.steuck at oracle.com Thu Nov 15 01:01:02 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Thu, 15 Nov 2012 01:01:02 +0000 Subject: hg: jdk8/tl/langtools: 3 new changesets Message-ID: <20121115010108.D41FB47993@hg.openjdk.java.net> Changeset: 056d828ac1e1 Author: katleman Date: 2012-11-08 11:53 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/056d828ac1e1 Added tag jdk8-b64 for changeset e6ee43b3e247 ! .hgtags Changeset: 5f2faba89cac Author: lana Date: 2012-11-09 14:47 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/5f2faba89cac Merge Changeset: b486794d160d Author: lana Date: 2012-11-14 16:41 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/b486794d160d Merge From lana.steuck at oracle.com Thu Nov 15 01:00:59 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Thu, 15 Nov 2012 01:00:59 +0000 Subject: hg: jdk8/tl/jaxws: Added tag jdk8-b64 for changeset 5ded18a14bcc Message-ID: <20121115010101.85E1F47992@hg.openjdk.java.net> Changeset: fbe54291c9d3 Author: katleman Date: 2012-11-08 11:51 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/fbe54291c9d3 Added tag jdk8-b64 for changeset 5ded18a14bcc ! .hgtags From lana.steuck at oracle.com Thu Nov 15 01:01:20 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Thu, 15 Nov 2012 01:01:20 +0000 Subject: hg: jdk8/tl/jdk: 12 new changesets Message-ID: <20121115010335.8FF3D47995@hg.openjdk.java.net> Changeset: 63726e5b90da Author: erikj Date: 2012-11-03 16:27 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/63726e5b90da 8002220: build-infra: update for mac, solaris 11 issues 8002184: Fixed exclude and includes for jarsigner in new build Reviewed-by: ohair ! makefiles/CompileJavaClasses.gmk ! makefiles/CompileNativeLibraries.gmk ! makefiles/CreateJars.gmk ! makefiles/GensrcJObjC.gmk Changeset: 26dbd73fb766 Author: katleman Date: 2012-11-07 15:39 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/26dbd73fb766 Merge ! makefiles/CompileJavaClasses.gmk ! makefiles/CompileNativeLibraries.gmk ! makefiles/CreateJars.gmk Changeset: ad5c1d6b1e16 Author: katleman Date: 2012-11-08 11:52 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ad5c1d6b1e16 Added tag jdk8-b64 for changeset 26dbd73fb766 ! .hgtags Changeset: 220d2458ce4b Author: lana Date: 2012-11-09 14:46 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/220d2458ce4b Merge Changeset: 3717bcf9d7a7 Author: dholmes Date: 2012-11-07 23:12 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3717bcf9d7a7 8002040: Allow Full Debug Symbols when cross-compiling Reviewed-by: dcubed, erikj, tbell ! make/common/Defs-linux.gmk Changeset: 1e79fec4a01f Author: ohrstrom Date: 2012-11-08 12:25 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1e79fec4a01f 8003161: small fixes to re-enable new build system Reviewed-by: dholmes, alanb, erikj ! makefiles/CompileNativeLibraries.gmk ! makefiles/CreateJars.gmk Changeset: 170e8ccfbc4f Author: tbell Date: 2012-11-12 10:20 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/170e8ccfbc4f 8002365: build-infra: Build-infra fails on solaris 11.1 on sparc. Summary: Add '-lc' to LDFLAGS for native libraries in CompileNativeLibraries.gmk Reviewed-by: ohair, tbell Contributed-by: erik.joelsson at oracle.com ! makefiles/CompileNativeLibraries.gmk Changeset: 2fc142843a93 Author: tbell Date: 2012-11-12 10:49 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2fc142843a93 8003177: build-infra: Compare reports diff in LocaleDataMetaInfo.class Summary: Remove spurious space in the locale lists Reviewed-by: naoto, ohair, tbell Contributed-by: erik.joelsson at oracle.com ! makefiles/GensrcLocaleDataMetaInfo.gmk Changeset: e9e8a5852690 Author: tbell Date: 2012-11-12 12:35 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e9e8a5852690 8002028: build-infra: need no-hotspot partial build Summary: Added configure option --with-import-hotspot=/path/to/j2sdkimage Reviewed-by: dholmes, tbell Contributed-by: erik.joelsson at oracle.com ! makefiles/Import.gmk Changeset: 84f0439ccaab Author: tbell Date: 2012-11-13 13:46 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/84f0439ccaab 8001965: build-infra: Large compare diffs between new and old on mac Summary: The wrong icon source file was used when building closed Reviewed-by: ohair, tbell Contributed-by: erik.joelsson at oracle.com ! makefiles/GensrcIcons.gmk Changeset: 130d3a54d28b Author: katleman Date: 2012-11-14 12:29 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/130d3a54d28b Merge Changeset: f4de6a38f794 Author: lana Date: 2012-11-14 16:41 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f4de6a38f794 Merge From rob.mckenna at oracle.com Thu Nov 15 01:11:46 2012 From: rob.mckenna at oracle.com (Rob McKenna) Date: Thu, 15 Nov 2012 01:11:46 +0000 Subject: What happened to System/Process.getPid() ? In-Reply-To: References: Message-ID: <50A44152.10601@oracle.com> Hi Thomas, Don't ask me why, but for some reason this mail just landed in my client now. (this happens a lot on this mailing list for some reason) getPid() is still on the todo list at the moment. Once I clear my plate a little I'll follow up on it. -Rob On 26/10/12 10:02, Thomas L wrote: > I'm sorry if I missed this, but I can't seem to find any information about > what happened to the RFE "provide process ID" [1]. This umbrella bug > report/RFE is marked as 'fixed', but I can't see that the "getPid" part is > included in the current build of JDK8 (build 62). > > The "process destroy/getPid" RFE was previously listed under JDK8 features, > but now it's gone.[2] > > And I can't find any information about "getPid()" being dropped from JDK8 > either. > > In his review request for the "System.killProcess" part of this RFE, Rob > McKenna wrote: > > "As per the bug report the toString/pid work has been left to be > completed separately."[3] > > What happened to "System/Process.getPid()" ? Is anyone actively working on > adding this to JDK8 ? > > [1]. http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4244896 > [2]. http://openjdk.java.net/projects/jdk8/features > [3]. > http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-April/009816.html > > Thanks > Thomas From jonathan.gibbons at oracle.com Thu Nov 15 01:23:13 2012 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Thu, 15 Nov 2012 01:23:13 +0000 Subject: hg: jdk8/tl/langtools: 7021614: extend com.sun.source API to support parsing javadoc comments Message-ID: <20121115012315.5118647996@hg.openjdk.java.net> Changeset: 33abf479f202 Author: jjg Date: 2012-11-14 17:23 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/33abf479f202 7021614: extend com.sun.source API to support parsing javadoc comments Reviewed-by: ksrini, strarup ! make/build.xml + 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/Tree.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/SimpleDocTreeVisitor.java ! src/share/classes/com/sun/source/util/Trees.java ! src/share/classes/com/sun/tools/javac/api/JavacTrees.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/AttrContext.java ! src/share/classes/com/sun/tools/javac/comp/Env.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java + src/share/classes/com/sun/tools/javac/parser/DocCommentParser.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/parser/JavadocTokenizer.java + src/share/classes/com/sun/tools/javac/parser/LazyDocCommentTable.java ! src/share/classes/com/sun/tools/javac/parser/ParserFactory.java - src/share/classes/com/sun/tools/javac/parser/SimpleDocCommentTable.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties + src/share/classes/com/sun/tools/javac/tree/DCTree.java ! src/share/classes/com/sun/tools/javac/tree/DocCommentTable.java + src/share/classes/com/sun/tools/javac/tree/DocPretty.java + src/share/classes/com/sun/tools/javac/tree/DocTreeMaker.java ! src/share/classes/com/sun/tools/javadoc/DocEnv.java ! src/share/classes/com/sun/tools/javadoc/SeeTagImpl.java ! test/tools/javac/diags/CheckExamples.java + test/tools/javac/diags/DocCommentProcessor.java ! test/tools/javac/diags/Example.java ! test/tools/javac/diags/RunExamples.java ! test/tools/javac/diags/examples.not-yet.txt + test/tools/javac/diags/examples/BadEntity.java + test/tools/javac/diags/examples/BadGreaterThan.java + test/tools/javac/diags/examples/BadInlineTag.java + test/tools/javac/diags/examples/GreaterThanExpected.java + test/tools/javac/diags/examples/MalformedHTML.java + test/tools/javac/diags/examples/MissingSemicolon.java + test/tools/javac/diags/examples/NoTagName.java + test/tools/javac/diags/examples/RefBadParens.java + test/tools/javac/diags/examples/RefIdentifierExpected.java + test/tools/javac/diags/examples/RefSyntaxError.java + test/tools/javac/diags/examples/RefUnexpectedInput.java + test/tools/javac/diags/examples/UnexpectedContent.java + test/tools/javac/diags/examples/UnterminatedInlineTag.java + test/tools/javac/diags/examples/UnterminatedSignature.java + test/tools/javac/doctree/AttrTest.java + test/tools/javac/doctree/AuthorTest.java + test/tools/javac/doctree/BadTest.java + test/tools/javac/doctree/CodeTest.java + test/tools/javac/doctree/DeprecatedTest.java + test/tools/javac/doctree/DocCommentTester.java + test/tools/javac/doctree/DocRootTest.java + test/tools/javac/doctree/ElementTest.java + test/tools/javac/doctree/EntityTest.java + test/tools/javac/doctree/ExceptionTest.java + test/tools/javac/doctree/FirstSentenceTest.java + test/tools/javac/doctree/InheritDocTest.java + test/tools/javac/doctree/LinkPlainTest.java + test/tools/javac/doctree/LinkTest.java + test/tools/javac/doctree/LiteralTest.java + test/tools/javac/doctree/ParamTest.java + test/tools/javac/doctree/ReferenceTest.java + test/tools/javac/doctree/ReturnTest.java + test/tools/javac/doctree/SeeTest.java + test/tools/javac/doctree/SerialDataTest.java + test/tools/javac/doctree/SerialFieldTest.java + test/tools/javac/doctree/SerialTest.java + test/tools/javac/doctree/SimpleDocTreeVisitorTest.java + test/tools/javac/doctree/SinceTest.java + test/tools/javac/doctree/TagTest.java + test/tools/javac/doctree/ThrowableTest.java + test/tools/javac/doctree/ValueTest.java + test/tools/javac/doctree/VersionTest.java From david.holmes at oracle.com Thu Nov 15 04:24:57 2012 From: david.holmes at oracle.com (David Holmes) Date: Thu, 15 Nov 2012 14:24:57 +1000 Subject: code review request: Test case for JDK-7198904 TreeMap.clone issue In-Reply-To: <50A39EED.9050902@oracle.com> References: <50A39EED.9050902@oracle.com> Message-ID: <50A46E99.3020409@oracle.com> Looks okay to me. David On 14/11/2012 11:38 PM, David Buck wrote: > Hi! > > This is a review request to add only the test case for the following > OracleJDK issue: > > [ 7198904 : (alt-rt) TreeMap.clone is broken ] > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7198904 > > The issue (root cause) is not in OpenJDK (i.e. the problem was OracleJDK > specific), but the test case is valid for both so it should go into > OpenJDK so we can prevent a similar issue from ever happening in both > releases moving forward. > > webrev: > > [ Code Review for jdk ] > http://cr.openjdk.java.net/~dbuck/7198904/webrev.00/ > > The OracleJDK fix (closed source) is ready and has already passed code > review. I intend to push both the OracleJDK fix and this test case into > their respective repositories at the same time once this review is done. > > Regards, > -Buck From zhong.j.yu at gmail.com Thu Nov 15 04:56:47 2012 From: zhong.j.yu at gmail.com (Zhong Yu) Date: Wed, 14 Nov 2012 22:56:47 -0600 Subject: hg: jdk8/tl/jdk: 6924259: Remove offset and count fields from java.lang.String In-Reply-To: References: Message-ID: Since this change is to achieve minor performance boost, it's not fair to defend it by saying that it only incurs minor performance penalties. Java programs are infested with strings, most of which could have used a more appropriate type, but it is the insane reality. Any change to the behavior of strings should have been backed up by a much more thorough analysis. Every usage of substring() was (hopefully) the result of some conscious reasoning about space-time. Even if this change does not significantly alter an application's performance, it invalidates all the reasoning, that's the worst blow in my book. There's no problem if substring() does copying from day one, but 17 years have passed. Zhong Yu On Wed, Nov 14, 2012 at 6:58 PM, Vitaly Davidovich wrote: > Personally, I feel like the concern is a bit overstated: > > 1) the n in O(n) is likely actually fairly small in practice (at least in > what I'd consider sane code) > 2) I think a lot of people that worry about perf probably aren't using > substring() anyway > 3) copying char[] is optimized by jit - this is basically a memcpy()-like > call, which modern machines handle well > 4) the upside is strings are 8 bytes smaller > 5) .NET substring() has always allocated new storage (via an optimized > internal VM call) and never shared the char[] and I haven't come across any > complaints or seen serious perf problems myself (granted I seldom use > substring) > > So I don't know if this is anything to worry about in practice. > > Sent from my phone > > On Nov 14, 2012 5:26 PM, "Zhong Yu" wrote: >> >> On 06/03/2012 11:35 PM, Mike Duigou wrote: >> > [I trimmed the distribution list] >> > >> > On Jun 3 2012, at 13:44 , Peter Levart wrote: >> > >> >> On Thursday, May 31, 2012 03:22:35 AM mike.duigou at oracle.com wrote: >> >>> Changeset: 2c773daa825d >> >>> Author: mduigou >> >>> Date: 2012-05-17 10:06 -0700 >> >>> URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2c773daa825d >> >>> >> >>> 6924259: Remove offset and count fields from java.lang.String >> >>> Summary: Removes the use of shared character array buffers by String >> >>> along >> >>> with the two fields needed to support the use of shared buffers. >> >> Wow, that's quite a change. >> > Indeed. It was a long time in development. It is a change which is >> > expected to be overall beneficial though and in the general case a positive >> > win. >> >> Wow! >> >> If the previous behavior of substring() was once a bug, by now it has >> become a well known feature. People know about it, and people depend >> on it. >> >> This change is a big surprise. Changing O(1) to O(n) is a breach of >> contract. It'll break lots of old code; and meanwhile lots of new code >> are still being written based on the old assumption. After people >> learned about the new behavior, they need to comb through and rewrite >> their code. >> >> The worst part is the same code performs very differently on different >> versions of JDK. What's a programmer supposed to do if his code >> targets JDK6 and above? If the cost of strings are no longer certain, >> what else can we believe in? >> >> Is there any chance in hell to roll it back? Maybe add a new method >> for the new behavior? >> >> Zhong Yu From david.holmes at oracle.com Thu Nov 15 05:05:32 2012 From: david.holmes at oracle.com (David Holmes) Date: Thu, 15 Nov 2012 15:05:32 +1000 Subject: Request for Review : 7175464 : entrySetView field is never updated in NavigableSubMap In-Reply-To: References: Message-ID: <50A4781C.701@oracle.com> Hi Mike, On 15/11/2012 3:49 AM, Mike Duigou wrote: > Hello all; > > A small but useful performance fix for sub-maps of TreeMap: > > http://cr.openjdk.java.net/~mduigou/7175464/0/webrev/ > > The entrySetView was not being cached. Seems a bug that entrySetView was never being set, but given that it wasn't this may now introduce an incompatability may it not? Even if the spec permits caching for how long have we always returned a new instance? David > There is no unit test because either implementation is permissible under the specification. The fix only has the effect of improving performance and reducing duplicate objects. > > Mike From zhouyx at linux.vnet.ibm.com Thu Nov 15 05:17:29 2012 From: zhouyx at linux.vnet.ibm.com (Sean Chou) Date: Thu, 15 Nov 2012 13:17:29 +0800 Subject: Request for review: 7201156 : jar tool fails to convert file separation characters for list and extract In-Reply-To: <50A32D74.3090703@linux.vnet.ibm.com> References: <509A3508.3010205@oracle.com> <509D0F8A.4030909@oracle.com> <50A0C8D4.6080901@oracle.com> <50A22D43.50308@oracle.com> <50A32D74.3090703@linux.vnet.ibm.com> Message-ID: That's right, thanks. On Wed, Nov 14, 2012 at 1:34 PM, Jonathan Lu wrote: > Hi Sean, > > Patch pushed @ http://hg.openjdk.java.net/**jdk8/tl/jdk/rev/83765e82cacb > Could you please verify? > > Thanks & regards > Jonathan > > > On 11/14/2012 10:23 AM, Sean Chou wrote: > >> Thanks Alan and Chris. >> >> >> On Tue, Nov 13, 2012 at 7:21 PM, Chris Hegarty >> **wrote: >> >> Sean, >>> >>> Looks good to me. Thanks for updating the test. >>> >>> -Chris. >>> >>> >>> On 11/13/2012 03:17 AM, Sean Chou wrote: >>> >>> Hi Alan, >>>> >>>> Here is the updated webrev: >>>> http://cr.openjdk.java.net/~****zhouyx/7201156/webrev.03/ >>>> > >>>> . >>>> >>>> >>>> On Mon, Nov 12, 2012 at 6:00 PM, Alan Bateman >>> >** >>>> >>>> wrote: >>>> >>>> On 12/11/2012 09:08, Sean Chou wrote: >>>> >>>>> Hi , >>>>> >>>>>> I didn't realize that rt.jar would miss before. The testcase is >>>>>> updated >>>>>> to create a temp file as well as test the extract option. However, >>>>>> extract >>>>>> testing will create a directory if it passes, I just deleted it in >>>>>> testcase. Please take a look. >>>>>> >>>>>> webrev: http://cr.openjdk.java.net/~******zhouyx/7201156/webrev.02/ >>>>>> >>>>>> > >>>>>> >>>>>> >>>>>> > >>>>>> >>>>>>> < >>>>>>> >>>>>> http://cr.openjdk.java.net/%******7Ezhouyx/7201156/webrev.02/<**ht** >>>>>> >>>>>> tp://cr.openjdk.java.net/%****7Ezhouyx/7201156/webrev.02/>>>>> tp://cr.openjdk.java.net/%**7Ezhouyx/7201156/webrev.02/ >>>>>> > >>>>>> . >>>>>> >>>>>> Thanks for removing the dependency on rt.jar. >>>>>> >>>>>> A couple of comments on the updated test: >>>>> >>>>> - in main then it still has "pathRtJar" so I assume you just forgot to >>>>> rename that. >>>>> >>>>> I forgot the name had its meaning. >>>>> >>>> >>>> - it would be good to change createJarFile to use try-with-resources so >>>>> that an error doesn't cause it to terminate with an open file. >>>>> >>>>> Changed. >>>>> >>>> >>>> - testJarExact, I assume you intended to name this testJarExtract. >>>>> >>>>> Yes! >>>>> >>>> >>>> - L114-117, the "./" is not needed. It would be okay to leave those >>>>> files >>>>> there if you want, jtreg will clean them up too. >>>>> >>>>> Thanks for the hint. I removed these lines, so the testcase looks >>>> tidy. >>>> >>>> >>>> -Alan. >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >> > -- Best Regards, Sean Chou From mike.duigou at oracle.com Thu Nov 15 05:28:28 2012 From: mike.duigou at oracle.com (Mike Duigou) Date: Wed, 14 Nov 2012 21:28:28 -0800 Subject: Request for Review : 7175464 : entrySetView field is never updated in NavigableSubMap In-Reply-To: <50A4781C.701@oracle.com> References: <50A4781C.701@oracle.com> Message-ID: <2CE873A3-D288-4319-8F69-2CD591F07DE3@oracle.com> This bug appears to have been present as far back as Java 6 when NavigableSet was introduced. I could only check 6u33 but it seems unlikely to have been broken during the course of Java 6 maintenance releases. As these are views which pass through mutation to the parent object I believe there are fewer compatibility concerns than might be expected. Compatibility concern would mostly involve use of the returned entrySetView for synchronization. Previously synchronization on the returned views would have been partially ineffectual because a new view object was returned every time. Sharing the returned views would have synchronized correctly but any other access to the source object either directly or through other views would have led to problems with concurrent modification of the source treemap. In the repaired implementation where a single view object is returned synchronization on the views would now be more effective and prevent concurrent race errors. It's possible that new deadlock conditions might be introduced but this seems unlikely. Mike On Nov 14 2012, at 21:05 , David Holmes wrote: > Hi Mike, > > On 15/11/2012 3:49 AM, Mike Duigou wrote: >> Hello all; >> >> A small but useful performance fix for sub-maps of TreeMap: >> >> http://cr.openjdk.java.net/~mduigou/7175464/0/webrev/ >> >> The entrySetView was not being cached. > > Seems a bug that entrySetView was never being set, but given that it wasn't this may now introduce an incompatability may it not? Even if the spec permits caching for how long have we always returned a new instance? > > David > >> There is no unit test because either implementation is permissible under the specification. The fix only has the effect of improving performance and reducing duplicate objects. >> >> Mike From david.holmes at oracle.com Thu Nov 15 06:56:05 2012 From: david.holmes at oracle.com (David Holmes) Date: Thu, 15 Nov 2012 16:56:05 +1000 Subject: Request for Review (#3) : CR#8001634 : Initial set of lambda functional interfaces In-Reply-To: References: Message-ID: <50A49205.6030108@oracle.com> Hi Mike, My original comment still stands regarding the wording in the Function specializations versus all the others. Why does, for example, IntFunction say "this is the {@code int}-bearing specialization for {@link Function}", yet IntBinaryOperator does not make a similar statement regarding BinaryOperator? David On 14/11/2012 11:19 AM, Mike Duigou wrote: > Hello all; > > I apologize for the quick turnaround from the second review request [1] but I've updated the webrev again: > > http://cr.openjdk.java.net/~mduigou/8001634/4/webrev/ > > Blame a busy Paul Sandoz who his making significant progress on the primitive specializations implementation. ;-) > > This update includes: > > - Block.apply renamed to Block.accept > - {Int|Long|Double}Block specializations added. > - Commented out "extends Combiner" in BinaryOperator was removed for now since Combiner is out of scope for this review. > - The {Int|Long|Double} specializations of BinaryOperator and UnaryOperator now show commented out extends of the generic version along with commented out default methods. This change will not be part of the commit but is meant to show where the implementation will be going. > - The {Int|Long|Double} specializations of Supplier now extend generic Supplier, have getAs{Int|Long|Double} as their abstract method and provide a commented out default get() method to satisfy the need for a get implementation. > - The {Int|Long|Double} specializations of Function now extend generic Function, have applyAs{Int|Long|Double} as their abstract method and provide a commented out default apply() method to satisfy the need for an apply implementation. > > Mike > > [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-November/012225.html From forax at univ-mlv.fr Thu Nov 15 08:04:22 2012 From: forax at univ-mlv.fr (Remi Forax) Date: Thu, 15 Nov 2012 09:04:22 +0100 Subject: RFR: 8003322: Add instrumentation points for tracing of I/O calls In-Reply-To: References: <50A39388.8060502@oracle.com> Message-ID: <50A4A206.5010808@univ-mlv.fr> Hi Staffan, in IOTraceAgent, ASM provides a method named Type.getOpcode(baseOpcode) that allows you to emit load/store or return depending on the type (type specialized opcode like ILOAD, ALOAD, etc are in the same order). // by example for load mv.visitVarInsn(type.getOpcode(ILOAD), slot); // and for return mv.visitVarInsn(type.getOpcode(IRETURN), slot); also I think your empty private constructor is not valid because it doesn't call (invokespecial) the constructor of Object. (I think you haven't a verify error because IOTrace is not verified because loaded by the bootclassloader). I also believe that because there is no jump in your code, there is no need to generate the stack frames (there is no stack frame). R?mi On 11/14/2012 06:35 PM, Staffan Larsen wrote: > Thanks for the detailed review, Alan. Comments inline. > > On 14 nov 2012, at 13:50, Alan Bateman wrote: > >> On 13/11/2012 10:16, Staffan Larsen wrote: >>> This is a request for review for adding tracing to I/O calls. For now, this is an empty infrastructure intended to enable diagnosing/tracing of i/o calls. A user of the API can register a callback for read and write operations on sockets and files. It does not (yet) cover asynchronous i/o calls. When not used, the implementation should add a minimum of overhead. To provide useful information to the user, FileInputStream, FileOutputStream and RandomAccessFile have been modified to keep track of the path they operate on (when available). >>> >>> Webrev: http://cr.openjdk.java.net/~sla/8003322/webrev.00/ >> Thanks for the update. Do you have any updated performance data to share (just to confirm that the updated implementation doesn't have any real impact)? > While I haven't been able to measure an impact myself, I want to confirm this with runs from the performance team. I'll get back as soon as I have something to share. > >> Anyway, I took a pass over the new webrev. >> >> I'm not sure that passing a value of 0 for errors to xxEnd is the best approach, particularly if this is ever extended to non-blocking I/O. Also I think there are a few inconsistencies with respect to EOF -- eg: in FileInputStream then read() will call the hook with 0 at EOF whereas the other read methods will call the hook with -1 at EOF. In FileChannelImpl then some places use normalize, some not. > Thanks for catching these inconsistencies, I have fixed them. > >> I guess the main question is whether the agent needs to distinguish I/O errors from EOF and 0 bytes (the latter is assuming this may be extended to non-blocking I/O). It may be that you need to use -2 or anything < -1 to distinguish all cases. > This one is hard. As you say, it would be great to differentiate between 0 bytes, EOF and Exceptions. The first two are quite easy as I could make -1 mean EOF. Exceptions are harder since I don't really know if there was an exception from where the xxEnd() method is called now (typically a finally clause). Adding a catch clause and calling xxEnd() from there would solve it, but make the code more complicated. Hard to tell if the extra code complexity is worth it. > >> Minor nit but there is a bit of inconsistency with the variables names, usage of "v" in RandomAccessFile for example whereas FIS/FOS have bytesRead and bytesWritten. > I change v to bytesRead or bytesWritten as appropriate. > >> Thanks for adding javadoc to IoTrace. One suggestion is to include a big warning that the hooks may be called while holding low-level locks in the implementation and so great care must be taken, any synchronization or interaction with other threads could easily deadlock the VM. > I have added this. > >> I skimmed over the tests (not a detailed review) and they look reasonable. You might need to check the copyright headers as it looks like at least one of the tests has the GPL+Classpath exception whereas we normally use just the GPL header on tests. > Fixed. > >> Also good to ensure that there is @bug tag on the tests to link it to 8003322. > Added. > >> In ioTraceTest.sh I see "cd ${PWD}" that I didn't quite get. > I do a few "cd" to different places to compile and create the jar, I then wanted to go back to the original directory to execute the test. > >> Do you think these tests will be reliable when running without an images build (meaning raw classes files on the system)? Just wondering if expectFileRead might fail due to I/O caused by class loading. > I have been running them without an image build with no problem, but I see what you mean. If this turns out to be a problem, then some classes may have to be pre-loaded (such as FileInputStream, FileOutputStream, FileChannel*, ByteBuffer). > >> That's all I have on the detailed review. > Thanks! > /Staffan > >> As you mentioned there is still have the substantive issue as to whether it's open season on sun.misc.IoTrace*. Ignoring Unsafe (we know this needs to be standardized or a standard alternative introduced), then nothing outside of the JDK should be using sun.* classes directly. >> >> -Alan >> >> >> >> From Alan.Bateman at oracle.com Thu Nov 15 10:08:10 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 15 Nov 2012 10:08:10 +0000 Subject: What happened to System/Process.getPid() ? In-Reply-To: <50A44152.10601@oracle.com> References: <50A44152.10601@oracle.com> Message-ID: <50A4BF0A.3060606@oracle.com> On 15/11/2012 01:11, Rob McKenna wrote: > Hi Thomas, > > Don't ask me why, but for some reason this mail just landed in my > client now. (this happens a lot on this mailing list for some reason) > > getPid() is still on the todo list at the moment. Once I clear my > plate a little I'll follow up on it. > > -Rob I just received too, and dozens of other mails so there must have been a blockage somewhere. I think the issue with 4244896 is just that you didn't change the synopsis to reflect what the changes were actually about. It would be good to link it to the bug suggesting a getPid equivalent. You probably know this but a getPid and perhaps a getCurrentPid requires great care. We cannot assume that it can be represented by an int or long, it needs to allow for environment that might not have the notion of process as we know it, also needs consideration of environment where they may be several VMs running in the same process. So lots of wriggle room in the spec, otherwise it will not be implementable everywhere. -Alan From staffan.larsen at oracle.com Thu Nov 15 10:13:54 2012 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 15 Nov 2012 11:13:54 +0100 Subject: RFR: 8003322: Add instrumentation points for tracing of I/O calls In-Reply-To: <50A4A206.5010808@univ-mlv.fr> References: <50A39388.8060502@oracle.com> <50A4A206.5010808@univ-mlv.fr> Message-ID: <6B528FBE-28A9-4D66-90D6-91EDDDFB9960@oracle.com> Hi R?mi, Thanks for your suggestions, they made the code much simpler - and more correct! /Staffan On 15 nov 2012, at 09:04, Remi Forax wrote: > Hi Staffan, > in IOTraceAgent, > ASM provides a method named Type.getOpcode(baseOpcode) that allows you > to emit load/store or return depending on the type > (type specialized opcode like ILOAD, ALOAD, etc are in the same order). > > // by example for load > mv.visitVarInsn(type.getOpcode(ILOAD), slot); > > // and for return > mv.visitVarInsn(type.getOpcode(IRETURN), slot); > > also I think your empty private constructor is not valid > because it doesn't call (invokespecial) the constructor of Object. > (I think you haven't a verify error because IOTrace is not > verified because loaded by the bootclassloader). > > I also believe that because there is no jump in your code, > there is no need to generate the stack frames > (there is no stack frame). > > R?mi > > On 11/14/2012 06:35 PM, Staffan Larsen wrote: >> Thanks for the detailed review, Alan. Comments inline. >> >> On 14 nov 2012, at 13:50, Alan Bateman wrote: >> >>> On 13/11/2012 10:16, Staffan Larsen wrote: >>>> This is a request for review for adding tracing to I/O calls. For now, this is an empty infrastructure intended to enable diagnosing/tracing of i/o calls. A user of the API can register a callback for read and write operations on sockets and files. It does not (yet) cover asynchronous i/o calls. When not used, the implementation should add a minimum of overhead. To provide useful information to the user, FileInputStream, FileOutputStream and RandomAccessFile have been modified to keep track of the path they operate on (when available). >>>> >>>> Webrev: http://cr.openjdk.java.net/~sla/8003322/webrev.00/ >>> Thanks for the update. Do you have any updated performance data to share (just to confirm that the updated implementation doesn't have any real impact)? >> While I haven't been able to measure an impact myself, I want to confirm this with runs from the performance team. I'll get back as soon as I have something to share. >> >>> Anyway, I took a pass over the new webrev. >>> >>> I'm not sure that passing a value of 0 for errors to xxEnd is the best approach, particularly if this is ever extended to non-blocking I/O. Also I think there are a few inconsistencies with respect to EOF -- eg: in FileInputStream then read() will call the hook with 0 at EOF whereas the other read methods will call the hook with -1 at EOF. In FileChannelImpl then some places use normalize, some not. >> Thanks for catching these inconsistencies, I have fixed them. >> >>> I guess the main question is whether the agent needs to distinguish I/O errors from EOF and 0 bytes (the latter is assuming this may be extended to non-blocking I/O). It may be that you need to use -2 or anything < -1 to distinguish all cases. >> This one is hard. As you say, it would be great to differentiate between 0 bytes, EOF and Exceptions. The first two are quite easy as I could make -1 mean EOF. Exceptions are harder since I don't really know if there was an exception from where the xxEnd() method is called now (typically a finally clause). Adding a catch clause and calling xxEnd() from there would solve it, but make the code more complicated. Hard to tell if the extra code complexity is worth it. >> >>> Minor nit but there is a bit of inconsistency with the variables names, usage of "v" in RandomAccessFile for example whereas FIS/FOS have bytesRead and bytesWritten. >> I change v to bytesRead or bytesWritten as appropriate. >> >>> Thanks for adding javadoc to IoTrace. One suggestion is to include a big warning that the hooks may be called while holding low-level locks in the implementation and so great care must be taken, any synchronization or interaction with other threads could easily deadlock the VM. >> I have added this. >> >>> I skimmed over the tests (not a detailed review) and they look reasonable. You might need to check the copyright headers as it looks like at least one of the tests has the GPL+Classpath exception whereas we normally use just the GPL header on tests. >> Fixed. >> >>> Also good to ensure that there is @bug tag on the tests to link it to 8003322. >> Added. >> >>> In ioTraceTest.sh I see "cd ${PWD}" that I didn't quite get. >> I do a few "cd" to different places to compile and create the jar, I then wanted to go back to the original directory to execute the test. >> >>> Do you think these tests will be reliable when running without an images build (meaning raw classes files on the system)? Just wondering if expectFileRead might fail due to I/O caused by class loading. >> I have been running them without an image build with no problem, but I see what you mean. If this turns out to be a problem, then some classes may have to be pre-loaded (such as FileInputStream, FileOutputStream, FileChannel*, ByteBuffer). >> >>> That's all I have on the detailed review. >> Thanks! >> /Staffan >> >>> As you mentioned there is still have the substantive issue as to whether it's open season on sun.misc.IoTrace*. Ignoring Unsafe (we know this needs to be standardized or a standard alternative introduced), then nothing outside of the JDK should be using sun.* classes directly. >>> >>> -Alan >>> >>> >>> >>> > From nils.loodin at oracle.com Thu Nov 15 10:52:21 2012 From: nils.loodin at oracle.com (Nils Loodin) Date: Thu, 15 Nov 2012 11:52:21 +0100 Subject: RFR: 8003471 - Add Add instrumentation facilities for Throwables Message-ID: <50A4C965.6020004@oracle.com> Hello all! Please review this change that would add facilities to help instrumentation of Throwables, to get a rough count of how many Exceptions and Errors an application has thrown during its lifetime. This can help developers and people working in customer-related support roles to do a high level assessment of a program to see if it has any undesirable patterns for instance. The instrumentation point will Receive the Throwable thrown, from which information about message and stack trace and throwable type can be extracted. Webrev: http://cr.openjdk.java.net/~nloodin/exception-tracing/webrev.01/ http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8003322 Cheers, Nils Loodin From Alan.Bateman at oracle.com Thu Nov 15 10:58:21 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 15 Nov 2012 10:58:21 +0000 Subject: Request for Review : 7175464 : entrySetView field is never updated in NavigableSubMap In-Reply-To: <2CE873A3-D288-4319-8F69-2CD591F07DE3@oracle.com> References: <50A4781C.701@oracle.com> <2CE873A3-D288-4319-8F69-2CD591F07DE3@oracle.com> Message-ID: <50A4CACD.7050107@oracle.com> On 15/11/2012 05:28, Mike Duigou wrote: > This bug appears to have been present as far back as Java 6 when NavigableSet was introduced. I could only check 6u33 but it seems unlikely to have been broken during the course of Java 6 maintenance releases. > > As these are views which pass through mutation to the parent object I believe there are fewer compatibility concerns than might be expected. > > Compatibility concern would mostly involve use of the returned entrySetView for synchronization. Previously synchronization on the returned views would have been partially ineffectual because a new view object was returned every time. Sharing the returned views would have synchronized correctly but any other access to the source object either directly or through other views would have led to problems with concurrent modification of the source treemap. > > In the repaired implementation where a single view object is returned synchronization on the views would now be more effective and prevent concurrent race errors. It's possible that new deadlock conditions might be introduced but this seems unlikely. > > Mike It does look like it has been there from the NS were added. I think it's safe to fix this and the change looks fine to me. -Alan From Alan.Bateman at oracle.com Thu Nov 15 11:06:27 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 15 Nov 2012 11:06:27 +0000 Subject: RFR: 8003380 - Compiler warnings in logging test code In-Reply-To: References: <50A40A00.8060106@oracle.com> Message-ID: <50A4CCB3.80305@oracle.com> On 14/11/2012 22:44, Chris Hegarty wrote: > - @SuppressWarnings("unused") Eclipse??? > Do we have precedent for adding these suppressions?? > I don't see it in the -Xlint options that javac supports so it might be specific to ECJ. I recall this topic came up during one of the warnings clean-up days, Stuart might remember the outcome. -Alan From paul.sandoz at oracle.com Thu Nov 15 11:11:39 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 15 Nov 2012 12:11:39 +0100 Subject: Request for Review : 7175464 : entrySetView field is never updated in NavigableSubMap In-Reply-To: <50A4CACD.7050107@oracle.com> References: <50A4781C.701@oracle.com> <2CE873A3-D288-4319-8F69-2CD591F07DE3@oracle.com> <50A4CACD.7050107@oracle.com> Message-ID: On Nov 15, 2012, at 11:58 AM, Alan Bateman wrote: > On 15/11/2012 05:28, Mike Duigou wrote: >> This bug appears to have been present as far back as Java 6 when NavigableSet was introduced. I could only check 6u33 but it seems unlikely to have been broken during the course of Java 6 maintenance releases. >> >> As these are views which pass through mutation to the parent object I believe there are fewer compatibility concerns than might be expected. >> >> Compatibility concern would mostly involve use of the returned entrySetView for synchronization. Previously synchronization on the returned views would have been partially ineffectual because a new view object was returned every time. Sharing the returned views would have synchronized correctly but any other access to the source object either directly or through other views would have led to problems with concurrent modification of the source treemap. >> >> In the repaired implementation where a single view object is returned synchronization on the views would now be more effective and prevent concurrent race errors. It's possible that new deadlock conditions might be introduced but this seems unlikely. >> >> Mike > It does look like it has been there from the NS were added. > > I think it's safe to fix this and the change looks fine to me. > +1 Paul. From Alan.Bateman at oracle.com Thu Nov 15 11:15:04 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 15 Nov 2012 11:15:04 +0000 Subject: RFR: 8003471 - Add Add instrumentation facilities for Throwables In-Reply-To: <50A4C965.6020004@oracle.com> References: <50A4C965.6020004@oracle.com> Message-ID: <50A4CEB8.6000305@oracle.com> On 15/11/2012 10:52, Nils Loodin wrote: > Hello all! > > Please review this change that would add facilities to help > instrumentation of Throwables, to get a rough count of how many > Exceptions and Errors an application has thrown during its lifetime. > > This can help developers and people working in customer-related > support roles to do a high level assessment of a program to see if it > has any undesirable patterns for instance. > > The instrumentation point will Receive the Throwable thrown, from > which information about message and stack trace and throwable type can > be extracted. > > Webrev: http://cr.openjdk.java.net/~nloodin/exception-tracing/webrev.01/ > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8003322 Nils - you can explain why the byte code instrumentation can't be used here? -Alan. From Alan.Bateman at oracle.com Thu Nov 15 11:48:58 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 15 Nov 2012 11:48:58 +0000 Subject: RFR: 6244047: impossible to specify directories to logging FileHandler unless they exist In-Reply-To: <50A41328.7040503@oracle.com> References: <509D777E.9020603@oracle.com> <509E3277.7010607@oracle.com> <50A184C7.4050706@oracle.com> <50A23838.9020501@oracle.com>, <50A29097.5020607@oracle.com> <50A2B316.3050805@oracle.com> <50A2BBEA.1080101@oracle.com> <50A37BA9.2000605@oracle.com> <50A4057B.3020006@oracle.com> <50A40F4E.4000807@oracle.com> <50A41328.7040503@oracle.com> Message-ID: <50A4D6AA.4030801@oracle.com> On 14/11/2012 21:54, Jim Gish wrote: > > On 11/14/2012 04:38 PM, Alan Bateman wrote: >> On 14/11/2012 20:56, Jim Gish wrote: >>> Check out the latest, please -- >>> http://cr.openjdk.java.net/~jgish/Bug6244047-FileHandler-CheckLockLocation/ >>> >>> -- If it's ok, please push it or let me know who to have do it? >> I think it's okay except that you don't need to catch IOException, >> simply catching FileAlreadyExistsException exception should do it. If >> you agree then update the patch and I can push it for you. > But of course. Sorry I missed the obvious. Just peeling the onion > when I could have taken a bite :-) Fixed, and updated. Good, it looks fine now. > > Exactly -- that's my point. This is one of those cases. You're > trying to create a new file in a directory, but the file you specified > isn't a directory - it's a plain file. The error code coming back is > ENOTDIR and so what you get is the more general FileSystemException > with "Not a directory" as the error message, when in fact, we could > throw NotDirectoryException if we'd simply check for errno of ENOTDIR > in the first place along with the other checks being done in > UnixException translateToIOException(File,String). This isn't an obvious as it might seem because having ENOTDIR always map to DirectoryNotEmptyException may cause that exception to be thrown in other cases too. Additionally, this specific exception was intended for cases where you attempt to do something on a directory but it turns out the file is not a directory, this is subtly different to the case here. So we need to separate this one, I think the FileSystemException that you are seeing now is reasonable. -Alan From nils.loodin at oracle.com Thu Nov 15 12:19:43 2012 From: nils.loodin at oracle.com (Nils Loodin) Date: Thu, 15 Nov 2012 13:19:43 +0100 Subject: RFR: 8003471 - Add Add instrumentation facilities for Throwables In-Reply-To: <50A4CEB8.6000305@oracle.com> References: <50A4C965.6020004@oracle.com> <50A4CEB8.6000305@oracle.com> Message-ID: <50A4DDDF.9070201@oracle.com> >> >> Webrev: http://cr.openjdk.java.net/~nloodin/exception-tracing/webrev.01/ >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8003322 > Nils - you can explain why the byte code instrumentation can't be used > here? No real reason it couldn't, I just hadn't implemented it that way for simplicity's sake. > > -Alan. /Nisse From martinrb at google.com Thu Nov 15 12:26:17 2012 From: martinrb at google.com (Martin Buchholz) Date: Thu, 15 Nov 2012 04:26:17 -0800 Subject: What happened to System/Process.getPid() ? In-Reply-To: <50A4BF0A.3060606@oracle.com> References: <50A44152.10601@oracle.com> <50A4BF0A.3060606@oracle.com> Message-ID: I was half-planning on implementing getPid back in 2008 but ran out of time. My intent was to have the pid simply be a String, even though on common platforms an int would suffice, leaving enough room for unusual implementations to get what they want. Essentially, return in String form what humans would use to identify processes on the machine, which might be e.g. "NODENAME:NNN" on a cluster. Martin On Thu, Nov 15, 2012 at 2:08 AM, Alan Bateman wrote: > On 15/11/2012 01:11, Rob McKenna wrote: > >> Hi Thomas, >> >> Don't ask me why, but for some reason this mail just landed in my client >> now. (this happens a lot on this mailing list for some reason) >> >> getPid() is still on the todo list at the moment. Once I clear my plate a >> little I'll follow up on it. >> >> -Rob >> > I just received too, and dozens of other mails so there must have been a > blockage somewhere. > > I think the issue with 4244896 is just that you didn't change the synopsis > to reflect what the changes were actually about. It would be good to link > it to the bug suggesting a getPid equivalent. You probably know this but a > getPid and perhaps a getCurrentPid requires great care. We cannot assume > that it can be represented by an int or long, it needs to allow for > environment that might not have the notion of process as we know it, also > needs consideration of environment where they may be several VMs running in > the same process. So lots of wriggle room in the spec, otherwise it will > not be implementable everywhere. > > -Alan > From Alan.Bateman at oracle.com Thu Nov 15 12:28:20 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 15 Nov 2012 12:28:20 +0000 Subject: RFR: 8003471 - Add Add instrumentation facilities for Throwables In-Reply-To: <50A4DDDF.9070201@oracle.com> References: <50A4C965.6020004@oracle.com> <50A4CEB8.6000305@oracle.com> <50A4DDDF.9070201@oracle.com> Message-ID: <50A4DFE4.5060108@oracle.com> On 15/11/2012 12:19, Nils Loodin wrote: >>> >>> Webrev: >>> http://cr.openjdk.java.net/~nloodin/exception-tracing/webrev.01/ >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8003322 >> Nils - you can explain why the byte code instrumentation can't be used >> here? > > No real reason it couldn't, I just hadn't implemented it that way for > simplicity's sake. I think it would be great if you could explore that. I think it would be a lot preferable than using invasive instrumentation as proposed. Also it would eliminate any concerns about stack overflow and whether this is a supported interface or not. -Alan From weijun.wang at oracle.com Thu Nov 15 12:46:43 2012 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 15 Nov 2012 20:46:43 +0800 Subject: Code review request: 8003263: redundant cast build failure after 8003120 In-Reply-To: <50A0CDFC.50302@oracle.com> References: <50A0B6AE.9020401@oracle.com> <50A0C492.6070500@oracle.com> <50A0CDFC.50302@oracle.com> Message-ID: <50A4E433.1010204@oracle.com> Ping again. If there is no more suggestion, I'll push my fix in the first webrev. Here I'm more concerned about the build failure than the behavior of the input streams. Thanks Max On 11/12/2012 06:22 PM, Weijun Wang wrote: > In fact, it looks like the resources object here is of type > InputStreamEnumeration (in > com/sun/naming/internal/VersionHelper12.java), with an > open-on-nextElement style. This means we can completely remove the while > (resources.hasMore()) block. > > Lance and Andrew added for confirmation. > > Thanks > Max > > On 11/12/2012 05:42 PM, Alan Bateman wrote: >> On 12/11/2012 08:43, Weijun Wang wrote: >>> A small webrev: >>> >>> http://cr.openjdk.java.net/~weijun/8003263/webrev.00/ >>> >>> The reason is that 8003120 added a new line >>> >>> InputStream istream = (InputStream)resources.next(); >>> >>> but resources is already of type NamingEnumeration. >>> >>> Building now shows >>> >>> ../../../src/share/classes/com/sun/naming/internal/ResourceManager.java:563: >>> >>> warning: [cast] redundant cast to InputStream >>> InputStream istream = >>> (InputStream)resources.next(); >>> >>> Noreg-trivial. >> Looks okay to me, just wondering if we should do a more complete fix for >> 8003120 while you are there (meaning it should attempt to close all >> resources even if there is an IOException is thrown during close). >> >> -Alan From alan.bateman at oracle.com Thu Nov 15 13:53:10 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 15 Nov 2012 13:53:10 +0000 Subject: hg: jdk8/tl/jdk: 6244047: impossible to specify directories to logging FileHandler unless they exist Message-ID: <20121115135401.1CC18479AB@hg.openjdk.java.net> Changeset: ac22a52a732c Author: jgish Date: 2012-11-15 13:46 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ac22a52a732c 6244047: impossible to specify directories to logging FileHandler unless they exist Reviewed-by: alanb ! src/share/classes/java/util/logging/FileHandler.java + test/java/util/logging/CheckLockLocationTest.java From paul.sandoz at oracle.com Thu Nov 15 14:02:56 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 15 Nov 2012 15:02:56 +0100 Subject: RFR: 8003471 - Add Add instrumentation facilities for Throwables In-Reply-To: <50A4DFE4.5060108@oracle.com> References: <50A4C965.6020004@oracle.com> <50A4CEB8.6000305@oracle.com> <50A4DDDF.9070201@oracle.com> <50A4DFE4.5060108@oracle.com> Message-ID: <847B969C-4040-48F2-9EBD-0DCA02B0599E@oracle.com> On Nov 15, 2012, at 1:28 PM, Alan Bateman wrote: > On 15/11/2012 12:19, Nils Loodin wrote: >>>> >>>> Webrev: http://cr.openjdk.java.net/~nloodin/exception-tracing/webrev.01/ >>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8003322 >>> Nils - you can explain why the byte code instrumentation can't be used >>> here? >> >> No real reason it couldn't, I just hadn't implemented it that way for simplicity's sake. > I think it would be great if you could explore that. I think it would be a lot preferable than using invasive instrumentation as proposed. Also it would eliminate any concerns about stack overflow and whether this is a supported interface or not. > I second that. Where possible we should strive to be B/DTrace-like in the approach to instrumentation. Paul. From jim.gish at oracle.com Thu Nov 15 14:51:09 2012 From: jim.gish at oracle.com (Jim Gish) Date: Thu, 15 Nov 2012 09:51:09 -0500 Subject: What happened to System/Process.getPid() ? In-Reply-To: References: <50A44152.10601@oracle.com> <50A4BF0A.3060606@oracle.com> Message-ID: <50A5015D.8070408@oracle.com> I got a start on this back in September ( http://cr.openjdk.java.net/~jgish/pidstuff/ ), but as Alan indicated, it's not as easy as all this. I haven't gotten back to it, but it is on our radar. Thanks, Jim On 11/15/2012 07:26 AM, Martin Buchholz wrote: > I was half-planning on implementing getPid back in 2008 but ran out of time. > > My intent was to have the pid simply be a String, even though on common > platforms an int would suffice, leaving enough room for unusual > implementations to get what they want. > Essentially, return in String form what humans would use to identify > processes on the machine, which might be e.g. "NODENAME:NNN" on a cluster. > > Martin > > On Thu, Nov 15, 2012 at 2:08 AM, Alan Bateman wrote: > >> On 15/11/2012 01:11, Rob McKenna wrote: >> >>> Hi Thomas, >>> >>> Don't ask me why, but for some reason this mail just landed in my client >>> now. (this happens a lot on this mailing list for some reason) >>> >>> getPid() is still on the todo list at the moment. Once I clear my plate a >>> little I'll follow up on it. >>> >>> -Rob >>> >> I just received too, and dozens of other mails so there must have been a >> blockage somewhere. >> >> I think the issue with 4244896 is just that you didn't change the synopsis >> to reflect what the changes were actually about. It would be good to link >> it to the bug suggesting a getPid equivalent. You probably know this but a >> getPid and perhaps a getCurrentPid requires great care. We cannot assume >> that it can be represented by an int or long, it needs to allow for >> environment that might not have the notion of process as we know it, also >> needs consideration of environment where they may be several VMs running in >> the same process. So lots of wriggle room in the spec, otherwise it will >> not be implementable everywhere. >> >> -Alan >> -- 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 alexey.utkin at oracle.com Thu Nov 15 15:08:03 2012 From: alexey.utkin at oracle.com (Alexey Utkin) Date: Thu, 15 Nov 2012 19:08:03 +0400 Subject: Review request: JDK-7162111 TEST_BUG: change tests run in headless mode [macosx] In-Reply-To: <50A2B619.5020908@oracle.com> References: <4FB3D342.80907@oracle.com> <50A24AA8.10402@oracle.com> <50A2596A.8040106@oracle.com> <50A272D0.5050202@oracle.com> <50A2B619.5020908@oracle.com> Message-ID: <50A50553.7080607@oracle.com> Let's move forward step by step and be very accurate. There are ~35 CoreLib tests with AWT/Swing. Here they are with short annotation (sub-question: is [closed/com/sun/jmx] a part of CoreLib? It is not in your list.): *closed/com/sun/jmx/snmp/B7159066.java : * test for AppContext - Useless in absence of AWT, headless - ok *closed/com/sun/jmx/trace/JmxTraceTest.java : * test for AppContext - Useless in absence of AWT, headless - ok *closed/java/net/URLClassLoader/ResExists.java :* Dirty test. Depends from rt.jar entry ["javax/swing/plaf/metal/icons/Warn.gif"] that is used for resource URL construction by App Class Loader. Test fails in absence of AWT, headless - ok. Easy to fix, but it cuts off test coverage. *closed/java/lang/ClassLoader/CheckClassName.java :* Covers class loader functionality. Fails in absence of AWT, headless - ok Easy to fix, but it cuts off test coverage. *closed/java/lang/ClassLoader/resource/GetResourceForApplets.java :* Covers class loader functionality. Manual. "ignore" keyword. Useless without AWT. *closed/java/lang/Package/CheckVersions.java, closed/java/lang/Package/CheckVersionsApplet.java : *Applet based. "ignore" keyword. Useless without AWT. *closed/java/lang/Runtime/shutdown/Basic.java :* Has a manual part, that is useless without AWT. *closed/java/lang/SecurityManager/Default.java :* Fails in absence of AWT, headless - ok, Easy to fix - choose another class for test access. *closed/java/net/InetAddress/GetLocalHost.java :* Manual applet based, that is useless without AWT. *closed/java/util/Properties/GenerifiedUses.java :* Fails in absence of AWT, headless - ok. Easy to fix, but it cuts off test coverage for bug: [5061476 Generification conflict: Properties vs. java.awt.image.ImageConsumer by neal.gafter info] *closed/java/util/TimeZone/Bug6351654.java: *test for AppContext - Useless in absence of AWT, headless - ok . *closed/java/util/TimeZone/DefaultTimeZoneTest.java :* Manual applet based, that is useless without AWT. *closed/javax/management/security/ClientNotifForwarderTest.java :* Fixed in webrev. *closed/javax/management/remote/mandatory/security/MarshalledObjectGetTest2.java,* *closed/javax/management/remote/mandatory/security/MarshalledObjectGetTest2.sh, closed/javax/management/remote/mandatory/security/SwingLazyValueAccessor.java : * Applet-based app-context test. Security bug - no description. Fails in absence of AWT, headless - ok. *closed/javax/script/TimeZoneAttackApplet.java, closed/javax/script/TimeZoneUserApplet.java : * Manual applet based, that is useless without AWT. *com/sun/jdi/ClassesByName2Test.java :* Loads Sun Toolkit. Easy to fix, but it cuts off test coverage for bug. *java/io/Serializable/resolveClass/deserializeButton/Foo.java*, *java/io/Serializable/resolveClass/deserializeButton/run.sh*, *java/io/Serializable/resolveClass/deserializeButton/Test.java* : Fixed in webrev. *java/io/Serializable/resolveProxyClass/NonPublicInterface.java :* Works in absence of AWT, headless - ok. Loads the AWT and Swing classes as test cases. The ClassNotFoundException exception does not leads to test fail. *java/lang/management/CompilationMXBean/Basic.java :* Calls java.awt.Toolkit.getDefaultToolkit(); javax.swing.UIManager.getInstalledLookAndFeels(); are in use. Test fails in absence of AWT, headless - ok. Easy to fix, but it cuts off test coverage. *java/lang/reflect/Proxy/ClassRestrictions.java :* Works in absence of AWT, headless - ok. Loads the AWT and Swing classes as test cases. (the same scenario as [java/io/Serializable/resolveProxyClass/NonPublicInterface.java]) The ClassNotFoundException exception does not leads to test fail. *java/lang/reflect/Generics/Probe.java* : Loads "javax.swing.JComboBox$AccessibleJComboBox"class. Fails in absence of AWT, headless - ok Easy to fix, but it cuts off test coverage. *java/lang/Throwable/LegacyChainedExceptionSerialization.java* : Instantiates "java.awt.print.PrinterIOException"class. Fails in absence of AWT, headless - ok Easy to fix, but it cuts off test coverage. *java/net/URLClassLoader/B5077773.java* : Hmm. Seems that is not URLClassLoader test. Checks an existence of "javax/swing/text/rtf/charsets/mac.txt" entry inside rt.jar. Fails in absence of Swing, headless - ok *java/util/Collections/EmptyIterator.java* : Calls testEmptyEnumeration(javax.swing.tree.DefaultMutableTreeNode .EMPTY_ENUMERATION); testEmptyEnumeration(javax.swing.text.SimpleAttributeSet .EMPTY.getAttributeNames()); as constructed empty entities. Fails in absence of Swing, headless - ok Easy to fix. *java/util/logging/LoggingDeadlock4.java :* Covers interaction between LogManager. and Logger.getLogger(). Fails in absence of Awt, headless - ok Easy to fix. *java/util/ResourceBundle/Control/Bug6530694.java :* Swing specific test. Useless in absence of Swing, headless - ok *java/util/ResourceBundle/Bug6287579.java* : Checks local resource loading. Fails in absence of Awt, headless - ok Easy to fix, but it cuts off test coverage. *java/util/ResourceBundle/Bug6299235Test.java :* Awt specific test. Checks local resource loading. Useless in absence of Awt, headless - ok *java/util/ResourceBundle/Control/Bug6530694.java :* Checks CoreResourceBundleControl on Swing UIDefaults. Fails in absence of Awt, headless - ok *sun/nio/cs/TestX11CNS.java, sun/nio/cs/TestX11JIS0201.java : *headless - ok. The tested subject seems have no relation with AWT or Swing. Questions: 1] That have I do with tests marked as "Easy to fix, but it cuts off test coverage"? 2] Should I remove/move the manual tests and tests that essentially depends from AWT or Swing? It seems that the switch "-Djava.awt.headless=true" is useless in all CoreLib tests. AWT uses the property to force running in headless mode. There are two cases: - manual or AWT/Swing-action dependent tests. An attempt to run they in headless mode leads to test fail. - AWT-class dependent tests. They skip AWT initialization.For these cases the value of the property does not affect the result. The only place where the "java.awt.headless" value is essential is the image coding/decoding. All mentioned tests (that are marked as "headless - ok") was tested in ssh session from Win to Mac OS without additional switches. Regards, -uta From jim.gish at oracle.com Thu Nov 15 15:24:14 2012 From: jim.gish at oracle.com (Jim Gish) Date: Thu, 15 Nov 2012 10:24:14 -0500 Subject: Review request: JDK-7162111 TEST_BUG: change tests run in headless mode [macosx] In-Reply-To: <50A50553.7080607@oracle.com> References: <4FB3D342.80907@oracle.com> <50A24AA8.10402@oracle.com> <50A2596A.8040106@oracle.com> <50A272D0.5050202@oracle.com> <50A2B619.5020908@oracle.com> <50A50553.7080607@oracle.com> Message-ID: <50A5091E.2080108@oracle.com> Alexey -- where's the webrev? This message just appeared in core-libs-dev, but I don't see the previous message(s) it appears to be a follow-up to. Thanks, Jim On 11/15/2012 10:08 AM, Alexey Utkin wrote: > Let's move forward step by step and be very accurate. > There are ~35 CoreLib tests with AWT/Swing. > > Here they are with short annotation (sub-question: is > [closed/com/sun/jmx] a part of CoreLib? It is not in your list.): > *closed/com/sun/jmx/snmp/B7159066.java : * > test for AppContext - Useless in absence of AWT, headless - ok > > *closed/com/sun/jmx/trace/JmxTraceTest.java : * > test for AppContext - Useless in absence of AWT, headless - ok > > *closed/java/net/URLClassLoader/ResExists.java :* > Dirty test. Depends from rt.jar entry > ["javax/swing/plaf/metal/icons/Warn.gif"] that is used > for resource URL construction by App Class Loader. > Test fails in absence of AWT, headless - ok. > Easy to fix, but it cuts off test coverage. > > *closed/java/lang/ClassLoader/CheckClassName.java :* > Covers class loader functionality. > Fails in absence of AWT, headless - ok > Easy to fix, but it cuts off test coverage. > > *closed/java/lang/ClassLoader/resource/GetResourceForApplets.java :* > Covers class loader functionality. > Manual. "ignore" keyword. Useless without AWT. > > *closed/java/lang/Package/CheckVersions.java, > closed/java/lang/Package/CheckVersionsApplet.java : > *Applet based. "ignore" keyword. Useless without AWT. > > *closed/java/lang/Runtime/shutdown/Basic.java :* > Has a manual part, that is useless without AWT. > > *closed/java/lang/SecurityManager/Default.java :* > Fails in absence of AWT, headless - ok, > Easy to fix - choose another class for test access. > > *closed/java/net/InetAddress/GetLocalHost.java :* > Manual applet based, that is useless without AWT. > > *closed/java/util/Properties/GenerifiedUses.java :* > Fails in absence of AWT, headless - ok. > Easy to fix, but it cuts off test coverage for bug: > [5061476 Generification conflict: Properties vs. > java.awt.image.ImageConsumer by neal.gafter info] > > *closed/java/util/TimeZone/Bug6351654.java: > *test for AppContext - Useless in absence of AWT, headless - ok . > > *closed/java/util/TimeZone/DefaultTimeZoneTest.java :* > Manual applet based, that is useless without AWT. > > *closed/javax/management/security/ClientNotifForwarderTest.java :* > Fixed in webrev. > > *closed/javax/management/remote/mandatory/security/MarshalledObjectGetTest2.java,* > > *closed/javax/management/remote/mandatory/security/MarshalledObjectGetTest2.sh, > > closed/javax/management/remote/mandatory/security/SwingLazyValueAccessor.java > : > * Applet-based app-context test. Security bug - no description. > Fails in absence of AWT, headless - ok. > > *closed/javax/script/TimeZoneAttackApplet.java, > closed/javax/script/TimeZoneUserApplet.java : > * Manual applet based, that is useless without AWT. > > *com/sun/jdi/ClassesByName2Test.java :* > Loads Sun Toolkit. > Easy to fix, but it cuts off test coverage for bug. > > *java/io/Serializable/resolveClass/deserializeButton/Foo.java*, > *java/io/Serializable/resolveClass/deserializeButton/run.sh*, > *java/io/Serializable/resolveClass/deserializeButton/Test.java* : > Fixed in webrev. > > *java/io/Serializable/resolveProxyClass/NonPublicInterface.java :* > Works in absence of AWT, headless - ok. > Loads the AWT and Swing classes as test cases. > The ClassNotFoundException exception does not leads to test fail. > > *java/lang/management/CompilationMXBean/Basic.java :* > Calls > java.awt.Toolkit.getDefaultToolkit(); > javax.swing.UIManager.getInstalledLookAndFeels(); > are in use. > Test fails in absence of AWT, headless - ok. > Easy to fix, but it cuts off test coverage. > > *java/lang/reflect/Proxy/ClassRestrictions.java :* > Works in absence of AWT, headless - ok. > Loads the AWT and Swing classes as test cases. > (the same scenario as > [java/io/Serializable/resolveProxyClass/NonPublicInterface.java]) > The ClassNotFoundException exception does not leads to test fail. > > *java/lang/reflect/Generics/Probe.java* : > Loads "javax.swing.JComboBox$AccessibleJComboBox"class. > Fails in absence of AWT, headless - ok > Easy to fix, but it cuts off test coverage. > > *java/lang/Throwable/LegacyChainedExceptionSerialization.java* : > Instantiates "java.awt.print.PrinterIOException"class. > Fails in absence of AWT, headless - ok > Easy to fix, but it cuts off test coverage. > > *java/net/URLClassLoader/B5077773.java* : > Hmm. Seems that is not URLClassLoader test. > Checks an existence of "javax/swing/text/rtf/charsets/mac.txt" entry > inside rt.jar. > Fails in absence of Swing, headless - ok > > *java/util/Collections/EmptyIterator.java* : > Calls > testEmptyEnumeration(javax.swing.tree.DefaultMutableTreeNode > .EMPTY_ENUMERATION); > testEmptyEnumeration(javax.swing.text.SimpleAttributeSet > .EMPTY.getAttributeNames()); > as constructed empty entities. > Fails in absence of Swing, headless - ok > Easy to fix. > > *java/util/logging/LoggingDeadlock4.java :* > Covers interaction between LogManager. and Logger.getLogger(). > Fails in absence of Awt, headless - ok > Easy to fix. > > *java/util/ResourceBundle/Control/Bug6530694.java :* > Swing specific test. > Useless in absence of Swing, headless - ok > > *java/util/ResourceBundle/Bug6287579.java* : > Checks local resource loading. > Fails in absence of Awt, headless - ok > Easy to fix, but it cuts off test coverage. > > *java/util/ResourceBundle/Bug6299235Test.java :* > Awt specific test. Checks local resource loading. > Useless in absence of Awt, headless - ok > > *java/util/ResourceBundle/Control/Bug6530694.java :* > Checks CoreResourceBundleControl on Swing UIDefaults. > Fails in absence of Awt, headless - ok > > *sun/nio/cs/TestX11CNS.java, > sun/nio/cs/TestX11JIS0201.java : > *headless - ok. The tested subject seems have no relation with AWT or > Swing. > > Questions: > 1] That have I do with tests marked as "Easy to fix, but it cuts off > test coverage"? > 2] Should I remove/move the manual tests and tests that essentially > depends from AWT or Swing? > > It seems that the switch "-Djava.awt.headless=true" is useless in all > CoreLib tests. > AWT uses the property to force running in headless mode. > There are two cases: > - manual or AWT/Swing-action dependent tests. An attempt to run they > in headless mode leads to test fail. > - AWT-class dependent tests. They skip AWT initialization.For these > cases the value of the property does not affect the result. > The only place where the "java.awt.headless" value is essential is the > image coding/decoding. > > All mentioned tests (that are marked as "headless - ok") was tested in > ssh session from Win to Mac OS without > additional switches. > > Regards, > -uta > > -- 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 Alan.Bateman at oracle.com Thu Nov 15 15:49:19 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 15 Nov 2012 15:49:19 +0000 Subject: Review request: JDK-7162111 TEST_BUG: change tests run in headless mode [macosx] In-Reply-To: <50A50553.7080607@oracle.com> References: <4FB3D342.80907@oracle.com> <50A24AA8.10402@oracle.com> <50A2596A.8040106@oracle.com> <50A272D0.5050202@oracle.com> <50A2B619.5020908@oracle.com> <50A50553.7080607@oracle.com> Message-ID: <50A50EFF.7000701@oracle.com> On 15/11/2012 15:08, Alexey Utkin wrote: > : > > Questions: > 1] That have I do with tests marked as "Easy to fix, but it cuts off > test coverage"? > 2] Should I remove/move the manual tests and tests that essentially > depends from AWT or Swing? > > It seems that the switch "-Djava.awt.headless=true" is useless in all > CoreLib tests. > AWT uses the property to force running in headless mode. > There are two cases: > - manual or AWT/Swing-action dependent tests. An attempt to run they > in headless mode leads to test fail. > - AWT-class dependent tests. They skip AWT initialization.For these > cases the value of the property does not affect the result. > The only place where the "java.awt.headless" value is essential is the > image coding/decoding. > > All mentioned tests (that are marked as "headless - ok") was tested in > ssh session from Win to Mac OS without > additional switches. > > Regards, > -uta Just to put some context on Alexey's mail. Alexey is looking at the tests in the jdk repository with a view to changing the tests for the core area so that they don't have dependencies on AWT/Swing. There are several reasons for doing this. If you look at the exclude list (jdk/test/ProblemList.txt) then there are 30-40 tests that are excluded on Mac because they are problematic for automated testing. We have Compact Profiles and eventually modules coming where it will be important to run tests on profiles of Java SE or when the desktop module is installed. Finally it improves the overall reliability of automated tests when they don't require a X11 server or DISPLAY to run. Alexey - I think -Djava.awt.headless=true is okay to add to some of the tests, the jrunscript and javax.script tests in particular. That would allow you to remove them from the exclude list. We don't want any manual tests, all tests should to be automatic. For the tests that you tagged as "Easy to fix, but it cuts off test coverage" then I think it requires looking at the test in further detail to understand the original bug. It looks to me that in several cases that AWT classes are not required, the test could have been written in other ways that don't require these classes. I think it's okay to do this in steps if you like, no need to address all issues at the same time. To that end it would be great if you could push the webrev for the changes to the jdk repository to cr.openjdk.java.net so that we can discuss it. -Alan. From staffan.larsen at oracle.com Thu Nov 15 15:50:50 2012 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 15 Nov 2012 16:50:50 +0100 Subject: RFR: 8003322: Add instrumentation points for tracing of I/O calls In-Reply-To: References: <50A39388.8060502@oracle.com> Message-ID: I now have some micro-benchmark numbers on windows and linux (the solaris runs are not complete yet). While doing these runs we initially saw a regression on the file reading benchmarks. Investigation showed that the compiler was not able to inline the IoTrace.xxBegin() and IoTrace.xxEnd() methods because the IoTraceContext class in the signature had not yet been loaded. This forced me to go back to just an Object in the signatures for these methods which allowed them to be inlined and performance restored. The newest version of the code is here: http://cr.openjdk.java.net/~sla/8003322/webrev.01/ Results of the benchmarks are here: http://cr.openjdk.java.net/~sla/8003322/webrev.01/Table.htm A copy of the microbenchmarks is here: http://cr.openjdk.java.net/~sla/iotrace/io-micros/ The microbenchmarks uses a harness that has not yet been open sourced, but I still think the code can be read and understood. It seems like the socket benchmarks show a much larger variance in the results than the file benchmarks. Thanks, /Staffan On 14 nov 2012, at 18:35, Staffan Larsen wrote: > Thanks for the detailed review, Alan. Comments inline. > > On 14 nov 2012, at 13:50, Alan Bateman wrote: > >> On 13/11/2012 10:16, Staffan Larsen wrote: >>> This is a request for review for adding tracing to I/O calls. For now, this is an empty infrastructure intended to enable diagnosing/tracing of i/o calls. A user of the API can register a callback for read and write operations on sockets and files. It does not (yet) cover asynchronous i/o calls. When not used, the implementation should add a minimum of overhead. To provide useful information to the user, FileInputStream, FileOutputStream and RandomAccessFile have been modified to keep track of the path they operate on (when available). >>> >>> Webrev: http://cr.openjdk.java.net/~sla/8003322/webrev.00/ >> Thanks for the update. Do you have any updated performance data to share (just to confirm that the updated implementation doesn't have any real impact)? > > While I haven't been able to measure an impact myself, I want to confirm this with runs from the performance team. I'll get back as soon as I have something to share. > >> Anyway, I took a pass over the new webrev. >> >> I'm not sure that passing a value of 0 for errors to xxEnd is the best approach, particularly if this is ever extended to non-blocking I/O. Also I think there are a few inconsistencies with respect to EOF -- eg: in FileInputStream then read() will call the hook with 0 at EOF whereas the other read methods will call the hook with -1 at EOF. In FileChannelImpl then some places use normalize, some not. > > Thanks for catching these inconsistencies, I have fixed them. > >> I guess the main question is whether the agent needs to distinguish I/O errors from EOF and 0 bytes (the latter is assuming this may be extended to non-blocking I/O). It may be that you need to use -2 or anything < -1 to distinguish all cases. > > This one is hard. As you say, it would be great to differentiate between 0 bytes, EOF and Exceptions. The first two are quite easy as I could make -1 mean EOF. Exceptions are harder since I don't really know if there was an exception from where the xxEnd() method is called now (typically a finally clause). Adding a catch clause and calling xxEnd() from there would solve it, but make the code more complicated. Hard to tell if the extra code complexity is worth it. > >> Minor nit but there is a bit of inconsistency with the variables names, usage of "v" in RandomAccessFile for example whereas FIS/FOS have bytesRead and bytesWritten. > > I change v to bytesRead or bytesWritten as appropriate. > >> Thanks for adding javadoc to IoTrace. One suggestion is to include a big warning that the hooks may be called while holding low-level locks in the implementation and so great care must be taken, any synchronization or interaction with other threads could easily deadlock the VM. > > I have added this. > >> I skimmed over the tests (not a detailed review) and they look reasonable. You might need to check the copyright headers as it looks like at least one of the tests has the GPL+Classpath exception whereas we normally use just the GPL header on tests. > > Fixed. > >> Also good to ensure that there is @bug tag on the tests to link it to 8003322. > > Added. > >> In ioTraceTest.sh I see "cd ${PWD}" that I didn't quite get. > > I do a few "cd" to different places to compile and create the jar, I then wanted to go back to the original directory to execute the test. > >> Do you think these tests will be reliable when running without an images build (meaning raw classes files on the system)? Just wondering if expectFileRead might fail due to I/O caused by class loading. > > I have been running them without an image build with no problem, but I see what you mean. If this turns out to be a problem, then some classes may have to be pre-loaded (such as FileInputStream, FileOutputStream, FileChannel*, ByteBuffer). > >> That's all I have on the detailed review. > > Thanks! > /Staffan > >> As you mentioned there is still have the substantive issue as to whether it's open season on sun.misc.IoTrace*. Ignoring Unsafe (we know this needs to be standardized or a standard alternative introduced), then nothing outside of the JDK should be using sun.* classes directly. >> >> -Alan >> >> >> >> > From chris.hegarty at oracle.com Thu Nov 15 15:52:52 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 15 Nov 2012 15:52:52 +0000 Subject: RFR: 8003380 - Compiler warnings in logging test code In-Reply-To: <50A425B4.20909@oracle.com> References: <50A40A00.8060106@oracle.com> <50A41FA0.7030908@oracle.com> <50A425B4.20909@oracle.com> Message-ID: <50A50FD4.8090306@oracle.com> Jim, I'm not convinced that the use of "unused" is strictly necessary, but I'm not an Eclipse user. It looks like there is an easy way around this. For example, in new/test/java/util/logging/LoggingDeadlock3.java, rather than add @SuppressWarnings("unused"), will the follow keep the compiler happy? < Logger logger = Logger.getLogger("com.sun.Hello"+cnt/10); --- > Logger.getLogger("com.sun.Hello"+cnt/10); ... and similar for other areas? Otherwise, I'm happy with the change and can push is for you. -Chris On 14/11/2012 23:13, Jim Gish wrote: > I've updated the webrev with your suggestion. Here it is: > http://cr.openjdk.java.net/~jgish/Bug8003380-logging-test-warnings/ > > > Could someone please push it? > > Thanks, > Jim > > On 11/14/2012 05:48 PM, Jim Gish wrote: >> >> On 11/14/2012 05:44 PM, Chris Hegarty wrote: >>> Interesting... fixing warnings in tests. A few comments. >> Right -- one might consider it overkill sine the warnings don't show >> up in normal testing, but they do show up in Eclipse. Just plain >> annoying. >>> >>> - LoggingMXBeanTest2.java >>> ListIterator -> ListIterator and remove redundant cast ? >> ok. >>> - @SuppressWarnings("unused") Eclipse??? >>> Do we have precedent for adding these suppressions?? >> Not that I know of. >>> - ClassLoaderLeakTest >>> Why the change to use toURI().toURL() ?? >> Because directly applying .toURL() unless it is on a URI is deprecated. >> >> ...Jim >>> -Chris >>> >>> On 14 Nov 2012, at 21:15, Jim Gish >> > wrote: >>> >>>> Please review >>>> http://cr.openjdk.java.net/~jgish/Bug8003380-logging-test-warnings/ >>>> >>>> >>>> >>>> These are simple changes to eliminate compiler warnings from >>>> java.util.logging test code. >>>> >>>> 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 >>>> >> > > -- > 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 jim.gish at oracle.com Thu Nov 15 16:07:06 2012 From: jim.gish at oracle.com (Jim Gish) Date: Thu, 15 Nov 2012 11:07:06 -0500 Subject: RFR: 8003380 - Compiler warnings in logging test code In-Reply-To: <50A50FD4.8090306@oracle.com> References: <50A40A00.8060106@oracle.com> <50A41FA0.7030908@oracle.com> <50A425B4.20909@oracle.com> <50A50FD4.8090306@oracle.com> Message-ID: <50A5132A.3080207@oracle.com> Well -- yes and no. The problem is the way Loggers are handled -- as weak refs. They can get easily gc'd. Now in this code it doesn't really make much difference, but I'm trying to be consistent. That said, the right thing, now that I look at it again, would be to make the declarations of logger static, to ensure they don't get gc'd. Initially I thought that instance variables would do the trick, but I've since learned otherwise. (There's much more behind the curtain here than I previously thought :-( ) Thanks, Jim On 11/15/2012 10:52 AM, Chris Hegarty wrote: > Jim, > > I'm not convinced that the use of "unused" is strictly necessary, but > I'm not an Eclipse user. It looks like there is an easy way around > this. For example, in > new/test/java/util/logging/LoggingDeadlock3.java, rather than add > @SuppressWarnings("unused"), will the follow keep the compiler happy? > > < Logger logger = Logger.getLogger("com.sun.Hello"+cnt/10); > --- > > Logger.getLogger("com.sun.Hello"+cnt/10); > > ... and similar for other areas? > > Otherwise, I'm happy with the change and can push is for you. > > -Chris > > On 14/11/2012 23:13, Jim Gish wrote: >> I've updated the webrev with your suggestion. Here it is: >> http://cr.openjdk.java.net/~jgish/Bug8003380-logging-test-warnings/ >> >> >> Could someone please push it? >> >> Thanks, >> Jim >> >> On 11/14/2012 05:48 PM, Jim Gish wrote: >>> >>> On 11/14/2012 05:44 PM, Chris Hegarty wrote: >>>> Interesting... fixing warnings in tests. A few comments. >>> Right -- one might consider it overkill sine the warnings don't show >>> up in normal testing, but they do show up in Eclipse. Just plain >>> annoying. >>>> >>>> - LoggingMXBeanTest2.java >>>> ListIterator -> ListIterator and remove redundant cast ? >>> ok. >>>> - @SuppressWarnings("unused") Eclipse??? >>>> Do we have precedent for adding these suppressions?? >>> Not that I know of. >>>> - ClassLoaderLeakTest >>>> Why the change to use toURI().toURL() ?? >>> Because directly applying .toURL() unless it is on a URI is deprecated. >>> >>> ...Jim >>>> -Chris >>>> >>>> On 14 Nov 2012, at 21:15, Jim Gish >>> > wrote: >>>> >>>>> Please review >>>>> http://cr.openjdk.java.net/~jgish/Bug8003380-logging-test-warnings/ >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> These are simple changes to eliminate compiler warnings from >>>>> java.util.logging test code. >>>>> >>>>> 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 >>>>> >>> >> >> -- >> 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 >> -- 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 rob.mckenna at oracle.com Thu Nov 15 16:19:05 2012 From: rob.mckenna at oracle.com (Rob McKenna) Date: Thu, 15 Nov 2012 16:19:05 +0000 Subject: What happened to System/Process.getPid() ? In-Reply-To: <50A5015D.8070408@oracle.com> References: <50A44152.10601@oracle.com> <50A4BF0A.3060606@oracle.com> <50A5015D.8070408@oracle.com> Message-ID: <50A515F9.80908@oracle.com> I've just done some bug cleanup here. I've altered the synopsis of 4244896 to: Provide Process.waitFor(timeout), Process.destroyForcibly() and Process.isAlive() and I've created: 8003488: (process) Provide Process.getPid() 8003490: (process) Provide System.getPid() For some reason Process bugs/feature requests always appear to come in pairs. I've closed a few other bugs as dups of these issues. (half may be fixed by one issue, the other half may apply to the new bugs) In general we should keep these requests as granular as possible to avoid the current situation. -Rob On 15/11/12 14:51, Jim Gish wrote: > I got a start on this back in September ( > http://cr.openjdk.java.net/~jgish/pidstuff/ > ), but as Alan > indicated, it's not as easy as all this. I haven't gotten back to it, > but it is on our radar. > > Thanks, > Jim > > On 11/15/2012 07:26 AM, Martin Buchholz wrote: >> I was half-planning on implementing getPid back in 2008 but ran out >> of time. >> >> My intent was to have the pid simply be a String, even though on common >> platforms an int would suffice, leaving enough room for unusual >> implementations to get what they want. >> Essentially, return in String form what humans would use to identify >> processes on the machine, which might be e.g. "NODENAME:NNN" on a >> cluster. >> >> Martin >> >> On Thu, Nov 15, 2012 at 2:08 AM, Alan Bateman >> wrote: >> >>> On 15/11/2012 01:11, Rob McKenna wrote: >>> >>>> Hi Thomas, >>>> >>>> Don't ask me why, but for some reason this mail just landed in my >>>> client >>>> now. (this happens a lot on this mailing list for some reason) >>>> >>>> getPid() is still on the todo list at the moment. Once I clear my >>>> plate a >>>> little I'll follow up on it. >>>> >>>> -Rob >>>> >>> I just received too, and dozens of other mails so there must have >>> been a >>> blockage somewhere. >>> >>> I think the issue with 4244896 is just that you didn't change the >>> synopsis >>> to reflect what the changes were actually about. It would be good to >>> link >>> it to the bug suggesting a getPid equivalent. You probably know this >>> but a >>> getPid and perhaps a getCurrentPid requires great care. We cannot >>> assume >>> that it can be represented by an int or long, it needs to allow for >>> environment that might not have the notion of process as we know it, >>> also >>> needs consideration of environment where they may be several VMs >>> running in >>> the same process. So lots of wriggle room in the spec, otherwise it >>> will >>> not be implementable everywhere. >>> >>> -Alan >>> > From jonathan.gibbons at oracle.com Thu Nov 15 17:19:12 2012 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Thu, 15 Nov 2012 17:19:12 +0000 Subject: hg: jdk8/tl/langtools: 8000800: javadoc uses static non-final fields Message-ID: <20121115171915.09027479B3@hg.openjdk.java.net> Changeset: bfec2a1cc869 Author: jjg Date: 2012-11-15 09:18 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/bfec2a1cc869 8000800: javadoc uses static non-final fields Reviewed-by: bpatel ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractExecutableMemberWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractMemberWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractTreeWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AllClassesFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeOptionalMemberWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeRequiredMemberWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ClassUseWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/ClassWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ConfigurationImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ConstantsSummaryWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ConstructorWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/EnumConstantWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/FieldWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDoclet.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlSerialFieldWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlSerialMethodWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/LinkFactoryImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/LinkInfoImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/MethodWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/NestedClassWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageUseWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/SerializedFormWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/SourceToHTMLConverter.java ! src/share/classes/com/sun/tools/doclets/formats/html/TagletWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/WriterFactoryImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/DocType.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlDocWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/AbstractDoclet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/Configuration.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AbstractBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AbstractMemberBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AnnotationTypeBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AnnotationTypeOptionalMemberBuilder.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/LayoutParser.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/SerializedFormBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/InheritDocTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/TagletWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Util.java ! src/share/classes/com/sun/tools/javadoc/ParamTagImpl.java ! test/com/sun/javadoc/MetaTag/MetaTag.java ! test/com/sun/javadoc/testHtmlDocument/TestHtmlDocument.java From mandy.chung at oracle.com Thu Nov 15 18:09:08 2012 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 15 Nov 2012 10:09:08 -0800 Subject: RFR: 8003471 - Add Add instrumentation facilities for Throwables In-Reply-To: <50A4DFE4.5060108@oracle.com> References: <50A4C965.6020004@oracle.com> <50A4CEB8.6000305@oracle.com> <50A4DDDF.9070201@oracle.com> <50A4DFE4.5060108@oracle.com> Message-ID: <50A52FC4.7090500@oracle.com> On 11/15/2012 4:28 AM, Alan Bateman wrote: > On 15/11/2012 12:19, Nils Loodin wrote: >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~nloodin/exception-tracing/webrev.01/ >>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8003322 >>> Nils - you can explain why the byte code instrumentation can't be used >>> here? >> >> No real reason it couldn't, I just hadn't implemented it that way for >> simplicity's sake. > I think it would be great if you could explore that. I think it would > be a lot preferable than using invasive instrumentation as proposed. > Also it would eliminate any concerns about stack overflow and whether > this is a supported interface or not. +1. You can check out hprof that uses dynamic bytecode instrumentation. Mandy From jonathan.gibbons at oracle.com Thu Nov 15 22:43:03 2012 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Thu, 15 Nov 2012 22:43:03 +0000 Subject: hg: jdk8/tl/langtools: 8003257: refactor javadoc tool option handling Message-ID: <20121115224305.AA89C479C2@hg.openjdk.java.net> Changeset: 467f4f754368 Author: jjg Date: 2012-11-15 14:41 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/467f4f754368 8003257: refactor javadoc tool option handling Reviewed-by: darcy ! src/share/classes/com/sun/tools/javadoc/DocEnv.java ! src/share/classes/com/sun/tools/javadoc/DocLocale.java ! src/share/classes/com/sun/tools/javadoc/DocletInvoker.java ! src/share/classes/com/sun/tools/javadoc/JavadocTool.java ! src/share/classes/com/sun/tools/javadoc/Messager.java ! src/share/classes/com/sun/tools/javadoc/Start.java + src/share/classes/com/sun/tools/javadoc/ToolOption.java From peter.levart at gmail.com Thu Nov 15 22:49:34 2012 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 15 Nov 2012 23:49:34 +0100 Subject: hg: jdk8/tl/jdk: 6924259: Remove offset and count fields from java.lang.String In-Reply-To: References: Message-ID: Hi, This change is 6 months old now. I wonder if Oracle received any complaints from the users since then. I mean complaints that are based on real observations of performance degradation in real code - not only speculation. Regards, Peter 2012/11/15 Zhong Yu > Since this change is to achieve minor performance boost, it's not fair > to defend it by saying that it only incurs minor performance > penalties. > > Java programs are infested with strings, most of which could have used > a more appropriate type, but it is the insane reality. Any change to > the behavior of strings should have been backed up by a much more > thorough analysis. > > Every usage of substring() was (hopefully) the result of some > conscious reasoning about space-time. Even if this change does not > significantly alter an application's performance, it invalidates all > the reasoning, that's the worst blow in my book. There's no problem if > substring() does copying from day one, but 17 years have passed. > > Zhong Yu > > On Wed, Nov 14, 2012 at 6:58 PM, Vitaly Davidovich > wrote: > > Personally, I feel like the concern is a bit overstated: > > > > 1) the n in O(n) is likely actually fairly small in practice (at least in > > what I'd consider sane code) > > 2) I think a lot of people that worry about perf probably aren't using > > substring() anyway > > 3) copying char[] is optimized by jit - this is basically a memcpy()-like > > call, which modern machines handle well > > 4) the upside is strings are 8 bytes smaller > > 5) .NET substring() has always allocated new storage (via an optimized > > internal VM call) and never shared the char[] and I haven't come across > any > > complaints or seen serious perf problems myself (granted I seldom use > > substring) > > > > So I don't know if this is anything to worry about in practice. > > > > Sent from my phone > > > > On Nov 14, 2012 5:26 PM, "Zhong Yu" wrote: > >> > >> On 06/03/2012 11:35 PM, Mike Duigou wrote: > >> > [I trimmed the distribution list] > >> > > >> > On Jun 3 2012, at 13:44 , Peter Levart wrote: > >> > > >> >> On Thursday, May 31, 2012 03:22:35 AM mike.duigou at oracle.comwrote: > >> >>> Changeset: 2c773daa825d > >> >>> Author: mduigou > >> >>> Date: 2012-05-17 10:06 -0700 > >> >>> URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2c773daa825d > >> >>> > >> >>> 6924259: Remove offset and count fields from java.lang.String > >> >>> Summary: Removes the use of shared character array buffers by String > >> >>> along > >> >>> with the two fields needed to support the use of shared buffers. > >> >> Wow, that's quite a change. > >> > Indeed. It was a long time in development. It is a change which is > >> > expected to be overall beneficial though and in the general case a > positive > >> > win. > >> > >> Wow! > >> > >> If the previous behavior of substring() was once a bug, by now it has > >> become a well known feature. People know about it, and people depend > >> on it. > >> > >> This change is a big surprise. Changing O(1) to O(n) is a breach of > >> contract. It'll break lots of old code; and meanwhile lots of new code > >> are still being written based on the old assumption. After people > >> learned about the new behavior, they need to comb through and rewrite > >> their code. > >> > >> The worst part is the same code performs very differently on different > >> versions of JDK. What's a programmer supposed to do if his code > >> targets JDK6 and above? If the cost of strings are no longer certain, > >> what else can we believe in? > >> > >> Is there any chance in hell to roll it back? Maybe add a new method > >> for the new behavior? > >> > >> Zhong Yu > From mandy.chung at oracle.com Thu Nov 15 23:17:02 2012 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 15 Nov 2012 15:17:02 -0800 Subject: Review Request: 8001533: Java launcher must launch JavaFX applications In-Reply-To: References: Message-ID: <50A577EE.2020507@oracle.com> Hi David, On 11/14/12 9:43 AM, David DeHaven wrote: > Bug: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8001533 > > Webrev: > http://cr.openjdk.java.net/~ddehaven/8001533/webrev.0/ java.c: L427 it would be helpful to add a comment to explain the case where appClass is different than mainClass. Probably the comment above L425 should be updated to reflect the support for JavaFX L428-430: is this fallback needed? Would it be better if LauncherHelper.getApplicationClass() always returns a non-null class if the mainClass has been loaded successfully. Looks like this is the case in your implementation. LauncherHelper.java L746 missing space between 'if' and '(' The javadoc for the checkAndLoadMain method would need to be updated The change looks okay to me and I can't spot anything wrong there. L496-517 somewhat duplicates the logic added for FX in the getMainClassFromJar method. Have you considered some refactoring work you could do to simplify the fix since I think once you get the classname of the entry point (either from a JAR or command-line and with and without the static void main method), the logic is essentially the same. To elaborate, I see that FXHelper.launchName L707-725 is needed mainly to give a useful error message. When you find the classname of the entry point, perhaps you can load the class and catch any linkage error and determine if it's caused by the absence of FX runtime and output an appropriate error. If the main class is successfully loaded, then proceed with L496-517 (or something like that). Just an idea you can explore. FXLauncherTest.java - very good test that covers many test cases. Do you plan to add the classpath case (i.e. not from a jar file)? Mandy From david.dehaven at oracle.com Fri Nov 16 01:01:28 2012 From: david.dehaven at oracle.com (David DeHaven) Date: Thu, 15 Nov 2012 17:01:28 -0800 Subject: Review Request: 8001533: Java launcher must launch JavaFX applications In-Reply-To: <50A577EE.2020507@oracle.com> References: <50A577EE.2020507@oracle.com> Message-ID: <40B1A69C-B03F-4FF2-967C-79F8938770BF@oracle.com> > java.c: L427 it would be helpful to add a comment to explain > the case where appClass is different than mainClass. > Probably the comment above L425 should be updated to > reflect the support for JavaFX Done. > L428-430: is this fallback needed? Would it be better > if LauncherHelper.getApplicationClass() always returns > a non-null class if the mainClass has been loaded successfully. > Looks like this is the case in your implementation. Good point, the helper would have aborted by that point. How about I change to NULL_CHECK(appClass) just for safety's sake? > LauncherHelper.java > L746 missing space between 'if' and '(' > The javadoc for the checkAndLoadMain method would need to be > updated Done, along with a couple more that Kumar found. > The change looks okay to me and I can't spot anything wrong there. > > L496-517 somewhat duplicates the logic added for FX in the > getMainClassFromJar method. Have you considered some refactoring > work you could do to simplify the fix since I think once you get > the classname of the entry point (either from a JAR or command-line > and with and without the static void main method), the logic is > essentially the same. To elaborate, I see that FXHelper.launchName > L707-725 is needed mainly to give a useful error message. When > you find the classname of the entry point, perhaps you can load > the class and catch any linkage error and determine if it's caused > by the absence of FX runtime and output an appropriate error. > If the main class is successfully loaded, then proceed with > L496-517 (or something like that). Just an idea you can explore. Yes, I do feel that especially in the -jar case there is some repetition. The trouble is the ambiguity of ClassNotFoundException. I'll poke at it and see what I can come up with. > FXLauncherTest.java - very good test that covers many test cases. > Do you plan to add the classpath case (i.e. not from a > jar file)? I hadn't, but if it's worthwhile then we could certainly add a test to do so. Thoughts on this Steve? -DrD- From steve.sides at oracle.com Fri Nov 16 01:54:15 2012 From: steve.sides at oracle.com (Steve Sides) Date: Thu, 15 Nov 2012 17:54:15 -0800 Subject: Review Request: 8001533: Java launcher must launch JavaFX applications In-Reply-To: <40B1A69C-B03F-4FF2-967C-79F8938770BF@oracle.com> References: <50A577EE.2020507@oracle.com> <40B1A69C-B03F-4FF2-967C-79F8938770BF@oracle.com> Message-ID: <50A59CC7.8090600@oracle.com> >> FXLauncherTest.java - very good test that covers many test cases. >> Do you plan to add the classpath case (i.e. not from a >> jar file)? > I hadn't, but if it's worthwhile then we could certainly add a test to do so. Thoughts on this Steve? I added it to the test plan to be implemented after initial push (I hope it's not required for the initial putback of the feature or we may miss m5). -steve > -DrD- > From weijun.wang at oracle.com Fri Nov 16 02:34:34 2012 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Fri, 16 Nov 2012 02:34:34 +0000 Subject: hg: jdk8/tl/jdk: 8003263: redundant cast build failure after 8003120 Message-ID: <20121116023446.50F97479C9@hg.openjdk.java.net> Changeset: 51c695958712 Author: weijun Date: 2012-11-16 10:34 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/51c695958712 8003263: redundant cast build failure after 8003120 Reviewed-by: alanb ! src/share/classes/com/sun/naming/internal/ResourceManager.java From mandy.chung at oracle.com Fri Nov 16 02:40:45 2012 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 15 Nov 2012 18:40:45 -0800 Subject: Review Request: 8001533: Java launcher must launch JavaFX applications In-Reply-To: <50A59CC7.8090600@oracle.com> References: <50A577EE.2020507@oracle.com> <40B1A69C-B03F-4FF2-967C-79F8938770BF@oracle.com> <50A59CC7.8090600@oracle.com> Message-ID: <50A5A7AD.2000308@oracle.com> On 11/15/2012 5:54 PM, Steve Sides wrote: > >>> FXLauncherTest.java - very good test that covers many test cases. >>> Do you plan to add the classpath case (i.e. not from a >>> jar file)? >> I hadn't, but if it's worthwhile then we could certainly add a test >> to do so. Thoughts on this Steve? > I added it to the test plan to be implemented after initial push (I > hope it's not required for the initial putback of the feature or we > may miss m5). It's fine with me if you add that case after the initial push. Mandy From mandy.chung at oracle.com Fri Nov 16 02:42:19 2012 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 15 Nov 2012 18:42:19 -0800 Subject: Review Request: 8001533: Java launcher must launch JavaFX applications In-Reply-To: <40B1A69C-B03F-4FF2-967C-79F8938770BF@oracle.com> References: <50A577EE.2020507@oracle.com> <40B1A69C-B03F-4FF2-967C-79F8938770BF@oracle.com> Message-ID: <50A5A80B.4060809@oracle.com> On 11/15/2012 5:01 PM, David DeHaven wrote: >> L428-430: is this fallback needed? Would it be better >> if LauncherHelper.getApplicationClass() always returns >> a non-null class if the mainClass has been loaded successfully. >> Looks like this is the case in your implementation. > Good point, the helper would have aborted by that point. How about I change to NULL_CHECK(appClass) just for safety's sake? > Sounds good to me. >> The change looks okay to me and I can't spot anything wrong there. >> >> L496-517 somewhat duplicates the logic added for FX in the >> getMainClassFromJar method. Have you considered some refactoring >> work you could do to simplify the fix since I think once you get >> the classname of the entry point (either from a JAR or command-line >> and with and without the static void main method), the logic is >> essentially the same. To elaborate, I see that FXHelper.launchName >> L707-725 is needed mainly to give a useful error message. When >> you find the classname of the entry point, perhaps you can load >> the class and catch any linkage error and determine if it's caused >> by the absence of FX runtime and output an appropriate error. >> If the main class is successfully loaded, then proceed with >> L496-517 (or something like that). Just an idea you can explore. > Yes, I do feel that especially in the -jar case there is some repetition. The trouble is the ambiguity of ClassNotFoundException. > > I'll poke at it and see what I can come up with. That's good. Mandy From mike.duigou at oracle.com Fri Nov 16 02:45:14 2012 From: mike.duigou at oracle.com (Mike Duigou) Date: Thu, 15 Nov 2012 18:45:14 -0800 Subject: code review request: Test case for JDK-7198904 TreeMap.clone issue In-Reply-To: <50A39EED.9050902@oracle.com> References: <50A39EED.9050902@oracle.com> Message-ID: Looks like a good test to me as well. The one possible addition is to check that m1 hasn't been modified after the mutation of m2. Mike On Nov 14 2012, at 05:38 , David Buck wrote: > Hi! > > This is a review request to add only the test case for the following OracleJDK issue: > > [ 7198904 : (alt-rt) TreeMap.clone is broken ] > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7198904 > > The issue (root cause) is not in OpenJDK (i.e. the problem was OracleJDK specific), but the test case is valid for both so it should go into OpenJDK so we can prevent a similar issue from ever happening in both releases moving forward. > > webrev: > > [ Code Review for jdk ] > http://cr.openjdk.java.net/~dbuck/7198904/webrev.00/ > > The OracleJDK fix (closed source) is ready and has already passed code review. I intend to push both the OracleJDK fix and this test case into their respective repositories at the same time once this review is done. > > Regards, > -Buck From david.holmes at oracle.com Fri Nov 16 03:35:10 2012 From: david.holmes at oracle.com (David Holmes) Date: Fri, 16 Nov 2012 13:35:10 +1000 Subject: RFR: 8003471 - Add Add instrumentation facilities for Throwables In-Reply-To: <50A52FC4.7090500@oracle.com> References: <50A4C965.6020004@oracle.com> <50A4CEB8.6000305@oracle.com> <50A4DDDF.9070201@oracle.com> <50A4DFE4.5060108@oracle.com> <50A52FC4.7090500@oracle.com> Message-ID: <50A5B46E.7090508@oracle.com> +2 Intrusive instrumentation just can't be the way to go. In addition though you need to be very careful about the impact on the initialization sequence of classes here. I suspect your instrumentation may be activated early during VM initialization where your instrumentation framework will not be able to be used. David On 16/11/2012 4:09 AM, Mandy Chung wrote: > On 11/15/2012 4:28 AM, Alan Bateman wrote: >> On 15/11/2012 12:19, Nils Loodin wrote: >>>>> >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~nloodin/exception-tracing/webrev.01/ >>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8003322 >>>> Nils - you can explain why the byte code instrumentation can't be used >>>> here? >>> >>> No real reason it couldn't, I just hadn't implemented it that way for >>> simplicity's sake. >> I think it would be great if you could explore that. I think it would >> be a lot preferable than using invasive instrumentation as proposed. >> Also it would eliminate any concerns about stack overflow and whether >> this is a supported interface or not. > > +1. > > You can check out hprof that uses dynamic bytecode instrumentation. > > Mandy From naoto.sato at oracle.com Fri Nov 16 04:18:51 2012 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Fri, 16 Nov 2012 04:18:51 +0000 Subject: hg: jdk8/tl/jdk: 7199750: Loading sequence of service provider is changed Message-ID: <20121116041903.58F5B479CC@hg.openjdk.java.net> Changeset: 64a42798ea5e Author: naoto Date: 2012-11-15 20:17 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/64a42798ea5e 7199750: Loading sequence of service provider is changed Reviewed-by: okutsu ! src/share/classes/sun/util/locale/provider/SPILocaleProviderAdapter.java ! test/java/util/PluggableLocale/CurrencyNameProviderTest.sh ! test/java/util/PluggableLocale/barprovider.jar ! test/java/util/PluggableLocale/providersrc/CurrencyNameProviderImpl2.java From david.dehaven at oracle.com Fri Nov 16 04:49:58 2012 From: david.dehaven at oracle.com (David DeHaven) Date: Thu, 15 Nov 2012 20:49:58 -0800 Subject: Review Request: 8001533: Java launcher must launch JavaFX applications In-Reply-To: <50A5A80B.4060809@oracle.com> References: <50A577EE.2020507@oracle.com> <40B1A69C-B03F-4FF2-967C-79F8938770BF@oracle.com> <50A5A80B.4060809@oracle.com> Message-ID: >>> L496-517 somewhat duplicates the logic added for FX in the >>> getMainClassFromJar method. Have you considered some refactoring >>> work you could do to simplify the fix since I think once you get >>> the classname of the entry point (either from a JAR or command-line >>> and with and without the static void main method), the logic is >>> essentially the same. To elaborate, I see that FXHelper.launchName >>> L707-725 is needed mainly to give a useful error message. When >>> you find the classname of the entry point, perhaps you can load >>> the class and catch any linkage error and determine if it's caused >>> by the absence of FX runtime and output an appropriate error. >>> If the main class is successfully loaded, then proceed with >>> L496-517 (or something like that). Just an idea you can explore. >> Yes, I do feel that especially in the -jar case there is some repetition. The trouble is the ambiguity of ClassNotFoundException. >> >> I'll poke at it and see what I can come up with. > > That's good. > Mandy I cleaned it up quite a bit, I think it looks a lot better now: http://cr.openjdk.java.net/~ddehaven/8001533/webrev.1/ The comments still need some attention, I'll get that first thing on the morrow. -DrD- From kurchi.subhra.hazra at oracle.com Fri Nov 16 06:16:17 2012 From: kurchi.subhra.hazra at oracle.com (Kurchi Subhra Hazra) Date: Thu, 15 Nov 2012 22:16:17 -0800 Subject: Code Review Request: 8003518: (prefs) Tests in jdk/test/java/util/prefs should not be run concurrently In-Reply-To: <50352740.8060302@oracle.com> References: <50352740.8060302@oracle.com> Message-ID: <50A5DA31.3040409@oracle.com> Hi, The tests in jdk/test/util/prefs are not good candidates to run concurrently, since on platforms such as Windows and Mac OS X, they currently read/write from the same location on the persistent storage. This fix simply informs jtreg[1] to not run these tests concurrently when using the conc:value option. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8003518 Webrev: http://cr.openjdk.java.net/~khazra/8003518/webrev/ Thanks, - Kurchi [1] http://openjdk.java.net/jtreg/ From Alan.Bateman at oracle.com Fri Nov 16 06:28:12 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 16 Nov 2012 06:28:12 +0000 Subject: Code Review Request: 8003518: (prefs) Tests in jdk/test/java/util/prefs should not be run concurrently In-Reply-To: <50A5DA31.3040409@oracle.com> References: <50352740.8060302@oracle.com> <50A5DA31.3040409@oracle.com> Message-ID: <50A5DCFC.1080108@oracle.com> On 16/11/2012 06:16, Kurchi Subhra Hazra wrote: > > Hi, > > The tests in jdk/test/util/prefs are not good candidates to run > concurrently, > since on platforms such as Windows and Mac OS X, they currently > read/write from > the same location on the persistent storage. This fix simply informs > jtreg[1] to > not run these tests concurrently when using the conc:value option. > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8003518 > Webrev: http://cr.openjdk.java.net/~khazra/8003518/webrev/ Looks fine, the only thing I suggest it adding it after java/rmi, that would make it consistent with othervm.dirs where the order is java, javax, com, sun. -Alan. From kurchi.subhra.hazra at oracle.com Fri Nov 16 06:34:30 2012 From: kurchi.subhra.hazra at oracle.com (Kurchi Subhra Hazra) Date: Thu, 15 Nov 2012 22:34:30 -0800 Subject: Code Review Request: 8003518: (prefs) Tests in jdk/test/java/util/prefs should not be run concurrently In-Reply-To: <50A5DCFC.1080108@oracle.com> References: <50352740.8060302@oracle.com> <50A5DA31.3040409@oracle.com> <50A5DCFC.1080108@oracle.com> Message-ID: <50A5DE76.6040807@oracle.com> Updated webrev: http://cr.openjdk.java.net/~khazra/8003518/webrev.01/ - Kurchi On 11/15/12 10:28 PM, Alan Bateman wrote: > On 16/11/2012 06:16, Kurchi Subhra Hazra wrote: >> >> Hi, >> >> The tests in jdk/test/util/prefs are not good candidates to run >> concurrently, >> since on platforms such as Windows and Mac OS X, they currently >> read/write from >> the same location on the persistent storage. This fix simply informs >> jtreg[1] to >> not run these tests concurrently when using the conc:value option. >> >> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8003518 >> Webrev: http://cr.openjdk.java.net/~khazra/8003518/webrev/ > Looks fine, the only thing I suggest it adding it after java/rmi, > that would make it consistent with othervm.dirs where the order is > java, javax, com, sun. > > -Alan. From mandy.chung at oracle.com Fri Nov 16 06:35:47 2012 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 15 Nov 2012 22:35:47 -0800 Subject: Code Review Request: 8003518: (prefs) Tests in jdk/test/java/util/prefs should not be run concurrently In-Reply-To: <50A5DA31.3040409@oracle.com> References: <50352740.8060302@oracle.com> <50A5DA31.3040409@oracle.com> Message-ID: <50A5DEC3.9030201@oracle.com> Looks good, Kurchi. Mandy On 11/15/2012 10:16 PM, Kurchi Subhra Hazra wrote: > > Hi, > > The tests in jdk/test/util/prefs are not good candidates to run > concurrently, > since on platforms such as Windows and Mac OS X, they currently > read/write from > the same location on the persistent storage. This fix simply informs > jtreg[1] to > not run these tests concurrently when using the conc:value option. > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8003518 > Webrev: http://cr.openjdk.java.net/~khazra/8003518/webrev/ > > > Thanks, > - Kurchi > > [1] http://openjdk.java.net/jtreg/ > > From Alan.Bateman at oracle.com Fri Nov 16 06:42:22 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 16 Nov 2012 06:42:22 +0000 Subject: Code Review Request: 8003518: (prefs) Tests in jdk/test/java/util/prefs should not be run concurrently In-Reply-To: <50A5DE76.6040807@oracle.com> References: <50352740.8060302@oracle.com> <50A5DA31.3040409@oracle.com> <50A5DCFC.1080108@oracle.com> <50A5DE76.6040807@oracle.com> Message-ID: <50A5E04E.4050202@oracle.com> On 16/11/2012 06:34, Kurchi Subhra Hazra wrote: > Updated webrev: http://cr.openjdk.java.net/~khazra/8003518/webrev.01/ > > - Kurchi Looks fine (I didn't mean you to have to re-generate a second webrev). -Alan. From jonathan.gibbons at oracle.com Fri Nov 16 07:07:50 2012 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Fri, 16 Nov 2012 07:07:50 +0000 Subject: hg: jdk8/tl/langtools: 2 new changesets Message-ID: <20121116070754.55549479E0@hg.openjdk.java.net> Changeset: 400a4e8accd3 Author: jjg Date: 2012-11-15 19:54 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/400a4e8accd3 8002079: update DocFile to use a JavaFileManager Reviewed-by: darcy ! src/share/classes/com/sun/tools/doclets/formats/html/ConfigurationImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlDocWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/Configuration.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocFile.java + src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocFileFactory.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocPath.java + src/share/classes/com/sun/tools/doclets/internal/toolkit/util/PathDocFileFactory.java + src/share/classes/com/sun/tools/doclets/internal/toolkit/util/SimpleDocFileFactory.java + src/share/classes/com/sun/tools/doclets/internal/toolkit/util/StandardDocFileFactory.java ! src/share/classes/com/sun/tools/javadoc/RootDocImpl.java Changeset: bdcef2ef52d2 Author: jjg Date: 2012-11-15 23:07 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/bdcef2ef52d2 6493690: javadoc should have a javax.tools.Tool service provider installed in tools.jar Reviewed-by: darcy ! src/share/classes/com/sun/tools/doclets/formats/html/ConfigurationImpl.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/Configuration.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/TagletManager.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocFile.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocFileFactory.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Extern.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/PathDocFileFactory.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/SimpleDocFileFactory.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/StandardDocFileFactory.java ! src/share/classes/com/sun/tools/javac/api/ClientCodeWrapper.java ! src/share/classes/com/sun/tools/javac/api/JavacTaskImpl.java ! src/share/classes/com/sun/tools/javac/nio/JavacPathFileManager.java ! src/share/classes/com/sun/tools/javac/util/AbstractDiagnosticFormatter.java ! src/share/classes/com/sun/tools/javadoc/DocletInvoker.java ! src/share/classes/com/sun/tools/javadoc/JavadocTool.java ! src/share/classes/com/sun/tools/javadoc/Messager.java ! src/share/classes/com/sun/tools/javadoc/Start.java + src/share/classes/com/sun/tools/javadoc/api/JavadocTaskImpl.java + src/share/classes/com/sun/tools/javadoc/api/JavadocTool.java ! src/share/classes/com/sun/tools/javadoc/resources/javadoc.properties + src/share/classes/javax/tools/DocumentationTool.java ! src/share/classes/javax/tools/JavaCompiler.java ! src/share/classes/javax/tools/ToolProvider.java ! test/tools/javadoc/CheckResourceKeys.java + test/tools/javadoc/api/basic/APITest.java + test/tools/javadoc/api/basic/DocletPathTest.java + test/tools/javadoc/api/basic/GetSourceVersionsTest.java + test/tools/javadoc/api/basic/GetTask_DiagListenerTest.java + test/tools/javadoc/api/basic/GetTask_DocletClassTest.java + test/tools/javadoc/api/basic/GetTask_FileManagerTest.java + test/tools/javadoc/api/basic/GetTask_FileObjectsTest.java + test/tools/javadoc/api/basic/GetTask_OptionsTest.java + test/tools/javadoc/api/basic/GetTask_WriterTest.java + test/tools/javadoc/api/basic/IsSupportedOptionTest.java + test/tools/javadoc/api/basic/JavadocTaskImplTest.java + test/tools/javadoc/api/basic/RunTest.java + test/tools/javadoc/api/basic/TagletPathTest.java + test/tools/javadoc/api/basic/Task_reuseTest.java + test/tools/javadoc/api/basic/pkg/C.java + test/tools/javadoc/api/basic/taglets/UnderlineTaglet.java From Alan.Bateman at oracle.com Fri Nov 16 09:22:17 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 16 Nov 2012 09:22:17 +0000 Subject: Review Request: 8001533: Java launcher must launch JavaFX applications In-Reply-To: References: <50A577EE.2020507@oracle.com> <40B1A69C-B03F-4FF2-967C-79F8938770BF@oracle.com> <50A5A80B.4060809@oracle.com> Message-ID: <50A605C9.3060508@oracle.com> On 16/11/2012 04:49, David DeHaven wrote: > : > I cleaned it up quite a bit, I think it looks a lot better now: > http://cr.openjdk.java.net/~ddehaven/8001533/webrev.1/ > > The comments still need some attention, I'll get that first thing on the morrow. > > -DrD- > I haven't done a detailed code review but I'm wondering about preferring JavaFX-Application-Class over Main-Class. I realize there may be some history here, perhaps with the javafxpackager tool, but I'm just concerned that the JAR File specification specifies the Main-Class attribute, now it will be usurped and ignored if this custom attribute is present. We also have to figure out how this is going to work with the Compact Profiles effort [1]. As part of this effort then a standard attribute, currently named "Profile", has been proposed so that main applications packaged as executable JAR files can indicate the minimum profile of Java SE that the needs. There is a prototype implementation in the jdk8/profiles/jdk repo [2]. We need to figure out where we are specification-wise if JavaFX-Application-Class is present and Main-Class is not present as it's not technically an executable JAR. A really minor comment in passing but I see you've renamed MAIN_CLASS to MF_MAIN_CLASS, personally I think the original name was better. -Alan. [1] http://openjdk.java.net/jeps/161 [2] http://hg.openjdk.java.net/jdk8/profiles/jdk From sean.mullan at oracle.com Fri Nov 16 14:54:26 2012 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 16 Nov 2012 09:54:26 -0500 Subject: [8] Code Review Request for CR 7167056 - Clarify that BasicPermission names that contain non-wildcard asterisks are not invalid Message-ID: <50A653A2.50400@oracle.com> This change affects components in the security and core libs areas. This is a minor specification clarification to avoid the use of the terms "valid" and "invalid" when describing the syntax for wildcard names in java.security.BasicPermission and various subclasses. This could be implied that these wildcard names are illegal and the constructors should throw an exception. However, they are acceptable, but simply won't be treated as wildcards by the implies method when matching against other permissions. bug : http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7167056 webrev: http://cr.openjdk.java.net/~mullan/webrevs/7167056/webrev.00/ Thanks, Sean From xuelei.fan at oracle.com Fri Nov 16 16:01:51 2012 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Sat, 17 Nov 2012 00:01:51 +0800 Subject: [8] Code Review Request for CR 7167056 - Clarify that BasicPermission names that contain non-wildcard asterisks are not invalid In-Reply-To: <50A653A2.50400@oracle.com> References: <50A653A2.50400@oracle.com> Message-ID: <50A6636F.1040101@oracle.com> Looks fine to me. Xuelei On 11/16/2012 10:54 PM, Sean Mullan wrote: > This change affects components in the security and core libs areas. > > This is a minor specification clarification to avoid the use of the terms > "valid" and "invalid" when describing the syntax for wildcard names in > java.security.BasicPermission and various subclasses. This could be implied that > these wildcard names are illegal and the constructors should throw an exception. > However, they are acceptable, but simply won't be treated as wildcards by the > implies method when matching against other permissions. > > bug : http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7167056 > webrev: http://cr.openjdk.java.net/~mullan/webrevs/7167056/webrev.00/ > > Thanks, > Sean > From kumar.x.srinivasan at oracle.com Fri Nov 16 16:56:23 2012 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Fri, 16 Nov 2012 08:56:23 -0800 Subject: Review Request: 8001533: Java launcher must launch JavaFX applications In-Reply-To: References: <50A577EE.2020507@oracle.com> <40B1A69C-B03F-4FF2-967C-79F8938770BF@oracle.com> <50A5A80B.4060809@oracle.com> Message-ID: <50A67037.1060308@oracle.com> Mandy, Thanks Mandy!, that tip cleaned up the code quite a bit, it is generally looking a lot better. David, One minor fix the while loop can be converted to a for loop making it slightly more compact, But I am fine either way. - Class sc = mainClass.getSuperclass(); - while (sc != null) { + for (Class sc = mainClass.getSuperclass(); sc != null; + sc = sc.getSuperclass()) { if (sc.getName().equals(JAVAFX_APPLICATION_CLASS_NAME)) { return true; } - sc = sc.getSuperclass(); } Steve, the case of jfxrt.jar not being on the class path, we currently pass vacuously. Instead, I think we can have a couple of negative tests, this way we can ensure the launcher behavior and error messages under these conditions. We can do this as a bug fix in M6. Thanks Kumar >>>> L496-517 somewhat duplicates the logic added for FX in the >>>> getMainClassFromJar method. Have you considered some refactoring >>>> work you could do to simplify the fix since I think once you get >>>> the classname of the entry point (either from a JAR or command-line >>>> and with and without the static void main method), the logic is >>>> essentially the same. To elaborate, I see that FXHelper.launchName >>>> L707-725 is needed mainly to give a useful error message. When >>>> you find the classname of the entry point, perhaps you can load >>>> the class and catch any linkage error and determine if it's caused >>>> by the absence of FX runtime and output an appropriate error. >>>> If the main class is successfully loaded, then proceed with >>>> L496-517 (or something like that). Just an idea you can explore. >>> Yes, I do feel that especially in the -jar case there is some repetition. The trouble is the ambiguity of ClassNotFoundException. >>> >>> I'll poke at it and see what I can come up with. >> That's good. >> Mandy > I cleaned it up quite a bit, I think it looks a lot better now: > http://cr.openjdk.java.net/~ddehaven/8001533/webrev.1/ > > The comments still need some attention, I'll get that first thing on the morrow. > > -DrD- > From brent.christian at oracle.com Fri Nov 16 17:32:52 2012 From: brent.christian at oracle.com (Brent Christian) Date: Fri, 16 Nov 2012 09:32:52 -0800 Subject: RFR: 7178922 : (props) re-visit how os.name is determined on Mac In-Reply-To: <50A40BEE.2030205@oracle.com> References: <50A2CED3.3080701@oracle.com> <50A2EE52.1020604@oracle.com> <50A40BEE.2030205@oracle.com> Message-ID: <50A678C4.6070207@oracle.com> Any more comments on this? -Brent On 11/14/12 1:23 PM, Brent Christian wrote: > Thanks, Sergey. > > It's good that we standardized on the recommended usage within the JDK > in order to stay ahead of a possible change to the value of ProductName > in /System/Library/CoreServices/SystemVersion.plist > > But we can expect that Java application developers use the same variety > of OS platform checks. Which is why we should maintain the current > value (versus risking apps breaking in the event of a change in > ProductName used by OS X), especially considering that it works fine > with the recommended osName.contains("OS X"). > > As is suggested in the bug report, if the Mac's OS changes so radically > that we should be reporting a new os.name ("Mac OS XI", or who knows > what), we will almost certainly need to update the JDK to run on it, at > which time we can also change the value of os.name. > > Thanks, > -Brent > > On 11/13/12 5:05 PM, Sergey Bylokhov wrote: >> So many efforts was done to unify this style across the jdk >> http://monaco.sfbay.sun.com/detail.jsf?cr=7147461 >> http://monaco.sfbay.sun.com/detail.jsf?cr=7130404 >> changesets >> http://hg.openjdk.java.net/jdk8/awt/jdk/rev/77b35c5c4b95 >> http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/970cbbba54b0 >> http://closedjdk.us.oracle.com/hsx/hotspot-rt/hotspot/test/closed/rev/40505e5a55e8 >> >> >> >> Note that official documentation from apple suggest: contains("OS X") >> https://developer.apple.com/library/mac/#technotes/tn2002/tn2110.html >> >> 14.11.2012 2:50, Brent Christian wrote: >>> At present, the JDK port for OS X gets its value for os.name from a >>> JRS function exported by the Apple Java Runtime Support framework. >>> >>> Historically this has either been "Mac OS X", or "Mac OS X Server", >>> but there have been reports that this could change at any time, e.g. >>> to just "OS X". This would break any app that relies on this property >>> to detect the Mac platform using something like: >>> >>> System.getProperty("os.name").startsWith("Mac"). >>> >>> To ensure compatibility going forward, the os.name System property on >>> Mac should be hard-coded to the value that is expected, "Mac OS X". >>> (FWIW, as of 10.7 Mac OS X Server is no longer a separate edition of >>> the OS). >>> >>> Webrev is here: >>> http://cr.openjdk.java.net/~bchristi/7178922/webrev.0/ >>> >>> Note: the setUnknownOSAndVersion() function is unused following my >>> change, so I went ahead and removed it. >>> >>> Thanks, >>> -Brent >> >> From david.dehaven at oracle.com Fri Nov 16 17:38:17 2012 From: david.dehaven at oracle.com (David DeHaven) Date: Fri, 16 Nov 2012 09:38:17 -0800 Subject: Review Request: 8001533: Java launcher must launch JavaFX applications In-Reply-To: <50A605C9.3060508@oracle.com> References: <50A577EE.2020507@oracle.com> <40B1A69C-B03F-4FF2-967C-79F8938770BF@oracle.com> <50A5A80B.4060809@oracle.com> <50A605C9.3060508@oracle.com> Message-ID: <457FC018-78C2-4C09-92F1-B1D07160912D@oracle.com> >> I cleaned it up quite a bit, I think it looks a lot better now: >> http://cr.openjdk.java.net/~ddehaven/8001533/webrev.1/ >> >> The comments still need some attention, I'll get that first thing on the morrow. >> >> -DrD- >> > I haven't done a detailed code review but I'm wondering about preferring JavaFX-Application-Class over Main-Class. I realize there may be some history here, perhaps with the javafxpackager tool, but I'm just concerned that the JAR File specification specifies the Main-Class attribute, now it will be usurped and ignored if this custom attribute is present. JavaFX-Application-Class is for backwards compatibility with existing applications, my understanding is it's being deprecated. Moving forward JavaFX applications will only use Main-Class. Kevin can correct me if I'm wrong :) Am I wrong in thinking there should be no impact on profile support if it's being deprecated? -DrD- From james.holmlund at oracle.com Fri Nov 16 18:29:04 2012 From: james.holmlund at oracle.com (james.holmlund at oracle.com) Date: Fri, 16 Nov 2012 18:29:04 +0000 Subject: hg: jdk8/tl/langtools: 8003357: Add support for jtreg -concurrency to langtools/test/Makefile Message-ID: <20121116182907.4468A47A10@hg.openjdk.java.net> Changeset: 843d3b191773 Author: jjh Date: 2012-11-16 18:27 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/843d3b191773 8003357: Add support for jtreg -concurrency to langtools/test/Makefile Reviewed-by: jjg ! test/Makefile From mandy.chung at oracle.com Fri Nov 16 19:55:41 2012 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 16 Nov 2012 11:55:41 -0800 Subject: Review Request: 8001533: Java launcher must launch JavaFX applications In-Reply-To: <457FC018-78C2-4C09-92F1-B1D07160912D@oracle.com> References: <50A577EE.2020507@oracle.com> <40B1A69C-B03F-4FF2-967C-79F8938770BF@oracle.com> <50A5A80B.4060809@oracle.com> <50A605C9.3060508@oracle.com> <457FC018-78C2-4C09-92F1-B1D07160912D@oracle.com> Message-ID: <50A69A3D.20008@oracle.com> On 11/16/12 9:38 AM, David DeHaven wrote: >>> I cleaned it up quite a bit, I think it looks a lot better now: >>> http://cr.openjdk.java.net/~ddehaven/8001533/webrev.1/ >>> >>> The comments still need some attention, I'll get that first thing on the morrow. >>> >>> -DrD- >>> >> I haven't done a detailed code review but I'm wondering about preferring JavaFX-Application-Class over Main-Class. I realize there may be some history here, perhaps with the javafxpackager tool, but I'm just concerned that the JAR File specification specifies the Main-Class attribute, now it will be usurped and ignored if this custom attribute is present. > JavaFX-Application-Class is for backwards compatibility with existing applications, my understanding is it's being deprecated. Moving forward JavaFX applications will only use Main-Class. Kevin can correct me if I'm wrong :) I have talked with Kevin to understand the backward compatibility better. For an existing JavaFX application, the JAR file manifest always has both the Main-Class and JavaFX-Application-Class attributes; in this case, it will ignore the Main-Class attribute and launch with com.sun.javafx.application.LauncherImpl. However, during our conversation, we raise other questions that don't have a clear answer yet. The main ones are whether the new javafxpackager would continue to add the Main-Class attribute and what it will be and whether continue to use the JavaFX-Application-Class attribute; if the class specified in the JavaFX-Application-Class attribute has the main method, what the Main-Class attribute should contain? > Am I wrong in thinking there should be no impact on profile support if it's being deprecated? If Main-Class is always present with JavaFX-Application-Class, it may be no impact; but this seems to be unclear at this moment. Kevin can chime in here and looks like this requires more investigation before we continue the code review. Mandy From kurchi.subhra.hazra at oracle.com Fri Nov 16 20:26:55 2012 From: kurchi.subhra.hazra at oracle.com (kurchi.subhra.hazra at oracle.com) Date: Fri, 16 Nov 2012 20:26:55 +0000 Subject: hg: jdk8/tl/jdk: 8003518: (prefs) Tests in jdk/test/java/util/prefs should not be run concurrently Message-ID: <20121116202707.B459547A18@hg.openjdk.java.net> Changeset: 0ee09f17361e Author: khazra Date: 2012-11-16 12:28 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0ee09f17361e 8003518: (prefs) Tests in jdk/test/java/util/prefs should not be run concurrently Summary: Add java/util/prefs to exclusiveAccess.dirs in TEST.ROOT Reviewed-by: alanb, mchung ! test/TEST.ROOT From mandy.chung at oracle.com Fri Nov 16 20:46:54 2012 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 16 Nov 2012 12:46:54 -0800 Subject: RFR: 7178922 : (props) re-visit how os.name is determined on Mac In-Reply-To: <50A678C4.6070207@oracle.com> References: <50A2CED3.3080701@oracle.com> <50A2EE52.1020604@oracle.com> <50A40BEE.2030205@oracle.com> <50A678C4.6070207@oracle.com> Message-ID: <50A6A63E.80708@oracle.com> Looks good to me. I can push it for you. Who are the reviewers besides me (it wasn't clear to me from the thread)? Mandy On 11/16/12 9:32 AM, Brent Christian wrote: > Any more comments on this? > > -Brent > > On 11/14/12 1:23 PM, Brent Christian wrote: >> Thanks, Sergey. >> >> It's good that we standardized on the recommended usage within the JDK >> in order to stay ahead of a possible change to the value of ProductName >> in /System/Library/CoreServices/SystemVersion.plist >> >> But we can expect that Java application developers use the same variety >> of OS platform checks. Which is why we should maintain the current >> value (versus risking apps breaking in the event of a change in >> ProductName used by OS X), especially considering that it works fine >> with the recommended osName.contains("OS X"). >> >> As is suggested in the bug report, if the Mac's OS changes so radically >> that we should be reporting a new os.name ("Mac OS XI", or who knows >> what), we will almost certainly need to update the JDK to run on it, at >> which time we can also change the value of os.name. >> >> Thanks, >> -Brent >> >> On 11/13/12 5:05 PM, Sergey Bylokhov wrote: >>> So many efforts was done to unify this style across the jdk >>> http://monaco.sfbay.sun.com/detail.jsf?cr=7147461 >>> http://monaco.sfbay.sun.com/detail.jsf?cr=7130404 >>> changesets >>> http://hg.openjdk.java.net/jdk8/awt/jdk/rev/77b35c5c4b95 >>> http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/970cbbba54b0 >>> http://closedjdk.us.oracle.com/hsx/hotspot-rt/hotspot/test/closed/rev/40505e5a55e8 >>> >>> >>> >>> >>> Note that official documentation from apple suggest: contains("OS X") >>> https://developer.apple.com/library/mac/#technotes/tn2002/tn2110.html >>> >>> 14.11.2012 2:50, Brent Christian wrote: >>>> At present, the JDK port for OS X gets its value for os.name from a >>>> JRS function exported by the Apple Java Runtime Support framework. >>>> >>>> Historically this has either been "Mac OS X", or "Mac OS X Server", >>>> but there have been reports that this could change at any time, e.g. >>>> to just "OS X". This would break any app that relies on this property >>>> to detect the Mac platform using something like: >>>> >>>> System.getProperty("os.name").startsWith("Mac"). >>>> >>>> To ensure compatibility going forward, the os.name System property on >>>> Mac should be hard-coded to the value that is expected, "Mac OS X". >>>> (FWIW, as of 10.7 Mac OS X Server is no longer a separate edition of >>>> the OS). >>>> >>>> Webrev is here: >>>> http://cr.openjdk.java.net/~bchristi/7178922/webrev.0/ >>>> >>>> Note: the setUnknownOSAndVersion() function is unused following my >>>> change, so I went ahead and removed it. >>>> >>>> Thanks, >>>> -Brent >>> >>> From mandy.chung at oracle.com Sat Nov 17 01:03:21 2012 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Sat, 17 Nov 2012 01:03:21 +0000 Subject: hg: jdk8/tl/jdk: 7178922: (props) re-visit how os.name is determined on Mac Message-ID: <20121117010342.D5F5347A1F@hg.openjdk.java.net> Changeset: 6f20caa6e1e9 Author: bchristi Date: 2012-11-16 17:01 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6f20caa6e1e9 7178922: (props) re-visit how os.name is determined on Mac Reviewed-by: alanb, mchung, skovatch, serb ! src/solaris/native/java/lang/java_props_macosx.c From stuart.marks at oracle.com Sat Nov 17 02:39:40 2012 From: stuart.marks at oracle.com (Stuart Marks) Date: Fri, 16 Nov 2012 18:39:40 -0800 Subject: RFR: 8003380 - Compiler warnings in logging test code In-Reply-To: <50A4CCB3.80305@oracle.com> References: <50A40A00.8060106@oracle.com> <50A4CCB3.80305@oracle.com> Message-ID: <50A6F8EC.7080905@oracle.com> On 11/15/12 3:06 AM, Alan Bateman wrote: > On 14/11/2012 22:44, Chris Hegarty wrote: >> - @SuppressWarnings("unused") Eclipse??? >> Do we have precedent for adding these suppressions?? >> > I don't see it in the -Xlint options that javac supports so it might be > specific to ECJ. I recall this topic came up during one of the warnings > clean-up days, Stuart might remember the outcome. Yes, I gave an (Oracle internal) tech talk on warnings cleanup some time back where I mentioned this issue. I'll repeat the results here for everybody's benefit. The background is that the words that can be supplied to @SuppressWarnings reside in an uncontrolled namespace. The JLS [1] defines only "unchecked" and any others are compiler-specific. The set of words accepted here by javac is the same as the words defined for -Xlint. I did a survey of the sources in the jdk repo and found that the javac-defined warnings suppression tags were: deprecation fallthrough rawtypes serial try unchecked In addition, I found the following non-javac tags used: all empty-statement unused LeakingThisInConstructor OverridableMethodCallInConstructor ResultOfObjectAllocationIgnored SleepWhileHoldingLock UnnecessaryLocalVariable I actually have no idea which tool processes these. The names are suggestive though. I don't think we ever determined any policy about which names ought to be used in the OpenJDK code base. At the very least I think any of the javac -Xlint words is acceptable. I could be convinced that allowing others is a good idea (such as the Eclipse ones) if they're useful and a definition is available somewhere. s'marks [1] http://docs.oracle.com/javase/specs/jls/se7/html/jls-9.html#jls-9.6.3.5 From stuart.marks at oracle.com Sat Nov 17 03:02:14 2012 From: stuart.marks at oracle.com (Stuart Marks) Date: Fri, 16 Nov 2012 19:02:14 -0800 Subject: RFR: 8003380 - Compiler warnings in logging test code In-Reply-To: <50A6F8EC.7080905@oracle.com> References: <50A40A00.8060106@oracle.com> <50A4CCB3.80305@oracle.com> <50A6F8EC.7080905@oracle.com> Message-ID: <50A6FE36.8050208@oracle.com> On 11/16/12 6:39 PM, Stuart Marks wrote: > The background is that the words that can be supplied to @SuppressWarnings > reside in an uncontrolled namespace. The JLS [1] defines only "unchecked" and > any others are compiler-specific. The set of words accepted here by javac is > the same as the words defined for -Xlint. > > [1] http://docs.oracle.com/javase/specs/jls/se7/html/jls-9.html#jls-9.6.3.5 Whoops, the JLS defines "deprecation" as well (as Alan pointed out in another thread the other day). But the rest of the point stands. s'marks From misterm at gmail.com Sat Nov 17 03:01:24 2012 From: misterm at gmail.com (Michael Nascimento) Date: Sat, 17 Nov 2012 01:01:24 -0200 Subject: RFR: 8003380 - Compiler warnings in logging test code In-Reply-To: <50A6F8EC.7080905@oracle.com> References: <50A40A00.8060106@oracle.com> <50A4CCB3.80305@oracle.com> <50A6F8EC.7080905@oracle.com> Message-ID: Some of these are actually supported by NetBeans, such as: LeakingThisInConstructor Regards, Michael On Sat, Nov 17, 2012 at 12:39 AM, Stuart Marks wrote: > On 11/15/12 3:06 AM, Alan Bateman wrote: >> >> On 14/11/2012 22:44, Chris Hegarty wrote: >>> >>> - @SuppressWarnings("unused") Eclipse??? >>> Do we have precedent for adding these suppressions?? >>> >> I don't see it in the -Xlint options that javac supports so it might be >> specific to ECJ. I recall this topic came up during one of the warnings >> clean-up days, Stuart might remember the outcome. > > > Yes, I gave an (Oracle internal) tech talk on warnings cleanup some time > back where I mentioned this issue. I'll repeat the results here for > everybody's benefit. > > The background is that the words that can be supplied to @SuppressWarnings > reside in an uncontrolled namespace. The JLS [1] defines only "unchecked" > and any others are compiler-specific. The set of words accepted here by > javac is the same as the words defined for -Xlint. > > I did a survey of the sources in the jdk repo and found that the > javac-defined warnings suppression tags were: > > deprecation fallthrough rawtypes serial try unchecked > > In addition, I found the following non-javac tags used: > > all > empty-statement > unused > LeakingThisInConstructor > OverridableMethodCallInConstructor > ResultOfObjectAllocationIgnored > SleepWhileHoldingLock > UnnecessaryLocalVariable > > I actually have no idea which tool processes these. The names are suggestive > though. I don't think we ever determined any policy about which names ought > to be used in the OpenJDK code base. At the very least I think any of the > javac -Xlint words is acceptable. I could be convinced that allowing others > is a good idea (such as the Eclipse ones) if they're useful and a definition > is available somewhere. > > s'marks > > > [1] http://docs.oracle.com/javase/specs/jls/se7/html/jls-9.html#jls-9.6.3.5 From maurizio.cimadamore at oracle.com Sat Nov 17 19:01:48 2012 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Sat, 17 Nov 2012 19:01:48 +0000 Subject: hg: jdk8/tl/langtools: 8003280: Add lambda tests Message-ID: <20121117190150.6CE1F47A31@hg.openjdk.java.net> Changeset: 01c9d4161882 Author: mcimadamore Date: 2012-11-17 19:01 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/01c9d4161882 8003280: Add lambda tests Summary: Turn on lambda expression, method reference and default method support Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Flags.java ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! 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/comp/Flow.java ! src/share/classes/com/sun/tools/javac/comp/Infer.java ! src/share/classes/com/sun/tools/javac/comp/Lower.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/comp/TransTypes.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/jvm/Pool.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/tree/Pretty.java ! src/share/classes/com/sun/tools/javac/util/RichDiagnosticFormatter.java ! src/share/classes/com/sun/tools/javac/util/Warner.java ! test/tools/javac/conditional/Conditional.java ! test/tools/javac/defaultMethods/ClassReaderTest/ClassReaderTest.java ! test/tools/javac/defaultMethods/Neg01.java ! test/tools/javac/defaultMethods/Neg02.java ! test/tools/javac/defaultMethods/Neg03.java ! test/tools/javac/defaultMethods/Neg04.java ! test/tools/javac/defaultMethods/Neg05.java ! test/tools/javac/defaultMethods/Neg06.java ! test/tools/javac/defaultMethods/Neg07.java ! test/tools/javac/defaultMethods/Neg08.java ! test/tools/javac/defaultMethods/Neg09.java ! test/tools/javac/defaultMethods/Neg10.java ! test/tools/javac/defaultMethods/Neg11.java ! test/tools/javac/defaultMethods/Neg12.java ! test/tools/javac/defaultMethods/Neg12.out ! test/tools/javac/defaultMethods/Neg13.java ! test/tools/javac/defaultMethods/Neg14.java ! test/tools/javac/defaultMethods/Neg15.java ! test/tools/javac/defaultMethods/Neg16.java ! test/tools/javac/defaultMethods/Pos01.java ! test/tools/javac/defaultMethods/Pos02.java ! test/tools/javac/defaultMethods/Pos04.java ! test/tools/javac/defaultMethods/Pos05.java ! test/tools/javac/defaultMethods/Pos06.java ! test/tools/javac/defaultMethods/Pos07.java ! test/tools/javac/defaultMethods/Pos08.java ! test/tools/javac/defaultMethods/Pos10.java ! test/tools/javac/defaultMethods/Pos11.java ! test/tools/javac/defaultMethods/Pos12.java ! test/tools/javac/defaultMethods/Pos13.java ! test/tools/javac/defaultMethods/Pos14.java ! test/tools/javac/defaultMethods/Pos15.java ! test/tools/javac/defaultMethods/Pos16.java ! test/tools/javac/defaultMethods/TestDefaultBody.java ! test/tools/javac/defaultMethods/TestNoBridgeOnDefaults.java ! test/tools/javac/defaultMethods/fd/FDTest.java ! test/tools/javac/defaultMethods/separate/Separate.java ! test/tools/javac/defaultMethods/super/TestDefaultSuperCall.java ! test/tools/javac/defaultMethods/syntax/TestDefaultMethodsSyntax.java - test/tools/javac/diags/examples/CantAccessArgTypeInFunctionalDesc.java ! test/tools/javac/diags/examples/CantAccessInnerClsConstr.java - test/tools/javac/diags/examples/CantAccessReturnTypeInFunctionalDesc.java - test/tools/javac/diags/examples/CantAccessThrownTypesInFunctionalDesc.java ! test/tools/javac/diags/examples/CantApplySymbolFragment.java ! test/tools/javac/diags/examples/CantApplySymbolsFragment.java ! test/tools/javac/diags/examples/CantRefNonEffectivelyFinalVar.java ! test/tools/javac/diags/examples/CantResolveLocationArgsFragment.java ! test/tools/javac/diags/examples/CantResolveLocationArgsParamsFragment.java - test/tools/javac/diags/examples/CantReturnValueForVoid.java + test/tools/javac/diags/examples/ConditionalTargetCantBeVoid.java ! test/tools/javac/diags/examples/CyclicInference.java ! test/tools/javac/diags/examples/DefaultOverridesObjectMember.java ! test/tools/javac/diags/examples/IncompatibleAbstracts.java ! test/tools/javac/diags/examples/IncompatibleArgTypesInLambda.java ! test/tools/javac/diags/examples/IncompatibleDescsInFunctionalIntf.java ! test/tools/javac/diags/examples/IncompatibleRetTypeInLambda.java ! test/tools/javac/diags/examples/IncompatibleRetTypeInMref.java ! test/tools/javac/diags/examples/IncompatibleThrownTypesInLambda.java ! test/tools/javac/diags/examples/IncompatibleThrownTypesInMref.java ! test/tools/javac/diags/examples/IncompatibleTypesInConditional.java ! test/tools/javac/diags/examples/InvalidGenericDescInFunctionalInterface.java ! test/tools/javac/diags/examples/LocalVarNeedsFinal.java ! test/tools/javac/diags/examples/MissingReturnValue.java ! test/tools/javac/diags/examples/MissingReturnValueFragment.java ! test/tools/javac/diags/examples/NoAbstracts.java ! test/tools/javac/diags/examples/NoSuitableFunctionalIntfInst.java ! test/tools/javac/diags/examples/NonStaticCantBeRefFragment.java ! test/tools/javac/diags/examples/NotAFunctionalIntf.java ! test/tools/javac/diags/examples/NotDefAccessClassIntfCantAccessFragment.java ! test/tools/javac/diags/examples/OverriddenDefault.java ! test/tools/javac/diags/examples/PotentialLambdaFound.java ! test/tools/javac/diags/examples/RedundantSupertype.java ! test/tools/javac/diags/examples/RefAmbiguousFragment.java ! test/tools/javac/diags/examples/TypesIncompatibleAbstractDefault.java ! test/tools/javac/diags/examples/TypesIncompatibleUnrelatedDefaults.java ! test/tools/javac/diags/examples/UnexpectedLambda.java ! test/tools/javac/diags/examples/UnexpectedMref.java + test/tools/javac/diags/examples/UnexpectedReturnValue.java ! test/tools/javac/generics/7022054/T7022054pos1.java + test/tools/javac/generics/7022054/T7022054pos1.out ! test/tools/javac/generics/7022054/T7022054pos2.java + test/tools/javac/generics/7022054/T7022054pos2.out + test/tools/javac/lambda/BadAccess.java + test/tools/javac/lambda/BadAccess.out + test/tools/javac/lambda/BadAccess02.java + test/tools/javac/lambda/BadAccess02.out + test/tools/javac/lambda/BadAccess03.java + test/tools/javac/lambda/BadAccess03.out + test/tools/javac/lambda/BadBreakContinue.java + test/tools/javac/lambda/BadBreakContinue.out + test/tools/javac/lambda/BadConv03.java + test/tools/javac/lambda/BadConv03.out + test/tools/javac/lambda/BadConv04.java + test/tools/javac/lambda/BadConv04.out + test/tools/javac/lambda/BadExpressionLambda.java + test/tools/javac/lambda/BadExpressionLambda.out + test/tools/javac/lambda/BadLambdaExpr.java + test/tools/javac/lambda/BadLambdaPos.java + test/tools/javac/lambda/BadLambdaPos.out + test/tools/javac/lambda/BadMethodCall.java + test/tools/javac/lambda/BadMethodCall.out + test/tools/javac/lambda/BadRecovery.java + test/tools/javac/lambda/BadRecovery.out + test/tools/javac/lambda/BadReturn.java + test/tools/javac/lambda/BadReturn.out + test/tools/javac/lambda/BadStatementInLambda.java + test/tools/javac/lambda/BadStatementInLambda.out + test/tools/javac/lambda/BadStatementInLambda02.java + test/tools/javac/lambda/BadStatementInLambda02.out + test/tools/javac/lambda/BadTargetType.java + test/tools/javac/lambda/BadTargetType.out + test/tools/javac/lambda/Conditional01.java + test/tools/javac/lambda/Conditional02.java + test/tools/javac/lambda/Conditional03.java + test/tools/javac/lambda/Conformance01.java + test/tools/javac/lambda/Defender01.java + test/tools/javac/lambda/DisjunctiveTypeTest.java + test/tools/javac/lambda/EffectivelyFinal01.java + test/tools/javac/lambda/EffectivelyFinal01.out ! test/tools/javac/lambda/EffectivelyFinalTest.java ! test/tools/javac/lambda/EffectivelyFinalTest01.out ! test/tools/javac/lambda/EffectivelyFinalTest02.out + test/tools/javac/lambda/ErroneousArg.java + test/tools/javac/lambda/ErroneousArg.out + test/tools/javac/lambda/ErroneousLambdaExpr.java ! test/tools/javac/lambda/InnerConstructor.java + test/tools/javac/lambda/LambdaCapture01.java + test/tools/javac/lambda/LambdaCapture02.java + test/tools/javac/lambda/LambdaCapture03.java + test/tools/javac/lambda/LambdaCapture04.java + test/tools/javac/lambda/LambdaCapture05.java + test/tools/javac/lambda/LambdaCapture06.java + test/tools/javac/lambda/LambdaConv01.java + test/tools/javac/lambda/LambdaConv03.java + test/tools/javac/lambda/LambdaConv05.java + test/tools/javac/lambda/LambdaConv06.java + test/tools/javac/lambda/LambdaConv08.java + test/tools/javac/lambda/LambdaConv09.java + test/tools/javac/lambda/LambdaConv09.out + test/tools/javac/lambda/LambdaConv10.java + test/tools/javac/lambda/LambdaConv10.out + test/tools/javac/lambda/LambdaConv11.java + test/tools/javac/lambda/LambdaConv12.java + test/tools/javac/lambda/LambdaConv13.java + test/tools/javac/lambda/LambdaConv16.java + test/tools/javac/lambda/LambdaConv17.java + test/tools/javac/lambda/LambdaConv18.java + test/tools/javac/lambda/LambdaConv18.out + test/tools/javac/lambda/LambdaConv19.java + test/tools/javac/lambda/LambdaConv20.java + test/tools/javac/lambda/LambdaConv21.java + test/tools/javac/lambda/LambdaConv21.out + test/tools/javac/lambda/LambdaConv22.java + test/tools/javac/lambda/LambdaConv23.java + test/tools/javac/lambda/LambdaConv24.java + test/tools/javac/lambda/LambdaConversionTest.java + test/tools/javac/lambda/LambdaEffectivelyFinalTest.java + test/tools/javac/lambda/LambdaEffectivelyFinalTest.out + test/tools/javac/lambda/LambdaExpr01.java + test/tools/javac/lambda/LambdaExpr02.java + test/tools/javac/lambda/LambdaExpr04.java + test/tools/javac/lambda/LambdaExpr05.java + test/tools/javac/lambda/LambdaExpr06.java + test/tools/javac/lambda/LambdaExpr07.java + test/tools/javac/lambda/LambdaExpr08.java + test/tools/javac/lambda/LambdaExpr09.java + test/tools/javac/lambda/LambdaExpr10.java + test/tools/javac/lambda/LambdaExpr10.out + test/tools/javac/lambda/LambdaExpr11.java + test/tools/javac/lambda/LambdaExpr12.java + test/tools/javac/lambda/LambdaExpr13.java + test/tools/javac/lambda/LambdaExpr14.java + test/tools/javac/lambda/LambdaExpr15.java + test/tools/javac/lambda/LambdaExpr16.java + test/tools/javac/lambda/LambdaExpr17.java + test/tools/javac/lambda/LambdaExpr18.java + test/tools/javac/lambda/LambdaExpr19.java + test/tools/javac/lambda/LambdaExpr19.out + test/tools/javac/lambda/LambdaExpr20.java + test/tools/javac/lambda/LambdaExprNotVoid.java + test/tools/javac/lambda/LambdaExprNotVoid.out ! test/tools/javac/lambda/LambdaParserTest.java + test/tools/javac/lambda/LambdaScope01.java + test/tools/javac/lambda/LambdaScope02.java + test/tools/javac/lambda/LambdaScope03.java + test/tools/javac/lambda/LambdaScope04.java + test/tools/javac/lambda/LambdaScope04.out + test/tools/javac/lambda/LocalBreakAndContinue.java + test/tools/javac/lambda/MethodReference01.java + test/tools/javac/lambda/MethodReference02.java + test/tools/javac/lambda/MethodReference03.java + test/tools/javac/lambda/MethodReference04.java + test/tools/javac/lambda/MethodReference04.out + test/tools/javac/lambda/MethodReference05.java + test/tools/javac/lambda/MethodReference06.java + test/tools/javac/lambda/MethodReference07.java + test/tools/javac/lambda/MethodReference08.java + test/tools/javac/lambda/MethodReference08.out + test/tools/javac/lambda/MethodReference09.java + test/tools/javac/lambda/MethodReference09.out + test/tools/javac/lambda/MethodReference10.java + test/tools/javac/lambda/MethodReference11.java + test/tools/javac/lambda/MethodReference12.java + test/tools/javac/lambda/MethodReference13.java + test/tools/javac/lambda/MethodReference14.java + test/tools/javac/lambda/MethodReference15.java + test/tools/javac/lambda/MethodReference16.java + test/tools/javac/lambda/MethodReference17.java + test/tools/javac/lambda/MethodReference18.java + test/tools/javac/lambda/MethodReference19.java + test/tools/javac/lambda/MethodReference20.java + test/tools/javac/lambda/MethodReference20.out + test/tools/javac/lambda/MethodReference21.java + test/tools/javac/lambda/MethodReference21.out + test/tools/javac/lambda/MethodReference22.java + test/tools/javac/lambda/MethodReference22.out + test/tools/javac/lambda/MethodReference23.java + test/tools/javac/lambda/MethodReference23.out + test/tools/javac/lambda/MethodReference24.java + test/tools/javac/lambda/MethodReference25.java + test/tools/javac/lambda/MethodReference26.java + test/tools/javac/lambda/MethodReference26.out + test/tools/javac/lambda/MethodReference27.java + test/tools/javac/lambda/MethodReference28.java + test/tools/javac/lambda/MethodReference28.out + test/tools/javac/lambda/MethodReference29.java + test/tools/javac/lambda/MethodReference30.java + test/tools/javac/lambda/MethodReference31.java + test/tools/javac/lambda/MethodReference32.java + test/tools/javac/lambda/MethodReference32.out + test/tools/javac/lambda/MethodReference33.java + test/tools/javac/lambda/MethodReference34.java + test/tools/javac/lambda/MethodReference35.java + test/tools/javac/lambda/MethodReference36.java + test/tools/javac/lambda/MethodReference37.java + test/tools/javac/lambda/MethodReference37.out + test/tools/javac/lambda/MethodReference38.java + test/tools/javac/lambda/MethodReference38.out + test/tools/javac/lambda/MethodReference39.java + test/tools/javac/lambda/MethodReference39.out + test/tools/javac/lambda/MethodReference40.java + test/tools/javac/lambda/MethodReference40.out + test/tools/javac/lambda/MethodReference41.java + test/tools/javac/lambda/MethodReference42.java + test/tools/javac/lambda/MethodReference43.java + test/tools/javac/lambda/MethodReference44.java + test/tools/javac/lambda/MethodReference45.java + test/tools/javac/lambda/MethodReference45.out + test/tools/javac/lambda/MethodReference46.java + test/tools/javac/lambda/MethodReference47.java + test/tools/javac/lambda/MethodReference47.out + test/tools/javac/lambda/MethodReference48.java + test/tools/javac/lambda/MethodReference49.java + test/tools/javac/lambda/MethodReference50.java + test/tools/javac/lambda/MethodReference50.out + test/tools/javac/lambda/MethodReference51.java + test/tools/javac/lambda/MethodReference51.out + test/tools/javac/lambda/MethodReference52.java + test/tools/javac/lambda/MethodReference52.out + test/tools/javac/lambda/MethodReference53.java + test/tools/javac/lambda/MethodReference53.out + test/tools/javac/lambda/MethodReference54.java + test/tools/javac/lambda/MethodReference54.out ! test/tools/javac/lambda/MethodReferenceParserTest.java + test/tools/javac/lambda/MostSpecific01.java + test/tools/javac/lambda/MostSpecific01.out + test/tools/javac/lambda/MostSpecific02.java + test/tools/javac/lambda/MostSpecific02.out + test/tools/javac/lambda/MostSpecific03.java + test/tools/javac/lambda/MostSpecific03.out + test/tools/javac/lambda/MostSpecific04.java + test/tools/javac/lambda/MostSpecific05.java + test/tools/javac/lambda/MostSpecific06.java + test/tools/javac/lambda/MostSpecific06.out + test/tools/javac/lambda/MostSpecific07.java + test/tools/javac/lambda/MostSpecific07.out + test/tools/javac/lambda/NakedThis.java + test/tools/javac/lambda/SourceLevelTest.java + test/tools/javac/lambda/SourceLevelTest.out + test/tools/javac/lambda/TargetType01.java + test/tools/javac/lambda/TargetType02.java + test/tools/javac/lambda/TargetType03.java + test/tools/javac/lambda/TargetType04.java + test/tools/javac/lambda/TargetType04.out + test/tools/javac/lambda/TargetType05.java + test/tools/javac/lambda/TargetType06.java + test/tools/javac/lambda/TargetType06.out + test/tools/javac/lambda/TargetType07.java + test/tools/javac/lambda/TargetType08.java + test/tools/javac/lambda/TargetType10.java + test/tools/javac/lambda/TargetType10.out + test/tools/javac/lambda/TargetType11.java + test/tools/javac/lambda/TargetType11.out + test/tools/javac/lambda/TargetType12.java + test/tools/javac/lambda/TargetType13.java + test/tools/javac/lambda/TargetType13.out + test/tools/javac/lambda/TargetType14.java + test/tools/javac/lambda/TargetType14.out + test/tools/javac/lambda/TargetType15.java + test/tools/javac/lambda/TargetType16.java + test/tools/javac/lambda/TargetType16.out + test/tools/javac/lambda/TargetType17.java + test/tools/javac/lambda/TargetType17.out + test/tools/javac/lambda/TargetType18.java + test/tools/javac/lambda/TargetType19.java + test/tools/javac/lambda/TargetType19.out + test/tools/javac/lambda/TargetType20.java + test/tools/javac/lambda/TargetType20.out + test/tools/javac/lambda/TargetType21.java + test/tools/javac/lambda/TargetType21.out + test/tools/javac/lambda/TargetType22.java + test/tools/javac/lambda/TargetType22.out + test/tools/javac/lambda/TargetType23.java + test/tools/javac/lambda/TargetType23.out + test/tools/javac/lambda/TargetType24.java + test/tools/javac/lambda/TargetType24.out + test/tools/javac/lambda/TargetType25.java + test/tools/javac/lambda/TargetType26.java + test/tools/javac/lambda/TargetType26.out + test/tools/javac/lambda/TargetType27.java + test/tools/javac/lambda/TargetType27.out + test/tools/javac/lambda/TargetType28.java + test/tools/javac/lambda/TargetType28.out + test/tools/javac/lambda/TargetType29.java + test/tools/javac/lambda/TargetType30.java + test/tools/javac/lambda/TargetType31.java + test/tools/javac/lambda/TargetType32.java + test/tools/javac/lambda/TargetType33.java + test/tools/javac/lambda/TargetType33.out + test/tools/javac/lambda/TargetType34.java + test/tools/javac/lambda/TargetType35.java + test/tools/javac/lambda/TargetType36.java + test/tools/javac/lambda/TargetType37.java + test/tools/javac/lambda/TargetType38.java + test/tools/javac/lambda/TargetType38.out + test/tools/javac/lambda/TargetType39.java + test/tools/javac/lambda/TargetType39.out + test/tools/javac/lambda/TargetType40.java + test/tools/javac/lambda/TargetType40.out + test/tools/javac/lambda/TargetType41.java + test/tools/javac/lambda/TargetType41.out + test/tools/javac/lambda/TargetType42.java + test/tools/javac/lambda/TargetType43.java + test/tools/javac/lambda/TargetType43.out + test/tools/javac/lambda/TargetType44.java + test/tools/javac/lambda/TargetType44.out + test/tools/javac/lambda/TargetType45.java + test/tools/javac/lambda/TargetType45.out + test/tools/javac/lambda/TargetType46.java + test/tools/javac/lambda/TargetType46.out + test/tools/javac/lambda/TargetType47.java + test/tools/javac/lambda/TargetType48.java + test/tools/javac/lambda/TargetType49.java + test/tools/javac/lambda/TargetType49.out + test/tools/javac/lambda/TargetType50.java + test/tools/javac/lambda/TargetType50.out ! test/tools/javac/lambda/TestInvokeDynamic.java + test/tools/javac/lambda/TestSelfRef.java + test/tools/javac/lambda/VoidCompatibility.java + test/tools/javac/lambda/VoidCompatibility.out + test/tools/javac/lambda/abort/Abort.java + test/tools/javac/lambda/badMemberRefBytecode/Main.java + test/tools/javac/lambda/badMemberRefBytecode/TestBadMemberRefBytecode.java + test/tools/javac/lambda/badMemberRefBytecode/Use.java + test/tools/javac/lambda/funcInterfaces/Helper.java + test/tools/javac/lambda/funcInterfaces/LambdaTest1.java + test/tools/javac/lambda/funcInterfaces/LambdaTest1_neg1.java + test/tools/javac/lambda/funcInterfaces/LambdaTest1_neg1.out + test/tools/javac/lambda/funcInterfaces/LambdaTest1_neg2.java + test/tools/javac/lambda/funcInterfaces/LambdaTest1_neg2.out + test/tools/javac/lambda/funcInterfaces/LambdaTest1_neg3.java + test/tools/javac/lambda/funcInterfaces/LambdaTest1_neg3.out + test/tools/javac/lambda/funcInterfaces/LambdaTest2_SAM1.java + test/tools/javac/lambda/funcInterfaces/LambdaTest2_SAM2.java + test/tools/javac/lambda/funcInterfaces/LambdaTest2_SAM3.java + test/tools/javac/lambda/funcInterfaces/LambdaTest2_neg1.java + test/tools/javac/lambda/funcInterfaces/LambdaTest2_neg1.out + test/tools/javac/lambda/funcInterfaces/NonSAM1.java + test/tools/javac/lambda/funcInterfaces/NonSAM1.out + test/tools/javac/lambda/funcInterfaces/NonSAM2.java + test/tools/javac/lambda/funcInterfaces/NonSAM2.out + test/tools/javac/lambda/funcInterfaces/NonSAM3.java + test/tools/javac/lambda/funcInterfaces/NonSAM3.out + test/tools/javac/lambda/lambdaExpression/AbstractClass_neg.java + test/tools/javac/lambda/lambdaExpression/AbstractClass_neg.out + test/tools/javac/lambda/lambdaExpression/AccessNonStatic_neg.java + test/tools/javac/lambda/lambdaExpression/AccessNonStatic_neg.out + test/tools/javac/lambda/lambdaExpression/EffectivelyFinal_neg.java + test/tools/javac/lambda/lambdaExpression/EffectivelyFinal_neg.out + test/tools/javac/lambda/lambdaExpression/InvalidExpression1.java + test/tools/javac/lambda/lambdaExpression/InvalidExpression1.out + test/tools/javac/lambda/lambdaExpression/InvalidExpression3.java + test/tools/javac/lambda/lambdaExpression/InvalidExpression3.out + test/tools/javac/lambda/lambdaExpression/InvalidExpression4.java + test/tools/javac/lambda/lambdaExpression/InvalidExpression4.out + test/tools/javac/lambda/lambdaExpression/InvalidExpression5.java + test/tools/javac/lambda/lambdaExpression/InvalidExpression5.out + test/tools/javac/lambda/lambdaExpression/InvalidExpression6.java + test/tools/javac/lambda/lambdaExpression/InvalidExpression6.out + test/tools/javac/lambda/lambdaExpression/LambdaTest1.java + test/tools/javac/lambda/lambdaExpression/LambdaTest2.java + test/tools/javac/lambda/lambdaExpression/LambdaTest3.java + test/tools/javac/lambda/lambdaExpression/LambdaTest4.java + test/tools/javac/lambda/lambdaExpression/LambdaTest5.java + test/tools/javac/lambda/lambdaExpression/LambdaTest6.java + test/tools/javac/lambda/lambdaExpression/SamConversion.java + test/tools/javac/lambda/lambdaExpression/SamConversionComboTest.java + test/tools/javac/lambda/methodReference/BridgeMethod.java + test/tools/javac/lambda/methodReference/MethodRef1.java + test/tools/javac/lambda/methodReference/MethodRef2.java + test/tools/javac/lambda/methodReference/MethodRef3.java + test/tools/javac/lambda/methodReference/MethodRef4.java + test/tools/javac/lambda/methodReference/MethodRef5.java + test/tools/javac/lambda/methodReference/MethodRef6.java + test/tools/javac/lambda/methodReference/MethodRef7.java + test/tools/javac/lambda/methodReference/MethodRef_neg.java + test/tools/javac/lambda/methodReference/MethodRef_neg.out + test/tools/javac/lambda/methodReference/SamConversion.java + test/tools/javac/lambda/methodReference/SamConversionComboTest.java + test/tools/javac/lambda/mostSpecific/StructuralMostSpecificTest.java + test/tools/javac/lambda/speculative/A.java + test/tools/javac/lambda/speculative/DiamondFinder.java + test/tools/javac/lambda/speculative/Main.java + test/tools/javac/lambda/speculative/Main.out + test/tools/javac/lambda/typeInference/InferenceTest11.java + test/tools/javac/lambda/typeInference/InferenceTest2.java + test/tools/javac/lambda/typeInference/InferenceTest2b.java + test/tools/javac/lambda/typeInference/InferenceTest3.java + test/tools/javac/lambda/typeInference/InferenceTest4.java + test/tools/javac/lambda/typeInference/InferenceTest5.java + test/tools/javac/lambda/typeInference/InferenceTest789.java + test/tools/javac/lambda/typeInference/InferenceTest_neg1_2.java + test/tools/javac/lambda/typeInference/InferenceTest_neg1_2.out + test/tools/javac/lambda/typeInference/InferenceTest_neg5.java + test/tools/javac/lambda/typeInference/InferenceTest_neg5.out + test/tools/javac/lambda/typeInference/combo/TypeInferenceComboTest.java ! test/tools/javac/typeAnnotations/newlocations/BasicTest.out From xuelei.fan at oracle.com Sun Nov 18 09:33:16 2012 From: xuelei.fan at oracle.com (xuelei.fan at oracle.com) Date: Sun, 18 Nov 2012 09:33:16 +0000 Subject: hg: jdk8/tl/jdk: 8003587: Warning cleanup in package javax.net.ssl Message-ID: <20121118093344.7501547A3A@hg.openjdk.java.net> Changeset: 25e5df117021 Author: xuelei Date: 2012-11-18 01:31 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/25e5df117021 8003587: Warning cleanup in package javax.net.ssl Summary: Removes unnecessary imports and adds missing Override annotations Reviewed-by: xuelei Contributed-by: Florian Weimer ! src/share/classes/javax/net/ssl/HandshakeCompletedEvent.java ! src/share/classes/javax/net/ssl/HostnameVerifier.java ! src/share/classes/javax/net/ssl/HttpsURLConnection.java ! src/share/classes/javax/net/ssl/KeyManagerFactory.java ! src/share/classes/javax/net/ssl/SSLContext.java ! src/share/classes/javax/net/ssl/SSLContextSpi.java ! src/share/classes/javax/net/ssl/SSLEngineResult.java ! src/share/classes/javax/net/ssl/SSLParameters.java ! src/share/classes/javax/net/ssl/SSLPermission.java ! src/share/classes/javax/net/ssl/SSLServerSocketFactory.java ! src/share/classes/javax/net/ssl/SSLSession.java ! src/share/classes/javax/net/ssl/SSLSocket.java ! src/share/classes/javax/net/ssl/SSLSocketFactory.java ! src/share/classes/javax/net/ssl/TrustManagerFactory.java ! src/share/classes/javax/net/ssl/X509KeyManager.java From weijun.wang at oracle.com Mon Nov 19 03:13:36 2012 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Mon, 19 Nov 2012 03:13:36 +0000 Subject: hg: jdk8/tl/jdk: 8002344: Krb5LoginModule config class does not return proper KDC list from DNS Message-ID: <20121119031357.4485A47A42@hg.openjdk.java.net> Changeset: f740a9ac6eb6 Author: weijun Date: 2012-11-19 11:13 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f740a9ac6eb6 8002344: Krb5LoginModule config class does not return proper KDC list from DNS Reviewed-by: weijun Contributed-by: Severin Gehwolf , Wang Weijun ! src/share/classes/sun/security/krb5/Config.java + test/sun/security/krb5/config/DNS.java + test/sun/security/krb5/config/NamingManager.java + test/sun/security/krb5/config/dns.sh From Alan.Bateman at oracle.com Mon Nov 19 09:42:27 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 19 Nov 2012 09:42:27 +0000 Subject: Review Request: 8001533: Java launcher must launch JavaFX applications In-Reply-To: <50A69A3D.20008@oracle.com> References: <50A577EE.2020507@oracle.com> <40B1A69C-B03F-4FF2-967C-79F8938770BF@oracle.com> <50A5A80B.4060809@oracle.com> <50A605C9.3060508@oracle.com> <457FC018-78C2-4C09-92F1-B1D07160912D@oracle.com> <50A69A3D.20008@oracle.com> Message-ID: <50A9FF03.3090001@oracle.com> On 16/11/2012 19:55, Mandy Chung wrote: > > If Main-Class is always present with JavaFX-Application-Class, it may > be no impact; but this seems to be unclear at this moment. Kevin can > chime in here and looks like this requires more investigation before > we continue the code review. I've read the other mails and I see that there are a number of discussion points that needs to be resolved before the proposal can move forward. On the Profile attribute then the concern is where Main-Class is not present, in that case the JAR file isn't technically an executable JAR file and so would be considered a library JAR in the current proposal, hence different defaults so no fast-fail for FX applications. -Alan. From Alan.Bateman at oracle.com Mon Nov 19 09:52:02 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 19 Nov 2012 09:52:02 +0000 Subject: RFR: 8003322: Add instrumentation points for tracing of I/O calls In-Reply-To: References: <50A39388.8060502@oracle.com> Message-ID: <50AA0142.3080502@oracle.com> On 15/11/2012 15:50, Staffan Larsen wrote: > I now have some micro-benchmark numbers on windows and linux (the > solaris runs are not complete yet). While doing these runs we > initially saw a regression on the file reading benchmarks. > Investigation showed that the compiler was not able to inline the > IoTrace.xxBegin() and IoTrace.xxEnd() methods because the > IoTraceContext class in the signature had not yet been loaded. This > forced me to go back to just an Object in the signatures for these > methods which allowed them to be inlined and performance restored. > Thanks for creating a set of micro-benchmarks and reducing the concern about this instrumentation. I guess you saw the review request from Nils where he proposed adding invasive instrumentation to Throwable. The consensus in the replies was that bytecode instrumentation seemed more appropriate. Aside from the path field that you've added to the streams classes, is there any reason why the I/O instrumentation couldn't also be done with bytecode instrumentation? -Alan From alexey.utkin at oracle.com Mon Nov 19 09:57:48 2012 From: alexey.utkin at oracle.com (Alexey Utkin) Date: Mon, 19 Nov 2012 13:57:48 +0400 Subject: Review request: JDK-7162111 TEST_BUG: change tests run in headless mode [macosx] (open part) Message-ID: <50AA029C.3090301@oracle.com> Bug description: https://jbs.oracle.com/bugs/browse/JDK-7162111 Here is the suggested fix: http://cr.openjdk.java.net/~uta/openjdk-webrevs/JDK-7162111/ Summary: Tests that are not changed and pass successfully (all tests run for jdk8): --------------------------------------------------------------------------------------------------- java/io/Serializable/serialver/classpath/run.sh java/io/Serializable/serialver/nested/run.sh java/util/ResourceBundle/Control/Bug6530694.java javax/script/CauseExceptionTest.java javax/script/GetInterfaceTest.java javax/script/JavaScriptScopeTest.java javax/script/NullUndefinedVarTest.java javax/script/PluggableContextTest.java javax/script/ProviderTest.sh javax/script/RhinoExceptionTest.java javax/script/StringWriterPrintTest.java javax/script/Test1.java javax/script/Test2.java javax/script/Test3.java javax/script/Test4.java javax/script/Test5.java javax/script/Test6.java javax/script/Test7.java javax/script/Test8.java javax/script/UnescapedBracketRegExTest.java javax/script/VersionTest.java sun/tools/jrunscript/jrunscript-argsTest.sh sun/tools/jrunscript/jrunscript-cpTest.sh sun/tools/jrunscript/jrunscript-DTest.sh sun/tools/jrunscript/jrunscript-eTest.sh sun/tools/jrunscript/jrunscript-fTest.sh sun/tools/jrunscript/jrunscriptTest.sh demo/jvmti/mtrace/TraceJFrame.java: ----------------------------------------------------- Inapplicable in headless mode: JFrame creation time is under investigation. Test was changed to pass successfully if headless mode was detected. java/io/Serializable/resolveClass/deserializeButton/run.sh: --------------------------------------------------------------------------------- The file [java/io/Serializable/resolveClass/deserializeButton/Foo.java] was changed. The pure Vector collection substitutes the AWT Button class in mixed ClassLoader objects serialization. The problem verification procedure was conserved. The switch "-Djava.awt.headless=true" is useless in all CoreLib tests. AWT uses the property to force running in headless mode. There are two cases: - manual or AWT/Swing-action dependent tests. An attempt to run they in headless mode leads to test fail. - AWT-class dependent tests. They skip AWT initialization.For these cases the value of the property does not affect the result. The only place where the "java.awt.headless" value is essential is the image coding/decoding. If the test fails with headless exception that is a good signal: test in not a pure CoreLib algorithm and code reach GUI initialization stage. Borderline case is the testing scripts. Script engine can preliminary instantiate GUI sub-system, but for that case inability to execute GUI-less scenario could be interpreted as bug. Currently all mentioned tests with suggested changes pass on Mac OS in ssh session from Windows machine (no chance for X11). Regards, -uta From staffan.larsen at oracle.com Mon Nov 19 11:15:28 2012 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 19 Nov 2012 12:15:28 +0100 Subject: RFR: 8003322: Add instrumentation points for tracing of I/O calls In-Reply-To: <50AA0142.3080502@oracle.com> References: <50A39388.8060502@oracle.com> <50AA0142.3080502@oracle.com> Message-ID: <28479F37-C81B-4CFB-811A-CEC45755B26B@oracle.com> On 19 nov 2012, at 10:52, Alan Bateman wrote: > On 15/11/2012 15:50, Staffan Larsen wrote: >> >> I now have some micro-benchmark numbers on windows and linux (the solaris runs are not complete yet). While doing these runs we initially saw a regression on the file reading benchmarks. Investigation showed that the compiler was not able to inline the IoTrace.xxBegin() and IoTrace.xxEnd() methods because the IoTraceContext class in the signature had not yet been loaded. This forced me to go back to just an Object in the signatures for these methods which allowed them to be inlined and performance restored. >> > Thanks for creating a set of micro-benchmarks and reducing the concern about this instrumentation. > > I guess you saw the review request from Nils where he proposed adding invasive instrumentation to Throwable. The consensus in the replies was that bytecode instrumentation seemed more appropriate. Aside from the path field that you've added to the streams classes, is there any reason why the I/O instrumentation couldn't also be done with bytecode instrumentation? I think you are right that bytecode instrumentation would also work. The only problem I see (apart from the path field) is the time it would take to develop such a solution. I'm not sure if that is a good enough argument for keeping the non-bytecode-instrumentation solution, though. Or if we could replace the non-bytecode-instrumentation solution with an updated bytecode instrumentation solution in a later update? Not ideal, but would allow us to complete the project on time. Thanks, /Staffan From Alan.Bateman at oracle.com Mon Nov 19 12:26:38 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 19 Nov 2012 12:26:38 +0000 Subject: Review request: JDK-7162111 TEST_BUG: change tests run in headless mode [macosx] (open part) In-Reply-To: <50AA029C.3090301@oracle.com> References: <50AA029C.3090301@oracle.com> Message-ID: <50AA257E.4070701@oracle.com> On 19/11/2012 09:57, Alexey Utkin wrote: > Bug description: > https://jbs.oracle.com/bugs/browse/JDK-7162111 > > Here is the suggested fix: > http://cr.openjdk.java.net/~uta/openjdk-webrevs/JDK-7162111/ Thanks for taking this one on. The change to JFrameCreateTime.java looks fine to me. For test/java/io/Serializable/resolveClass/deserializeButton/Foo.java then I suggest removing the "was java.awt.Button" references from the comments. The reason is that it will likely confuse future maintainers. Also I think Adapter should be renamed, perhaps Element? Finally the Error message still includes "Button" in the message and we should change that. Otherwise it's great to have this test running headless. One thing you'll need to do is remove these tests from the exclude list (jdk/test/ProblemList.txt), otherwise they will not be run on the Mac as they are currently excluded for that platform. I realize you've run the javax.script and jrunscript tests and they pass for you but it may be that they aren't run (because they excluded and ProblemList.txt has not been updated) or maybe you just didn't run into the conditions that cause AWT to hang. I think these tests should have their @run tag changed so that they run with -Djava.awt.headless=true. That will allow them to be removed from the exclude list. I looked at java/util/ResourceBundle/Control/Bug6530694.java and it appears that -Djava.awt.headless=true has added as part of the forward-port of the Mac port so I think this means it can be removed from the exclude list now. -Alan. From Alan.Bateman at oracle.com Mon Nov 19 12:35:39 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 19 Nov 2012 12:35:39 +0000 Subject: RFR: 8003322: Add instrumentation points for tracing of I/O calls In-Reply-To: <28479F37-C81B-4CFB-811A-CEC45755B26B@oracle.com> References: <50A39388.8060502@oracle.com> <50AA0142.3080502@oracle.com> <28479F37-C81B-4CFB-811A-CEC45755B26B@oracle.com> Message-ID: <50AA279B.7060505@oracle.com> On 19/11/2012 11:15, Staffan Larsen wrote: > : > I think you are right that bytecode instrumentation would also work. The only problem I see (apart from the path field) is the time it would take to develop such a solution. I'm not sure if that is a good enough argument for keeping the non-bytecode-instrumentation solution, though. Or if we could replace the non-bytecode-instrumentation solution with an updated bytecode instrumentation solution in a later update? Not ideal, but would allow us to complete the project on time. > I'd go along with that, assuming of course that the changes to use bytecode instrumentation aren't pushed out indefinitely. -Alan From Alan.Bateman at oracle.com Mon Nov 19 12:47:19 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 19 Nov 2012 12:47:19 +0000 Subject: 8003607: More ProblemList.txt updates (11/2012) Message-ID: <50AA2A56.1000801@oracle.com> I need a reviewer for a few miscellaneous updates to the ProblemList.txt file (the motive as always to get a clean test run of jdk8/tl). The updates this time are: 1. Jaroslav Bachor?k fixed a long standing timing issue in the RMI-IIOP Tie classes generated by rmic so this allows us to liberate javax/management/remote/mandatory/connection/ReconnectTest.java. 2. The test that Jim Gish added as part of 6244047 doesn't work on Windows so I propose to exclude it until the test is fixed. 3. The MS-CAPI tests interfere with each other when running on Windows with -concurrency > 1 so I propose to just add it to the exclusiveAccess.dirs list for now and that will force these tests to run sequentially (even if -concurrency is specified). -Alan diff --git a/test/ProblemList.txt b/test/ProblemList.txt --- a/test/ProblemList.txt +++ b/test/ProblemList.txt @@ -147,9 +147,6 @@ java/lang/management/MemoryMXBean/LowMem # 6959636 javax/management/loading/LibraryLoader/LibraryLoaderTest.java windows-all - -# 7144846 -javax/management/remote/mandatory/connection/ReconnectTest.java generic-all # 7120365 javax/management/remote/mandatory/notif/DiffHBTest.java generic-all @@ -376,6 +373,9 @@ java/util/concurrent/ThreadPoolExecutor/ # Filed 6772009 java/util/concurrent/locks/ReentrantLock/CancelledLockLoops.java generic-all +# 8003596 +java/util/logging/CheckLockLocationTest.java windows-all + # 7041639, Solaris DSA keypair generation bug java/util/TimeZone/TimeZoneDatePermissionCheck.sh solaris-all diff --git a/test/TEST.ROOT b/test/TEST.ROOT --- a/test/TEST.ROOT +++ b/test/TEST.ROOT @@ -9,4 +9,4 @@ othervm.dirs=java/awt java/beans java/rm othervm.dirs=java/awt java/beans java/rmi javax/accessibility javax/imageio javax/sound javax/print javax/management com/sun/awt sun/awt sun/java2d sun/pisces sun/rmi # Tests that cannot run concurrently -exclusiveAccess.dirs=java/rmi/Naming java/util/prefs sun/management/jmxremote sun/tools/jstatd +exclusiveAccess.dirs=java/rmi/Naming java/util/prefs sun/management/jmxremote sun/tools/jstatd sun/security/mscapi From Lance.Andersen at oracle.com Mon Nov 19 13:00:19 2012 From: Lance.Andersen at oracle.com (Lance Andersen) Date: Mon, 19 Nov 2012 08:00:19 -0500 Subject: 8003607: More ProblemList.txt updates (11/2012) In-Reply-To: <50AA2A56.1000801@oracle.com> References: <50AA2A56.1000801@oracle.com> Message-ID: Looks fine -- 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 Sent from my iPhone On Nov 19, 2012, at 7:47 AM, Alan Bateman wrote: > > I need a reviewer for a few miscellaneous updates to the ProblemList.txt file (the motive as always to get a clean test run of jdk8/tl). The updates this time are: > > 1. Jaroslav Bachor?k fixed a long standing timing issue in the RMI-IIOP Tie classes generated by rmic so this allows us to liberate javax/management/remote/mandatory/connection/ReconnectTest.java. > > 2. The test that Jim Gish added as part of 6244047 doesn't work on Windows so I propose to exclude it until the test is fixed. > > 3. The MS-CAPI tests interfere with each other when running on Windows with -concurrency > 1 so I propose to just add it to the exclusiveAccess.dirs list for now and that will force these tests to run sequentially (even if -concurrency is specified). > > -Alan > > > > diff --git a/test/ProblemList.txt b/test/ProblemList.txt > --- a/test/ProblemList.txt > +++ b/test/ProblemList.txt > @@ -147,9 +147,6 @@ java/lang/management/MemoryMXBean/LowMem > > # 6959636 > javax/management/loading/LibraryLoader/LibraryLoaderTest.java windows-all > - > -# 7144846 > -javax/management/remote/mandatory/connection/ReconnectTest.java generic-all > > # 7120365 > javax/management/remote/mandatory/notif/DiffHBTest.java generic-all > @@ -376,6 +373,9 @@ java/util/concurrent/ThreadPoolExecutor/ > # Filed 6772009 > java/util/concurrent/locks/ReentrantLock/CancelledLockLoops.java generic-all > > +# 8003596 > +java/util/logging/CheckLockLocationTest.java windows-all > + > # 7041639, Solaris DSA keypair generation bug > java/util/TimeZone/TimeZoneDatePermissionCheck.sh solaris-all > > diff --git a/test/TEST.ROOT b/test/TEST.ROOT > --- a/test/TEST.ROOT > +++ b/test/TEST.ROOT > @@ -9,4 +9,4 @@ othervm.dirs=java/awt java/beans java/rm > othervm.dirs=java/awt java/beans java/rmi javax/accessibility javax/imageio javax/sound javax/print javax/management com/sun/awt sun/awt sun/java2d sun/pisces sun/rmi > > # Tests that cannot run concurrently > -exclusiveAccess.dirs=java/rmi/Naming java/util/prefs sun/management/jmxremote sun/tools/jstatd > +exclusiveAccess.dirs=java/rmi/Naming java/util/prefs sun/management/jmxremote sun/tools/jstatd sun/security/mscapi From alan.bateman at oracle.com Mon Nov 19 13:17:29 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Mon, 19 Nov 2012 13:17:29 +0000 Subject: hg: jdk8/tl/jdk: 8003607: More ProblemList.txt updates (11/2012) Message-ID: <20121119131750.9313747A4F@hg.openjdk.java.net> Changeset: 3877706701b1 Author: alanb Date: 2012-11-19 13:17 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3877706701b1 8003607: More ProblemList.txt updates (11/2012) Reviewed-by: lancea ! test/ProblemList.txt ! test/TEST.ROOT From alexey.utkin at oracle.com Mon Nov 19 14:54:42 2012 From: alexey.utkin at oracle.com (Alexey Utkin) Date: Mon, 19 Nov 2012 18:54:42 +0400 Subject: Review request: JDK-7162111 TEST_BUG: change tests run in headless mode [macosx] (open part) In-Reply-To: <50AA257E.4070701@oracle.com> References: <50AA029C.3090301@oracle.com> <50AA257E.4070701@oracle.com> Message-ID: <50AA4832.60908@oracle.com> Here is the updated version: http://cr.openjdk.java.net/~uta/openjdk-webrevs/JDK-7162111/webrev.01/ On 19.11.2012 16:26, Alan Bateman wrote: > On 19/11/2012 09:57, Alexey Utkin wrote: >> Bug description: >> https://jbs.oracle.com/bugs/browse/JDK-7162111 >> >> Here is the suggested fix: >> http://cr.openjdk.java.net/~uta/openjdk-webrevs/JDK-7162111/ > Thanks for taking this one on. > > The change to JFrameCreateTime.java looks fine to me. > > For test/java/io/Serializable/resolveClass/deserializeButton/Foo.java > then I suggest removing the "was java.awt.Button" references from the > comments. The reason is that it will likely confuse future > maintainers. Also I think Adapter should be renamed, perhaps Element? > Finally the Error message still includes "Button" in the message and > we should change that. Otherwise it's great to have this test running > headless. Done. > > One thing you'll need to do is remove these tests from the exclude > list (jdk/test/ProblemList.txt), otherwise they will not be run on the > Mac as they are currently excluded for that platform. Done. > > I realize you've run the javax.script and jrunscript tests and they > pass for you but it may be that they aren't run (because they excluded > and ProblemList.txt has not been updated) or maybe you just didn't run > into the conditions that cause AWT to hang. I think these tests should > have their @run tag changed so that they run with > -Djava.awt.headless=true. That will allow them to be removed from the > exclude list. > > I looked at java/util/ResourceBundle/Control/Bug6530694.java and it > appears that -Djava.awt.headless=true has added as part of the > forward-port of the Mac port so I think this means it can be removed > from the exclude list now. Here is the JPRT respond with fixed test/ProblemList.txt: http://prt-web.us.oracle.com//archive/2012/11/2012-11-19-123835.fritz.jdk/JobStatus.txt Run time: 01H 16m 33s Build Stats: 18 pass, 0 fail, 0 killed, 0 working, 0 initializing, 0 not started Test Stats: 30 pass, 0 fail, 0 killed, 0 working, 0 initializing, 0 not started Looks good without "-Djava.awt.headless=true". Regards, -uta From martin.desruisseaux at geomatys.fr Mon Nov 19 15:46:58 2012 From: martin.desruisseaux at geomatys.fr (Martin Desruisseaux) Date: Tue, 20 Nov 2012 00:46:58 +0900 Subject: Unnecessary array copy in AbstractStringBuilder.indexOf(String)? Message-ID: <50AA5472.2080405@geomatys.fr> Hello all I noticed that AbstractStringBuilder.indexOf(String, int) is implemented as below: public int indexOf(String str, int fromIndex) { return String.indexOf(value, 0, count, str.toCharArray(), 0, str.length(), fromIndex); } The call to str.toCharArray() creates a copy of the String.value char[] array. This copy doesn't seem necessary since the above String.indexOf(...) method doesn't modify the array content. Shouldn't AbstractStringBuilder passes directly the reference to the String internal array instead, maybe using package-privated access to the array? Admittedly the cloned array is usually small, but the call to indexOf(String, int) is often done in a loop. Martin From david.dehaven at oracle.com Mon Nov 19 16:47:48 2012 From: david.dehaven at oracle.com (David DeHaven) Date: Mon, 19 Nov 2012 08:47:48 -0800 Subject: Review Request: 8001533: Java launcher must launch JavaFX applications In-Reply-To: <50A9FF03.3090001@oracle.com> References: <50A577EE.2020507@oracle.com> <40B1A69C-B03F-4FF2-967C-79F8938770BF@oracle.com> <50A5A80B.4060809@oracle.com> <50A605C9.3060508@oracle.com> <457FC018-78C2-4C09-92F1-B1D07160912D@oracle.com> <50A69A3D.20008@oracle.com> <50A9FF03.3090001@oracle.com> Message-ID: <3396A514-C6DE-4A35-91F6-809E478ABE7A@oracle.com> >> If Main-Class is always present with JavaFX-Application-Class, it may be no impact; but this seems to be unclear at this moment. Kevin can chime in here and looks like this requires more investigation before we continue the code review. > I've read the other mails and I see that there are a number of discussion points that needs to be resolved before the proposal can move forward. Yes, we've been discussing offline to nail down the actual wants for this feature. > On the Profile attribute then the concern is where Main-Class is not present, in that case the JAR file isn't technically an executable JAR file and so would be considered a library JAR in the current proposal, hence different defaults so no fast-fail for FX applications. Oh, I see your point there. Kumar brought up the idea of checking what Java version was targeted when it was compiled to kick in a backwards compatibility mode. I think moving forward there won't be any chance of not having a Main-Class, and I don't think javafxpackager has ever created a jar without it so if one did exist it would have been manually assembled. -DrD- From Alan.Bateman at oracle.com Mon Nov 19 16:57:52 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 19 Nov 2012 16:57:52 +0000 Subject: Review request: JDK-7162111 TEST_BUG: change tests run in headless mode [macosx] (open part) In-Reply-To: <50AA4832.60908@oracle.com> References: <50AA029C.3090301@oracle.com> <50AA257E.4070701@oracle.com> <50AA4832.60908@oracle.com> Message-ID: <50AA6510.1040108@oracle.com> On 19/11/2012 14:54, Alexey Utkin wrote: > Here is the updated version: > > http://cr.openjdk.java.net/~uta/openjdk-webrevs/JDK-7162111/webrev.01/ In Foo.java then I assume Vector would be better. I don't think you can remove the javax/script/** tests from the exclude list without adding -Djava.awt.headless=true to the @run tag of each of those tests. Otherwise looks fine to me. -Alan From mike.duigou at oracle.com Mon Nov 19 17:49:22 2012 From: mike.duigou at oracle.com (Mike Duigou) Date: Mon, 19 Nov 2012 09:49:22 -0800 Subject: (CR#6553074) Unnecessary array copy in AbstractStringBuilder.indexOf(String)? In-Reply-To: <50AA5472.2080405@geomatys.fr> References: <50AA5472.2080405@geomatys.fr> Message-ID: <8662144B-4B1C-4C1C-B41D-987A200722D2@oracle.com> By amazing coincidence a review for fixing this was issued last week: http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-November/012266.html Additional review would be welcome. :-) The patch will probably be ready for push before the end of the month. Mike On Nov 19 2012, at 07:46 , Martin Desruisseaux wrote: > Hello all > > I noticed that AbstractStringBuilder.indexOf(String, int) is implemented as below: > > public int indexOf(String str, int fromIndex) { > return String.indexOf(value, 0, count, > str.toCharArray(), 0, str.length(), fromIndex); > } > > The call to str.toCharArray() creates a copy of the String.value char[] array. This copy doesn't seem necessary since the above String.indexOf(...) method doesn't modify the array content. Shouldn't AbstractStringBuilder passes directly the reference to the String internal array instead, maybe using package-privated access to the array? > > Admittedly the cloned array is usually small, but the call to indexOf(String, int) is often done in a loop. > > Martin > From kevin.rushforth at oracle.com Sat Nov 17 00:05:09 2012 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 16 Nov 2012 16:05:09 -0800 Subject: Review Request: 8001533: Java launcher must launch JavaFX applications In-Reply-To: <457FC018-78C2-4C09-92F1-B1D07160912D@oracle.com> References: <50A577EE.2020507@oracle.com> <40B1A69C-B03F-4FF2-967C-79F8938770BF@oracle.com> <50A5A80B.4060809@oracle.com> <50A605C9.3060508@oracle.com> <457FC018-78C2-4C09-92F1-B1D07160912D@oracle.com> Message-ID: <50A6D4B5.3070400@oracle.com> Hi Dave, I hadn't yet given much thought to retiring the JavaFX-Application-Class attribute, but I agree that it could be considered legacy if we do make the change to the javafxpackager to drop it. I just talked with Mandy about a couple of launcher questions that she had relating to the main class. During the course of answering her questions, a couple of other questions and thoughts came up regarding launching via the Main-Class versus the JavaFX-Main-Class if both are present. I wanted to discuss these before I provide my feedback on the webrev itself. There are three primary scenarios to consider when executing an application from a jar file. I put the most interesting one first: 1) An existing JavaFX application, packaged either using the javafxpackager tool or the underlying task from javafx-ant.jar, which is used by the packager. The jar file produced by the current version of this tool will always have both of the following entries in its MANIFEST: JavaFX-Application-Class: mypkg.MyApp Main-Class: com/javafx/main/Main where "mypkg.MyApp" is the actual name of a public class that extends "javafx.application.Application". The packager inserts the "com/javafx/main/Main.class" file into the jar file. That class does not exists in the JavaFX runtime jar file, jfxrt.jar (which is currently in JRE/lib and is moving to JRE/lib/ext). When this jar file is launched today with "java -jar myjar.jar" the java launcher does the usual thing with this jar file and calls the main(String[]) method of the com.javafx.main.Main class, which will do the following: A) Locate the javafx runtime and construct a URLClassLoader with that jar and the deploy jars on the classpath. Locating the JavaFX runtime jar is no longer necessary, but adding the deploy.jar is still needed unless we want to regress from current behavior. As an aside, Mandy found a potential bug by code inspection in the way the JavaFX main launcher class constructs the class loader -- it uses "null" as the parent rather than ClassLoader.getSystemClassLoader(), which may be the root cause of RT-20988 . B) Read the manifest for the JavaFX-Main-Class, the JavaFX-Preloader-Class, and the JavaFX-Class-Path (which the javafxpackager supports to allow a developer to specify additional dependent jar files). C) Sets up a network proxy unless the JavaFX-Feature-Proxy manifest entry is set to something other than "auto" (auto is the default). D) Call into the platform LauncherImpl.launchApplication method, passing in the application class, the preloader class (if specified in the jar manifest), and the command line arguments. So here is the dilemma. When coming up with the requirements for the launcher, we had defined that the JavaFX-Application-Class should be called in this case for existing FX applications, taking precedence over the Main-Class. I still believe that is the best choice, but it isn't without drawbacks (see below). If the new JDK8 java launcher were to call into the main method of the class specified by Main-Class, ignoring the JavaFX-Main-Class, then we would not get any benefit out of the new launcher for existing applications. The main method of the FX Main launcher class included in the jar will use whatever the current mechanism is for locating the JavaFX classes, which seems undesirable since it adds those jars to a new URLClassLoader that it creates rather than just using the existing class loader. Further, we would be stuck with any bugs that we might find in that old, "statically linked" Main FX launcher, such as the bug that Mandy found. However, while we no longer need or want the "locate jfxrt.jar and add it to the classpath" part of what the existing Main class does, it does do a couple other things that are useful. If the new java launcher calls directly into the JavaFX runtime LauncherImpl.launchApplication method, bypassing the main method of the packaged Main class, we will have no good way -- and probably not enough information -- to know whether or not to set up the proxy configuration and add additional jars onto the classpath (deploy.jar and any jar files specified by JavaFX-Class-Path at a minimum). Currently you don't support the JavaFX-Preloader-Class either, but that is more easily solvable. Either way, it seems like we will have some compatibility issues and functionality concerns. I think this is solvable, perhaps by defining a new variant of LauncherImpl.launchApplication that accepts more arguments (like a map of the manifest entries), but I wanted to raise the issue. The other two cases are much easier: 2) A Java application using some JavaFX that is packaged by just jar-ing up the class files and setting a main class via the "Main-Class" jar attribute in the MANIFEST, and without a "JavaFX-Main-Class" aattribute. Running "java -jar myapp.jar" will just launch an run the app by calling into the "public static void main(String[])" method. With the modified JDK8 launcher, the only question is this: if the specified Main-Class both extends javafx.application.Application *and* has a main method, which one should take precedence? I can see arguments for either one. For consistency with applets and webstart applications, it seems that launching it as an FX application will provide the most consistent experience. This is what your webrev will do which seems good. Note that the same concern about lack of support for JavaFX-Preloader-Class, etc, exists in this case as in scenario #1. 3) A JavaFX application, packaged manually or by a modified version of the JavaFX packager, without a Main-Class (no such modification has been specified, but could be considered once the java launcher is modified to recognize JavaFX classes as an alternative to dropping JavaFX-Application-Class and just using the MainClass). In this example, the MANIFEST of the jar file would have the JavaFX-Application-Class to specify the subclass of javafx.application.Application that should be launched. If this case is supported, it would be simple and would do what we want, but might not actually occur depending on other decisions that are made. Mandy can chime in with her thoughts on this, but it seems that we need to answer the questions in scenario #1 before proceeding. Do you think it might be better to wait until these can be resolved even it means missing M5 (the move of jfxrt.jar to lib/ext won't happen for M5 anyway...it is scheduled for M6)? Or do you think they can be resolved with minor changes to the existing functionality? -- Kevin David DeHaven wrote: >>> I cleaned it up quite a bit, I think it looks a lot better now: >>> http://cr.openjdk.java.net/~ddehaven/8001533/webrev.1/ >>> >>> The comments still need some attention, I'll get that first thing on the morrow. >>> >>> -DrD- >>> >>> >> I haven't done a detailed code review but I'm wondering about preferring JavaFX-Application-Class over Main-Class. I realize there may be some history here, perhaps with the javafxpackager tool, but I'm just concerned that the JAR File specification specifies the Main-Class attribute, now it will be usurped and ignored if this custom attribute is present. >> > > JavaFX-Application-Class is for backwards compatibility with existing applications, my understanding is it's being deprecated. Moving forward JavaFX applications will only use Main-Class. Kevin can correct me if I'm wrong :) > > Am I wrong in thinking there should be no impact on profile support if it's being deprecated? > > -DrD- > > From jonathan.gibbons at oracle.com Mon Nov 19 19:39:10 2012 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Mon, 19 Nov 2012 19:39:10 +0000 Subject: hg: jdk8/tl/langtools: 8001098: Provide a simple light-weight "plug-in" mechanism for javac Message-ID: <20121119193913.EB92A47A59@hg.openjdk.java.net> Changeset: c0f0c41cafa0 Author: jjg Date: 2012-11-19 11:38 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/c0f0c41cafa0 8001098: Provide a simple light-weight "plug-in" mechanism for javac Reviewed-by: mcimadamore + src/share/classes/com/sun/source/util/Plugin.java ! src/share/classes/com/sun/source/util/Trees.java ! src/share/classes/com/sun/tools/javac/api/BasicJavacTask.java ! src/share/classes/com/sun/tools/javac/api/JavacTaskImpl.java ! src/share/classes/com/sun/tools/javac/api/JavacTrees.java ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/main/Main.java ! src/share/classes/com/sun/tools/javac/main/Option.java ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java ! src/share/classes/com/sun/tools/javac/resources/javac.properties + test/tools/javac/plugin/showtype/Identifiers.java + test/tools/javac/plugin/showtype/Identifiers.out + test/tools/javac/plugin/showtype/Identifiers_PI.out + test/tools/javac/plugin/showtype/ShowTypePlugin.java + test/tools/javac/plugin/showtype/Test.java From Ulf.Zibis at CoSoCo.de Mon Nov 19 21:12:51 2012 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Mon, 19 Nov 2012 22:12:51 +0100 Subject: (CR#6553074) Unnecessary array copy in AbstractStringBuilder.indexOf(String)? In-Reply-To: <8662144B-4B1C-4C1C-B41D-987A200722D2@oracle.com> References: <50AA5472.2080405@geomatys.fr> <8662144B-4B1C-4C1C-B41D-987A200722D2@oracle.com> Message-ID: <50AAA0D3.8040201@CoSoCo.de> Hi, I'm wondering, if we still need 1739 static int indexOf(char[] source, int sourceOffset, int sourceCount, 1740 char[] target, int targetOffset, int targetCount, 1741 int fromIndex) { since bug 6924259: Remove offset and count fields from java.lang.String. I guess we only need 1739 static int indexOf(char[] source, int sourceCount, 1740 char[] target, int fromIndex) { anymore. -Ulf Am 19.11.2012 18:49, schrieb Mike Duigou: > By amazing coincidence a review for fixing this was issued last week: > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-November/012266.html > > Additional review would be welcome. :-) > > The patch will probably be ready for push before the end of the month. > > Mike > > On Nov 19 2012, at 07:46 , Martin Desruisseaux wrote: > >> Hello all >> >> I noticed that AbstractStringBuilder.indexOf(String, int) is implemented as below: >> >> public int indexOf(String str, int fromIndex) { >> return String.indexOf(value, 0, count, >> str.toCharArray(), 0, str.length(), fromIndex); >> } >> >> The call to str.toCharArray() creates a copy of the String.value char[] array. This copy doesn't seem necessary since the above String.indexOf(...) method doesn't modify the array content. Shouldn't AbstractStringBuilder passes directly the reference to the String internal array instead, maybe using package-privated access to the array? >> >> Admittedly the cloned array is usually small, but the call to indexOf(String, int) is often done in a loop. >> >> Martin >> > From mike.duigou at oracle.com Mon Nov 19 22:09:26 2012 From: mike.duigou at oracle.com (Mike Duigou) Date: Mon, 19 Nov 2012 14:09:26 -0800 Subject: Request for Review : 6553074 : String{Buffer, Builder}.indexOf(Str, int) contains unnecessary allocation In-Reply-To: <50A40BF9.3090208@oracle.com> References: <69BAB031-C94A-4D2D-A5C4-11A42F168C44@oracle.com> <50A40BF9.3090208@oracle.com> Message-ID: On Nov 14 2012, at 13:24 , Jim Gish wrote: > Mike, > > In String.java, with the new methods you're adding, should we make those String target parameters a CharSequence instead? A String param enables us to extract the internal char array for the search. We could not do so with a CharSequence and would have to create a substring somewhat like the old implementation did. Mike > Thanks, > Jim > > On 11/14/2012 01:27 PM, Mike Duigou wrote: >> Hello all; >> >> This patch causes the indexOf and lastIndexOf implementation in AbstractStringBuilder to directly compare the character arrays rather than making a copy of the substring before comparing. >> >> http://cr.openjdk.java.net/~mduigou/6553074/0/webrev/ >> >> From mike.duigou at oracle.com Mon Nov 19 22:16:49 2012 From: mike.duigou at oracle.com (Mike Duigou) Date: Mon, 19 Nov 2012 14:16:49 -0800 Subject: (CR#6553074) Unnecessary array copy in AbstractStringBuilder.indexOf(String)? In-Reply-To: <50AAA0D3.8040201@CoSoCo.de> References: <50AA5472.2080405@geomatys.fr> <8662144B-4B1C-4C1C-B41D-987A200722D2@oracle.com> <50AAA0D3.8040201@CoSoCo.de> Message-ID: <19385DEA-727D-432B-A183-4FFFABB63E60@oracle.com> I didn't attempt to evaluate that or refactor it in this round. Something for a future patch. A simplification/refactoring patch for indexOf/lastIndexOf would certainly be welcome. Mike On Nov 19 2012, at 13:12 , Ulf Zibis wrote: > Hi, > > I'm wondering, if we still need > 1739 static int indexOf(char[] source, int sourceOffset, int sourceCount, > 1740 char[] target, int targetOffset, int targetCount, > 1741 int fromIndex) { > since bug 6924259: Remove offset and count fields from java.lang.String. > > I guess we only need > 1739 static int indexOf(char[] source, int sourceCount, > 1740 char[] target, int fromIndex) { > anymore. > > -Ulf > > Am 19.11.2012 18:49, schrieb Mike Duigou: >> By amazing coincidence a review for fixing this was issued last week: >> >> http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-November/012266.html >> >> Additional review would be welcome. :-) >> >> The patch will probably be ready for push before the end of the month. >> >> Mike >> >> On Nov 19 2012, at 07:46 , Martin Desruisseaux wrote: >> >>> Hello all >>> >>> I noticed that AbstractStringBuilder.indexOf(String, int) is implemented as below: >>> >>> public int indexOf(String str, int fromIndex) { >>> return String.indexOf(value, 0, count, >>> str.toCharArray(), 0, str.length(), fromIndex); >>> } >>> >>> The call to str.toCharArray() creates a copy of the String.value char[] array. This copy doesn't seem necessary since the above String.indexOf(...) method doesn't modify the array content. Shouldn't AbstractStringBuilder passes directly the reference to the String internal array instead, maybe using package-privated access to the array? >>> >>> Admittedly the cloned array is usually small, but the call to indexOf(String, int) is often done in a loop. >>> >>> Martin >>> >> > From bhavesh.x.patel at oracle.com Tue Nov 20 00:10:20 2012 From: bhavesh.x.patel at oracle.com (bhavesh.x.patel at oracle.com) Date: Tue, 20 Nov 2012 00:10:20 +0000 Subject: hg: jdk8/tl/langtools: 8002304: Group methods by types in methods summary section Message-ID: <20121120001025.33FE847A60@hg.openjdk.java.net> Changeset: 522a1ee72340 Author: bpatel Date: 2012-11-19 16:10 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/522a1ee72340 8002304: Group methods by types in methods summary section Reviewed-by: jjg ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractMemberWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDoclet.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/SubWriterHolderWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlStyle.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlTree.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/MemberSummaryWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/MemberSummaryBuilder.java + src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/activetitlebar.gif + src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/activetitlebar_end.gif + src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/script.js ! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/stylesheet.css ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocPaths.java + src/share/classes/com/sun/tools/doclets/internal/toolkit/util/MethodTypes.java ! test/com/sun/javadoc/testHtmlTableTags/TestHtmlTableTags.java + test/com/sun/javadoc/testMethodTypes/TestMethodTypes.java + test/com/sun/javadoc/testMethodTypes/pkg1/A.java + test/com/sun/javadoc/testMethodTypes/pkg1/B.java + test/com/sun/javadoc/testMethodTypes/pkg1/D.java ! test/tools/javadoc/api/basic/APITest.java From jonathan.gibbons at oracle.com Tue Nov 20 00:41:14 2012 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Tue, 20 Nov 2012 00:41:14 +0000 Subject: hg: jdk8/tl/langtools: 8003655: Add javac.jvm.ClassFile.V52 Message-ID: <20121120004116.ADD6447A61@hg.openjdk.java.net> Changeset: 2531de382983 Author: jjg Date: 2012-11-19 16:40 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/2531de382983 8003655: Add javac.jvm.ClassFile.V52 Reviewed-by: ksrini ! src/share/classes/com/sun/tools/javac/jvm/ClassFile.java From Ulf.Zibis at CoSoCo.de Tue Nov 20 02:17:45 2012 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Tue, 20 Nov 2012 03:17:45 +0100 Subject: Request for Review : 6553074 : String{Buffer, Builder}.indexOf(Str, int) contains unnecessary allocation In-Reply-To: References: <69BAB031-C94A-4D2D-A5C4-11A42F168C44@oracle.com> <50A40BF9.3090208@oracle.com> Message-ID: <50AAE849.5@CoSoCo.de> Am 19.11.2012 23:09, schrieb Mike Duigou: > On Nov 14 2012, at 13:24 , Jim Gish wrote: > >> Mike, >> >> In String.java, with the new methods you're adding, should we make those String target parameters a CharSequence instead? > A String param enables us to extract the internal char array for the search. We could not do so with a CharSequence and would have to create a substring somewhat like the old implementation did. ... or switch by a instanceof statement and then call ((String)sequence).value. -Ulf From david.dehaven at oracle.com Tue Nov 20 02:43:33 2012 From: david.dehaven at oracle.com (David DeHaven) Date: Mon, 19 Nov 2012 18:43:33 -0800 Subject: Review Request: 8001533: Java launcher must launch JavaFX applications In-Reply-To: <3396A514-C6DE-4A35-91F6-809E478ABE7A@oracle.com> References: <50A577EE.2020507@oracle.com> <40B1A69C-B03F-4FF2-967C-79F8938770BF@oracle.com> <50A5A80B.4060809@oracle.com> <50A605C9.3060508@oracle.com> <457FC018-78C2-4C09-92F1-B1D07160912D@oracle.com> <50A69A3D.20008@oracle.com> <50A9FF03.3090001@oracle.com> <3396A514-C6DE-4A35-91F6-809E478ABE7A@oracle.com> Message-ID: >>> If Main-Class is always present with JavaFX-Application-Class, it may be no impact; but this seems to be unclear at this moment. Kevin can chime in here and looks like this requires more investigation before we continue the code review. >> I've read the other mails and I see that there are a number of discussion points that needs to be resolved before the proposal can move forward. > > Yes, we've been discussing offline to nail down the actual wants for this feature. After discussion and debate, we've decided the best course of action right now is to drop the JavaFX-Application-Class support for this round and revisit (hopefully quickly) in M6. This should alleviate any concerns for Profile support. There are other issues that require work to be done on the FX side before we can proceed beyond this, but this should provide a good baseline to accommodate those changes when they're ready. So, without further ado, here's the updated webrev: http://cr.openjdk.java.net/~ddehaven/8001533/webrev.2/ -DrD- From mandy.chung at oracle.com Tue Nov 20 03:45:01 2012 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 19 Nov 2012 19:45:01 -0800 Subject: Review Request: 8001533: Java launcher must launch JavaFX applications In-Reply-To: References: <50A577EE.2020507@oracle.com> <40B1A69C-B03F-4FF2-967C-79F8938770BF@oracle.com> <50A5A80B.4060809@oracle.com> <50A605C9.3060508@oracle.com> <457FC018-78C2-4C09-92F1-B1D07160912D@oracle.com> <50A69A3D.20008@oracle.com> <50A9FF03.3090001@oracle.com> <3396A514-C6DE-4A35-91F6-809E478ABE7A@oracle.com> Message-ID: <50AAFCBD.7070707@oracle.com> On 11/19/2012 6:43 PM, David DeHaven wrote: >>> I've read the other mails and I see that there are a number of discussion points that needs to be resolved before the proposal can move forward. >> Yes, we've been discussing offline to nail down the actual wants for this feature. > After discussion and debate, we've decided the best course of action right now is to drop the JavaFX-Application-Class support for this round and revisit (hopefully quickly) in M6. This should alleviate any concerns for Profile support. There are other issues that require work to be done on the FX side before we can proceed beyond this, but this should provide a good baseline to accommodate those changes when they're ready. > > So, without further ado, here's the updated webrev: > http://cr.openjdk.java.net/~ddehaven/8001533/webrev.2/ > Looks good to me. Basically the change now is to support launching a FX application class that has no static void main method and there is no change in launching a JAR file nor an entry point with static void main method. Nits: LauncherHelper.java L71: I actually had the same comment as Alan that I prefer the original MAIN_CLASS variable name. L444-452: the comment doesn't match the impl e.g. 3 & 4 should be reversed. L504, 536, 540: extra spaces in aligning the line above. In fact, David has fixed these nits (thanks David): http://cr.openjdk.java.net/~ddehaven/8001533/webrev.3/ Mandy From mike.duigou at oracle.com Tue Nov 20 03:55:38 2012 From: mike.duigou at oracle.com (Mike Duigou) Date: Mon, 19 Nov 2012 19:55:38 -0800 Subject: Request for Review (#3) : CR#8001634 : Initial set of lambda functional interfaces In-Reply-To: <50A49205.6030108@oracle.com> References: <50A49205.6030108@oracle.com> Message-ID: <477DA9BF-CC3A-4390-93CB-118C622F9066@oracle.com> The reason is that {Int|Double|Long}Function take an object and yield a primitive. Supplier, BinaryOperator, UnaryOperator and Block variants all operate on the primitive type (or the boxed version) and don't utilize any generic reference types. The only reference types used are the boxed versions of the primitive. Mike On Nov 14 2012, at 22:56 , David Holmes wrote: > Hi Mike, > > My original comment still stands regarding the wording in the Function specializations versus all the others. Why does, for example, IntFunction say "this is the {@code int}-bearing specialization for {@link Function}", yet IntBinaryOperator does not make a similar statement regarding BinaryOperator? > > David > > On 14/11/2012 11:19 AM, Mike Duigou wrote: >> Hello all; >> >> I apologize for the quick turnaround from the second review request [1] but I've updated the webrev again: >> >> http://cr.openjdk.java.net/~mduigou/8001634/4/webrev/ >> >> Blame a busy Paul Sandoz who his making significant progress on the primitive specializations implementation. ;-) >> >> This update includes: >> >> - Block.apply renamed to Block.accept >> - {Int|Long|Double}Block specializations added. >> - Commented out "extends Combiner" in BinaryOperator was removed for now since Combiner is out of scope for this review. >> - The {Int|Long|Double} specializations of BinaryOperator and UnaryOperator now show commented out extends of the generic version along with commented out default methods. This change will not be part of the commit but is meant to show where the implementation will be going. >> - The {Int|Long|Double} specializations of Supplier now extend generic Supplier, have getAs{Int|Long|Double} as their abstract method and provide a commented out default get() method to satisfy the need for a get implementation. >> - The {Int|Long|Double} specializations of Function now extend generic Function, have applyAs{Int|Long|Double} as their abstract method and provide a commented out default apply() method to satisfy the need for an apply implementation. >> >> Mike >> >> [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-November/012225.html From mike.duigou at oracle.com Tue Nov 20 04:55:33 2012 From: mike.duigou at oracle.com (Mike Duigou) Date: Mon, 19 Nov 2012 20:55:33 -0800 Subject: Request for Review (#4) : CR#8001634 : Initial set of lambda functional interfaces In-Reply-To: References: Message-ID: <8733618F-C751-414F-ACE2-D1C9B6E70257@oracle.com> I have posted another revision at http://cr.openjdk.java.net/~mduigou/8001634/5/webrev/ This version contains some method remaining in the {I|L|D}UnaryOperation and {I|L|D}BinaryOperator and a few Javadoc fixes. The package javadoc ie. package-info.java, is known to be a weak point right now. We're still debating what must be said here and what would be better said attached to the APIs which consume these functional interfaces. We don't anticipate many (any?) further changes to the naming before commit at this point. Mike On Nov 13 2012, at 17:19 , Mike Duigou wrote: > Hello all; > > I apologize for the quick turnaround from the second review request [1] but I've updated the webrev again: > > http://cr.openjdk.java.net/~mduigou/8001634/4/webrev/ > > Blame a busy Paul Sandoz who his making significant progress on the primitive specializations implementation. ;-) > > This update includes: > > - Block.apply renamed to Block.accept > - {Int|Long|Double}Block specializations added. > - Commented out "extends Combiner" in BinaryOperator was removed for now since Combiner is out of scope for this review. > - The {Int|Long|Double} specializations of BinaryOperator and UnaryOperator now show commented out extends of the generic version along with commented out default methods. This change will not be part of the commit but is meant to show where the implementation will be going. > - The {Int|Long|Double} specializations of Supplier now extend generic Supplier, have getAs{Int|Long|Double} as their abstract method and provide a commented out default get() method to satisfy the need for a get implementation. > - The {Int|Long|Double} specializations of Function now extend generic Function, have applyAs{Int|Long|Double} as their abstract method and provide a commented out default apply() method to satisfy the need for an apply implementation. > > Mike > > [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-November/012225.html From mike.duigou at oracle.com Tue Nov 20 04:58:12 2012 From: mike.duigou at oracle.com (Mike Duigou) Date: Mon, 19 Nov 2012 20:58:12 -0800 Subject: Request for Review (#2) : CR#8001634 : Initial set of lambda functional interfaces In-Reply-To: References: Message-ID: On Nov 14 2012, at 02:48 , Stephen Colebourne wrote: > On 13 November 2012 19:05, Mike Duigou wrote: >> - Mapper.map becomes Function.apply >> - Factory.make becomes Supplier.get >> - Specializations of Supplier for int, long, double >> - Reorder type variables to put result last >> - Fixes many javadoc and stylistic comments. >> >> What didn't change: >> - Block was not renamed to Action or Procedure. The name Block.apply currently conflicts with Function.apply and should be renamed. Block.accept? Block.perform? >> - Combiner will be part of the full API but it's only present in this patch as a comment. >> - No default methods. >> >> Unless there are sustained and persuasive objections this will be committed to the jdk8/tl workspace at the end of this week or early next week. (Hence "core-libs-dev" being the primary review list) > > The interface definitions say nothing about null. I'd like to see > something in there, even if it is to say "null handling behaviour is > defined by the implementation". For these interfaces it's defined by the APIs which utilize them. I'm unsure how useful it is to say "treatment of nulls depends on usage". Mike From david.holmes at oracle.com Tue Nov 20 06:31:42 2012 From: david.holmes at oracle.com (David Holmes) Date: Tue, 20 Nov 2012 16:31:42 +1000 Subject: Request for Review (#4) : CR#8001634 : Initial set of lambda functional interfaces In-Reply-To: <8733618F-C751-414F-ACE2-D1C9B6E70257@oracle.com> References: <8733618F-C751-414F-ACE2-D1C9B6E70257@oracle.com> Message-ID: <50AB23CE.2030104@oracle.com> Hi Mike, Minor typos and inconsistencies: DoubleBinaryOperator.java 28 * Combines two {@code double} operands producing an {@code double} result. an -> a 51 * @param rightvalue used as the right operand Need space after right 52 * @return result value of the operation "result value" doesn't read right - just "@return the result of ..." - as for BinaryOperator.operate General consistency: all like methods in a family of interfaces should use the same wording. Eg BinaryOperator.operate says "upon the provided operands" whereas DoubleBinaryOperator.* says "upon the operands". Ditto across families ie UnaryOperator and BinaryOperator should use consistent terminology for operands and results. --- DoubleBlock.java: 31 * @param The type of input objects to {@code accept}. DoubleBlock is not a generic type. (Surely this should be generating a javadoc warning?) --- DoubleFunction.java 32 * @param the type of input objects to the {@code apply} operation. You now potentially have multiple operation methods, and T refers to the input of all of them. ---- General consistency comments across everything: - Use of operand versus provided operand versus input value etc - Use of result vs computed result vs result value vs output etc --- Function.java 33 * @param the type of output objects from {@code apply} operation. from -> from the 43 * @param t the input object to be to which the function will be applied. delete "to be" ? Or else re-word. --- UnaryOperator.java 28 * Operator on a single operand. Operator -> operate ? 30 * @param the type of input objects to {@code operate} and of the result. objects -> object --- Cheers, David On 20/11/2012 2:55 PM, Mike Duigou wrote: > I have posted another revision at > > http://cr.openjdk.java.net/~mduigou/8001634/5/webrev/ > > This version contains some method remaining in the {I|L|D}UnaryOperation and {I|L|D}BinaryOperator and a few Javadoc fixes. > > The package javadoc ie. package-info.java, is known to be a weak point right now. We're still debating what must be said here and what would be better said attached to the APIs which consume these functional interfaces. > > We don't anticipate many (any?) further changes to the naming before commit at this point. > > Mike > > On Nov 13 2012, at 17:19 , Mike Duigou wrote: > >> Hello all; >> >> I apologize for the quick turnaround from the second review request [1] but I've updated the webrev again: >> >> http://cr.openjdk.java.net/~mduigou/8001634/4/webrev/ >> >> Blame a busy Paul Sandoz who his making significant progress on the primitive specializations implementation. ;-) >> >> This update includes: >> >> - Block.apply renamed to Block.accept >> - {Int|Long|Double}Block specializations added. >> - Commented out "extends Combiner" in BinaryOperator was removed for now since Combiner is out of scope for this review. >> - The {Int|Long|Double} specializations of BinaryOperator and UnaryOperator now show commented out extends of the generic version along with commented out default methods. This change will not be part of the commit but is meant to show where the implementation will be going. >> - The {Int|Long|Double} specializations of Supplier now extend generic Supplier, have getAs{Int|Long|Double} as their abstract method and provide a commented out default get() method to satisfy the need for a get implementation. >> - The {Int|Long|Double} specializations of Function now extend generic Function, have applyAs{Int|Long|Double} as their abstract method and provide a commented out default apply() method to satisfy the need for an apply implementation. >> >> Mike >> >> [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-November/012225.html > From chris.hegarty at oracle.com Tue Nov 20 09:27:36 2012 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Tue, 20 Nov 2012 09:27:36 +0000 Subject: hg: jdk8/tl/jdk: 8000476: Memory Leaks and uninitialized memory access in PKCS11 and other native code Message-ID: <20121120092756.0EB9547A75@hg.openjdk.java.net> Changeset: 2d08b404cd91 Author: jzavgren Date: 2012-11-20 09:26 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2d08b404cd91 8000476: Memory Leaks and uninitialized memory access in PKCS11 and other native code Reviewed-by: dsamersoff, valeriep, chegar ! src/share/bin/wildcard.c ! src/share/native/sun/security/jgss/wrapper/GSSLibStub.c ! src/share/native/sun/security/pkcs11/wrapper/p11_mutex.c ! src/solaris/bin/java_md_solinux.c From Alan.Bateman at oracle.com Tue Nov 20 10:14:01 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 20 Nov 2012 10:14:01 +0000 Subject: Review Request: 8001533: Java launcher must launch JavaFX applications In-Reply-To: References: <50A577EE.2020507@oracle.com> <40B1A69C-B03F-4FF2-967C-79F8938770BF@oracle.com> <50A5A80B.4060809@oracle.com> <50A605C9.3060508@oracle.com> <457FC018-78C2-4C09-92F1-B1D07160912D@oracle.com> <50A69A3D.20008@oracle.com> <50A9FF03.3090001@oracle.com> <3396A514-C6DE-4A35-91F6-809E478ABE7A@oracle.com> Message-ID: <50AB57E9.9060201@oracle.com> On 20/11/2012 02:43, David DeHaven wrote: > : > After discussion and debate, we've decided the best course of action right now is to drop the JavaFX-Application-Class support for this round and revisit (hopefully quickly) in M6. This should alleviate any concerns for Profile support. There are other issues that require work to be done on the FX side before we can proceed beyond this, but this should provide a good baseline to accommodate those changes when they're ready. > > So, without further ado, here's the updated webrev: > http://cr.openjdk.java.net/~ddehaven/8001533/webrev.2/ > > -DrD- Thanks for the update, it looks reasonable now. -Alan From david.buck at oracle.com Tue Nov 20 12:55:37 2012 From: david.buck at oracle.com (David Buck) Date: Tue, 20 Nov 2012 21:55:37 +0900 Subject: code review request: Test case for JDK-7198904 TreeMap.clone issue In-Reply-To: References: <50A39EED.9050902@oracle.com> Message-ID: <50AB7DC9.7080706@oracle.com> Hi! > The one possible addition is to check that m1 hasn't been modified > after the mutation of m2. Sounds good. I have added the second test and retested against both OpenJDK and OracleJDK builds: [ Code Review for jdk ] http://cr.openjdk.java.net/~dbuck/7198904/webrev.01/ Would someone please review this new version of the test case? Cheers, -Buck On 11/16/12 11:45, Mike Duigou wrote: > Looks like a good test to me as well. The one possible addition is to check that m1 hasn't been modified after the mutation of m2. > > Mike > > On Nov 14 2012, at 05:38 , David Buck wrote: > >> Hi! >> >> This is a review request to add only the test case for the following OracleJDK issue: >> >> [ 7198904 : (alt-rt) TreeMap.clone is broken ] >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7198904 >> >> The issue (root cause) is not in OpenJDK (i.e. the problem was OracleJDK specific), but the test case is valid for both so it should go into OpenJDK so we can prevent a similar issue from ever happening in both releases moving forward. >> >> webrev: >> >> [ Code Review for jdk ] >> http://cr.openjdk.java.net/~dbuck/7198904/webrev.00/ >> >> The OracleJDK fix (closed source) is ready and has already passed code review. I intend to push both the OracleJDK fix and this test case into their respective repositories at the same time once this review is done. >> >> Regards, >> -Buck > From Alan.Bateman at oracle.com Tue Nov 20 13:45:34 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 20 Nov 2012 13:45:34 +0000 Subject: (CR#6553074) Unnecessary array copy in AbstractStringBuilder.indexOf(String)? In-Reply-To: <8662144B-4B1C-4C1C-B41D-987A200722D2@oracle.com> References: <50AA5472.2080405@geomatys.fr> <8662144B-4B1C-4C1C-B41D-987A200722D2@oracle.com> Message-ID: <50AB897E.40604@oracle.com> On 19/11/2012 17:49, Mike Duigou wrote: > By amazing coincidence a review for fixing this was issued last week: > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-November/012266.html > > Additional review would be welcome. :-) > > The patch will probably be ready for push before the end of the month. > > Mike > I looked at the webrev and it looks okay to me, I agree with separating any additional refactoring into another bug. -Alan From staffan.larsen at oracle.com Tue Nov 20 14:10:47 2012 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 20 Nov 2012 15:10:47 +0100 Subject: RFR: 8003322: Add instrumentation points for tracing of I/O calls In-Reply-To: <50AA279B.7060505@oracle.com> References: <50A39388.8060502@oracle.com> <50AA0142.3080502@oracle.com> <28479F37-C81B-4CFB-811A-CEC45755B26B@oracle.com> <50AA279B.7060505@oracle.com> Message-ID: <7C9B7EE6-E9BB-4F4C-81BD-B8AECE689739@oracle.com> On 19 nov 2012, at 13:35, Alan Bateman wrote: > On 19/11/2012 11:15, Staffan Larsen wrote: >> : >> I think you are right that bytecode instrumentation would also work. The only problem I see (apart from the path field) is the time it would take to develop such a solution. I'm not sure if that is a good enough argument for keeping the non-bytecode-instrumentation solution, though. Or if we could replace the non-bytecode-instrumentation solution with an updated bytecode instrumentation solution in a later update? Not ideal, but would allow us to complete the project on time. >> > I'd go along with that, assuming of course that the changes to use bytecode instrumentation aren't pushed out indefinitely. The original plan was for the code in this review to go into both 8 and 7u12. Since 7u12 has a tighter deadline, a possible path would be to include it only in 7u12, but not in 8. For 8 we would then implement a fully dynamic solution. The only thing needed in 8 from this review would be the path field added to the stream classes. Does that sound like a plan? Thanks, /Staffan From Alan.Bateman at oracle.com Tue Nov 20 14:20:30 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 20 Nov 2012 14:20:30 +0000 Subject: RFR: 8003322: Add instrumentation points for tracing of I/O calls In-Reply-To: <7C9B7EE6-E9BB-4F4C-81BD-B8AECE689739@oracle.com> References: <50A39388.8060502@oracle.com> <50AA0142.3080502@oracle.com> <28479F37-C81B-4CFB-811A-CEC45755B26B@oracle.com> <50AA279B.7060505@oracle.com> <7C9B7EE6-E9BB-4F4C-81BD-B8AECE689739@oracle.com> Message-ID: <50AB91AE.4040909@oracle.com> On 20/11/2012 14:10, Staffan Larsen wrote: > : > The original plan was for the code in this review to go into both 8 and 7u12. Since 7u12 has a tighter deadline, a possible path would be to include it only in 7u12, but not in 8. For 8 we would then implement a fully dynamic solution. The only thing needed in 8 from this review would be the path field added to the stream classes. Does that sound like a plan? > I think this is a good plan. I suggest bringing it up on jdk7u-dev so that the jdk7u maintainers can think about the issue (rather that trying to get approval at the last minute when you are reading to push). -Alan From kumar.x.srinivasan at oracle.com Tue Nov 20 14:30:19 2012 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Tue, 20 Nov 2012 06:30:19 -0800 Subject: Review Request: 8001533: Java launcher must launch JavaFX applications In-Reply-To: <50AB57E9.9060201@oracle.com> References: <50A577EE.2020507@oracle.com> <40B1A69C-B03F-4FF2-967C-79F8938770BF@oracle.com> <50A5A80B.4060809@oracle.com> <50A605C9.3060508@oracle.com> <457FC018-78C2-4C09-92F1-B1D07160912D@oracle.com> <50A69A3D.20008@oracle.com> <50A9FF03.3090001@oracle.com> <3396A514-C6DE-4A35-91F6-809E478ABE7A@oracle.com> <50AB57E9.9060201@oracle.com> Message-ID: <50AB93FB.1000905@oracle.com> On 11/20/2012 2:14 AM, Alan Bateman wrote: > On 20/11/2012 02:43, David DeHaven wrote: >> : >> After discussion and debate, we've decided the best course of action >> right now is to drop the JavaFX-Application-Class support for this >> round and revisit (hopefully quickly) in M6. This should alleviate >> any concerns for Profile support. There are other issues that require >> work to be done on the FX side before we can proceed beyond this, but >> this should provide a good baseline to accommodate those changes when >> they're ready. >> >> So, without further ado, here's the updated webrev: >> http://cr.openjdk.java.net/~ddehaven/8001533/webrev.2/ >> >> -DrD- > Thanks for the update, it looks reasonable now. Thanks everyone, as an FYI, I am splitting the changeset into two distinct JBS issues and changesets, so that proper credits can be attributed to the respective authors. Yes, We will smooth the rough edges in M6 with further hashing and testing. Kumar > > -Alan From kumar.x.srinivasan at oracle.com Tue Nov 20 14:51:13 2012 From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com) Date: Tue, 20 Nov 2012 14:51:13 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20121120145147.C9BA147A7E@hg.openjdk.java.net> Changeset: 914cd9b482c8 Author: ksrini Date: 2012-11-19 19:49 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/914cd9b482c8 8001533: java launcher must launch javafx applications Reviewed-by: ksrini, mchung, kcr, alanb Contributed-by: david.dehaven at oracle.com ! src/share/bin/java.c ! src/share/classes/sun/launcher/LauncherHelper.java ! src/share/classes/sun/launcher/resources/launcher.properties ! test/tools/launcher/TestHelper.java Changeset: b1c364c84d09 Author: ksrini Date: 2012-11-19 19:50 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b1c364c84d09 8003660: (launcher) 8001533 regression tests Reviewed-by: ksrini, mchung, kcr, ddehaven Contributed-by: steve.sides at oracle.com + test/tools/launcher/FXLauncherTest.java From jonathan.gibbons at oracle.com Tue Nov 20 15:22:04 2012 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Tue, 20 Nov 2012 15:22:04 +0000 Subject: hg: jdk8/tl/langtools: 8003649: regression/langtools: tools/javac/doctree Message-ID: <20121120152207.387C447A80@hg.openjdk.java.net> Changeset: a25c53e12bd0 Author: jjg Date: 2012-11-20 07:21 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/a25c53e12bd0 8003649: regression/langtools: tools/javac/doctree Reviewed-by: ksrini ! test/tools/javac/doctree/DocCommentTester.java From jonathan.gibbons at oracle.com Tue Nov 20 15:26:09 2012 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Tue, 20 Nov 2012 15:26:09 +0000 Subject: hg: jdk8/tl/langtools: 8003650: java.lang.Exception: expected string not found: pkg/package-frame.html Message-ID: <20121120152612.50E7847A81@hg.openjdk.java.net> Changeset: fb97eaf93d61 Author: jjg Date: 2012-11-20 07:25 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/fb97eaf93d61 8003650: java.lang.Exception: expected string not found: pkg/package-frame.html Reviewed-by: ksrini ! test/tools/javadoc/api/basic/GetTask_WriterTest.java ! test/tools/javadoc/api/basic/RunTest.java From maurizio.cimadamore at oracle.com Tue Nov 20 15:44:10 2012 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Tue, 20 Nov 2012 15:44:10 +0000 Subject: hg: jdk8/tl/langtools: 8003663: lambda test fails on Windows Message-ID: <20121120154413.2471947A85@hg.openjdk.java.net> Changeset: 7538e419a588 Author: mcimadamore Date: 2012-11-20 15:43 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/7538e419a588 8003663: lambda test fails on Windows Summary: fix path separator issue in test Reviewed-by: jjg ! test/tools/javac/lambda/abort/Abort.java From mike.duigou at oracle.com Tue Nov 20 17:05:00 2012 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 20 Nov 2012 09:05:00 -0800 Subject: code review request: Test case for JDK-7198904 TreeMap.clone issue In-Reply-To: <50AB7DC9.7080706@oracle.com> References: <50A39EED.9050902@oracle.com> <50AB7DC9.7080706@oracle.com> Message-ID: Looks good. Thank you for making the change. Mike On Nov 20 2012, at 04:55 , David Buck wrote: > Hi! > > > The one possible addition is to check that m1 hasn't been modified > > after the mutation of m2. > > Sounds good. I have added the second test and retested against both OpenJDK and OracleJDK builds: > > [ Code Review for jdk ] > http://cr.openjdk.java.net/~dbuck/7198904/webrev.01/ > > Would someone please review this new version of the test case? > > Cheers, > -Buck > > On 11/16/12 11:45, Mike Duigou wrote: >> Looks like a good test to me as well. The one possible addition is to check that m1 hasn't been modified after the mutation of m2. >> >> Mike >> >> On Nov 14 2012, at 05:38 , David Buck wrote: >> >>> Hi! >>> >>> This is a review request to add only the test case for the following OracleJDK issue: >>> >>> [ 7198904 : (alt-rt) TreeMap.clone is broken ] >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7198904 >>> >>> The issue (root cause) is not in OpenJDK (i.e. the problem was OracleJDK specific), but the test case is valid for both so it should go into OpenJDK so we can prevent a similar issue from ever happening in both releases moving forward. >>> >>> webrev: >>> >>> [ Code Review for jdk ] >>> http://cr.openjdk.java.net/~dbuck/7198904/webrev.00/ >>> >>> The OracleJDK fix (closed source) is ready and has already passed code review. I intend to push both the OracleJDK fix and this test case into their respective repositories at the same time once this review is done. >>> >>> Regards, >>> -Buck >> From mandy.chung at oracle.com Tue Nov 20 17:30:16 2012 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 20 Nov 2012 09:30:16 -0800 Subject: RFR: 8003322: Add instrumentation points for tracing of I/O calls In-Reply-To: <50AB91AE.4040909@oracle.com> References: <50A39388.8060502@oracle.com> <50AA0142.3080502@oracle.com> <28479F37-C81B-4CFB-811A-CEC45755B26B@oracle.com> <50AA279B.7060505@oracle.com> <7C9B7EE6-E9BB-4F4C-81BD-B8AECE689739@oracle.com> <50AB91AE.4040909@oracle.com> Message-ID: <50ABBE28.70907@oracle.com> On 11/20/12 6:20 AM, Alan Bateman wrote: > On 20/11/2012 14:10, Staffan Larsen wrote: >> : >> The original plan was for the code in this review to go into both 8 >> and 7u12. Since 7u12 has a tighter deadline, a possible path would be >> to include it only in 7u12, but not in 8. For 8 we would then >> implement a fully dynamic solution. The only thing needed in 8 from >> this review would be the path field added to the stream classes. Does >> that sound like a plan? >> > I think this is a good plan. I suggest bringing it up on jdk7u-dev so > that the jdk7u maintainers can think about the issue (rather that > trying to get approval at the last minute when you are reading to push). This sounds a good plan to me too. This would take the pressure off 7u12 deadline while a better solution will be implemented for 8. Mandy From robert.field at oracle.com Tue Nov 20 17:59:47 2012 From: robert.field at oracle.com (robert.field at oracle.com) Date: Tue, 20 Nov 2012 17:59:47 +0000 Subject: hg: jdk8/tl/langtools: 8003639: convert lambda testng tests to jtreg and add them Message-ID: <20121120175949.EAF1147A92@hg.openjdk.java.net> Changeset: d898d9ee352f Author: rfield Date: 2012-11-20 09:58 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/d898d9ee352f 8003639: convert lambda testng tests to jtreg and add them Reviewed-by: mcimadamore + test/tools/javac/defaultMethodExecution/DefaultMethodRegressionTests.java - test/tools/javac/defaultMethods/fd/FDTest.java - test/tools/javac/defaultMethods/fd/shapegen/ClassCase.java - test/tools/javac/defaultMethods/fd/shapegen/Hierarchy.java - test/tools/javac/defaultMethods/fd/shapegen/HierarchyGenerator.java - test/tools/javac/defaultMethods/fd/shapegen/Rule.java - test/tools/javac/defaultMethods/fd/shapegen/RuleGroup.java - test/tools/javac/defaultMethods/fd/shapegen/TTNode.java - test/tools/javac/defaultMethods/fd/shapegen/TTParser.java - test/tools/javac/defaultMethods/fd/shapegen/TTShape.java + test/tools/javac/lambda/lambdaExecution/InInterface.java + test/tools/javac/lambda/lambdaExecution/InnerConstructor.java + test/tools/javac/lambda/lambdaExecution/LambdaTranslationTest1.java + test/tools/javac/lambda/lambdaExecution/LambdaTranslationTest2.java + test/tools/javac/lambda/lambdaExecution/TBlock.java + test/tools/javac/lambda/lambdaExecution/TMapper.java + test/tools/javac/lambda/lambdaExecution/TPredicate.java + test/tools/javac/lambda/methodReferenceExecution/MethodReferenceTestFDCCE.java + test/tools/javac/lambda/methodReferenceExecution/MethodReferenceTestInnerDefault.java + test/tools/javac/lambda/methodReferenceExecution/MethodReferenceTestInnerInstance.java + test/tools/javac/lambda/methodReferenceExecution/MethodReferenceTestInnerVarArgsThis.java + test/tools/javac/lambda/methodReferenceExecution/MethodReferenceTestInstance.java + test/tools/javac/lambda/methodReferenceExecution/MethodReferenceTestKinds.java + test/tools/javac/lambda/methodReferenceExecution/MethodReferenceTestNew.java + test/tools/javac/lambda/methodReferenceExecution/MethodReferenceTestNewInner.java + test/tools/javac/lambda/methodReferenceExecution/MethodReferenceTestSueCase1.java + test/tools/javac/lambda/methodReferenceExecution/MethodReferenceTestSueCase2.java + test/tools/javac/lambda/methodReferenceExecution/MethodReferenceTestSueCase4.java + test/tools/javac/lambda/methodReferenceExecution/MethodReferenceTestSuper.java + test/tools/javac/lambda/methodReferenceExecution/MethodReferenceTestSuperDefault.java + test/tools/javac/lambda/methodReferenceExecution/MethodReferenceTestTypeConversion.java + test/tools/javac/lambda/methodReferenceExecution/MethodReferenceTestVarArgs.java + test/tools/javac/lambda/methodReferenceExecution/MethodReferenceTestVarArgsExt.java + test/tools/javac/lambda/methodReferenceExecution/MethodReferenceTestVarArgsSuper.java + test/tools/javac/lambda/methodReferenceExecution/MethodReferenceTestVarArgsSuperDefault.java + test/tools/javac/lambda/methodReferenceExecution/MethodReferenceTestVarArgsThis.java + test/tools/javac/lambdaShapes/TEST.properties + test/tools/javac/lambdaShapes/org/openjdk/tests/javac/FDTest.java + test/tools/javac/lambdaShapes/org/openjdk/tests/separate/AttributeInjector.java + test/tools/javac/lambdaShapes/org/openjdk/tests/separate/ClassFile.java + test/tools/javac/lambdaShapes/org/openjdk/tests/separate/ClassFilePreprocessor.java + test/tools/javac/lambdaShapes/org/openjdk/tests/separate/ClassToInterfaceConverter.java + test/tools/javac/lambdaShapes/org/openjdk/tests/separate/Compiler.java + test/tools/javac/lambdaShapes/org/openjdk/tests/separate/DirectedClassLoader.java + test/tools/javac/lambdaShapes/org/openjdk/tests/separate/SourceModel.java + test/tools/javac/lambdaShapes/org/openjdk/tests/separate/TestHarness.java + test/tools/javac/lambdaShapes/org/openjdk/tests/shapegen/ClassCase.java + test/tools/javac/lambdaShapes/org/openjdk/tests/shapegen/Hierarchy.java + test/tools/javac/lambdaShapes/org/openjdk/tests/shapegen/HierarchyGenerator.java + test/tools/javac/lambdaShapes/org/openjdk/tests/shapegen/Rule.java + test/tools/javac/lambdaShapes/org/openjdk/tests/shapegen/RuleGroup.java + test/tools/javac/lambdaShapes/org/openjdk/tests/shapegen/TTNode.java + test/tools/javac/lambdaShapes/org/openjdk/tests/shapegen/TTParser.java + test/tools/javac/lambdaShapes/org/openjdk/tests/shapegen/TTShape.java + test/tools/javac/lambdaShapes/org/openjdk/tests/vm/DefaultMethodsTest.java + test/tools/javac/lambdaShapes/org/openjdk/tests/vm/FDSeparateCompilationTest.java From jonathan.gibbons at oracle.com Wed Nov 21 18:54:35 2012 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Wed, 21 Nov 2012 18:54:35 +0000 Subject: hg: jdk8/tl/langtools: 7190862: javap shows an incorrect type for operands if the 'wide' prefix is used; ... Message-ID: <20121121185437.6EC0347AC4@hg.openjdk.java.net> Changeset: d9fe1f80515d Author: vromero Date: 2012-11-21 18:40 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/d9fe1f80515d 7190862: javap shows an incorrect type for operands if the 'wide' prefix is used 7109747: (javap) classfile not treating iinc_w correctly. Reviewed-by: jjg, mcimadamore ! src/share/classes/com/sun/tools/classfile/Instruction.java ! src/share/classes/com/sun/tools/classfile/Opcode.java + test/tools/javap/T7190862.java From jonathan.gibbons at oracle.com Wed Nov 21 19:54:43 2012 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Wed, 21 Nov 2012 19:54:43 +0000 Subject: hg: jdk8/tl/langtools: 6574624: javax.tools.JavaCompiler spec contains errors in sample code Message-ID: <20121121195445.6DE1847AC6@hg.openjdk.java.net> Changeset: 3746b071d75b Author: vromero Date: 2012-11-21 19:09 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/3746b071d75b 6574624: javax.tools.JavaCompiler spec contains errors in sample code Reviewed-by: jjg, mcimadamore ! src/share/classes/javax/tools/JavaCompiler.java From alexey.utkin at oracle.com Thu Nov 22 07:38:03 2012 From: alexey.utkin at oracle.com (Alexey Utkin) Date: Thu, 22 Nov 2012 11:38:03 +0400 Subject: Review request: JDK-7162111 TEST_BUG: change tests run in headless mode [macosx] (open part) In-Reply-To: <50AA6510.1040108@oracle.com> References: <50AA029C.3090301@oracle.com> <50AA257E.4070701@oracle.com> <50AA4832.60908@oracle.com> <50AA6510.1040108@oracle.com> Message-ID: <50ADD65B.9020502@oracle.com> Bug description: https://jbs.oracle.com/bugs/browse/JDK-7162111 Here is the suggested fix that contains the changes in JFrameCreateTime.java: http://cr.openjdk.java.net/~uta/openjdk-webrevs/JDK-7162111/webrev.02 JPRT results: http://prt-web.us.oracle.com//archive/2012/11/2012-11-21-165117.fritz.jdk/JobStatus.txt (no fails in modified tests) I take in account the AWT problem on Mac OS: in ssh session due to compatibility reason AWT switches to X11 toolkit if DISPLAY variable is defined. But Mac OS implementation of X11 toolkit has a deadlock/linkage problems. In JDK8 the X11 toolkit support is obsolete and problem would be resolved by AWT team. Regards, -uta On 19.11.2012 20:57, Alan Bateman wrote: > On 19/11/2012 14:54, Alexey Utkin wrote: >> Here is the updated version: >> >> http://cr.openjdk.java.net/~uta/openjdk-webrevs/JDK-7162111/webrev.01/ > In Foo.java then I assume Vector would be better. Well, I did the substitution that repeats the original. The Button class contains the base, not child-typed collection of the MouseListener instances (not Adapters). > > I don't think you can remove the javax/script/** tests from the > exclude list without adding -Djava.awt.headless=true to the @run tag > of each of those tests. > I did. It works. > Otherwise looks fine to me. > > -Alan From Alan.Bateman at oracle.com Thu Nov 22 08:41:54 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 22 Nov 2012 08:41:54 +0000 Subject: Review request: JDK-7162111 TEST_BUG: change tests run in headless mode [macosx] (open part) In-Reply-To: <50ADD65B.9020502@oracle.com> References: <50AA029C.3090301@oracle.com> <50AA257E.4070701@oracle.com> <50AA4832.60908@oracle.com> <50AA6510.1040108@oracle.com> <50ADD65B.9020502@oracle.com> Message-ID: <50ADE552.2090909@oracle.com> On 22/11/2012 07:38, Alexey Utkin wrote: > : > > I take in account the AWT problem on Mac OS: > in ssh session due to compatibility reason AWT switches to X11 > toolkit if DISPLAY variable is defined. > But Mac OS implementation of X11 toolkit has a deadlock/linkage problems. > In JDK8 the X11 toolkit support is obsolete and problem would be > resolved by AWT team. Alexey - can you explain this comment a bit further? Are you saying that the X11 support has been removed or will be removed? We've had major grief get automated testing running on Mac OSX and I would prefer not to remove the tests from the ProblemList until we are confident that the AWT deadlock issue has been resolved. -Alan From alexey.utkin at oracle.com Thu Nov 22 09:12:48 2012 From: alexey.utkin at oracle.com (Alexey Utkin) Date: Thu, 22 Nov 2012 13:12:48 +0400 Subject: Review request: JDK-7162111 TEST_BUG: change tests run in headless mode [macosx] (open part) In-Reply-To: <50ADE552.2090909@oracle.com> References: <50AA029C.3090301@oracle.com> <50AA257E.4070701@oracle.com> <50AA4832.60908@oracle.com> <50AA6510.1040108@oracle.com> <50ADD65B.9020502@oracle.com> <50ADE552.2090909@oracle.com> Message-ID: <50ADEC90.4020204@oracle.com> On 22.11.2012 12:41, Alan Bateman wrote: > On 22/11/2012 07:38, Alexey Utkin wrote: >> : >> >> I take in account the AWT problem on Mac OS: >> in ssh session due to compatibility reason AWT switches to X11 >> toolkit if DISPLAY variable is defined. >> But Mac OS implementation of X11 toolkit has a deadlock/linkage problems. >> In JDK8 the X11 toolkit support is obsolete and problem would be >> resolved by AWT team. > Alexey - can you explain this comment a bit further? Are you saying > that the X11 support has been removed or will be removed? We've had > major grief get automated testing running on Mac OSX and I would > prefer not to remove the tests from the ProblemList until we are > confident that the AWT deadlock issue has been resolved. In accordance with the AWT plan the support for X11 toolkit on Mac OS has to be removed. As a result the issues in that part of code are frozen. In fact the most of work is already done, except the border cases similar to described in the comment. More over, seems that it is the only case with problem (falldown to X11 toolkit without switches in command line for very specific environment). The best choice would be the ban for DISPLAY variable setup on JPRT computers as temporary solution. AWT deadlock issue for X11 toolkit on Mac OS will not be resolved, instead, X11 toolkit will be forbidden for Mac OS. > > -Alan From Alan.Bateman at oracle.com Thu Nov 22 09:57:07 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 22 Nov 2012 09:57:07 +0000 Subject: Review request: JDK-7162111 TEST_BUG: change tests run in headless mode [macosx] (open part) In-Reply-To: <50ADD65B.9020502@oracle.com> References: <50AA029C.3090301@oracle.com> <50AA257E.4070701@oracle.com> <50AA4832.60908@oracle.com> <50AA6510.1040108@oracle.com> <50ADD65B.9020502@oracle.com> Message-ID: <50ADF6F3.5070500@oracle.com> On 22/11/2012 07:38, Alexey Utkin wrote: > Bug description: > https://jbs.oracle.com/bugs/browse/JDK-7162111 > > Here is the suggested fix that contains the changes in > JFrameCreateTime.java: > http://cr.openjdk.java.net/~uta/openjdk-webrevs/JDK-7162111/webrev.02 The changes to test/java/io/Serializable/resolveClass/* looks fine for me. On JFrameCreateTime.java then I wonder if the headless check should be in TraceJFrame instead. I suspect this because JFrameCreateTime is the "target app" that is traced. Either way, I'm curious why Throwable is caught I looked at GraphicsEnvironment.getLocalGraphicsEnvironment() and isHeadlessInstance() and neither is specified to throw anything, I'm just curious what we are catching and recovering from, an Error perhaps? -Alan. From rob.mckenna at oracle.com Thu Nov 22 16:36:44 2012 From: rob.mckenna at oracle.com (Rob McKenna) Date: Thu, 22 Nov 2012 16:36:44 +0000 Subject: Request for review: 7173494: some jdk tests are not run in test/Makefile Message-ID: <50AE549C.8010701@oracle.com> Hi folks, Looking to backport these changes to the test makefiles to jdk7. As per Alans original mail: "This one is a small clean-up of the test targets defined in jdk/test/Makefile. The union of the tests executed by each of the make targets should be the entire test suite but this isn't so, there are small number of tests that aren't run. I've renamed jdk_misc to jdk_other (the original name is confusing because of sun.misc) and expanded it to run additional areas that have a small number of tests. If more tests are added to these areas over time then it may make sense to add new targets in the future. "make jdk_jmx" now runs the JMX tests as it was confusing to have those tests split between management1 and management2. I've also renamed jdk_tools1 to jdk_jdi to make it clear that this is the JDI tests rather than tools. When Kelly originally set this up he split the NIO tests into 3 batches, I don't think this is necessary any longer (the really slow tests have been long been dialed down or changed to run much faster). " The tl folder refers to the forest root, the jdk folder refers to the jdk repo. http://cr.openjdk.java.net/~robm/7173494/ ( 8 changesets: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3b79177ebfef http://hg.openjdk.java.net/jdk8/tl/rev/4bde5640fb36 ) -Rob From rob.mckenna at oracle.com Thu Nov 22 21:27:13 2012 From: rob.mckenna at oracle.com (Rob McKenna) Date: Thu, 22 Nov 2012 21:27:13 +0000 Subject: Request for Review: 5049299: (process) Use posix_spawn, not fork, on S10 to avoid swap exhaustion Message-ID: <50AE98B1.2040200@oracle.com> Hi folks, Looking for a review for the webrev below, which also resolves: 7175692: (process) Process.exec should use posix_spawn [macosx] For additional context and a brief description it would be well worth looking at the following thread started by Michael McMahon, who did the brunt of the work for this fix: http://mail.openjdk.java.net/pipermail/core-libs-dev/2009-May/thread.html#1644 Basically the fix aims to swap fork for posix_spawn as the default process launch mechanism on Solaris and Mac OSX in order to avoid swap exhaustion issues encountered with fork()/exec(). It also offers a flag (java.lang.useFork) to allow a user to revert to the old behaviour. I'm having trouble seeing the wood for the trees at this point so I'm anticipating plenty of feedback. In particular I'd appreciate some discussion on: - The binary launcher name & property name may need some work. A more general property ("java.lang.launchMechanism") to allow a user to specify a particular call was mooted too. It may be more future proof and I'm completely open to that. (e.g. launchMechanism=spawn|fork|vfork|clone - we would obviously ignore inapplicable values on a per-platform basis) - I'd like a more robust way of checking that someone isn't trying to use jprochelper outside of the context for which it is meant. - The decision around which call to use getting moved to the java level and away from the native preprocessor. The webrev is at: http://cr.openjdk.java.net/~robm/5049299/webrev.01/ Thanks a lot, -Rob From weijun.wang at oracle.com Fri Nov 23 04:20:03 2012 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 23 Nov 2012 12:20:03 +0800 Subject: Canonical path for /ssss/../../ ? Message-ID: <50AEF973.2080202@oracle.com> I've seen something weird on Linux: new File("/ssss/../").getCanonicalFile()' = / new File("/ssss/../../").getCanonicalFile()' = /.. new File("/ssss/../../../").getCanonicalFile()' = / new File("/ssss/../../../../").getCanonicalFile()' = /.. and new File("/ssss/../..").getCanonicalFile().getCanonicalFile() = / Is "/.." canonical? Shouldn't getCanonicalFile() be idempotent? Thanks Max From youdwei at linux.vnet.ibm.com Fri Nov 23 08:07:22 2012 From: youdwei at linux.vnet.ibm.com (Deven You) Date: Fri, 23 Nov 2012 16:07:22 +0800 Subject: javax.sql.rowset.serial.SerialBlob doesn't support free and getBinaryStream In-Reply-To: References: <4FE81ED6.7020909@linux.vnet.ibm.com> <4FF16425.9070308@linux.vnet.ibm.com> <40E34C07-424B-4569-8BCA-82AECEB865CB@oracle.com> <4FF533A4.80808@linux.vnet.ibm.com> <97CD7D6F-DEF1-43B0-A529-54628081EED6@oracle.com> <505BDD2A.40206@linux.vnet.ibm.com> <505C2738.50206@oracle.com> <508E3596.3070705@linux.vnet.ibm.com> Message-ID: <50AF2EBA.1050109@linux.vnet.ibm.com> Hi Lance, Is there any plan for this issue, if any could you update to me? Thanks a lot! On 10/29/2012 06:39 PM, Lance Andersen - Oracle wrote: > Hi Deven, > > I will address the needed updates a bit later. > > Thank you for your input > > Best > Lance > On Oct 29, 2012, at 3:51 AM, Deven You wrote: > >> Hi Alan, >> >> The Java Spec does not mention the thread safe for JDBC API. But I see the other code in SerialBlob/SerialClob have not consider it. >> >> I think use buff == null to replace isFree is a good idea because it also avoid the problem for the condition buf == null && isFree == false so we won't need create a readObject method. >> >> Thanks for your suggestion for isFree, I will correct it later. >> >> Lance: How about your suggestion? Since you mentioned you will develop the implementation yourself. I use my implementation mainly for the test cases. But you may also take a look my implementation. >> >> Thanks a lot! >> >> On 09/21/2012 04:37 PM, Alan Bateman wrote: >>> On 21/09/2012 04:21, Deven You wrote: >>>> Hi Lance, >>>> >>>> I am very busy with other work so I can't work with the SerialBlob/SerialClob item for long time. I am very happy to refine the current test case and create new tests for SerialClob. >>>> >>>> I have create a new webre[1] for this task, please review it. >>>> >>>> [1] http://cr.openjdk.java.net/~youdwei/OJDK-576/webrev.01/ >>>> >>>> PS: If the isFree is not transient, I want to know how we add this field to the javadoc serialized form? >>> I don't know very much about the rowset API and I can't see anything to specify whether it is meant to be safe for use by concurrent threads. There are clearly lots of issues here and implementing free introduces a lot more, especially with the possibility of an asynchronous free or more than one thread calling free at around the same time. >>> >>> Have you considered "buf == null" to mean that the resources are freed? That might avoid needing to change the serialized form. Also as these types are serializable it means you have to consider the case where you deserialize to buf == null && isFree == false for example. On that point, it looks to me that this code needs a readObject anyway (for several reasons). >>> >>> A small point is that "isFree" is a odd name for a method that doesn't return a boolean. If the patch goes ahead then I think it needs a better name, ensureNotFree or requireNotFree or something like that. >>> >>> -Alan. >>> > > > 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 alexey.utkin at oracle.com Fri Nov 23 09:09:48 2012 From: alexey.utkin at oracle.com (alexey.utkin at oracle.com) Date: Fri, 23 Nov 2012 09:09:48 +0000 Subject: hg: jdk8/tl/jdk: 8003898: X11 toolkit can be chosen as the default toolkit Message-ID: <20121123091008.A675F47AEF@hg.openjdk.java.net> Changeset: ee6e5b7d5d55 Author: uta Date: 2012-11-23 13:07 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ee6e5b7d5d55 8003898: X11 toolkit can be chosen as the default toolkit Summary: XToolkit is not selected for any values of system-wide environment variables (ex. DISPLAY). Reviewed-by: anthony, art ! src/solaris/native/java/lang/java_props_macosx.c From Alan.Bateman at oracle.com Fri Nov 23 09:47:56 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 23 Nov 2012 09:47:56 +0000 Subject: hg: jdk8/tl/jdk: 8003898: X11 toolkit can be chosen as the default toolkit In-Reply-To: <20121123091008.A675F47AEF@hg.openjdk.java.net> References: <20121123091008.A675F47AEF@hg.openjdk.java.net> Message-ID: <50AF464C.8020902@oracle.com> On 23/11/2012 09:09, alexey.utkin at oracle.com wrote: > Changeset: ee6e5b7d5d55 > Author: uta > Date: 2012-11-23 13:07 +0400 > URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ee6e5b7d5d55 > > 8003898: X11 toolkit can be chosen as the default toolkit > Summary: XToolkit is not selected for any values of system-wide environment variables (ex. DISPLAY). > Reviewed-by: anthony, art > > ! src/solaris/native/java/lang/java_props_macosx.c > Thank you, it's great to have this fix in jdk8/tl, it means we should now finally be able to un-exclude all those tests that you proposed in your earlier webrev. -Alan From alexey.utkin at oracle.com Fri Nov 23 10:40:20 2012 From: alexey.utkin at oracle.com (Alexey Utkin) Date: Fri, 23 Nov 2012 14:40:20 +0400 Subject: Review request: JDK-7162111 TEST_BUG: change tests run in headless mode [macosx] (open part - ver. 3) In-Reply-To: <50ADF6F3.5070500@oracle.com> References: <50AA029C.3090301@oracle.com> <50AA257E.4070701@oracle.com> <50AA4832.60908@oracle.com> <50AA6510.1040108@oracle.com> <50ADD65B.9020502@oracle.com> <50ADF6F3.5070500@oracle.com> Message-ID: <50AF5294.6090405@oracle.com> The sub-task JDK-8003898 (X11 toolkit can be chosen as the default toolkit) was resolved. New version that takes it into account (changes in TraceJFrame.java): http://cr.openjdk.java.net/~uta/openjdk-webrevs/JDK-7162111/webrev.03/ On 22.11.2012 13:57, Alan Bateman wrote: > On 22/11/2012 07:38, Alexey Utkin wrote: >> Bug description: >> https://jbs.oracle.com/bugs/browse/JDK-7162111 >> >> Here is the suggested fix that contains the changes in >> JFrameCreateTime.java: >> http://cr.openjdk.java.net/~uta/openjdk-webrevs/JDK-7162111/webrev.02 > The changes to test/java/io/Serializable/resolveClass/* looks fine for me. > > On JFrameCreateTime.java then I wonder if the headless check should be > in TraceJFrame instead. I suspect this because JFrameCreateTime is the > "target app" that is traced. Either way, I'm curious why Throwable is > caught I looked at GraphicsEnvironment.getLocalGraphicsEnvironment() > and isHeadlessInstance() and neither is specified to throw anything, > I'm just curious what we are catching and recovering from, an Error > perhaps? > Done. > -Alan. From Alan.Bateman at oracle.com Fri Nov 23 10:58:07 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 23 Nov 2012 10:58:07 +0000 Subject: Review request: JDK-7162111 TEST_BUG: change tests run in headless mode [macosx] (open part - ver. 3) In-Reply-To: <50AF5294.6090405@oracle.com> References: <50AA029C.3090301@oracle.com> <50AA257E.4070701@oracle.com> <50AA4832.60908@oracle.com> <50AA6510.1040108@oracle.com> <50ADD65B.9020502@oracle.com> <50ADF6F3.5070500@oracle.com> <50AF5294.6090405@oracle.com> Message-ID: <50AF56BF.1070804@oracle.com> On 23/11/2012 10:40, Alexey Utkin wrote: > The sub-task JDK-8003898 (X11 toolkit can be chosen as the default > toolkit) was resolved. > New version that takes it into account (changes in TraceJFrame.java): > http://cr.openjdk.java.net/~uta/openjdk-webrevs/JDK-7162111/webrev.03/ > This looks good to me. Do you mind leaving in the jdk_io header in ProblemList? It just makes it obvious to people where to list tests as we've already tried to group them by area (no need to generate a new webrev for this of course). -Alan From peter.levart at gmail.com Fri Nov 23 11:08:32 2012 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 23 Nov 2012 12:08:32 +0100 Subject: bottleneck by java.lang.Class.getAnnotations() - a better patch In-Reply-To: <509A3A63.5010102@gmail.com> References: <924D06EC-F603-4E6A-A7FE-7A05C77B1217@gmail.com> <23313EDE-3AB7-4E53-8EB1-A6F6CC9383B9@gmail.com> <5093A8D3.4030800@gmail.com> <5096CFBD.2010604@gmail.com> <5096F5B0.8070304@gmail.com> <50974D3D.1040502@oracle.com> <50990CB8.2040400@gmail.com> <5099C2FA.2020202@oracle.com> <509A3A63.5010102@gmail.com> Message-ID: <50AF5930.5010903@gmail.com> Hi David, Alan, Alexander and others, Here's a refinement of a patch I proposed in this thread a couple of weeks ago: http://dl.dropbox.com/u/101777488/jdk8-hacks/JEP-149/webrev.02/index.html The changed sources can be browsed here: https://github.com/plevart/jdk8-hacks/tree/annotation-arrays/src/java/lang The main improvement is the replacement of a filed: Map, Annotation> declaredAnnotations; with plain: Annotation[] declaredAnnotations; ...in the Class.VolatileData structure. It can be seen from the public API that caching a HashMap of declared annotations is never needed since the only public method (getDeclaredAnnotations()) returns an array. Therefore it is much more efficient to cache the array and only clone it on every public method invocation. Unfortunately it is not so with "annotations" field. There is a public method (getAnnotation(Class)) that has O(1) time complexity because of keeping a HashMap in the cache. I did an experiment with keeping annotations (declared + inherited) in an array, sorted by the hashCode of annotationType and the lookup then was a binary search by hashCode of annotationType followed by linear search of the equal hashCode neighborhood. This has O(log N) time complexity, which is not so bad, but the constant factor was pretty high because invoking Annotation.annotationType() method goes through dynamic Proxy to an InvocationHandler... Speaking of that, I think there's plenty of opportunity for JEP-149 related optimization in the field of annotations. For example, generating a special class for every annotationType that would hold it's own annotation data and answer to method requests directly would give a large time and space gain. It can also be noticed that there's a discrepancy of how lookup is implemented for example: - lookup of Annotation by annotationType on a class is a HashMap.get() which has O(1) time complexity - lookup of a of Field by fieldName on a class is a linear search in an array which has O(N) time complexity - similar for Method by methodName and argumentTypes - O(N) The time complexity improvement for Field and Method lookup could be performed by keeping some cached arrays pre-sorted by the name of Field or Method and employing a binary search to locate or almost-locate the object. Since public API explicitly states that methods returning arrays of Fields and Methods do not specify any order, pre-sorting the arrays would not break the contract. Regards, Peter On 11/07/2012 11:39 AM, Peter Levart wrote: > On 11/07/2012 03:10 AM, David Holmes wrote: >> Hi Peter, >> >> The movement of the reflection caches to a helper object is exactly >> what I had previously proposed here (some differences in the details >> of course): >> >> http://cr.openjdk.java.net/~dholmes/JEP-149/webrev/ >> >> and discussed here: >> >> http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-April/009749.html >> >> >> but this did not touch the annotations fields. >> >> David > > Hi David, > > Thanks for the pointer. There is a discussion between Brian and you > (to quote some of it): > > On 5/04/2012 1:28 PM, Brian Goetz wrote: > >/ Reducing the number of SoftReferences in ReflectionHelper also seems an > />/ attractive target for memory reduction. Rather than eight soft > />/ references (eight extra objects), maintaining a SoftRef to the entire > />/ RH, or at least to the part of the RH that is currently SR'ed if the two > />/ non-SR'ed fields can't be recomputed, would save you a whole pile of > />/ objects per class (and might also reduce pressure on GC, having 8x fewer > />/ SRs to process.) > / > I'd have to consider the intended semantics of these soft references > before considering any change here. It would hard to predict how this > might impact runtime performance if we have coarser-grained soft > references. The current changes should be semantically null. > > >/ Finally, you may be able save an extra field per Class by storing the > />/ ReflectionHelper in a ClassValue on Java SE 8, rather than a field. > / > ClassValue is something I'm keeping an eye on, but an entry in > ClassValue is going to consume more dynamic memory than a single direct > field. > > Thanks, > David > > > ...the 8 SoftReferences refer to arrays which are never hard > referenced by the outside world (arrays are always defensively > copied), so it's reasonable to expect that all SoftReferences would be > cleared at the same time anyway. And if 8 SoftReferences are replaced > with 1, the worst case scenario (to quote Hinkmond Wong): > > Hi Brian, > > One of the issues we have in the Java Embedded group (as David points > out in his summary), is that while on paper the theoretical max savings > seems great (as you point out also), in practice as David points out in > his note, this might be a wash if there are a lot more reflection using > classes vs. non-reflection using classes in "typical" real-world > applications, not the low or zero reflection using class ratio that > happens in the theoretical "best case". > > So, a question comes up if we should judge the merit of this change on > the theoretical "best case" scenario, or should we judge it on > real-world applicability to "typical" apps (such as a finite set of > customer surveyed embedded apps that we feel represent a real-world > scenario). > > > Thanks, > Hinkmond > > > ...actually becomes even more favourable. We reduce huge overhead > (each SoftReference is 4 OOPs and 1 long). And if this single > SoftReference is ever cleared, more memory is released - the whole > structure (ReflectionHelper / VolatileData) > > Other differences in details between your proposal and mine: > > In your proposal, the method ReflectionHelper rh() is equivalent to > mine VolatileData volatileData() - it lazily constructs the structure > and returns it. My implementation also incorporates the logic of > clearCachesOnClassRedefinition() by returning and installing a new > instance of the structure in case a redefinition is detected. This has > a profound impact on the correctness of the cached data in face of > races that can occur. > > In your proposal, even if the VM could atomically publish changes to > raw reflection data and the classRedefinitionCount at the same time > (we hope that at least the order of publishing is such that > classRedefinitionCount is updated last), it can theoretically be that > 2 or more redefinitions of the same class happen in close proximity: > > VM thread: redefines the class to version=1 > thread 1: clears the cache and takes version=1 raw data and computes > derived data but gets pre-empted before installing it > VM thread: redefines the class to version=2 > thread 2: clears the cache and takes version=2 raw data and computes > derived data and installs it > thread 1: ...gets back and installs version=1 derived data over > version=2 data > > ...if there are no more class redefinitions, the stale version of > derived data can persist indefinitely. > > In my proposal, each thread will get it's own copy of the structure in > the above scenario and install the derived data into it. It can happen > that a particular instance of the structure does not represent a > "snapshot" view of the world, but that is not important, since that > particular inconsistent instance is only used for the in-flight call > and only in that part that is consistent. Other callers will get a > fresh instance. > > There is also one thing I overlooked and you haven't: the > cachedConstructor and newInstanceCallerCache fields. > > I'll have to look at how to incorporate them into my scheme. They are > currently neither SoftReferenced nor cleared at class redefinition. As > the cachedConstructor is only used to implement the .newInstance() > method, I wonder if it is safe not to clear it when the class is > redefined. Are old versions of Constructors still valid for invoking > in a redefined class? I guess they must be, since user code is free to > cache it's own versions and class redefinition should not prevent > invoking them... > > Since cachedConstructor/newInstanceCallerCache are used to optimize > .newInstance() method. That alone suggests that calling this method is > more common use-case than others. Perhaps leaving this pair of fields > out of the game is a better approach space-saving wise. > > Regards, Peter > >> >> On 6/11/2012 11:12 PM, Peter Levart wrote: >>> On 11/05/2012 06:23 AM, David Holmes wrote: >>>> Hi Peter, >>>> >>>> Moving the annotations fields into a helper object would tie in with >>>> the Class-instance size reduction effort that was investigated as part >>>> of "JEP 149: Reduce Core-Library Memory Usage": >>>> >>>> http://openjdk.java.net/jeps/149 >>>> >>>> The investigations there to date only looked at relocating the >>>> reflection related fields, though the JEP mentions the annotations as >>>> well. >>>> >>>> Any such effort requires extensive benchmarking and performance >>>> analysis before being accepted though. >>>> >>>> David >>>> ----- >>>> >>> >>> On 11/05/2012 10:25 AM, Alan Bateman wrote: >>>> Here's a good starting place on the interaction of runtime visible >>>> attributes and RedefineClasses/RetransformClasses: >>>> >>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5002251 >>>> >>>> -Alan. >>> >>> Hi all, >>> >>> Presented here is a patch mainly against java.lang.Class and also >>> against java.lang.reflect.[Field,Method,Constructor,Executable] >>> classes. >>> >>> Currently java.lang.Class uses the following fields to maintain caches >>> of reflection data that are invalidated as a result of class or >>> superclass redefinition/re-transformation: >>> >>> private volatile transient SoftReference declaredFields; >>> private volatile transient SoftReference publicFields; >>> private volatile transient SoftReference declaredMethods; >>> private volatile transient SoftReference publicMethods; >>> private volatile transient SoftReference[]> >>> declaredConstructors; >>> private volatile transient SoftReference[]> >>> publicConstructors; >>> private volatile transient SoftReference declaredPublicFields; >>> private volatile transient SoftReference >>> declaredPublicMethods; >>> >>> // Value of classRedefinedCount when we last cleared the cached values >>> // that are sensitive to class redefinition. >>> private volatile transient int lastRedefinedCount = 0; >>> >>> // Annotations cache >>> private transient Map, Annotation> >>> annotations; >>> private transient Map, Annotation> >>> declaredAnnotations; >>> >>> If I understand Alan's references correctly, current VM can redefine >>> the >>> class in a way that changes method bodies. Also new methods can be >>> added. And the set of annotations can also be altered. And future >>> improvements could allow even more. >>> >>> Because annotations are cached on Field/Method/Constructor instances, >>> all the above fields must be invalidated when the class or >>> superclass is >>> redefined. >>> >>> It can also be observed that Field/Method/Constructor caches are >>> maintained using SoftReferences but annotations are hard references. I >>> don't know if this is intentional. I believe that annotations could >>> also >>> be SoftReferenced, so that in the event of memory pressure they get >>> cleared. Many applications retrieve annotations only in the early >>> stages >>> of their life-cycle and then either cache them themselves or forget >>> about them. >>> >>> So I designed the patch to equalize this. If this is undesirable, the >>> patch could be modified to make a distinction again. >>> >>> The patch replaces the above-mentioned java.lang.Class fields with a >>> single field: >>> >>> private volatile transient SoftReference> volatileData; >>> >>> ...which is a SoftReference to the following structure: >>> >>> // volatile data that might get invalid when JVM TI >>> RedefineClasses() is >>> called >>> static class VolatileData { >>> volatile Field[] declaredFields; >>> volatile Field[] publicFields; >>> volatile Method[] declaredMethods; >>> volatile Method[] publicMethods; >>> volatile Constructor[] declaredConstructors; >>> volatile Constructor[] publicConstructors; >>> // Intermediate results for getFields and getMethods >>> volatile Field[] declaredPublicFields; >>> volatile Method[] declaredPublicMethods; >>> // Annotations >>> volatile Map, Annotation> annotations; >>> volatile Map, Annotation> >>> declaredAnnotations; >>> // Value of classRedefinedCount when we created this VolatileData >>> instance >>> final int redefinedCount; >>> >>> So let's look at static overhead differences using 64 bit addressing >>> (useful load - arrays, Maps not counted since the patched code uses the >>> same amount of same types of each). >>> >>> * Fresh java.lang.Class instance: >>> >>> current JDK8 code: >>> >>> 10 OOPs + 1 int = 10*8+4 = 84 bytes in 1 instance >>> >>> vs. patched code : >>> >>> 1 OOP = 8 bytes in 1 instance >>> >>> * Fully loaded java.lang.Class (Fields, Methods, Constructors, >>> annotations): >>> >>> current JDK8 code: >>> >>> 10 OOPs + 1 int = 84 bytes >>> 8 SoftReference instances = 8*(header + 4 OOPs + 1 long) = >>> 8*(24+32+8) = >>> 8*64 = 512 bytes >>> total: 84+512 = 596 bytes in 9 instances >>> >>> vs. patched code : >>> >>> 1 OOP = 8 bytes >>> 1 SoftReference = 64 bytes >>> 1 VolatileData = header + 10 OOPs + 1 int = 24+84 = 108 bytes >>> total: 8+64+108 = 180 bytes in 3 instances >>> >>> So we have 84 vs. 8 (empty) or 596 vs. 180 (fully loaded) byte >>> overheads and >>> 1 vs. 1 (empty) or 9 vs. 3 (fully loaded) instance overheads >>> >>> Other than that, the patch also removes synchronized blocks for lazy >>> initialization of annotations in Class, Field, Method and Constructor >>> and replaces them with volatile fields. In case of Class.volatileData, >>> this field is initialized using a CAS so there is no race which could >>> install an already stale instance over more recent. Although such race >>> would quickly be corrected at next call to any retrieval method, >>> because >>> redefinedCount is now an integral part of the cached structure not an >>> individual volatile field. >>> >>> There is also a change in how annotations are cached in Field, Method >>> and Constructor. Originally they are cached in each copy of the >>> Field/Method/Constructor that is returned to the outside world at each >>> invocation of Class.getFields() etc. Such caching is not very effective >>> if the annotations are only retrieved once per instance. The patch >>> changes this and delegates caching to the "root" instance which is held >>> inside Class so caching becomes more effective in certain usage >>> patterns. There's now a possible hot-spot on the "root" instance but >>> that seems not to be a bottleneck since the fast-path does not involve >>> blocking synchronization (just volatile read). The effects of this >>> change are clearly visible in one of the benchmarks. >>> >>> I have tried to create 3 micro benchmarks which exercise concurrent >>> load >>> on 3 Class instances. >>> >>> Here's the benchmark code: >>> >>> https://raw.github.com/plevart/jdk8-hacks/master/src/test/ReflectionTest.java >>> >>> >>> And here are the results when run on an Intel i7 CPU (4 cores, 2 >>> threads/core) Linux machine using -Xmx4G VM option: >>> >>> https://raw.github.com/plevart/jdk8-hacks/master/benchmark_results.txt >>> >>> >>> The huge difference of Test1 results is a direct consequence of patched >>> code delegating caching of annotations in Field/Method/Constructor to >>> the "root" instance. >>> >>> Test2 results show no noticeable difference between original and >>> patched >>> code. This, I believe, is the most common usage of the API, so another >>> level of indirection does not appear to present any noticeable >>> performance overhead. >>> >>> The Test3 on the other hand shows the synchronization overhead of >>> current jdk8 code in comparison with non-blocking synchronization in >>> patched code. >>> >>> JEP 149 also mentions testing with SPECjbb2005 and SPECjvm98, but that >>> exceeds my possibilities. >>> >>> The patch against jdk8/jdk8/jdk hg repository is here: >>> >>> https://raw.github.com/plevart/jdk8-hacks/master/volatile_class_data_caching.patch >>> >>> >>> You can also browse the changed sources: >>> >>> https://github.com/plevart/jdk8-hacks >>> >>> >>> Regards, Peter >>> From Alan.Bateman at oracle.com Fri Nov 23 11:22:44 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 23 Nov 2012 11:22:44 +0000 Subject: Request for review: 7173494: some jdk tests are not run in test/Makefile In-Reply-To: <50AE549C.8010701@oracle.com> References: <50AE549C.8010701@oracle.com> Message-ID: <50AF5C84.40305@oracle.com> On 22/11/2012 16:36, Rob McKenna wrote: > Hi folks, > > Looking to backport these changes to the test makefiles to jdk7. As > per Alans original mail: > > "This one is a small clean-up of the test targets defined in > jdk/test/Makefile. The union of the tests executed by each of the make > targets should be the entire test suite but this isn't so, there are > small number of tests that aren't run. > > I've renamed jdk_misc to jdk_other (the original name is confusing > because of sun.misc) and expanded it to run additional areas that have > a small number of tests. If more tests are added to these areas over > time then it may make sense to add new targets in the future. > > "make jdk_jmx" now runs the JMX tests as it was confusing to have > those tests split between management1 and management2. I've also > renamed jdk_tools1 to jdk_jdi to make it clear that this is the JDI > tests rather than tools. When Kelly originally set this up he split > the NIO tests into 3 batches, I don't think this is necessary any > longer (the really slow tests have been long been dialed down or > changed to run much faster). " > > The tl folder refers to the forest root, the jdk folder refers to the > jdk repo. > > http://cr.openjdk.java.net/~robm/7173494/ > > ( 8 changesets: > > http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3b79177ebfef > http://hg.openjdk.java.net/jdk8/tl/rev/4bde5640fb36 ) > > -Rob This looks okay to me, at least I don't see anything obviously different to the changes that we have in 8. I assume you will test these changes well before pushing them as it's very easy to get the configuration wrong. -Alan From alexey.utkin at oracle.com Fri Nov 23 11:22:40 2012 From: alexey.utkin at oracle.com (Alexey Utkin) Date: Fri, 23 Nov 2012 15:22:40 +0400 Subject: Review request: JDK-7162111 TEST_BUG: change tests run in headless mode [macosx] (open part - ver. 3) In-Reply-To: <50AF56BF.1070804@oracle.com> References: <50AA029C.3090301@oracle.com> <50AA257E.4070701@oracle.com> <50AA4832.60908@oracle.com> <50AA6510.1040108@oracle.com> <50ADD65B.9020502@oracle.com> <50ADF6F3.5070500@oracle.com> <50AF5294.6090405@oracle.com> <50AF56BF.1070804@oracle.com> Message-ID: <50AF5C80.4000607@oracle.com> On 23.11.2012 14:58, Alan Bateman wrote: > On 23/11/2012 10:40, Alexey Utkin wrote: >> The sub-task JDK-8003898 (X11 toolkit can be chosen as the default >> toolkit) was resolved. >> New version that takes it into account (changes in TraceJFrame.java): >> http://cr.openjdk.java.net/~uta/openjdk-webrevs/JDK-7162111/webrev.03/ >> > This looks good to me. > > Do you mind leaving in the jdk_io header in ProblemList? It just makes > it obvious to people where to list tests as we've already tried to > group them by area (no need to generate a new webrev for this of course). I do not know the policy for such a case. If you like to remove the jdk_io header in ProblemList, I will. -uta > -Alan From Alan.Bateman at oracle.com Fri Nov 23 11:24:36 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 23 Nov 2012 11:24:36 +0000 Subject: Review request: JDK-7162111 TEST_BUG: change tests run in headless mode [macosx] (open part - ver. 3) In-Reply-To: <50AF5C80.4000607@oracle.com> References: <50AA029C.3090301@oracle.com> <50AA257E.4070701@oracle.com> <50AA4832.60908@oracle.com> <50AA6510.1040108@oracle.com> <50ADD65B.9020502@oracle.com> <50ADF6F3.5070500@oracle.com> <50AF5294.6090405@oracle.com> <50AF56BF.1070804@oracle.com> <50AF5C80.4000607@oracle.com> Message-ID: <50AF5CF4.5040003@oracle.com> On 23/11/2012 11:22, Alexey Utkin wrote: > On 23.11.2012 14:58, Alan Bateman wrote: >> On 23/11/2012 10:40, Alexey Utkin wrote: >>> The sub-task JDK-8003898 (X11 toolkit can be chosen as the default >>> toolkit) was resolved. >>> New version that takes it into account (changes in TraceJFrame.java): >>> http://cr.openjdk.java.net/~uta/openjdk-webrevs/JDK-7162111/webrev.03/ >>> >> This looks good to me. >> >> Do you mind leaving in the jdk_io header in ProblemList? It just >> makes it obvious to people where to list tests as we've already tried >> to group them by area (no need to generate a new webrev for this of >> course). > I do not know the policy for such a case. If you like to remove the > jdk_io header in ProblemList, I will. I would prefer if you left it in the file (you'll see other examples in there where we leave a header as a placeholder so that folks know where to list the tests). -Alan From alexey.utkin at oracle.com Fri Nov 23 11:40:52 2012 From: alexey.utkin at oracle.com (Alexey Utkin) Date: Fri, 23 Nov 2012 15:40:52 +0400 Subject: Review request: JDK-7162111 TEST_BUG: change tests run in headless mode [macosx] (open part - ver. 3) In-Reply-To: <50AF5CF4.5040003@oracle.com> References: <50AA029C.3090301@oracle.com> <50AA257E.4070701@oracle.com> <50AA4832.60908@oracle.com> <50AA6510.1040108@oracle.com> <50ADD65B.9020502@oracle.com> <50ADF6F3.5070500@oracle.com> <50AF5294.6090405@oracle.com> <50AF56BF.1070804@oracle.com> <50AF5C80.4000607@oracle.com> <50AF5CF4.5040003@oracle.com> Message-ID: <50AF60C4.4090006@oracle.com> On 23.11.2012 15:24, Alan Bateman wrote: > On 23/11/2012 11:22, Alexey Utkin wrote: >> On 23.11.2012 14:58, Alan Bateman wrote: >>> On 23/11/2012 10:40, Alexey Utkin wrote: >>>> The sub-task JDK-8003898 (X11 toolkit can be chosen as the default >>>> toolkit) was resolved. >>>> New version that takes it into account (changes in TraceJFrame.java): >>>> http://cr.openjdk.java.net/~uta/openjdk-webrevs/JDK-7162111/webrev.03/ >>>> >>> This looks good to me. >>> >>> Do you mind leaving in the jdk_io header in ProblemList? It just >>> makes it obvious to people where to list tests as we've already >>> tried to group them by area (no need to generate a new webrev for >>> this of course). >> I do not know the policy for such a case. If you like to remove the >> jdk_io header in ProblemList, I will. > I would prefer if you left it in the file (you'll see other examples > in there where we leave a header as a placeholder so that folks know > where to list the tests). I mean: # jdk_io -# 7162111 - these tests need to be updated to run headless -java/io/Serializable/resolveClass/deserializeButton/run.sh macosx-all -java/io/Serializable/serialver/classpath/run.sh macosx-all -java/io/Serializable/serialver/nested/run.sh macosx-all - ############################################################################ > > -Alan From Alan.Bateman at oracle.com Fri Nov 23 11:56:28 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 23 Nov 2012 11:56:28 +0000 Subject: Request for Review: 5049299: (process) Use posix_spawn, not fork, on S10 to avoid swap exhaustion In-Reply-To: <50AE98B1.2040200@oracle.com> References: <50AE98B1.2040200@oracle.com> Message-ID: <50AF646C.4040809@oracle.com> On 22/11/2012 21:27, Rob McKenna wrote: > Hi folks, > > Looking for a review for the webrev below, which also resolves: > > 7175692: (process) Process.exec should use posix_spawn [macosx] > > For additional context and a brief description it would be well worth > looking at the following thread started by Michael McMahon, who did > the brunt of the work for this fix: > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2009-May/thread.html#1644 > > > Basically the fix aims to swap fork for posix_spawn as the default > process launch mechanism on Solaris and Mac OSX in order to avoid swap > exhaustion issues encountered with fork()/exec(). It also offers a > flag (java.lang.useFork) to allow a user to revert to the old behaviour. > > I'm having trouble seeing the wood for the trees at this point so I'm > anticipating plenty of feedback. In particular I'd appreciate some > discussion on: > > - The binary launcher name & property name may need some work. A more > general property ("java.lang.launchMechanism") to allow a user to > specify a particular call was mooted too. It may be more future proof > and I'm completely open to that. (e.g. > launchMechanism=spawn|fork|vfork|clone - we would obviously ignore > inapplicable values on a per-platform basis) > - I'd like a more robust way of checking that someone isn't trying to > use jprochelper outside of the context for which it is meant. > - The decision around which call to use getting moved to the java > level and away from the native preprocessor. > > The webrev is at: > > http://cr.openjdk.java.net/~robm/5049299/webrev.01/ > It's great to get this one moving again, we should have helped Michael more to get this over the line on the first outing. This one will require very careful review, I don't have cycles this week, I hope others do. For now I think that naming the trampoline jprochelper or jspawnhelper is okay. To make it more robust then I'd probably prepend a magic number or some token. Also I'd probably fstat stdin and uses S_FIFO to check the mode. As the property is implementation specific then I think something like jdk.lang.process.useFork is a better start. It would be nice not to require it although I agree we have to walk carefully as this area has a tendency to bite back. I don't think you need to make it any more configurable than that. If this is successful then I think we should look at updating the hotspot code too as it has the same issue with VM options such as OnError. -Alan. From Alan.Bateman at oracle.com Fri Nov 23 11:57:25 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 23 Nov 2012 11:57:25 +0000 Subject: Review request: JDK-7162111 TEST_BUG: change tests run in headless mode [macosx] (open part - ver. 3) In-Reply-To: <50AF60C4.4090006@oracle.com> References: <50AA029C.3090301@oracle.com> <50AA257E.4070701@oracle.com> <50AA4832.60908@oracle.com> <50AA6510.1040108@oracle.com> <50ADD65B.9020502@oracle.com> <50ADF6F3.5070500@oracle.com> <50AF5294.6090405@oracle.com> <50AF56BF.1070804@oracle.com> <50AF5C80.4000607@oracle.com> <50AF5CF4.5040003@oracle.com> <50AF60C4.4090006@oracle.com> Message-ID: <50AF64A5.1020701@oracle.com> On 23/11/2012 11:40, Alexey Utkin wrote: > I mean: > # jdk_io > -# 7162111 - these tests need to be updated to run headless > -java/io/Serializable/resolveClass/deserializeButton/run.sh macosx-all > -java/io/Serializable/serialver/classpath/run.sh macosx-all > -java/io/Serializable/serialver/nested/run.sh macosx-all > - > ############################################################################ Yes, exactly. -Alan From zhong.j.yu at gmail.com Fri Nov 23 15:38:53 2012 From: zhong.j.yu at gmail.com (Zhong Yu) Date: Fri, 23 Nov 2012 09:38:53 -0600 Subject: hg: jdk8/tl/jdk: 6924259: Remove offset and count fields from java.lang.String In-Reply-To: References: Message-ID: I just realized that I also use String.trim() a lot, and have always assumed it's very cheap; that's no longer the case. JDK itself contains many usages of trim(); even a lot of str.substring().trim() Just saying. On Wed, Nov 14, 2012 at 9:14 AM, Zhong Yu wrote: > Changing String.substring() from O(1) to O(n) is a big deal; we may > say it breaks compatibility. > > Any code that intends to work across JDK versions before and after 7u6 > cannot use the method, since its behavior is so different in different > versions. > > Any deployment that upgrades JDK to 7u6 and later needs to review all > its usages of substring(). That's a ton of work. A quick workaround > might be to refactor all substring() usages to some `old_substring()` > method that preserves O(1). Unfortunately `old_substring()` cannot > exist, so there's no quick workaround possible. > > The memory leak problem of the old substring() method is well-known > among Java programmers, it's not really a big problem today. > > For the uninitiated, they might expect that substring() is leak-free; > but they might also expect that substring() is O(1). There's no > apparent reason why favoring one is better than favoring the other. > > In the old implementation, there's a workaround to achieve leak-free, > by `new String(String)`. > > In the new implementation, there is no workaround to achieve O(1), > unless the developer uses something other than String. It is basically > impossible to change String to another type if it's part of a method > signature. > > With all these problems, please reconsider this change and see if you > should roll it back. Thanks. > > Zhong Yu From Lance.Andersen at oracle.com Fri Nov 23 16:45:40 2012 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Fri, 23 Nov 2012 11:45:40 -0500 Subject: javax.sql.rowset.serial.SerialBlob doesn't support free and getBinaryStream In-Reply-To: <50AF2EBA.1050109@linux.vnet.ibm.com> References: <4FE81ED6.7020909@linux.vnet.ibm.com> <4FF16425.9070308@linux.vnet.ibm.com> <40E34C07-424B-4569-8BCA-82AECEB865CB@oracle.com> <4FF533A4.80808@linux.vnet.ibm.com> <97CD7D6F-DEF1-43B0-A529-54628081EED6@oracle.com> <505BDD2A.40206@linux.vnet.ibm.com> <505C2738.50206@oracle.com> <508E3596.3070705@linux.vnet.ibm.com> <50AF2EBA.1050109@linux.vnet.ibm.com> Message-ID: It is on my list. to update the javadocs I need a ccc which I have not done yet and is needed as part of this change On Nov 23, 2012, at 3:07 AM, Deven You wrote: > Hi Lance, > > Is there any plan for this issue, if any could you update to me? > > Thanks a lot! > On 10/29/2012 06:39 PM, Lance Andersen - Oracle wrote: >> Hi Deven, >> >> I will address the needed updates a bit later. >> >> Thank you for your input >> >> Best >> Lance >> On Oct 29, 2012, at 3:51 AM, Deven You wrote: >> >>> Hi Alan, >>> >>> The Java Spec does not mention the thread safe for JDBC API. But I see the other code in SerialBlob/SerialClob have not consider it. >>> >>> I think use buff == null to replace isFree is a good idea because it also avoid the problem for the condition buf == null && isFree == false so we won't need create a readObject method. >>> >>> Thanks for your suggestion for isFree, I will correct it later. >>> >>> Lance: How about your suggestion? Since you mentioned you will develop the implementation yourself. I use my implementation mainly for the test cases. But you may also take a look my implementation. >>> >>> Thanks a lot! >>> >>> On 09/21/2012 04:37 PM, Alan Bateman wrote: >>>> On 21/09/2012 04:21, Deven You wrote: >>>>> Hi Lance, >>>>> >>>>> I am very busy with other work so I can't work with the SerialBlob/SerialClob item for long time. I am very happy to refine the current test case and create new tests for SerialClob. >>>>> >>>>> I have create a new webre[1] for this task, please review it. >>>>> >>>>> [1] http://cr.openjdk.java.net/~youdwei/OJDK-576/webrev.01/ >>>>> >>>>> PS: If the isFree is not transient, I want to know how we add this field to the javadoc serialized form? >>>> I don't know very much about the rowset API and I can't see anything to specify whether it is meant to be safe for use by concurrent threads. There are clearly lots of issues here and implementing free introduces a lot more, especially with the possibility of an asynchronous free or more than one thread calling free at around the same time. >>>> >>>> Have you considered "buf == null" to mean that the resources are freed? That might avoid needing to change the serialized form. Also as these types are serializable it means you have to consider the case where you deserialize to buf == null && isFree == false for example. On that point, it looks to me that this code needs a readObject anyway (for several reasons). >>>> >>>> A small point is that "isFree" is a odd name for a method that doesn't return a boolean. If the patch goes ahead then I think it needs a better name, ensureNotFree or requireNotFree or something like that. >>>> >>>> -Alan. >>>> >> >> >> 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 peter.levart at gmail.com Fri Nov 23 17:09:08 2012 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 23 Nov 2012 18:09:08 +0100 Subject: bottleneck by java.lang.Class.getAnnotations() - a better patch In-Reply-To: <50AF5930.5010903@gmail.com> References: <924D06EC-F603-4E6A-A7FE-7A05C77B1217@gmail.com> <23313EDE-3AB7-4E53-8EB1-A6F6CC9383B9@gmail.com> <5093A8D3.4030800@gmail.com> <5096CFBD.2010604@gmail.com> <5096F5B0.8070304@gmail.com> <50974D3D.1040502@oracle.com> <50990CB8.2040400@gmail.com> <5099C2FA.2020202@oracle.com> <509A3A63.5010102@gmail.com> <50AF5930.5010903@gmail.com> Message-ID: <50AFADB4.9000204@gmail.com> Hi again, I have found an inconsistency in the last patch I posted. Specifically the Method.getAnnotation(Class) and Constructor.getAnnotation(Class) did not delegate to the root instance as .getAnnotations() did. I corrected that in new revision of the patch: http://dl.dropbox.com/u/101777488/jdk8-hacks/JEP-149/webrev.03/index.html I also modified the benchmarks somewhat so that now they exercise the .getAnnotation(Class) methods on various objects instead of bulk getAnnotations() methods: https://raw.github.com/plevart/jdk8-hacks/annotation-arrays/src/test/ReflectionTest.java I got results for 2 different machines: Desktop PC (one socket i7-2600K, 4 cores), Linux 3.6 64bit: https://raw.github.com/plevart/jdk8-hacks/annotation-arrays/benchmark_results_i7-2600K.txt and: Sun Blade T6320 (one socket T2, 8 cores), Solaris 10 64bit: https://raw.github.com/plevart/jdk8-hacks/annotation-arrays/benchmark_results_T2.txt On the T2, the concurrency bottleneck is even more visible. Regards, Peter On 11/23/2012 12:08 PM, Peter Levart wrote: > Hi David, Alan, Alexander and others, > > Here's a refinement of a patch I proposed in this thread a couple of > weeks ago: > > http://dl.dropbox.com/u/101777488/jdk8-hacks/JEP-149/webrev.02/index.html > > The changed sources can be browsed here: > > https://github.com/plevart/jdk8-hacks/tree/annotation-arrays/src/java/lang > > The main improvement is the replacement of a filed: > > Map, Annotation> declaredAnnotations; > > with plain: > > Annotation[] declaredAnnotations; > > ...in the Class.VolatileData structure. It can be seen from the public > API that caching a HashMap of declared annotations is never needed > since the only public method (getDeclaredAnnotations()) returns an > array. Therefore it is much more efficient to cache the array and only > clone it on every public method invocation. > > Unfortunately it is not so with "annotations" field. There is a public > method (getAnnotation(Class)) that has O(1) time > complexity because of keeping a HashMap in the cache. > > I did an experiment with keeping annotations (declared + inherited) in > an array, sorted by the hashCode of annotationType and the lookup then > was a binary search by hashCode of annotationType followed by linear > search of the equal hashCode neighborhood. This has O(log N) time > complexity, which is not so bad, but the constant factor was pretty > high because invoking Annotation.annotationType() method goes through > dynamic Proxy to an InvocationHandler... > > Speaking of that, I think there's plenty of opportunity for JEP-149 > related optimization in the field of annotations. For example, > generating a special class for every annotationType that would hold > it's own annotation data and answer to method requests directly would > give a large time and space gain. > > It can also be noticed that there's a discrepancy of how lookup is > implemented for example: > - lookup of Annotation by annotationType on a class is a HashMap.get() > which has O(1) time complexity > - lookup of a of Field by fieldName on a class is a linear search in > an array which has O(N) time complexity > - similar for Method by methodName and argumentTypes - O(N) > > The time complexity improvement for Field and Method lookup could be > performed by keeping some cached arrays pre-sorted by the name of > Field or Method and employing a binary search to locate or > almost-locate the object. Since public API explicitly states that > methods returning arrays of Fields and Methods do not specify any > order, pre-sorting the arrays would not break the contract. > > Regards, Peter > > On 11/07/2012 11:39 AM, Peter Levart wrote: >> On 11/07/2012 03:10 AM, David Holmes wrote: >>> Hi Peter, >>> >>> The movement of the reflection caches to a helper object is exactly >>> what I had previously proposed here (some differences in the details >>> of course): >>> >>> http://cr.openjdk.java.net/~dholmes/JEP-149/webrev/ >>> >>> and discussed here: >>> >>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-April/009749.html >>> >>> >>> but this did not touch the annotations fields. >>> >>> David >> >> Hi David, >> >> Thanks for the pointer. There is a discussion between Brian and you >> (to quote some of it): >> >> On 5/04/2012 1:28 PM, Brian Goetz wrote: >> >/ Reducing the number of SoftReferences in ReflectionHelper also seems an >> />/ attractive target for memory reduction. Rather than eight soft >> />/ references (eight extra objects), maintaining a SoftRef to the entire >> />/ RH, or at least to the part of the RH that is currently SR'ed if the two >> />/ non-SR'ed fields can't be recomputed, would save you a whole pile of >> />/ objects per class (and might also reduce pressure on GC, having 8x fewer >> />/ SRs to process.) >> / >> I'd have to consider the intended semantics of these soft references >> before considering any change here. It would hard to predict how this >> might impact runtime performance if we have coarser-grained soft >> references. The current changes should be semantically null. >> >> >/ Finally, you may be able save an extra field per Class by storing the >> />/ ReflectionHelper in a ClassValue on Java SE 8, rather than a field. >> / >> ClassValue is something I'm keeping an eye on, but an entry in >> ClassValue is going to consume more dynamic memory than a single direct >> field. >> >> Thanks, >> David >> >> >> ...the 8 SoftReferences refer to arrays which are never hard >> referenced by the outside world (arrays are always defensively >> copied), so it's reasonable to expect that all SoftReferences would >> be cleared at the same time anyway. And if 8 SoftReferences are >> replaced with 1, the worst case scenario (to quote Hinkmond Wong): >> >> Hi Brian, >> >> One of the issues we have in the Java Embedded group (as David points >> out in his summary), is that while on paper the theoretical max savings >> seems great (as you point out also), in practice as David points out in >> his note, this might be a wash if there are a lot more reflection using >> classes vs. non-reflection using classes in "typical" real-world >> applications, not the low or zero reflection using class ratio that >> happens in the theoretical "best case". >> >> So, a question comes up if we should judge the merit of this change on >> the theoretical "best case" scenario, or should we judge it on >> real-world applicability to "typical" apps (such as a finite set of >> customer surveyed embedded apps that we feel represent a real-world >> scenario). >> >> >> Thanks, >> Hinkmond >> >> >> ...actually becomes even more favourable. We reduce huge overhead >> (each SoftReference is 4 OOPs and 1 long). And if this single >> SoftReference is ever cleared, more memory is released - the whole >> structure (ReflectionHelper / VolatileData) >> >> Other differences in details between your proposal and mine: >> >> In your proposal, the method ReflectionHelper rh() is equivalent to >> mine VolatileData volatileData() - it lazily constructs the structure >> and returns it. My implementation also incorporates the logic of >> clearCachesOnClassRedefinition() by returning and installing a new >> instance of the structure in case a redefinition is detected. This >> has a profound impact on the correctness of the cached data in face >> of races that can occur. >> >> In your proposal, even if the VM could atomically publish changes to >> raw reflection data and the classRedefinitionCount at the same time >> (we hope that at least the order of publishing is such that >> classRedefinitionCount is updated last), it can theoretically be that >> 2 or more redefinitions of the same class happen in close proximity: >> >> VM thread: redefines the class to version=1 >> thread 1: clears the cache and takes version=1 raw data and computes >> derived data but gets pre-empted before installing it >> VM thread: redefines the class to version=2 >> thread 2: clears the cache and takes version=2 raw data and computes >> derived data and installs it >> thread 1: ...gets back and installs version=1 derived data over >> version=2 data >> >> ...if there are no more class redefinitions, the stale version of >> derived data can persist indefinitely. >> >> In my proposal, each thread will get it's own copy of the structure >> in the above scenario and install the derived data into it. It can >> happen that a particular instance of the structure does not represent >> a "snapshot" view of the world, but that is not important, since that >> particular inconsistent instance is only used for the in-flight call >> and only in that part that is consistent. Other callers will get a >> fresh instance. >> >> There is also one thing I overlooked and you haven't: the >> cachedConstructor and newInstanceCallerCache fields. >> >> I'll have to look at how to incorporate them into my scheme. They are >> currently neither SoftReferenced nor cleared at class redefinition. >> As the cachedConstructor is only used to implement the .newInstance() >> method, I wonder if it is safe not to clear it when the class is >> redefined. Are old versions of Constructors still valid for invoking >> in a redefined class? I guess they must be, since user code is free >> to cache it's own versions and class redefinition should not prevent >> invoking them... >> >> Since cachedConstructor/newInstanceCallerCache are used to optimize >> .newInstance() method. That alone suggests that calling this method >> is more common use-case than others. Perhaps leaving this pair of >> fields out of the game is a better approach space-saving wise. >> >> Regards, Peter >> >>> >>> On 6/11/2012 11:12 PM, Peter Levart wrote: >>>> On 11/05/2012 06:23 AM, David Holmes wrote: >>>>> Hi Peter, >>>>> >>>>> Moving the annotations fields into a helper object would tie in with >>>>> the Class-instance size reduction effort that was investigated as >>>>> part >>>>> of "JEP 149: Reduce Core-Library Memory Usage": >>>>> >>>>> http://openjdk.java.net/jeps/149 >>>>> >>>>> The investigations there to date only looked at relocating the >>>>> reflection related fields, though the JEP mentions the annotations as >>>>> well. >>>>> >>>>> Any such effort requires extensive benchmarking and performance >>>>> analysis before being accepted though. >>>>> >>>>> David >>>>> ----- >>>>> >>>> >>>> On 11/05/2012 10:25 AM, Alan Bateman wrote: >>>>> Here's a good starting place on the interaction of runtime visible >>>>> attributes and RedefineClasses/RetransformClasses: >>>>> >>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5002251 >>>>> >>>>> -Alan. >>>> >>>> Hi all, >>>> >>>> Presented here is a patch mainly against java.lang.Class and also >>>> against java.lang.reflect.[Field,Method,Constructor,Executable] >>>> classes. >>>> >>>> Currently java.lang.Class uses the following fields to maintain caches >>>> of reflection data that are invalidated as a result of class or >>>> superclass redefinition/re-transformation: >>>> >>>> private volatile transient SoftReference declaredFields; >>>> private volatile transient SoftReference publicFields; >>>> private volatile transient SoftReference declaredMethods; >>>> private volatile transient SoftReference publicMethods; >>>> private volatile transient SoftReference[]> >>>> declaredConstructors; >>>> private volatile transient SoftReference[]> >>>> publicConstructors; >>>> private volatile transient SoftReference >>>> declaredPublicFields; >>>> private volatile transient SoftReference >>>> declaredPublicMethods; >>>> >>>> // Value of classRedefinedCount when we last cleared the cached values >>>> // that are sensitive to class redefinition. >>>> private volatile transient int lastRedefinedCount = 0; >>>> >>>> // Annotations cache >>>> private transient Map, Annotation> >>>> annotations; >>>> private transient Map, Annotation> >>>> declaredAnnotations; >>>> >>>> If I understand Alan's references correctly, current VM can >>>> redefine the >>>> class in a way that changes method bodies. Also new methods can be >>>> added. And the set of annotations can also be altered. And future >>>> improvements could allow even more. >>>> >>>> Because annotations are cached on Field/Method/Constructor instances, >>>> all the above fields must be invalidated when the class or >>>> superclass is >>>> redefined. >>>> >>>> It can also be observed that Field/Method/Constructor caches are >>>> maintained using SoftReferences but annotations are hard references. I >>>> don't know if this is intentional. I believe that annotations could >>>> also >>>> be SoftReferenced, so that in the event of memory pressure they get >>>> cleared. Many applications retrieve annotations only in the early >>>> stages >>>> of their life-cycle and then either cache them themselves or forget >>>> about them. >>>> >>>> So I designed the patch to equalize this. If this is undesirable, the >>>> patch could be modified to make a distinction again. >>>> >>>> The patch replaces the above-mentioned java.lang.Class fields with a >>>> single field: >>>> >>>> private volatile transient SoftReference> >>>> volatileData; >>>> >>>> ...which is a SoftReference to the following structure: >>>> >>>> // volatile data that might get invalid when JVM TI >>>> RedefineClasses() is >>>> called >>>> static class VolatileData { >>>> volatile Field[] declaredFields; >>>> volatile Field[] publicFields; >>>> volatile Method[] declaredMethods; >>>> volatile Method[] publicMethods; >>>> volatile Constructor[] declaredConstructors; >>>> volatile Constructor[] publicConstructors; >>>> // Intermediate results for getFields and getMethods >>>> volatile Field[] declaredPublicFields; >>>> volatile Method[] declaredPublicMethods; >>>> // Annotations >>>> volatile Map, Annotation> annotations; >>>> volatile Map, Annotation> >>>> declaredAnnotations; >>>> // Value of classRedefinedCount when we created this VolatileData >>>> instance >>>> final int redefinedCount; >>>> >>>> So let's look at static overhead differences using 64 bit addressing >>>> (useful load - arrays, Maps not counted since the patched code uses >>>> the >>>> same amount of same types of each). >>>> >>>> * Fresh java.lang.Class instance: >>>> >>>> current JDK8 code: >>>> >>>> 10 OOPs + 1 int = 10*8+4 = 84 bytes in 1 instance >>>> >>>> vs. patched code : >>>> >>>> 1 OOP = 8 bytes in 1 instance >>>> >>>> * Fully loaded java.lang.Class (Fields, Methods, Constructors, >>>> annotations): >>>> >>>> current JDK8 code: >>>> >>>> 10 OOPs + 1 int = 84 bytes >>>> 8 SoftReference instances = 8*(header + 4 OOPs + 1 long) = >>>> 8*(24+32+8) = >>>> 8*64 = 512 bytes >>>> total: 84+512 = 596 bytes in 9 instances >>>> >>>> vs. patched code : >>>> >>>> 1 OOP = 8 bytes >>>> 1 SoftReference = 64 bytes >>>> 1 VolatileData = header + 10 OOPs + 1 int = 24+84 = 108 bytes >>>> total: 8+64+108 = 180 bytes in 3 instances >>>> >>>> So we have 84 vs. 8 (empty) or 596 vs. 180 (fully loaded) byte >>>> overheads and >>>> 1 vs. 1 (empty) or 9 vs. 3 (fully loaded) instance overheads >>>> >>>> Other than that, the patch also removes synchronized blocks for lazy >>>> initialization of annotations in Class, Field, Method and Constructor >>>> and replaces them with volatile fields. In case of Class.volatileData, >>>> this field is initialized using a CAS so there is no race which could >>>> install an already stale instance over more recent. Although such race >>>> would quickly be corrected at next call to any retrieval method, >>>> because >>>> redefinedCount is now an integral part of the cached structure not an >>>> individual volatile field. >>>> >>>> There is also a change in how annotations are cached in Field, Method >>>> and Constructor. Originally they are cached in each copy of the >>>> Field/Method/Constructor that is returned to the outside world at each >>>> invocation of Class.getFields() etc. Such caching is not very >>>> effective >>>> if the annotations are only retrieved once per instance. The patch >>>> changes this and delegates caching to the "root" instance which is >>>> held >>>> inside Class so caching becomes more effective in certain usage >>>> patterns. There's now a possible hot-spot on the "root" instance but >>>> that seems not to be a bottleneck since the fast-path does not involve >>>> blocking synchronization (just volatile read). The effects of this >>>> change are clearly visible in one of the benchmarks. >>>> >>>> I have tried to create 3 micro benchmarks which exercise concurrent >>>> load >>>> on 3 Class instances. >>>> >>>> Here's the benchmark code: >>>> >>>> https://raw.github.com/plevart/jdk8-hacks/master/src/test/ReflectionTest.java >>>> >>>> >>>> And here are the results when run on an Intel i7 CPU (4 cores, 2 >>>> threads/core) Linux machine using -Xmx4G VM option: >>>> >>>> https://raw.github.com/plevart/jdk8-hacks/master/benchmark_results.txt >>>> >>>> >>>> The huge difference of Test1 results is a direct consequence of >>>> patched >>>> code delegating caching of annotations in Field/Method/Constructor to >>>> the "root" instance. >>>> >>>> Test2 results show no noticeable difference between original and >>>> patched >>>> code. This, I believe, is the most common usage of the API, so another >>>> level of indirection does not appear to present any noticeable >>>> performance overhead. >>>> >>>> The Test3 on the other hand shows the synchronization overhead of >>>> current jdk8 code in comparison with non-blocking synchronization in >>>> patched code. >>>> >>>> JEP 149 also mentions testing with SPECjbb2005 and SPECjvm98, but that >>>> exceeds my possibilities. >>>> >>>> The patch against jdk8/jdk8/jdk hg repository is here: >>>> >>>> https://raw.github.com/plevart/jdk8-hacks/master/volatile_class_data_caching.patch >>>> >>>> >>>> You can also browse the changed sources: >>>> >>>> https://github.com/plevart/jdk8-hacks >>>> >>>> >>>> Regards, Peter >>>> > From xuelei.fan at oracle.com Sat Nov 24 11:36:08 2012 From: xuelei.fan at oracle.com (xuelei.fan at oracle.com) Date: Sat, 24 Nov 2012 11:36:08 +0000 Subject: hg: jdk8/tl/jdk: 8001751: Javadoc warnings in JSSE code Message-ID: <20121124113655.9694A47B01@hg.openjdk.java.net> Changeset: 621c379d909d Author: xuelei Date: 2012-11-24 03:34 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/621c379d909d 8001751: Javadoc warnings in JSSE code Reviewed-by: alanb ! src/share/classes/javax/net/ssl/HostnameVerifier.java ! src/share/classes/javax/net/ssl/SNIHostName.java ! src/share/classes/javax/net/ssl/SNIMatcher.java ! src/share/classes/javax/net/ssl/SNIServerName.java ! src/share/classes/javax/net/ssl/SSLParameters.java ! src/share/classes/javax/net/ssl/SSLSocketFactory.java From xuelei.fan at oracle.com Sat Nov 24 12:10:29 2012 From: xuelei.fan at oracle.com (xuelei.fan at oracle.com) Date: Sat, 24 Nov 2012 12:10:29 +0000 Subject: hg: jdk8/tl/jdk: 8003950: Adds missing Override annotations and removes unnecessary imports in sun.security.ssl Message-ID: <20121124121041.DA75147B02@hg.openjdk.java.net> Changeset: f7d45462b225 Author: xuelei Date: 2012-11-24 04:09 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f7d45462b225 8003950: Adds missing Override annotations and removes unnecessary imports in sun.security.ssl Reviewed-by: xuelei Contributed-by: Florian Weimer ! src/share/classes/sun/security/ssl/AppInputStream.java ! src/share/classes/sun/security/ssl/AppOutputStream.java ! src/share/classes/sun/security/ssl/BaseSSLSocketImpl.java ! src/share/classes/sun/security/ssl/ByteBufferInputStream.java ! src/share/classes/sun/security/ssl/CipherBox.java ! src/share/classes/sun/security/ssl/CipherSuite.java ! src/share/classes/sun/security/ssl/CipherSuiteList.java ! src/share/classes/sun/security/ssl/ClientHandshaker.java ! src/share/classes/sun/security/ssl/DHClientKeyExchange.java ! src/share/classes/sun/security/ssl/ECDHClientKeyExchange.java ! src/share/classes/sun/security/ssl/ECDHCrypt.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/ExtensionType.java ! src/share/classes/sun/security/ssl/HandshakeHash.java ! src/share/classes/sun/security/ssl/HandshakeInStream.java ! src/share/classes/sun/security/ssl/HandshakeMessage.java ! src/share/classes/sun/security/ssl/HandshakeOutStream.java ! src/share/classes/sun/security/ssl/Handshaker.java ! src/share/classes/sun/security/ssl/HelloExtension.java ! src/share/classes/sun/security/ssl/HelloExtensions.java ! src/share/classes/sun/security/ssl/InputRecord.java ! src/share/classes/sun/security/ssl/JsseJce.java ! src/share/classes/sun/security/ssl/KerberosClientKeyExchange.java ! src/share/classes/sun/security/ssl/KeyManagerFactoryImpl.java ! src/share/classes/sun/security/ssl/Krb5Helper.java ! src/share/classes/sun/security/ssl/OutputRecord.java ! src/share/classes/sun/security/ssl/ProtocolList.java ! src/share/classes/sun/security/ssl/ProtocolVersion.java ! src/share/classes/sun/security/ssl/RSAClientKeyExchange.java ! src/share/classes/sun/security/ssl/RSASignature.java ! src/share/classes/sun/security/ssl/RenegotiationInfoExtension.java ! src/share/classes/sun/security/ssl/SSLAlgorithmConstraints.java ! src/share/classes/sun/security/ssl/SSLContextImpl.java ! src/share/classes/sun/security/ssl/SSLEngineImpl.java ! src/share/classes/sun/security/ssl/SSLServerSocketFactoryImpl.java ! src/share/classes/sun/security/ssl/SSLServerSocketImpl.java ! src/share/classes/sun/security/ssl/SSLSessionContextImpl.java ! src/share/classes/sun/security/ssl/SSLSessionImpl.java ! src/share/classes/sun/security/ssl/SSLSocketFactoryImpl.java ! src/share/classes/sun/security/ssl/SSLSocketImpl.java ! src/share/classes/sun/security/ssl/ServerHandshaker.java ! src/share/classes/sun/security/ssl/ServerNameExtension.java ! src/share/classes/sun/security/ssl/SessionId.java ! src/share/classes/sun/security/ssl/SunJSSE.java ! src/share/classes/sun/security/ssl/SunX509KeyManagerImpl.java ! src/share/classes/sun/security/ssl/SupportedEllipticCurvesExtension.java ! src/share/classes/sun/security/ssl/SupportedEllipticPointFormatsExtension.java ! src/share/classes/sun/security/ssl/TrustManagerFactoryImpl.java ! src/share/classes/sun/security/ssl/UnknownExtension.java ! src/share/classes/sun/security/ssl/X509KeyManagerImpl.java ! src/share/classes/sun/security/ssl/X509TrustManagerImpl.java From xuelei.fan at oracle.com Sat Nov 24 12:28:56 2012 From: xuelei.fan at oracle.com (xuelei.fan at oracle.com) Date: Sat, 24 Nov 2012 12:28:56 +0000 Subject: hg: jdk8/tl/jdk: 8003951: Removes unused variables in sun.security.ssl Message-ID: <20121124122908.0B17E47B03@hg.openjdk.java.net> Changeset: d30c13172254 Author: xuelei Date: 2012-11-24 04:27 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d30c13172254 8003951: Removes unused variables in sun.security.ssl Reviewed-by: xuelei Contributed-by: Florian Weimer ! src/share/classes/sun/security/ssl/HandshakeMessage.java ! src/share/classes/sun/security/ssl/JsseJce.java ! src/share/classes/sun/security/ssl/SSLServerSocketImpl.java ! src/share/classes/sun/security/ssl/SSLSessionContextImpl.java ! src/share/classes/sun/security/ssl/SSLSocketFactoryImpl.java ! src/share/classes/sun/security/ssl/X509TrustManagerImpl.java From lance.andersen at oracle.com Sat Nov 24 22:05:27 2012 From: lance.andersen at oracle.com (Lance Andersen - Oracle) Date: Sat, 24 Nov 2012 17:05:27 -0500 Subject: Adding field to BatchUpdateException Message-ID: <52053C90-5BC1-4FED-A75A-C4015D5F5CD4@oracle.com> Hi, For JDBC 4.2, I am adding methods to allow for larger update counts (request from JDBC driver vendors) and because of this I have to tweak BatchUpdateException The Statement interface has the method int[] executeBatch() I am planning to add long[] executeLargeBatch(). To accomodate this change, I also need to add a new field and the method getLargeUpdateCount to BatchUpdateException. I have exchanged emails on this with Alan and he indicated that the changes seemed reasonable but to send a general email out to see if anything was missed from the serialization perspective. I have added JDBC Unit tests to validate that the serialization/deserialization works between JDBC 4.1 and JDBC 4.2 and they run without a problem. Best Lance new-host-2:sql lanceandersen$ diff BatchUpdateException.java ~/NetBeansProjects/JDBC4.2/jdbc4.0/src/java/sql/ 2c2 < * Copyright (c) 1998, 2011, Oracle and/or its affiliates. All rights reserved. --- > * Copyright (c) 1998, 2012, Oracle and/or its affiliates. All rights reserved. 27a28,31 > import java.io.IOException; > import java.io.InvalidObjectException; > import java.io.ObjectInputStream; > import java.io.ObjectOutputStream; 83a88 > this.longUpdateCounts = (updateCounts == null) ? null : copyUpdateCount(updateCounts); 192c197 < this((cause == null ? null : cause.toString()), null, 0, null, cause); --- > this((cause == null ? null : cause.toString()), null, 0, (int[])null, cause); 295a301 > this.longUpdateCounts = (updateCounts == null) ? null : copyUpdateCount(updateCounts); 331c337,401 < --- > > /** > * Constructs a BatchUpdateException object initialized with > * a given reason, SQLState, vendorCode > * cause and updateCounts. > *

> * This constructor should be used when the returned update count may exceed > * {@link Integer.MAX_VALUE}. > *

> * @param reason a description of the error > * @param SQLState an XOPEN or SQL:2003 code identifying the exception > * @param vendorCode an exception code used by a particular > * database vendor > * @param updateCounts an array of long, with each element > *indicating the update count, Statement.SUCCESS_NO_INFO or > * Statement.EXECUTE_FAILED for each SQL command in > * the batch for JDBC drivers that continue processing > * after a command failure; an update count or > * Statement.SUCCESS_NO_INFO for each SQL command in the batch > * prior to the failure for JDBC drivers that stop processing after a command > * failure > * @param cause the underlying reason for this SQLException > * (which is saved for later retrieval by the getCause() method); > * may be null indicating the cause is non-existent or unknown. > * @since 1.8 > */ > public BatchUpdateException(String reason, String SQLState, int vendorCode, > long []updateCounts,Throwable cause) { > super(reason, SQLState, vendorCode, cause); > this.longUpdateCounts = (updateCounts == null) ? null : Arrays.copyOf(updateCounts, updateCounts.length); > this.updateCounts = (longUpdateCounts == null) ? null : copyUpdateCount(longUpdateCounts); > } > > /** > * Retrieves the update count for each update statement in the batch > * update that executed successfully before this exception occurred. > * A driver that implements batch updates may or may not continue to > * process the remaining commands in a batch when one of the commands > * fails to execute properly. If the driver continues processing commands, > * the array returned by this method will have as many elements as > * there are commands in the batch; otherwise, it will contain an > * update count for each command that executed successfully before > * the BatchUpdateException was thrown. > *

> * This method should be used when the returned update count may exceed > * {@link Integer.MAX_VALUE}. > *

> * @return an array of long containing the update counts > * for the updates that were executed successfully before this error > * occurred. Or, if the driver continues to process commands after an > * error, one of the following for every command in the batch: > *

    > *
  1. an update count > *
  2. Statement.SUCCESS_NO_INFO to indicate that the command > * executed successfully but the number of rows affected is unknown > *
  3. Statement.EXECUTE_FAILED to indicate that the command > * failed to execute successfully > *
> * @since 1.8 > */ > public long[] getLargeUpdateCounts() { > return (longUpdateCounts == null) ? null : > Arrays.copyOf(longUpdateCounts, longUpdateCounts.length); > } > 337c407,414 < private final int[] updateCounts; --- > private int[] updateCounts; > > /** > * The array that describes the outcome of a batch execution. > * @serial > * @since 1.8 > */ > private long[] longUpdateCounts; 339a417,474 > > /* > * Utility method to copy int[] updateCount to long[] updateCount > */ > private static long[] copyUpdateCount(int[] uc) { > long[] copy = new long[uc.length]; > for(int i= 0; i< uc.length; i++) { > copy[i] = uc[i]; > > } > return copy; > } > > /* > * Utility method to copy int[] updateCount to long[] updateCount > */ > private static int[] copyUpdateCount(long[] uc) { > int[] copy = new int[uc.length]; > for(int i= 0; i< uc.length; i++) { > copy[i] = (int) uc[i]; > } > return copy; > } > /** > * readObject is called to restore the state of the > * {@code BatchUpdateException} from a stream. > */ > private void readObject(ObjectInputStream s) > throws IOException, ClassNotFoundException { > > ObjectInputStream.GetField fields = s.readFields(); > int[] tmp = (int[])fields.get("updateCounts", null); > long[] tmp2 = (long[])fields.get("longUpdateCounts", null); > if(tmp != null && tmp2 != null && tmp.length != tmp2.length) > throw new InvalidObjectException("update counts are not the expected size"); > if (tmp != null) > updateCounts = tmp.clone(); > if (tmp2 != null) > longUpdateCounts = tmp2.clone(); > if(updateCounts == null && longUpdateCounts != null) > updateCounts = copyUpdateCount(longUpdateCounts); > if(longUpdateCounts == null && updateCounts != null) > longUpdateCounts = copyUpdateCount(updateCounts); > > } > > /** > * writeObject is called to save the state of the {@code BatchUpdateException} > * to a stream. > */ > private void writeObject(ObjectOutputStream s) > throws IOException, ClassNotFoundException { > > ObjectOutputStream.PutField fields = s.putFields(); > fields.put("updateCounts", updateCounts); > fields.put("longUpdateCounts", longUpdateCounts); > s.writeFields(); > } 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 Alan.Bateman at oracle.com Sun Nov 25 22:07:27 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 25 Nov 2012 22:07:27 +0000 Subject: 8003949: LogManager, downgrade normative reference to ${java.home}/lib/logging.properties Message-ID: <50B2969F.8040101@oracle.com> As part of preparing for modules [1], we need to examine a number of normative references to files in ${java.home} with a view to downgrading these references to non-normative status. This is important as we need the flexibility to eventually move some of these files into module-private locations, maybe in some cases replace them with something else. This is something I've bought up on security-dev and i18n-dev recently as there are number of references to files in ${java.home} that need to be examined. The focus of this mail is java.util.logging.LogManager as it specifies that the default configuration is loaded from ${java.home}/lib/logging.properties. Clearly this file is changed in some environments, although running with java.util.logging.config.file is probably more robust in that the settings can be used with different JDK installations. The proposed changes (javadoc changes only, no implementation changes) is here: http://cr.openjdk.java.net/~alanb/8003949/webrev/ Note that I have also removed the statement that "properties may be set via the Preference API" as the implementation has never used the preferences and not worth re-visiting now. -Alan [1] http://openjdk.java.net/jeps/162 From weijun.wang at oracle.com Mon Nov 26 05:46:24 2012 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 26 Nov 2012 13:46:24 +0800 Subject: Reflection.getCallerClass(n) does not skip reflection calls in constructors Message-ID: <50B30230.5000400@oracle.com> Hi I'm trying to use Reflection.getCallerClass(n) to find out who is calling a method. The method's spec says: .... Frames associated with java.lang.reflect.Method.invoke() and its implementation are completely ignored and do not count toward the number of "real" frames skipped. This is very nice but it does not mention Constructor.newInstance(). In fact, I do see the following entries if I'm creating an object thru reflection: Callee class sun.reflect.NativeConstructorAccessorImpl class sun.reflect.NativeConstructorAccessorImpl class sun.reflect.DelegatingConstructorAccessorImpl class java.lang.reflect.Constructor Caller Is there any reason why we cannot do the same for constructor instantiation? Thanks Max From joe.darcy at oracle.com Mon Nov 26 06:51:43 2012 From: joe.darcy at oracle.com (Joe Darcy) Date: Sun, 25 Nov 2012 22:51:43 -0800 Subject: Adding field to BatchUpdateException In-Reply-To: <52053C90-5BC1-4FED-A75A-C4015D5F5CD4@oracle.com> References: <52053C90-5BC1-4FED-A75A-C4015D5F5CD4@oracle.com> Message-ID: <50B3117F.7090305@oracle.com> Hi Lance, I don't see an obvious problem with the code, but I strongly suggest documenting the correctness conditions regarding the updateCounts and longUpdateCounts fields; I think that would ease reviewing the new constructors and serialization code. Cheers, -Joe On 11/24/2012 2:05 PM, Lance Andersen - Oracle wrote: > Hi, > > For JDBC 4.2, I am adding methods to allow for larger update counts (request from JDBC driver vendors) and because of this I have to tweak BatchUpdateException > > The Statement interface has the method > > int[] executeBatch() > > I am planning to add > > long[] executeLargeBatch(). > > To accomodate this change, I also need to add a new field and the method getLargeUpdateCount to BatchUpdateException. > > I have exchanged emails on this with Alan and he indicated that the changes seemed reasonable but to send a general email out to see if anything was missed from the serialization perspective. > > I have added JDBC Unit tests to validate that the serialization/deserialization works between JDBC 4.1 and JDBC 4.2 and they run without a problem. > > > Best > Lance > > new-host-2:sql lanceandersen$ diff BatchUpdateException.java ~/NetBeansProjects/JDBC4.2/jdbc4.0/src/java/sql/ > 2c2 > < * Copyright (c) 1998, 2011, Oracle and/or its affiliates. All rights reserved. > --- >> * Copyright (c) 1998, 2012, Oracle and/or its affiliates. All rights reserved. > 27a28,31 >> import java.io.IOException; >> import java.io.InvalidObjectException; >> import java.io.ObjectInputStream; >> import java.io.ObjectOutputStream; > 83a88 >> this.longUpdateCounts = (updateCounts == null) ? null : copyUpdateCount(updateCounts); > 192c197 > < this((cause == null ? null : cause.toString()), null, 0, null, cause); > --- >> this((cause == null ? null : cause.toString()), null, 0, (int[])null, cause); > 295a301 >> this.longUpdateCounts = (updateCounts == null) ? null : copyUpdateCount(updateCounts); > 331c337,401 > < > --- >> >> /** >> * Constructs a BatchUpdateException object initialized with >> * a given reason, SQLState, vendorCode >> * cause and updateCounts. >> *

>> * This constructor should be used when the returned update count may exceed >> * {@link Integer.MAX_VALUE}. >> *

>> * @param reason a description of the error >> * @param SQLState an XOPEN or SQL:2003 code identifying the exception >> * @param vendorCode an exception code used by a particular >> * database vendor >> * @param updateCounts an array of long, with each element >> *indicating the update count, Statement.SUCCESS_NO_INFO or >> * Statement.EXECUTE_FAILED for each SQL command in >> * the batch for JDBC drivers that continue processing >> * after a command failure; an update count or >> * Statement.SUCCESS_NO_INFO for each SQL command in the batch >> * prior to the failure for JDBC drivers that stop processing after a command >> * failure >> * @param cause the underlying reason for this SQLException >> * (which is saved for later retrieval by the getCause() method); >> * may be null indicating the cause is non-existent or unknown. >> * @since 1.8 >> */ >> public BatchUpdateException(String reason, String SQLState, int vendorCode, >> long []updateCounts,Throwable cause) { >> super(reason, SQLState, vendorCode, cause); >> this.longUpdateCounts = (updateCounts == null) ? null : Arrays.copyOf(updateCounts, updateCounts.length); >> this.updateCounts = (longUpdateCounts == null) ? null : copyUpdateCount(longUpdateCounts); >> } >> >> /** >> * Retrieves the update count for each update statement in the batch >> * update that executed successfully before this exception occurred. >> * A driver that implements batch updates may or may not continue to >> * process the remaining commands in a batch when one of the commands >> * fails to execute properly. If the driver continues processing commands, >> * the array returned by this method will have as many elements as >> * there are commands in the batch; otherwise, it will contain an >> * update count for each command that executed successfully before >> * the BatchUpdateException was thrown. >> *

>> * This method should be used when the returned update count may exceed >> * {@link Integer.MAX_VALUE}. >> *

>> * @return an array of long containing the update counts >> * for the updates that were executed successfully before this error >> * occurred. Or, if the driver continues to process commands after an >> * error, one of the following for every command in the batch: >> *

    >> *
  1. an update count >> *
  2. Statement.SUCCESS_NO_INFO to indicate that the command >> * executed successfully but the number of rows affected is unknown >> *
  3. Statement.EXECUTE_FAILED to indicate that the command >> * failed to execute successfully >> *
>> * @since 1.8 >> */ >> public long[] getLargeUpdateCounts() { >> return (longUpdateCounts == null) ? null : >> Arrays.copyOf(longUpdateCounts, longUpdateCounts.length); >> } >> > 337c407,414 > < private final int[] updateCounts; > --- >> private int[] updateCounts; >> >> /** >> * The array that describes the outcome of a batch execution. >> * @serial >> * @since 1.8 >> */ >> private long[] longUpdateCounts; > 339a417,474 >> >> /* >> * Utility method to copy int[] updateCount to long[] updateCount >> */ >> private static long[] copyUpdateCount(int[] uc) { >> long[] copy = new long[uc.length]; >> for(int i= 0; i< uc.length; i++) { >> copy[i] = uc[i]; >> >> } >> return copy; >> } >> >> /* >> * Utility method to copy int[] updateCount to long[] updateCount >> */ >> private static int[] copyUpdateCount(long[] uc) { >> int[] copy = new int[uc.length]; >> for(int i= 0; i< uc.length; i++) { >> copy[i] = (int) uc[i]; >> } >> return copy; >> } >> /** >> * readObject is called to restore the state of the >> * {@code BatchUpdateException} from a stream. >> */ >> private void readObject(ObjectInputStream s) >> throws IOException, ClassNotFoundException { >> >> ObjectInputStream.GetField fields = s.readFields(); >> int[] tmp = (int[])fields.get("updateCounts", null); >> long[] tmp2 = (long[])fields.get("longUpdateCounts", null); >> if(tmp != null && tmp2 != null && tmp.length != tmp2.length) >> throw new InvalidObjectException("update counts are not the expected size"); >> if (tmp != null) >> updateCounts = tmp.clone(); >> if (tmp2 != null) >> longUpdateCounts = tmp2.clone(); >> if(updateCounts == null && longUpdateCounts != null) >> updateCounts = copyUpdateCount(longUpdateCounts); >> if(longUpdateCounts == null && updateCounts != null) >> longUpdateCounts = copyUpdateCount(updateCounts); >> >> } >> >> /** >> * writeObject is called to save the state of the {@code BatchUpdateException} >> * to a stream. >> */ >> private void writeObject(ObjectOutputStream s) >> throws IOException, ClassNotFoundException { >> >> ObjectOutputStream.PutField fields = s.putFields(); >> fields.put("updateCounts", updateCounts); >> fields.put("longUpdateCounts", longUpdateCounts); >> s.writeFields(); >> } > > > 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 staffan.larsen at oracle.com Mon Nov 26 09:40:30 2012 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 26 Nov 2012 10:40:30 +0100 Subject: RFR: 8003322: Add instrumentation points for tracing of I/O calls In-Reply-To: <50ABBE28.70907@oracle.com> References: <50A39388.8060502@oracle.com> <50AA0142.3080502@oracle.com> <28479F37-C81B-4CFB-811A-CEC45755B26B@oracle.com> <50AA279B.7060505@oracle.com> <7C9B7EE6-E9BB-4F4C-81BD-B8AECE689739@oracle.com> <50AB91AE.4040909@oracle.com> <50ABBE28.70907@oracle.com> Message-ID: A webrev for the changes going into 7u12 is here: http://cr.openjdk.java.net/~sla/8003322/webrev.jdk7.00/ Thanks, /Staffan On 20 nov 2012, at 18:30, Mandy Chung wrote: > On 11/20/12 6:20 AM, Alan Bateman wrote: >> On 20/11/2012 14:10, Staffan Larsen wrote: >>> : >>> The original plan was for the code in this review to go into both 8 and 7u12. Since 7u12 has a tighter deadline, a possible path would be to include it only in 7u12, but not in 8. For 8 we would then implement a fully dynamic solution. The only thing needed in 8 from this review would be the path field added to the stream classes. Does that sound like a plan? >>> >> I think this is a good plan. I suggest bringing it up on jdk7u-dev so that the jdk7u maintainers can think about the issue (rather that trying to get approval at the last minute when you are reading to push). > > This sounds a good plan to me too. This would take the pressure off 7u12 deadline while a better solution will be implemented for 8. > > Mandy From alexey.utkin at oracle.com Mon Nov 26 10:38:13 2012 From: alexey.utkin at oracle.com (Alexey Utkin) Date: Mon, 26 Nov 2012 14:38:13 +0400 Subject: Review request: JDK-7162111 TEST_BUG: change tests run in headless mode [macosx] (open part - ver. 3) In-Reply-To: <50AF64A5.1020701@oracle.com> References: <50AA029C.3090301@oracle.com> <50AA257E.4070701@oracle.com> <50AA4832.60908@oracle.com> <50AA6510.1040108@oracle.com> <50ADD65B.9020502@oracle.com> <50ADF6F3.5070500@oracle.com> <50AF5294.6090405@oracle.com> <50AF56BF.1070804@oracle.com> <50AF5C80.4000607@oracle.com> <50AF5CF4.5040003@oracle.com> <50AF60C4.4090006@oracle.com> <50AF64A5.1020701@oracle.com> Message-ID: <50B34695.5030502@oracle.com> I need the second reviewer. -uta On 23.11.2012 15:57, Alan Bateman wrote: > On 23/11/2012 11:40, Alexey Utkin wrote: >> I mean: >> # jdk_io >> -# 7162111 - these tests need to be updated to run headless >> -java/io/Serializable/resolveClass/deserializeButton/run.sh macosx-all >> -java/io/Serializable/serialver/classpath/run.sh macosx-all >> -java/io/Serializable/serialver/nested/run.sh macosx-all >> - >> ############################################################################ > Yes, exactly. > > -Alan From Alan.Bateman at oracle.com Mon Nov 26 11:08:32 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 26 Nov 2012 11:08:32 +0000 Subject: Review request: JDK-7162111 TEST_BUG: change tests run in headless mode [macosx] (open part - ver. 3) In-Reply-To: <50B34695.5030502@oracle.com> References: <50AA029C.3090301@oracle.com> <50AA257E.4070701@oracle.com> <50AA4832.60908@oracle.com> <50AA6510.1040108@oracle.com> <50ADD65B.9020502@oracle.com> <50ADF6F3.5070500@oracle.com> <50AF5294.6090405@oracle.com> <50AF56BF.1070804@oracle.com> <50AF5C80.4000607@oracle.com> <50AF5CF4.5040003@oracle.com> <50AF60C4.4090006@oracle.com> <50AF64A5.1020701@oracle.com> <50B34695.5030502@oracle.com> Message-ID: <50B34DB0.7090801@oracle.com> On 26/11/2012 10:38, Alexey Utkin wrote: > I need the second reviewer. > > -uta One reviewer is fine. -Alan From alexey.utkin at oracle.com Mon Nov 26 11:56:28 2012 From: alexey.utkin at oracle.com (alexey.utkin at oracle.com) Date: Mon, 26 Nov 2012 11:56:28 +0000 Subject: hg: jdk8/tl/jdk: 7162111: TEST_BUG: change tests run in headless mode [macosx] (open) Message-ID: <20121126115703.7539047B1F@hg.openjdk.java.net> Changeset: 8970128e040d Author: uta Date: 2012-11-26 15:54 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8970128e040d 7162111: TEST_BUG: change tests run in headless mode [macosx] (open) Summary: In problem tests detection of AWT headless mode was introduced or AWT dependence was removed. Reviewed-by: alanb ! test/ProblemList.txt ! test/demo/jvmti/mtrace/TraceJFrame.java ! test/java/io/Serializable/resolveClass/deserializeButton/Foo.java ! test/java/io/Serializable/resolveClass/deserializeButton/Test.java ! test/java/io/Serializable/resolveClass/deserializeButton/run.sh From sean.mullan at oracle.com Mon Nov 26 13:54:42 2012 From: sean.mullan at oracle.com (sean.mullan at oracle.com) Date: Mon, 26 Nov 2012 13:54:42 +0000 Subject: hg: jdk8/tl/jdk: 3 new changesets Message-ID: <20121126135526.EBF6547B20@hg.openjdk.java.net> Changeset: 054470092795 Author: mullan Date: 2012-11-26 08:12 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/054470092795 7167056: Clarify that BasicPermission names that contain non-wildcard asterisks are not invalid Reviewed-by: weijun, xuelei ! src/share/classes/com/sun/net/ssl/SSLPermission.java ! src/share/classes/java/lang/RuntimePermission.java ! src/share/classes/java/net/NetPermission.java ! src/share/classes/java/security/BasicPermission.java ! src/share/classes/java/sql/SQLPermission.java ! src/share/classes/java/util/PropertyPermission.java ! src/share/classes/javax/net/ssl/SSLPermission.java + test/java/security/BasicPermission/Wildcard.java Changeset: ea66140be78d Author: mullan Date: 2012-11-26 08:23 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ea66140be78d Merge - makefiles/docs/CORE_PKGS.gmk - makefiles/docs/Makefile - makefiles/docs/NON_CORE_PKGS.gmk - makefiles/docs/Notes.html - makefiles/mapfiles/launchers/mapfile-amd64 - makefiles/mapfiles/launchers/mapfile-i586 - makefiles/mapfiles/libawt_headless/reorder-i586 - makefiles/mapfiles/libjava/reorder-i586 - makefiles/mapfiles/libjpeg/reorder-i586 - makefiles/mapfiles/libnio/mapfile-bsd - makefiles/mapfiles/libnio/reorder-i586 - makefiles/mapfiles/libverify/reorder-i586 - makefiles/mapfiles/libzip/reorder-i586 - makefiles/sun/xawt/ToBin.java ! src/share/classes/java/security/BasicPermission.java ! src/share/classes/java/sql/SQLPermission.java ! src/share/classes/java/util/PropertyPermission.java ! src/share/classes/javax/net/ssl/SSLPermission.java - src/share/classes/sun/net/www/protocol/gopher/GopherClient.java - src/share/classes/sun/net/www/protocol/gopher/Handler.java Changeset: d7ed56d57d97 Author: mullan Date: 2012-11-26 08:34 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d7ed56d57d97 Merge From Alan.Bateman at oracle.com Mon Nov 26 14:31:27 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 26 Nov 2012 14:31:27 +0000 Subject: RFR: 8003322: Add instrumentation points for tracing of I/O calls In-Reply-To: References: <50A39388.8060502@oracle.com> <50AA0142.3080502@oracle.com> <28479F37-C81B-4CFB-811A-CEC45755B26B@oracle.com> <50AA279B.7060505@oracle.com> <7C9B7EE6-E9BB-4F4C-81BD-B8AECE689739@oracle.com> <50AB91AE.4040909@oracle.com> <50ABBE28.70907@oracle.com> Message-ID: <50B37D3F.2050405@oracle.com> On 26/11/2012 09:40, Staffan Larsen wrote: > A webrev for the changes going into 7u12 is here: > http://cr.openjdk.java.net/~sla/8003322/webrev.jdk7.00/ > > I think the changes are fine for 7u12 and we look forward to a less invasive solution for jdk8. -Alan From paul.sandoz at oracle.com Mon Nov 26 15:18:08 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 26 Nov 2012 16:18:08 +0100 Subject: 8003949: LogManager, downgrade normative reference to ${java.home}/lib/logging.properties In-Reply-To: <50B2969F.8040101@oracle.com> References: <50B2969F.8040101@oracle.com> Message-ID: Hi Alan, + * If neither of these properties is defined then the LogManager uses its + * default configuration. The default configuration is typically loaded from the + * properties file "{@code lib/logging.properties}" in the Java installation + * directory. Will typical become atypical for OpenJDK by the time Java 9 ships? Paul. On Nov 25, 2012, at 11:07 PM, Alan Bateman wrote: > > As part of preparing for modules [1], we need to examine a number of normative references to files in ${java.home} with a view to downgrading these references to non-normative status. This is important as we need the flexibility to eventually move some of these files into module-private locations, maybe in some cases replace them with something else. This is something I've bought up on security-dev and i18n-dev recently as there are number of references to files in ${java.home} that need to be examined. > > The focus of this mail is java.util.logging.LogManager as it specifies that the default configuration is loaded from ${java.home}/lib/logging.properties. Clearly this file is changed in some environments, although running with java.util.logging.config.file is probably more robust in that the settings can be used with different JDK installations. The proposed changes (javadoc changes only, no implementation changes) is here: > http://cr.openjdk.java.net/~alanb/8003949/webrev/ > > Note that I have also removed the statement that "properties may be set via the Preference API" as the implementation has never used the preferences and not worth re-visiting now. > > -Alan > > [1] http://openjdk.java.net/jeps/162 From Alan.Bateman at oracle.com Mon Nov 26 15:52:48 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 26 Nov 2012 15:52:48 +0000 Subject: 8003949: LogManager, downgrade normative reference to ${java.home}/lib/logging.properties In-Reply-To: References: <50B2969F.8040101@oracle.com> Message-ID: <50B39050.4070800@oracle.com> On 26/11/2012 15:18, Paul Sandoz wrote: > Hi Alan, > > + * If neither of these properties is defined then the LogManager uses its > + * default configuration. The default configuration is typically loaded from the > + * properties file "{@code lib/logging.properties}" in the Java installation > + * directory. > > Will typical become atypical for OpenJDK by the time Java 9 ships? > It's possible although in the current jigsaw/jigsaw builds we have retained this and other files that users might change in their original location. The javadoc change, along with a few others in the pipe, will lesson the impact of moving to a modules image a module-private configuration. -Alan. From mandy.chung at oracle.com Mon Nov 26 17:40:09 2012 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 26 Nov 2012 09:40:09 -0800 Subject: 8003949: LogManager, downgrade normative reference to ${java.home}/lib/logging.properties In-Reply-To: <50B2969F.8040101@oracle.com> References: <50B2969F.8040101@oracle.com> Message-ID: <50B3A979.1020805@oracle.com> On 11/25/12 2:07 PM, Alan Bateman wrote: > > ... > > The focus of this mail is java.util.logging.LogManager as it specifies > that the default configuration is loaded from > ${java.home}/lib/logging.properties. Clearly this file is changed in > some environments, although running with java.util.logging.config.file > is probably more robust in that the settings can be used with > different JDK installations. The proposed changes (javadoc changes > only, no implementation changes) is here: > http://cr.openjdk.java.net/~alanb/8003949/webrev/ > This looks fine with me. > Note that I have also removed the statement that "properties may be > set via the Preference API" as the implementation has never used the > preferences and not worth re-visiting now. > I agree that it's good to take this statement out. Mandy From mandy.chung at oracle.com Mon Nov 26 18:31:15 2012 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 26 Nov 2012 10:31:15 -0800 Subject: RFR: 8003322: Add instrumentation points for tracing of I/O calls In-Reply-To: References: <50A39388.8060502@oracle.com> <50AA0142.3080502@oracle.com> <28479F37-C81B-4CFB-811A-CEC45755B26B@oracle.com> <50AA279B.7060505@oracle.com> <7C9B7EE6-E9BB-4F4C-81BD-B8AECE689739@oracle.com> <50AB91AE.4040909@oracle.com> <50ABBE28.70907@oracle.com> Message-ID: <50B3B573.3000902@oracle.com> On 11/26/12 1:40 AM, Staffan Larsen wrote: > A webrev for the changes going into 7u12 is here: > http://cr.openjdk.java.net/~sla/8003322/webrev.jdk7.00/ > The changes look fine for 7u12. Thanks for looking into the dynamic bytecode instrumentation solution for jdk8. Mandy From lance.andersen at oracle.com Mon Nov 26 19:44:47 2012 From: lance.andersen at oracle.com (Lance Andersen - Oracle) Date: Mon, 26 Nov 2012 14:44:47 -0500 Subject: Adding field to BatchUpdateException In-Reply-To: <50B3117F.7090305@oracle.com> References: <52053C90-5BC1-4FED-A75A-C4015D5F5CD4@oracle.com> <50B3117F.7090305@oracle.com> Message-ID: Hi Joe, Thank you for the sanity check. I had added the following to the top of the javadoc (still playing with the wording): As of Java SE 8, the method getLargeUpdateCount has been added to provide support for update counts that may be exceed Integer.MAX_VALUE and returned by the method Statement.executeLargeBatch. A JDBC driver implementation is required to throw BatchUpdateException(String reason, String SQLState, int vendorCode, long []updateCounts,Throwable cause) if an error occurs during the the execution of Statement.executeLargeBatch. If Statement.executeLargeBatch is invoked it is recommended that getLargeUpdateCounts be called instead of getUpdateCounts in order to avoid a possible overflow of the integer update count. Best Lance On Nov 26, 2012, at 1:51 AM, Joe Darcy wrote: > Hi Lance, > > I don't see an obvious problem with the code, but I strongly suggest documenting the correctness conditions regarding the updateCounts and longUpdateCounts fields; I think that would ease reviewing the new constructors and serialization code. > > Cheers, > > -Joe > > On 11/24/2012 2:05 PM, Lance Andersen - Oracle wrote: >> Hi, >> >> For JDBC 4.2, I am adding methods to allow for larger update counts (request from JDBC driver vendors) and because of this I have to tweak BatchUpdateException >> >> The Statement interface has the method >> >> int[] executeBatch() >> >> I am planning to add >> >> long[] executeLargeBatch(). >> >> To accomodate this change, I also need to add a new field and the method getLargeUpdateCount to BatchUpdateException. >> >> I have exchanged emails on this with Alan and he indicated that the changes seemed reasonable but to send a general email out to see if anything was missed from the serialization perspective. >> >> I have added JDBC Unit tests to validate that the serialization/deserialization works between JDBC 4.1 and JDBC 4.2 and they run without a problem. >> >> >> Best >> Lance >> >> new-host-2:sql lanceandersen$ diff BatchUpdateException.java ~/NetBeansProjects/JDBC4.2/jdbc4.0/src/java/sql/ >> 2c2 >> < * Copyright (c) 1998, 2011, Oracle and/or its affiliates. All rights reserved. >> --- >>> * Copyright (c) 1998, 2012, Oracle and/or its affiliates. All rights reserved. >> 27a28,31 >>> import java.io.IOException; >>> import java.io.InvalidObjectException; >>> import java.io.ObjectInputStream; >>> import java.io.ObjectOutputStream; >> 83a88 >>> this.longUpdateCounts = (updateCounts == null) ? null : copyUpdateCount(updateCounts); >> 192c197 >> < this((cause == null ? null : cause.toString()), null, 0, null, cause); >> --- >>> this((cause == null ? null : cause.toString()), null, 0, (int[])null, cause); >> 295a301 >>> this.longUpdateCounts = (updateCounts == null) ? null : copyUpdateCount(updateCounts); >> 331c337,401 >> < >> --- >>> /** >>> * Constructs a BatchUpdateException object initialized with >>> * a given reason, SQLState, vendorCode >>> * cause and updateCounts. >>> *

>>> * This constructor should be used when the returned update count may exceed >>> * {@link Integer.MAX_VALUE}. >>> *

>>> * @param reason a description of the error >>> * @param SQLState an XOPEN or SQL:2003 code identifying the exception >>> * @param vendorCode an exception code used by a particular >>> * database vendor >>> * @param updateCounts an array of long, with each element >>> *indicating the update count, Statement.SUCCESS_NO_INFO or >>> * Statement.EXECUTE_FAILED for each SQL command in >>> * the batch for JDBC drivers that continue processing >>> * after a command failure; an update count or >>> * Statement.SUCCESS_NO_INFO for each SQL command in the batch >>> * prior to the failure for JDBC drivers that stop processing after a command >>> * failure >>> * @param cause the underlying reason for this SQLException >>> * (which is saved for later retrieval by the getCause() method); >>> * may be null indicating the cause is non-existent or unknown. >>> * @since 1.8 >>> */ >>> public BatchUpdateException(String reason, String SQLState, int vendorCode, >>> long []updateCounts,Throwable cause) { >>> super(reason, SQLState, vendorCode, cause); >>> this.longUpdateCounts = (updateCounts == null) ? null : Arrays.copyOf(updateCounts, updateCounts.length); >>> this.updateCounts = (longUpdateCounts == null) ? null : copyUpdateCount(longUpdateCounts); >>> } >>> /** >>> * Retrieves the update count for each update statement in the batch >>> * update that executed successfully before this exception occurred. >>> * A driver that implements batch updates may or may not continue to >>> * process the remaining commands in a batch when one of the commands >>> * fails to execute properly. If the driver continues processing commands, >>> * the array returned by this method will have as many elements as >>> * there are commands in the batch; otherwise, it will contain an >>> * update count for each command that executed successfully before >>> * the BatchUpdateException was thrown. >>> *

>>> * This method should be used when the returned update count may exceed >>> * {@link Integer.MAX_VALUE}. >>> *

>>> * @return an array of long containing the update counts >>> * for the updates that were executed successfully before this error >>> * occurred. Or, if the driver continues to process commands after an >>> * error, one of the following for every command in the batch: >>> *

    >>> *
  1. an update count >>> *
  2. Statement.SUCCESS_NO_INFO to indicate that the command >>> * executed successfully but the number of rows affected is unknown >>> *
  3. Statement.EXECUTE_FAILED to indicate that the command >>> * failed to execute successfully >>> *
>>> * @since 1.8 >>> */ >>> public long[] getLargeUpdateCounts() { >>> return (longUpdateCounts == null) ? null : >>> Arrays.copyOf(longUpdateCounts, longUpdateCounts.length); >>> } >>> >> 337c407,414 >> < private final int[] updateCounts; >> --- >>> private int[] updateCounts; >>> >>> /** >>> * The array that describes the outcome of a batch execution. >>> * @serial >>> * @since 1.8 >>> */ >>> private long[] longUpdateCounts; >> 339a417,474 >>> /* >>> * Utility method to copy int[] updateCount to long[] updateCount >>> */ >>> private static long[] copyUpdateCount(int[] uc) { >>> long[] copy = new long[uc.length]; >>> for(int i= 0; i< uc.length; i++) { >>> copy[i] = uc[i]; >>> } >>> return copy; >>> } >>> /* >>> * Utility method to copy int[] updateCount to long[] updateCount >>> */ >>> private static int[] copyUpdateCount(long[] uc) { >>> int[] copy = new int[uc.length]; >>> for(int i= 0; i< uc.length; i++) { >>> copy[i] = (int) uc[i]; >>> } >>> return copy; >>> } >>> /** >>> * readObject is called to restore the state of the >>> * {@code BatchUpdateException} from a stream. >>> */ >>> private void readObject(ObjectInputStream s) >>> throws IOException, ClassNotFoundException { >>> ObjectInputStream.GetField fields = s.readFields(); >>> int[] tmp = (int[])fields.get("updateCounts", null); >>> long[] tmp2 = (long[])fields.get("longUpdateCounts", null); >>> if(tmp != null && tmp2 != null && tmp.length != tmp2.length) >>> throw new InvalidObjectException("update counts are not the expected size"); >>> if (tmp != null) >>> updateCounts = tmp.clone(); >>> if (tmp2 != null) >>> longUpdateCounts = tmp2.clone(); >>> if(updateCounts == null && longUpdateCounts != null) >>> updateCounts = copyUpdateCount(longUpdateCounts); >>> if(longUpdateCounts == null && updateCounts != null) >>> longUpdateCounts = copyUpdateCount(updateCounts); >>> >>> } >>> /** >>> * writeObject is called to save the state of the {@code BatchUpdateException} >>> * to a stream. >>> */ >>> private void writeObject(ObjectOutputStream s) >>> throws IOException, ClassNotFoundException { >>> >>> ObjectOutputStream.PutField fields = s.putFields(); >>> fields.put("updateCounts", updateCounts); >>> fields.put("longUpdateCounts", longUpdateCounts); >>> s.writeFields(); >>> } >> >> >> 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 >> >> > -------------- next part -------------- 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 Ulf.Zibis at CoSoCo.de Mon Nov 26 22:10:48 2012 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Mon, 26 Nov 2012 23:10:48 +0100 Subject: Adding field to BatchUpdateException In-Reply-To: References: <52053C90-5BC1-4FED-A75A-C4015D5F5CD4@oracle.com> <50B3117F.7090305@oracle.com> Message-ID: <50B3E8E8.3000602@CoSoCo.de> Hi Lance, I would throw an IllegalStateException if invoking e.g. getUpdateCounts on integer overflow. -Ulf Am 26.11.2012 20:44, schrieb Lance Andersen - Oracle: > Hi Joe, > > Thank you for the sanity check. > > I had added the following to the top of the javadoc (still playing with the wording): > > As of Java SE 8, the method getLargeUpdateCount has been added to provide support for update counts that may be exceed Integer.MAX_VALUE and returned by the method Statement.executeLargeBatch. A JDBC driver implementation is required to throw BatchUpdateException(String reason, String SQLState, int vendorCode, long []updateCounts,Throwable cause) if an error occurs during the the execution of Statement.executeLargeBatch. If Statement.executeLargeBatch is invoked it is recommended that getLargeUpdateCounts be called instead of getUpdateCounts in order to avoid a possible overflow of the integer update count. > > > Best > Lance > > On Nov 26, 2012, at 1:51 AM, Joe Darcy wrote: > >> Hi Lance, >> >> I don't see an obvious problem with the code, but I strongly suggest documenting the correctness conditions regarding the updateCounts and longUpdateCounts fields; I think that would ease reviewing the new constructors and serialization code. >> >> Cheers, >> >> -Joe >> >> On 11/24/2012 2:05 PM, Lance Andersen - Oracle wrote: >>> Hi, >>> >>> For JDBC 4.2, I am adding methods to allow for larger update counts (request from JDBC driver vendors) and because of this I have to tweak BatchUpdateException >>> >>> The Statement interface has the method >>> >>> int[] executeBatch() >>> >>> I am planning to add >>> >>> long[] executeLargeBatch(). >>> >>> To accomodate this change, I also need to add a new field and the method getLargeUpdateCount to BatchUpdateException. >>> >>> I have exchanged emails on this with Alan and he indicated that the changes seemed reasonable but to send a general email out to see if anything was missed from the serialization perspective. >>> >>> I have added JDBC Unit tests to validate that the serialization/deserialization works between JDBC 4.1 and JDBC 4.2 and they run without a problem. >>> >>> >>> Best >>> Lance >>> >>> new-host-2:sql lanceandersen$ diff BatchUpdateException.java ~/NetBeansProjects/JDBC4.2/jdbc4.0/src/java/sql/ >>> 2c2 >>> < * Copyright (c) 1998, 2011, Oracle and/or its affiliates. All rights reserved. >>> --- >>>> * Copyright (c) 1998, 2012, Oracle and/or its affiliates. All rights reserved. >>> 27a28,31 >>>> import java.io.IOException; >>>> import java.io.InvalidObjectException; >>>> import java.io.ObjectInputStream; >>>> import java.io.ObjectOutputStream; >>> 83a88 >>>> this.longUpdateCounts = (updateCounts == null) ? null : copyUpdateCount(updateCounts); >>> 192c197 >>> < this((cause == null ? null : cause.toString()), null, 0, null, cause); >>> --- >>>> this((cause == null ? null : cause.toString()), null, 0, (int[])null, cause); >>> 295a301 >>>> this.longUpdateCounts = (updateCounts == null) ? null : copyUpdateCount(updateCounts); >>> 331c337,401 >>> < >>> --- >>>> /** >>>> * Constructs a BatchUpdateException object initialized with >>>> * a given reason, SQLState, vendorCode >>>> * cause and updateCounts. >>>> *

>>>> * This constructor should be used when the returned update count may exceed >>>> * {@link Integer.MAX_VALUE}. >>>> *

>>>> * @param reason a description of the error >>>> * @param SQLState an XOPEN or SQL:2003 code identifying the exception >>>> * @param vendorCode an exception code used by a particular >>>> * database vendor >>>> * @param updateCounts an array of long, with each element >>>> *indicating the update count, Statement.SUCCESS_NO_INFO or >>>> * Statement.EXECUTE_FAILED for each SQL command in >>>> * the batch for JDBC drivers that continue processing >>>> * after a command failure; an update count or >>>> * Statement.SUCCESS_NO_INFO for each SQL command in the batch >>>> * prior to the failure for JDBC drivers that stop processing after a command >>>> * failure >>>> * @param cause the underlying reason for this SQLException >>>> * (which is saved for later retrieval by the getCause() method); >>>> * may be null indicating the cause is non-existent or unknown. >>>> * @since 1.8 >>>> */ >>>> public BatchUpdateException(String reason, String SQLState, int vendorCode, >>>> long []updateCounts,Throwable cause) { >>>> super(reason, SQLState, vendorCode, cause); >>>> this.longUpdateCounts = (updateCounts == null) ? null : Arrays.copyOf(updateCounts, updateCounts.length); >>>> this.updateCounts = (longUpdateCounts == null) ? null : copyUpdateCount(longUpdateCounts); >>>> } >>>> /** >>>> * Retrieves the update count for each update statement in the batch >>>> * update that executed successfully before this exception occurred. >>>> * A driver that implements batch updates may or may not continue to >>>> * process the remaining commands in a batch when one of the commands >>>> * fails to execute properly. If the driver continues processing commands, >>>> * the array returned by this method will have as many elements as >>>> * there are commands in the batch; otherwise, it will contain an >>>> * update count for each command that executed successfully before >>>> * the BatchUpdateException was thrown. >>>> *

>>>> * This method should be used when the returned update count may exceed >>>> * {@link Integer.MAX_VALUE}. >>>> *

>>>> * @return an array of long containing the update counts >>>> * for the updates that were executed successfully before this error >>>> * occurred. Or, if the driver continues to process commands after an >>>> * error, one of the following for every command in the batch: >>>> *

    >>>> *
  1. an update count >>>> *
  2. Statement.SUCCESS_NO_INFO to indicate that the command >>>> * executed successfully but the number of rows affected is unknown >>>> *
  3. Statement.EXECUTE_FAILED to indicate that the command >>>> * failed to execute successfully >>>> *
>>>> * @since 1.8 >>>> */ >>>> public long[] getLargeUpdateCounts() { >>>> return (longUpdateCounts == null) ? null : >>>> Arrays.copyOf(longUpdateCounts, longUpdateCounts.length); >>>> } >>>> >>> 337c407,414 >>> < private final int[] updateCounts; >>> --- >>>> private int[] updateCounts; >>>> >>>> /** >>>> * The array that describes the outcome of a batch execution. >>>> * @serial >>>> * @since 1.8 >>>> */ >>>> private long[] longUpdateCounts; >>> 339a417,474 >>>> /* >>>> * Utility method to copy int[] updateCount to long[] updateCount >>>> */ >>>> private static long[] copyUpdateCount(int[] uc) { >>>> long[] copy = new long[uc.length]; >>>> for(int i= 0; i< uc.length; i++) { >>>> copy[i] = uc[i]; >>>> } >>>> return copy; >>>> } >>>> /* >>>> * Utility method to copy int[] updateCount to long[] updateCount >>>> */ >>>> private static int[] copyUpdateCount(long[] uc) { >>>> int[] copy = new int[uc.length]; >>>> for(int i= 0; i< uc.length; i++) { >>>> copy[i] = (int) uc[i]; >>>> } >>>> return copy; >>>> } >>>> /** >>>> * readObject is called to restore the state of the >>>> * {@code BatchUpdateException} from a stream. >>>> */ >>>> private void readObject(ObjectInputStream s) >>>> throws IOException, ClassNotFoundException { >>>> ObjectInputStream.GetField fields = s.readFields(); >>>> int[] tmp = (int[])fields.get("updateCounts", null); >>>> long[] tmp2 = (long[])fields.get("longUpdateCounts", null); >>>> if(tmp != null && tmp2 != null && tmp.length != tmp2.length) >>>> throw new InvalidObjectException("update counts are not the expected size"); >>>> if (tmp != null) >>>> updateCounts = tmp.clone(); >>>> if (tmp2 != null) >>>> longUpdateCounts = tmp2.clone(); >>>> if(updateCounts == null && longUpdateCounts != null) >>>> updateCounts = copyUpdateCount(longUpdateCounts); >>>> if(longUpdateCounts == null && updateCounts != null) >>>> longUpdateCounts = copyUpdateCount(updateCounts); >>>> >>>> } >>>> /** >>>> * writeObject is called to save the state of the {@code BatchUpdateException} >>>> * to a stream. >>>> */ >>>> private void writeObject(ObjectOutputStream s) >>>> throws IOException, ClassNotFoundException { >>>> >>>> ObjectOutputStream.PutField fields = s.putFields(); >>>> fields.put("updateCounts", updateCounts); >>>> fields.put("longUpdateCounts", longUpdateCounts); >>>> s.writeFields(); >>>> } >>> >>> 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 Nov 26 22:19:15 2012 From: lance.andersen at oracle.com (Lance Andersen - Oracle) Date: Mon, 26 Nov 2012 17:19:15 -0500 Subject: Adding field to BatchUpdateException In-Reply-To: <50B3E8E8.3000602@CoSoCo.de> References: <52053C90-5BC1-4FED-A75A-C4015D5F5CD4@oracle.com> <50B3117F.7090305@oracle.com> <50B3E8E8.3000602@CoSoCo.de> Message-ID: <8FB3EEEE-9427-4CD8-B979-E2705C7240BB@oracle.com> Hi Ulf, Thank you for the suggestion The current spec is silent on what happens if the update count overflows for any executeUpdate method. Today the driver vendors just pass in their array of UpdateCounts (or status) to BatchException (or overflow the return count from executeUpdate) if an error occurs at some point along the way. I really would prefer to not change any existing behavior here at all. If application programmers care about the update count, then they will switch to new xxxLarge methods. Best Lance On Nov 26, 2012, at 5:10 PM, Ulf Zibis wrote: > Hi Lance, > > I would throw an IllegalStateException if invoking e.g. getUpdateCounts on integer overflow. > > -Ulf > > > Am 26.11.2012 20:44, schrieb Lance Andersen - Oracle: >> Hi Joe, >> >> Thank you for the sanity check. >> >> I had added the following to the top of the javadoc (still playing with the wording): >> >> As of Java SE 8, the method getLargeUpdateCount has been added to provide support for update counts that may be exceed Integer.MAX_VALUE and returned by the method Statement.executeLargeBatch. A JDBC driver implementation is required to throw BatchUpdateException(String reason, String SQLState, int vendorCode, long []updateCounts,Throwable cause) if an error occurs during the the execution of Statement.executeLargeBatch. If Statement.executeLargeBatch is invoked it is recommended that getLargeUpdateCounts be called instead of getUpdateCounts in order to avoid a possible overflow of the integer update count. >> >> >> Best >> Lance >> >> On Nov 26, 2012, at 1:51 AM, Joe Darcy wrote: >> >>> Hi Lance, >>> >>> I don't see an obvious problem with the code, but I strongly suggest documenting the correctness conditions regarding the updateCounts and longUpdateCounts fields; I think that would ease reviewing the new constructors and serialization code. >>> >>> Cheers, >>> >>> -Joe >>> >>> On 11/24/2012 2:05 PM, Lance Andersen - Oracle wrote: >>>> Hi, >>>> >>>> For JDBC 4.2, I am adding methods to allow for larger update counts (request from JDBC driver vendors) and because of this I have to tweak BatchUpdateException >>>> >>>> The Statement interface has the method >>>> >>>> int[] executeBatch() >>>> >>>> I am planning to add >>>> >>>> long[] executeLargeBatch(). >>>> >>>> To accomodate this change, I also need to add a new field and the method getLargeUpdateCount to BatchUpdateException. >>>> >>>> I have exchanged emails on this with Alan and he indicated that the changes seemed reasonable but to send a general email out to see if anything was missed from the serialization perspective. >>>> >>>> I have added JDBC Unit tests to validate that the serialization/deserialization works between JDBC 4.1 and JDBC 4.2 and they run without a problem. >>>> >>>> >>>> Best >>>> Lance >>>> >>>> new-host-2:sql lanceandersen$ diff BatchUpdateException.java ~/NetBeansProjects/JDBC4.2/jdbc4.0/src/java/sql/ >>>> 2c2 >>>> < * Copyright (c) 1998, 2011, Oracle and/or its affiliates. All rights reserved. >>>> --- >>>>> * Copyright (c) 1998, 2012, Oracle and/or its affiliates. All rights reserved. >>>> 27a28,31 >>>>> import java.io.IOException; >>>>> import java.io.InvalidObjectException; >>>>> import java.io.ObjectInputStream; >>>>> import java.io.ObjectOutputStream; >>>> 83a88 >>>>> this.longUpdateCounts = (updateCounts == null) ? null : copyUpdateCount(updateCounts); >>>> 192c197 >>>> < this((cause == null ? null : cause.toString()), null, 0, null, cause); >>>> --- >>>>> this((cause == null ? null : cause.toString()), null, 0, (int[])null, cause); >>>> 295a301 >>>>> this.longUpdateCounts = (updateCounts == null) ? null : copyUpdateCount(updateCounts); >>>> 331c337,401 >>>> < >>>> --- >>>>> /** >>>>> * Constructs a BatchUpdateException object initialized with >>>>> * a given reason, SQLState, vendorCode >>>>> * cause and updateCounts. >>>>> *

>>>>> * This constructor should be used when the returned update count may exceed >>>>> * {@link Integer.MAX_VALUE}. >>>>> *

>>>>> * @param reason a description of the error >>>>> * @param SQLState an XOPEN or SQL:2003 code identifying the exception >>>>> * @param vendorCode an exception code used by a particular >>>>> * database vendor >>>>> * @param updateCounts an array of long, with each element >>>>> *indicating the update count, Statement.SUCCESS_NO_INFO or >>>>> * Statement.EXECUTE_FAILED for each SQL command in >>>>> * the batch for JDBC drivers that continue processing >>>>> * after a command failure; an update count or >>>>> * Statement.SUCCESS_NO_INFO for each SQL command in the batch >>>>> * prior to the failure for JDBC drivers that stop processing after a command >>>>> * failure >>>>> * @param cause the underlying reason for this SQLException >>>>> * (which is saved for later retrieval by the getCause() method); >>>>> * may be null indicating the cause is non-existent or unknown. >>>>> * @since 1.8 >>>>> */ >>>>> public BatchUpdateException(String reason, String SQLState, int vendorCode, >>>>> long []updateCounts,Throwable cause) { >>>>> super(reason, SQLState, vendorCode, cause); >>>>> this.longUpdateCounts = (updateCounts == null) ? null : Arrays.copyOf(updateCounts, updateCounts.length); >>>>> this.updateCounts = (longUpdateCounts == null) ? null : copyUpdateCount(longUpdateCounts); >>>>> } >>>>> /** >>>>> * Retrieves the update count for each update statement in the batch >>>>> * update that executed successfully before this exception occurred. >>>>> * A driver that implements batch updates may or may not continue to >>>>> * process the remaining commands in a batch when one of the commands >>>>> * fails to execute properly. If the driver continues processing commands, >>>>> * the array returned by this method will have as many elements as >>>>> * there are commands in the batch; otherwise, it will contain an >>>>> * update count for each command that executed successfully before >>>>> * the BatchUpdateException was thrown. >>>>> *

>>>>> * This method should be used when the returned update count may exceed >>>>> * {@link Integer.MAX_VALUE}. >>>>> *

>>>>> * @return an array of long containing the update counts >>>>> * for the updates that were executed successfully before this error >>>>> * occurred. Or, if the driver continues to process commands after an >>>>> * error, one of the following for every command in the batch: >>>>> *

    >>>>> *
  1. an update count >>>>> *
  2. Statement.SUCCESS_NO_INFO to indicate that the command >>>>> * executed successfully but the number of rows affected is unknown >>>>> *
  3. Statement.EXECUTE_FAILED to indicate that the command >>>>> * failed to execute successfully >>>>> *
>>>>> * @since 1.8 >>>>> */ >>>>> public long[] getLargeUpdateCounts() { >>>>> return (longUpdateCounts == null) ? null : >>>>> Arrays.copyOf(longUpdateCounts, longUpdateCounts.length); >>>>> } >>>>> >>>> 337c407,414 >>>> < private final int[] updateCounts; >>>> --- >>>>> private int[] updateCounts; >>>>> >>>>> /** >>>>> * The array that describes the outcome of a batch execution. >>>>> * @serial >>>>> * @since 1.8 >>>>> */ >>>>> private long[] longUpdateCounts; >>>> 339a417,474 >>>>> /* >>>>> * Utility method to copy int[] updateCount to long[] updateCount >>>>> */ >>>>> private static long[] copyUpdateCount(int[] uc) { >>>>> long[] copy = new long[uc.length]; >>>>> for(int i= 0; i< uc.length; i++) { >>>>> copy[i] = uc[i]; >>>>> } >>>>> return copy; >>>>> } >>>>> /* >>>>> * Utility method to copy int[] updateCount to long[] updateCount >>>>> */ >>>>> private static int[] copyUpdateCount(long[] uc) { >>>>> int[] copy = new int[uc.length]; >>>>> for(int i= 0; i< uc.length; i++) { >>>>> copy[i] = (int) uc[i]; >>>>> } >>>>> return copy; >>>>> } >>>>> /** >>>>> * readObject is called to restore the state of the >>>>> * {@code BatchUpdateException} from a stream. >>>>> */ >>>>> private void readObject(ObjectInputStream s) >>>>> throws IOException, ClassNotFoundException { >>>>> ObjectInputStream.GetField fields = s.readFields(); >>>>> int[] tmp = (int[])fields.get("updateCounts", null); >>>>> long[] tmp2 = (long[])fields.get("longUpdateCounts", null); >>>>> if(tmp != null && tmp2 != null && tmp.length != tmp2.length) >>>>> throw new InvalidObjectException("update counts are not the expected size"); >>>>> if (tmp != null) >>>>> updateCounts = tmp.clone(); >>>>> if (tmp2 != null) >>>>> longUpdateCounts = tmp2.clone(); >>>>> if(updateCounts == null && longUpdateCounts != null) >>>>> updateCounts = copyUpdateCount(longUpdateCounts); >>>>> if(longUpdateCounts == null && updateCounts != null) >>>>> longUpdateCounts = copyUpdateCount(updateCounts); >>>>> >>>>> } >>>>> /** >>>>> * writeObject is called to save the state of the {@code BatchUpdateException} >>>>> * to a stream. >>>>> */ >>>>> private void writeObject(ObjectOutputStream s) >>>>> throws IOException, ClassNotFoundException { >>>>> >>>>> ObjectOutputStream.PutField fields = s.putFields(); >>>>> fields.put("updateCounts", updateCounts); >>>>> fields.put("longUpdateCounts", longUpdateCounts); >>>>> s.writeFields(); >>>>> } >>>> >>>> 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 Nov 26 23:08:48 2012 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Mon, 26 Nov 2012 23:08:48 +0000 Subject: hg: jdk8/tl/jdk: 8001634: Initial set of functional interface types Message-ID: <20121126230909.6075A47B30@hg.openjdk.java.net> Changeset: c2e80176a697 Author: mduigou Date: 2012-11-26 15:08 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c2e80176a697 8001634: Initial set of functional interface types Summary: Add the core functional interfaces used by the JSR335 libraries. Reviewed-by: dholmes, briangoetz, darcy ! make/docs/CORE_PKGS.gmk ! make/java/java/Makefile + src/share/classes/java/util/function/BinaryOperator.java + src/share/classes/java/util/function/Block.java + src/share/classes/java/util/function/DoubleBinaryOperator.java + src/share/classes/java/util/function/DoubleBlock.java + src/share/classes/java/util/function/DoubleFunction.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/IntFunction.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/LongFunction.java + src/share/classes/java/util/function/LongSupplier.java + src/share/classes/java/util/function/LongUnaryOperator.java + src/share/classes/java/util/function/Predicate.java + src/share/classes/java/util/function/Supplier.java + src/share/classes/java/util/function/UnaryOperator.java + src/share/classes/java/util/function/package-info.java From mike.duigou at oracle.com Tue Nov 27 02:12:40 2012 From: mike.duigou at oracle.com (Mike Duigou) Date: Mon, 26 Nov 2012 18:12:40 -0800 Subject: Request for Review : CR#8004015 : Add interface extends and defaults for basic functional interfaces Message-ID: Hello all; In the original patch which added the basic lambda functional interfaces, CR#8001634 [1], none of the interfaces extended other interfaces. The reason was primarily that the javac compiler did not, at the time that 8001634 was proposed, support extension methods. The compiler now supports adding of method defaults so this patch improves the functional interfaces by filing in the inheritance hierarchy. Adding the parent interfaces and default methods allows each functional interface to be used in more places. It is especially important for the functional interfaces which support primitive types, IntSupplier, IntFunction, IntUnaryOperator, IntBinaryOperator, etc. We expect that eventually standard implementations of these interfaces will be provided for functions like max, min, sum, etc. By extending the reference oriented functional interfaces such as Function, the primitive implementations can be used with the boxed primitive types along with the primitive types for which they are defined. The patch to add parent interfaces and default methods can be found here: http://cr.openjdk.java.net/~mduigou/8004015/0/webrev/ http://cr.openjdk.java.net/~mduigou/8004015/0/specdiff/java/util/function/package-summary.html Mike [1] http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c2e80176a697 From martinrb at google.com Tue Nov 27 06:47:19 2012 From: martinrb at google.com (Martin Buchholz) Date: Mon, 26 Nov 2012 22:47:19 -0800 Subject: Request for Review: 5049299: (process) Use posix_spawn, not fork, on S10 to avoid swap exhaustion In-Reply-To: <50AF646C.4040809@oracle.com> References: <50AE98B1.2040200@oracle.com> <50AF646C.4040809@oracle.com> Message-ID: Rob, Thanks for taking on this big scary change. Our experience having run with the vfork based implementation on Linux has been very positive. This addresses a real need that is shared by all big processes that desire offspring. You might want to look through my comments from the last round of review, back when I had more brain cells. I agree giving people the choice to use the algorithm using a system property is a good one. The strategy of using posix_spawn of a small helper process seems good (more portable than vfork or clone). If it works well universally, you might even consider making it the default on Linux (although I worry about - if it works, don't break it). clone is not known to work reliably (I tried and failed). I would leave it #ifdef'ed out by default. don't put the helper program in JAVAHOME/bin because users should never invoke it directly - it shouldn't be on anyone's PATH. Not sure why so many dirs in HELPERLDFLAGS. I would think that the prochelper program would be a tiny C programs with no need to pull in any other jdk libraries. + String osarch = System.getProperty("os.arch"); + if (osarch.equals("sparcv9") || osarch.equals("amd64")) { + osarch += "/"; On Solaris bi-arch I think you need only one jprochelper, not two, since a 32-bit helper can exec a 64-bit subprocess. +#if defined(__solaris__) || defined(__APPLE__) +#include +#endif I think you want to autoconfiscate something like HAVE_POSIX_SPAWN instead. +#ifdef _CS_PATH I would separate out smaller less risky improvements like use of _CS_PATH into a separate change. Martin On Fri, Nov 23, 2012 at 3:56 AM, Alan Bateman wrote: > On 22/11/2012 21:27, Rob McKenna wrote: > >> Hi folks, >> >> Looking for a review for the webrev below, which also resolves: >> >> 7175692: (process) Process.exec should use posix_spawn [macosx] >> >> For additional context and a brief description it would be well worth >> looking at the following thread started by Michael McMahon, who did the >> brunt of the work for this fix: >> >> http://mail.openjdk.java.net/**pipermail/core-libs-dev/2009-** >> May/thread.html#1644 >> >> Basically the fix aims to swap fork for posix_spawn as the default >> process launch mechanism on Solaris and Mac OSX in order to avoid swap >> exhaustion issues encountered with fork()/exec(). It also offers a flag >> (java.lang.useFork) to allow a user to revert to the old behaviour. >> >> I'm having trouble seeing the wood for the trees at this point so I'm >> anticipating plenty of feedback. In particular I'd appreciate some >> discussion on: >> >> - The binary launcher name & property name may need some work. A more >> general property ("java.lang.launchMechanism") to allow a user to specify a >> particular call was mooted too. It may be more future proof and I'm >> completely open to that. (e.g. launchMechanism=spawn|fork|**vfork|clone >> - we would obviously ignore inapplicable values on a per-platform basis) >> - I'd like a more robust way of checking that someone isn't trying to use >> jprochelper outside of the context for which it is meant. >> - The decision around which call to use getting moved to the java level >> and away from the native preprocessor. >> >> The webrev is at: >> >> http://cr.openjdk.java.net/~**robm/5049299/webrev.01/< >> http://cr.openjdk.java.net/%**7Erobm/5049299/webrev.01/ >> > >> > It's great to get this one moving again, we should have helped Michael > more to get this over the line on the first outing. > > This one will require very careful review, I don't have cycles this week, > I hope others do. For now I think that naming the trampoline jprochelper or > jspawnhelper is okay. To make it more robust then I'd probably prepend a > magic number or some token. Also I'd probably fstat stdin and uses S_FIFO > to check the mode. > > As the property is implementation specific then I think something like > jdk.lang.process.useFork is a better start. It would be nice not to require > it although I agree we have to walk carefully as this area has a tendency > to bite back. I don't think you need to make it any more configurable than > that. > > If this is successful then I think we should look at updating the hotspot > code too as it has the same issue with VM options such as OnError. > > -Alan. > > From peter.levart at gmail.com Tue Nov 27 07:52:50 2012 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 27 Nov 2012 08:52:50 +0100 Subject: AnnotationParser optimization - JEP-149 Message-ID: <50B47152.4020505@gmail.com> Hi all, This might not be much of an improvement, but it is very easy to do: --- a/src/share/classes/sun/reflect/annotation/AnnotationParser.java Thu Nov 15 15:40:03 2012 -0800 +++ b/src/share/classes/sun/reflect/annotation/AnnotationParser.java Tue Nov 27 08:39:58 2012 +0100 @@ -227,7 +227,7 @@ Map> memberTypes = type.memberTypes(); Map memberValues = - new LinkedHashMap(type.memberDefaults()); + new HashMap(type.memberDefaults()); int numMembers = buf.getShort() & 0xFFFF; for (int i = 0; i < numMembers; i++) { It saves 1 OOP and 1 boolean for each Annotation instance + 2 OOPs for each Annotation member value. It changes the serialization format of Annotation instances, but in a way that is backwards and forwards compatible. Semantically it does not present any difference, since the only place that the Map is used is to Map.get(member) in the AnnotationInvocationHandler - it is never iterated. Regards, Peter From joe.darcy at oracle.com Tue Nov 27 08:29:28 2012 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 27 Nov 2012 00:29:28 -0800 Subject: Adding field to BatchUpdateException In-Reply-To: References: <52053C90-5BC1-4FED-A75A-C4015D5F5CD4@oracle.com> <50B3117F.7090305@oracle.com> Message-ID: <50B479E8.0@oracle.com> Hi Lance, As a general comment, I would prefer release-specific information ("As of Java SE 8...") to appear not in javadoc, but in the non-javadoc comments in a class. Such release-specific notes in the specification quickly become out of date. I suggest explicitly documenting how the two fields interact in serialization and in live objects. For example, can at most one be non-null at once, etc. HTH, -Joe On 11/26/2012 11:44 AM, Lance Andersen - Oracle wrote: > Hi Joe, > > Thank you for the sanity check. > > I had added the following to the top of the javadoc (still playing with the wording): > > As of Java SE 8, the method getLargeUpdateCount has been added to provide support for update counts that may be exceed Integer.MAX_VALUE and returned by the method Statement.executeLargeBatch. A JDBC driver implementation is required to throw BatchUpdateException(String reason, String SQLState, int vendorCode, long []updateCounts,Throwable cause) if an error occurs during the the execution of Statement.executeLargeBatch. If Statement.executeLargeBatch is invoked it is recommended that getLargeUpdateCounts be called instead of getUpdateCounts in order to avoid a possible overflow of the integer update count. > > > Best > Lance > > On Nov 26, 2012, at 1:51 AM, Joe Darcy wrote: > >> Hi Lance, >> >> I don't see an obvious problem with the code, but I strongly suggest documenting the correctness conditions regarding the updateCounts and longUpdateCounts fields; I think that would ease reviewing the new constructors and serialization code. >> >> Cheers, >> >> -Joe >> >> On 11/24/2012 2:05 PM, Lance Andersen - Oracle wrote: >>> Hi, >>> >>> For JDBC 4.2, I am adding methods to allow for larger update counts (request from JDBC driver vendors) and because of this I have to tweak BatchUpdateException >>> >>> The Statement interface has the method >>> >>> int[] executeBatch() >>> >>> I am planning to add >>> >>> long[] executeLargeBatch(). >>> >>> To accomodate this change, I also need to add a new field and the method getLargeUpdateCount to BatchUpdateException. >>> >>> I have exchanged emails on this with Alan and he indicated that the changes seemed reasonable but to send a general email out to see if anything was missed from the serialization perspective. >>> >>> I have added JDBC Unit tests to validate that the serialization/deserialization works between JDBC 4.1 and JDBC 4.2 and they run without a problem. >>> >>> >>> Best >>> Lance >>> >>> new-host-2:sql lanceandersen$ diff BatchUpdateException.java ~/NetBeansProjects/JDBC4.2/jdbc4.0/src/java/sql/ >>> 2c2 >>> < * Copyright (c) 1998, 2011, Oracle and/or its affiliates. All rights reserved. >>> --- >>>> * Copyright (c) 1998, 2012, Oracle and/or its affiliates. All rights reserved. >>> 27a28,31 >>>> import java.io.IOException; >>>> import java.io.InvalidObjectException; >>>> import java.io.ObjectInputStream; >>>> import java.io.ObjectOutputStream; >>> 83a88 >>>> this.longUpdateCounts = (updateCounts == null) ? null : copyUpdateCount(updateCounts); >>> 192c197 >>> < this((cause == null ? null : cause.toString()), null, 0, null, cause); >>> --- >>>> this((cause == null ? null : cause.toString()), null, 0, (int[])null, cause); >>> 295a301 >>>> this.longUpdateCounts = (updateCounts == null) ? null : copyUpdateCount(updateCounts); >>> 331c337,401 >>> < >>> --- >>>> /** >>>> * Constructs a BatchUpdateException object initialized with >>>> * a given reason, SQLState, vendorCode >>>> * cause and updateCounts. >>>> *

>>>> * This constructor should be used when the returned update count may exceed >>>> * {@link Integer.MAX_VALUE}. >>>> *

>>>> * @param reason a description of the error >>>> * @param SQLState an XOPEN or SQL:2003 code identifying the exception >>>> * @param vendorCode an exception code used by a particular >>>> * database vendor >>>> * @param updateCounts an array of long, with each element >>>> *indicating the update count, Statement.SUCCESS_NO_INFO or >>>> * Statement.EXECUTE_FAILED for each SQL command in >>>> * the batch for JDBC drivers that continue processing >>>> * after a command failure; an update count or >>>> * Statement.SUCCESS_NO_INFO for each SQL command in the batch >>>> * prior to the failure for JDBC drivers that stop processing after a command >>>> * failure >>>> * @param cause the underlying reason for this SQLException >>>> * (which is saved for later retrieval by the getCause() method); >>>> * may be null indicating the cause is non-existent or unknown. >>>> * @since 1.8 >>>> */ >>>> public BatchUpdateException(String reason, String SQLState, int vendorCode, >>>> long []updateCounts,Throwable cause) { >>>> super(reason, SQLState, vendorCode, cause); >>>> this.longUpdateCounts = (updateCounts == null) ? null : Arrays.copyOf(updateCounts, updateCounts.length); >>>> this.updateCounts = (longUpdateCounts == null) ? null : copyUpdateCount(longUpdateCounts); >>>> } >>>> /** >>>> * Retrieves the update count for each update statement in the batch >>>> * update that executed successfully before this exception occurred. >>>> * A driver that implements batch updates may or may not continue to >>>> * process the remaining commands in a batch when one of the commands >>>> * fails to execute properly. If the driver continues processing commands, >>>> * the array returned by this method will have as many elements as >>>> * there are commands in the batch; otherwise, it will contain an >>>> * update count for each command that executed successfully before >>>> * the BatchUpdateException was thrown. >>>> *

>>>> * This method should be used when the returned update count may exceed >>>> * {@link Integer.MAX_VALUE}. >>>> *

>>>> * @return an array of long containing the update counts >>>> * for the updates that were executed successfully before this error >>>> * occurred. Or, if the driver continues to process commands after an >>>> * error, one of the following for every command in the batch: >>>> *

    >>>> *
  1. an update count >>>> *
  2. Statement.SUCCESS_NO_INFO to indicate that the command >>>> * executed successfully but the number of rows affected is unknown >>>> *
  3. Statement.EXECUTE_FAILED to indicate that the command >>>> * failed to execute successfully >>>> *
>>>> * @since 1.8 >>>> */ >>>> public long[] getLargeUpdateCounts() { >>>> return (longUpdateCounts == null) ? null : >>>> Arrays.copyOf(longUpdateCounts, longUpdateCounts.length); >>>> } >>>> >>> 337c407,414 >>> < private final int[] updateCounts; >>> --- >>>> private int[] updateCounts; >>>> >>>> /** >>>> * The array that describes the outcome of a batch execution. >>>> * @serial >>>> * @since 1.8 >>>> */ >>>> private long[] longUpdateCounts; >>> 339a417,474 >>>> /* >>>> * Utility method to copy int[] updateCount to long[] updateCount >>>> */ >>>> private static long[] copyUpdateCount(int[] uc) { >>>> long[] copy = new long[uc.length]; >>>> for(int i= 0; i< uc.length; i++) { >>>> copy[i] = uc[i]; >>>> } >>>> return copy; >>>> } >>>> /* >>>> * Utility method to copy int[] updateCount to long[] updateCount >>>> */ >>>> private static int[] copyUpdateCount(long[] uc) { >>>> int[] copy = new int[uc.length]; >>>> for(int i= 0; i< uc.length; i++) { >>>> copy[i] = (int) uc[i]; >>>> } >>>> return copy; >>>> } >>>> /** >>>> * readObject is called to restore the state of the >>>> * {@code BatchUpdateException} from a stream. >>>> */ >>>> private void readObject(ObjectInputStream s) >>>> throws IOException, ClassNotFoundException { >>>> ObjectInputStream.GetField fields = s.readFields(); >>>> int[] tmp = (int[])fields.get("updateCounts", null); >>>> long[] tmp2 = (long[])fields.get("longUpdateCounts", null); >>>> if(tmp != null && tmp2 != null && tmp.length != tmp2.length) >>>> throw new InvalidObjectException("update counts are not the expected size"); >>>> if (tmp != null) >>>> updateCounts = tmp.clone(); >>>> if (tmp2 != null) >>>> longUpdateCounts = tmp2.clone(); >>>> if(updateCounts == null && longUpdateCounts != null) >>>> updateCounts = copyUpdateCount(longUpdateCounts); >>>> if(longUpdateCounts == null && updateCounts != null) >>>> longUpdateCounts = copyUpdateCount(updateCounts); >>>> >>>> } >>>> /** >>>> * writeObject is called to save the state of the {@code BatchUpdateException} >>>> * to a stream. >>>> */ >>>> private void writeObject(ObjectOutputStream s) >>>> throws IOException, ClassNotFoundException { >>>> >>>> ObjectOutputStream.PutField fields = s.putFields(); >>>> fields.put("updateCounts", updateCounts); >>>> fields.put("longUpdateCounts", longUpdateCounts); >>>> s.writeFields(); >>>> } >>> >>> 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 staffan.larsen at oracle.com Tue Nov 27 10:22:53 2012 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 27 Nov 2012 11:22:53 +0100 Subject: RFR (S): 7155168: java/util/TimeZone/Bug6912560.java: expected Asia/Tokyo Message-ID: <715B07EA-8FCC-4701-8B56-B69F7F9CA7DE@oracle.com> Please review this fix for the java/util/TimeZone/Bug6912560.java test. The problem with the test is that it fails when running with Java Flight Recorder enabled. This is because JFR will call TimeZone.getDefault() when it starts up, before the main() method is called. This will cause TimeZone to cache the value so that when the test calls TimeZone.getDefault() it will get the old value. The solution here is to reset the value in the beginning of the test. Webrev: http://cr.openjdk.java.net/~sla/7155168/webrev.00/test/java/util/TimeZone/Bug6912560.java.sdiff.html Thanks, /Staffan From staffan.larsen at oracle.com Tue Nov 27 10:25:51 2012 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 27 Nov 2012 11:25:51 +0100 Subject: RFR: 8003322: Add instrumentation points for tracing of I/O calls In-Reply-To: <50B3B573.3000902@oracle.com> References: <50A39388.8060502@oracle.com> <50AA0142.3080502@oracle.com> <28479F37-C81B-4CFB-811A-CEC45755B26B@oracle.com> <50AA279B.7060505@oracle.com> <7C9B7EE6-E9BB-4F4C-81BD-B8AECE689739@oracle.com> <50AB91AE.4040909@oracle.com> <50ABBE28.70907@oracle.com> <50B3B573.3000902@oracle.com> Message-ID: Alan, Mandy: thanks for the reviews! On 26 nov 2012, at 19:31, Mandy Chung wrote: > On 11/26/12 1:40 AM, Staffan Larsen wrote: >> >> A webrev for the changes going into 7u12 is here: http://cr.openjdk.java.net/~sla/8003322/webrev.jdk7.00/ > > The changes look fine for 7u12. Thanks for looking into the dynamic bytecode instrumentation solution for jdk8. > > Mandy From david.holmes at oracle.com Tue Nov 27 10:45:26 2012 From: david.holmes at oracle.com (David Holmes) Date: Tue, 27 Nov 2012 20:45:26 +1000 Subject: RFR (S): 7155168: java/util/TimeZone/Bug6912560.java: expected Asia/Tokyo In-Reply-To: <715B07EA-8FCC-4701-8B56-B69F7F9CA7DE@oracle.com> References: <715B07EA-8FCC-4701-8B56-B69F7F9CA7DE@oracle.com> Message-ID: <50B499C6.8020503@oracle.com> Hi Staffan, On 27/11/2012 8:22 PM, Staffan Larsen wrote: > Please review this fix for the java/util/TimeZone/Bug6912560.java test. > > The problem with the test is that it fails when running with Java Flight Recorder enabled. This is because JFR will call TimeZone.getDefault() when it starts up, before the main() method is called. This will cause TimeZone to cache the value so that when the test calls TimeZone.getDefault() it will get the old value. The solution here is to reset the value in the beginning of the test. > > Webrev: http://cr.openjdk.java.net/~sla/7155168/webrev.00/test/java/util/TimeZone/Bug6912560.java.sdiff.html The change to the test seems reasonable. But I can't help but think that this behaviour of JFR will cause problems for real applications that expect to be first to access the timezone. Perhaps JFR should reset the timezone after it grabs a copy? David ----- > Thanks, > /Staffan From Alan.Bateman at oracle.com Tue Nov 27 10:48:00 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 27 Nov 2012 10:48:00 +0000 Subject: RFR (S): 7155168: java/util/TimeZone/Bug6912560.java: expected Asia/Tokyo In-Reply-To: <715B07EA-8FCC-4701-8B56-B69F7F9CA7DE@oracle.com> References: <715B07EA-8FCC-4701-8B56-B69F7F9CA7DE@oracle.com> Message-ID: <50B49A60.4010708@oracle.com> On 27/11/2012 10:22, Staffan Larsen wrote: > Please review this fix for the java/util/TimeZone/Bug6912560.java test. > > The problem with the test is that it fails when running with Java Flight Recorder enabled. This is because JFR will call TimeZone.getDefault() when it starts up, before the main() method is called. This will cause TimeZone to cache the value so that when the test calls TimeZone.getDefault() it will get the old value. The solution here is to reset the value in the beginning of the test. > > Webrev: http://cr.openjdk.java.net/~sla/7155168/webrev.00/test/java/util/TimeZone/Bug6912560.java.sdiff.html > > Thanks, > /Staffan From paul.sandoz at oracle.com Tue Nov 27 10:57:35 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 27 Nov 2012 11:57:35 +0100 Subject: 8003949: LogManager, downgrade normative reference to ${java.home}/lib/logging.properties In-Reply-To: <50B39050.4070800@oracle.com> References: <50B2969F.8040101@oracle.com> <50B39050.4070800@oracle.com> Message-ID: <8E7D26CF-2C86-4572-AFDB-0C2F9CA162A5@oracle.com> On Nov 26, 2012, at 4:52 PM, Alan Bateman wrote: > On 26/11/2012 15:18, Paul Sandoz wrote: >> Hi Alan, >> >> + * If neither of these properties is defined then the LogManager uses its >> + * default configuration. The default configuration is typically loaded from the >> + * properties file "{@code lib/logging.properties}" in the Java installation >> + * directory. >> >> Will typical become atypical for OpenJDK by the time Java 9 ships? >> > It's possible although in the current jigsaw/jigsaw builds we have retained this and other files that users might change in their original location. The javadoc change, along with a few others in the pipe, will lesson the impact of moving to a modules image a module-private configuration. > OK. +1 from me. Paul. From Alan.Bateman at oracle.com Tue Nov 27 11:02:42 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 27 Nov 2012 11:02:42 +0000 Subject: RFR (S): 7155168: java/util/TimeZone/Bug6912560.java: expected Asia/Tokyo In-Reply-To: <715B07EA-8FCC-4701-8B56-B69F7F9CA7DE@oracle.com> References: <715B07EA-8FCC-4701-8B56-B69F7F9CA7DE@oracle.com> Message-ID: <50B49DD2.9000509@oracle.com> On 27/11/2012 10:22, Staffan Larsen wrote: > Please review this fix for the java/util/TimeZone/Bug6912560.java test. > > The problem with the test is that it fails when running with Java Flight Recorder enabled. This is because JFR will call TimeZone.getDefault() when it starts up, before the main() method is called. This will cause TimeZone to cache the value so that when the test calls TimeZone.getDefault() it will get the old value. The solution here is to reset the value in the beginning of the test. > > Webrev: http://cr.openjdk.java.net/~sla/7155168/webrev.00/test/java/util/TimeZone/Bug6912560.java.sdiff.html > I suspect this test will fail with java agents too, say when doing code coverage during test runs. It might be better to just change the @run tag to specify -D user.timezone= Asia/Tokyo, assuming this solves the problem too. -Alan. From Alan.Bateman at oracle.com Tue Nov 27 11:06:25 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 27 Nov 2012 11:06:25 +0000 Subject: Request for Review: 5049299: (process) Use posix_spawn, not fork, on S10 to avoid swap exhaustion In-Reply-To: References: <50AE98B1.2040200@oracle.com> <50AF646C.4040809@oracle.com> Message-ID: <50B49EB1.1060703@oracle.com> On 27/11/2012 06:47, Martin Buchholz wrote: > : > > On Solaris bi-arch I think you need only one jprochelper, not two, > since a 32-bit helper can exec a 64-bit subprocess. > This is a good point, it needs to know if the target program is 32-bit or 64-bit and chose the appropriate trampoline/helper. -Alan. From scolebourne at joda.org Tue Nov 27 11:56:31 2012 From: scolebourne at joda.org (Stephen Colebourne) Date: Tue, 27 Nov 2012 11:56:31 +0000 Subject: Request for Review : CR#8004015 : Add interface extends and defaults for basic functional interfaces In-Reply-To: References: Message-ID: On 27 November 2012 02:12, Mike Duigou wrote: > In the original patch which added the basic lambda functional interfaces, CR#8001634 [1], none of the interfaces extended other interfaces. The reason was primarily that the javac compiler did not, at the time that 8001634 was proposed, support extension methods. The compiler now supports adding of method defaults so this patch improves the functional interfaces by filing in the inheritance hierarchy. > > Adding the parent interfaces and default methods allows each functional interface to be used in more places. It is especially important for the functional interfaces which support primitive types, IntSupplier, IntFunction, IntUnaryOperator, IntBinaryOperator, etc. We expect that eventually standard implementations of these interfaces will be provided for functions like max, min, sum, etc. By extending the reference oriented functional interfaces such as Function, the primitive implementations can be used with the boxed primitive types along with the primitive types for which they are defined. > > The patch to add parent interfaces and default methods can be found here: > > http://cr.openjdk.java.net/~mduigou/8004015/0/webrev/ > http://cr.openjdk.java.net/~mduigou/8004015/0/specdiff/java/util/function/package-summary.html Each of the default methods is formatted on a single line. I consider this to be bad style, they should be formatted as per "normal" methods: @Override public default Double operate(Double left, Double right) { return operateAsDouble((double) left, (double) right); } It is vitally important to get this kind of formatting/style correct. Developers the world over will be copying what the style is in these classes. There is also no Javadoc on the default method override. In this case, passing a null to either parameter will result in an NPE. This should be documented. More generally, you/Oracle should define a standard form of words for describing what a default method does. Interfaces have not had them before, and their behaviour needs documenting (even if it seems obvious). /** * An operation upon two operands yielding a result. * The operands and the result are all of the same type. *

* The default implementation calls {@link operate(double,double)}, * throwing NullPointerException if either input is null. * * @param left the first operand, not null * @param left the first operand, not null * @return the result, not null */ @Override public default Double operate(Double left, Double right) { return operateAsDouble((double) left, (double) right); } Stephen From staffan.larsen at oracle.com Tue Nov 27 12:26:17 2012 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 27 Nov 2012 13:26:17 +0100 Subject: RFR (S): 7155168: java/util/TimeZone/Bug6912560.java: expected Asia/Tokyo In-Reply-To: <50B49DD2.9000509@oracle.com> References: <715B07EA-8FCC-4701-8B56-B69F7F9CA7DE@oracle.com> <50B49DD2.9000509@oracle.com> Message-ID: <4808282E-0F56-4BED-B805-F21A3673BECB@oracle.com> On 27 nov 2012, at 12:02, Alan Bateman wrote: > On 27/11/2012 10:22, Staffan Larsen wrote: >> >> Please review this fix for the java/util/TimeZone/Bug6912560.java test. >> >> The problem with the test is that it fails when running with Java Flight Recorder enabled. This is because JFR will call TimeZone.getDefault() when it starts up, before the main() method is called. This will cause TimeZone to cache the value so that when the test calls TimeZone.getDefault() it will get the old value. The solution here is to reset the value in the beginning of the test. >> >> Webrev: http://cr.openjdk.java.net/~sla/7155168/webrev.00/test/java/util/TimeZone/Bug6912560.java.sdiff.html >> > I suspect this test will fail with java agents too, say when doing code coverage during test runs. > > It might be better to just change the @run tag to specify -D user.timezone= Asia/Tokyo, assuming this solves the problem too. The test installs a security manager and that has to be present during the call to getDefault() when getDefault() does the real work (not just reading from the cache). Setting -Duser.timezone will not help as the only fix. /Staffan From staffan.larsen at oracle.com Tue Nov 27 12:26:40 2012 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 27 Nov 2012 13:26:40 +0100 Subject: RFR (S): 7155168: java/util/TimeZone/Bug6912560.java: expected Asia/Tokyo In-Reply-To: <50B499C6.8020503@oracle.com> References: <715B07EA-8FCC-4701-8B56-B69F7F9CA7DE@oracle.com> <50B499C6.8020503@oracle.com> Message-ID: <5940FFE6-9BFE-4221-89F6-355F7D555A0C@oracle.com> On 27 nov 2012, at 11:45, David Holmes wrote: > Hi Staffan, > > On 27/11/2012 8:22 PM, Staffan Larsen wrote: >> Please review this fix for the java/util/TimeZone/Bug6912560.java test. >> >> The problem with the test is that it fails when running with Java Flight Recorder enabled. This is because JFR will call TimeZone.getDefault() when it starts up, before the main() method is called. This will cause TimeZone to cache the value so that when the test calls TimeZone.getDefault() it will get the old value. The solution here is to reset the value in the beginning of the test. >> >> Webrev: http://cr.openjdk.java.net/~sla/7155168/webrev.00/test/java/util/TimeZone/Bug6912560.java.sdiff.html > > The change to the test seems reasonable. > > But I can't help but think that this behaviour of JFR will cause problems for real applications that expect to be first to access the timezone. Perhaps JFR should reset the timezone after it grabs a copy? Good point. I can fix that, too. /Staffan > > David > ----- > >> Thanks, >> /Staffan From fweimer at redhat.com Tue Nov 27 12:16:47 2012 From: fweimer at redhat.com (Florian Weimer) Date: Tue, 27 Nov 2012 13:16:47 +0100 Subject: Request for Review : CR#8004015 : Add interface extends and defaults for basic functional interfaces In-Reply-To: References: Message-ID: <50B4AF2F.7020902@redhat.com> On 11/27/2012 03:12 AM, Mike Duigou wrote: > In the original patch which added the basic lambda functional interfaces, CR#8001634 [1], none of the interfaces extended other interfaces. The reason was primarily that the javac compiler did not, at the time that 8001634 was proposed, support extension methods. The compiler now supports adding of method defaults so this patch improves the functional interfaces by filing in the inheritance hierarchy. > > Adding the parent interfaces and default methods allows each functional interface to be used in more places. It is especially important for the functional interfaces which support primitive types, IntSupplier, IntFunction, IntUnaryOperator, IntBinaryOperator, etc. We expect that eventually standard implementations of these interfaces will be provided for functions like max, min, sum, etc. By extending the reference oriented functional interfaces such as Function, the primitive implementations can be used with the boxed primitive types along with the primitive types for which they are defined. +public interface DoubleBinaryOperator extends BinaryOperator { Doesn't the extends go in the wrong direction? Not every BinaryOperator can be be used as a DoubleBinaryOperator because of null values. I think the documentation should reflect that. -- Florian Weimer / Red Hat Product Security Team From Alan.Bateman at oracle.com Tue Nov 27 13:57:16 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 27 Nov 2012 13:57:16 +0000 Subject: RFR (S): 7155168: java/util/TimeZone/Bug6912560.java: expected Asia/Tokyo In-Reply-To: <4808282E-0F56-4BED-B805-F21A3673BECB@oracle.com> References: <715B07EA-8FCC-4701-8B56-B69F7F9CA7DE@oracle.com> <50B49DD2.9000509@oracle.com> <4808282E-0F56-4BED-B805-F21A3673BECB@oracle.com> Message-ID: <50B4C6BC.9000307@oracle.com> On 27/11/2012 12:26, Staffan Larsen wrote: > : > > The test installs a security manager and that has to be present during > the call to getDefault() when getDefault() does the real work (not > just reading from the cache). Setting -Duser.timezone will not help as > the only fix. > What I mean is change the @run line to this: @run main/othervm -Djava.security.manager -Duser.timezone= Asia/Tokyo ... I have not tried it to know if the "/" will cause a problem on Windows. -Alan. From staffan.larsen at oracle.com Tue Nov 27 14:08:17 2012 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 27 Nov 2012 15:08:17 +0100 Subject: RFR (S): 7155168: java/util/TimeZone/Bug6912560.java: expected Asia/Tokyo In-Reply-To: <50B4C6BC.9000307@oracle.com> References: <715B07EA-8FCC-4701-8B56-B69F7F9CA7DE@oracle.com> <50B49DD2.9000509@oracle.com> <4808282E-0F56-4BED-B805-F21A3673BECB@oracle.com> <50B4C6BC.9000307@oracle.com> Message-ID: Setting -Djava.security.manager on the @run gives me an AccessControlException from jtreg. I could work around this by creating a policy file, I guess. Exception in thread "main" java.security.AccessControlException: access denied ("java.io.FilePermission" "/Users/staffan/mercurial/jdk8-tl/jdk/JTwork/classes/java/util/TimeZone/Bug6912560.jta" "read") at java.security.AccessControlContext.checkPermission(AccessControlContext.java:364) at java.security.AccessController.checkPermission(AccessController.java:560) at java.lang.SecurityManager.checkPermission(SecurityManager.java:549) at java.lang.SecurityManager.checkRead(SecurityManager.java:888) at java.io.FileInputStream.(FileInputStream.java:125) at java.io.FileInputStream.(FileInputStream.java:91) at java.io.FileReader.(FileReader.java:58) at com.sun.javatest.regtest.MainWrapper.main(MainWrapper.java:45) On 27 nov 2012, at 14:57, Alan Bateman wrote: > On 27/11/2012 12:26, Staffan Larsen wrote: >> >> : >> >> The test installs a security manager and that has to be present during the call to getDefault() when getDefault() does the real work (not just reading from the cache). Setting -Duser.timezone will not help as the only fix. >> > What I mean is change the @run line to this: > > @run main/othervm -Djava.security.manager -Duser.timezone= Asia/Tokyo ... > > I have not tried it to know if the "/" will cause a problem on Windows. > > -Alan. From sean.coffey at oracle.com Tue Nov 27 16:02:28 2012 From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=) Date: Tue, 27 Nov 2012 16:02:28 +0000 Subject: RFR (S): 7155168: java/util/TimeZone/Bug6912560.java: expected Asia/Tokyo In-Reply-To: <50B49DD2.9000509@oracle.com> References: <715B07EA-8FCC-4701-8B56-B69F7F9CA7DE@oracle.com> <50B49DD2.9000509@oracle.com> Message-ID: <50B4E414.3060500@oracle.com> > I suspect this test will fail with java agents too, say when doing > code coverage during test runs. > > It might be better to just change the @run tag to specify -D > user.timezone= Asia/Tokyo, assuming this solves the problem too. This test runs in othervm mode by default. Any java agents calling into this would already have been causing an issue. Right ? Is this outside the scope of the fix we need in 7155168 ? regards, Sean. On 27/11/2012 11:02, Alan Bateman wrote: > On 27/11/2012 10:22, Staffan Larsen wrote: >> Please review this fix for the java/util/TimeZone/Bug6912560.java test. >> >> The problem with the test is that it fails when running with Java >> Flight Recorder enabled. This is because JFR will call >> TimeZone.getDefault() when it starts up, before the main() method is >> called. This will cause TimeZone to cache the value so that when the >> test calls TimeZone.getDefault() it will get the old value. The >> solution here is to reset the value in the beginning of the test. >> >> Webrev: >> http://cr.openjdk.java.net/~sla/7155168/webrev.00/test/java/util/TimeZone/Bug6912560.java.sdiff.html >> > I suspect this test will fail with java agents too, say when doing > code coverage during test runs. > > It might be better to just change the @run tag to specify -D > user.timezone= Asia/Tokyo, assuming this solves the problem too. > > -Alan. From chris.hegarty at oracle.com Tue Nov 27 17:16:10 2012 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Tue, 27 Nov 2012 17:16:10 +0000 Subject: hg: jdk8/tl/jdk: 8003833: Spurious NPE from Socket.getIn/OutputStream Message-ID: <20121127171622.2C62847B48@hg.openjdk.java.net> Changeset: ddf97baea570 Author: chegar Date: 2012-11-27 17:15 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ddf97baea570 8003833: Spurious NPE from Socket.getIn/OutputStream Reviewed-by: alanb, dsamersoff ! src/share/classes/java/net/AbstractPlainSocketImpl.java + test/java/net/Socket/Streams.java From mike.duigou at oracle.com Tue Nov 27 17:32:06 2012 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 27 Nov 2012 09:32:06 -0800 Subject: Request for Review : CR#8004015 : Add interface extends and defaults for basic functional interfaces In-Reply-To: References: Message-ID: <54FA2248-91D9-4181-AC30-22FB365D3297@oracle.com> On Nov 27 2012, at 03:56 , Stephen Colebourne wrote: > On 27 November 2012 02:12, Mike Duigou wrote: >> In the original patch which added the basic lambda functional interfaces, CR#8001634 [1], none of the interfaces extended other interfaces. The reason was primarily that the javac compiler did not, at the time that 8001634 was proposed, support extension methods. The compiler now supports adding of method defaults so this patch improves the functional interfaces by filing in the inheritance hierarchy. >> >> Adding the parent interfaces and default methods allows each functional interface to be used in more places. It is especially important for the functional interfaces which support primitive types, IntSupplier, IntFunction, IntUnaryOperator, IntBinaryOperator, etc. We expect that eventually standard implementations of these interfaces will be provided for functions like max, min, sum, etc. By extending the reference oriented functional interfaces such as Function, the primitive implementations can be used with the boxed primitive types along with the primitive types for which they are defined. >> >> The patch to add parent interfaces and default methods can be found here: >> >> http://cr.openjdk.java.net/~mduigou/8004015/0/webrev/ >> http://cr.openjdk.java.net/~mduigou/8004015/0/specdiff/java/util/function/package-summary.html > > Each of the default methods is formatted on a single line. I consider > this to be bad style, they should be formatted as per "normal" > methods: > @Override > public default Double operate(Double left, Double right) { > return operateAsDouble((double) left, (double) right); > } > > It is vitally important to get this kind of formatting/style correct. > Developers the world over will be copying what the style is in these > classes. I totally agree that we should be consistent but I don't believe that there's a consensus yet on what good style is for these cases. What's your rationale for it being "bad style"? > There is also no Javadoc on the default method override. That was intentional. The goal was to inherit from the original definition. > In this case, > passing a null to either parameter will result in an NPE. This should > be documented. Agreed. However... The following seems entirely overkill and given how these interfaces are likely to be used the javadoc will not be visible. My inclination is to add the description regarding null behaviour to the class javadoc at the same point where it's described that IntBlock can be used for Block. ie. This is the primitive type specialization of Block for int and also may be used as a Block provided that the parameter to accept(Integer) always is non-null. > > More generally, you/Oracle should define a standard form of words for > describing what a default method does. Interfaces have not had them > before, and their behaviour needs documenting (even if it seems > obvious). > > /** > * An operation upon two operands yielding a result. > * The operands and the result are all of the same type. > *

> * The default implementation calls {@link operate(double,double)}, > * throwing NullPointerException if either input is null. > * > * @param left the first operand, not null > * @param left the first operand, not null > * @return the result, not null > */ > @Override > public default Double operate(Double left, Double right) { > return operateAsDouble((double) left, (double) right); > } > > Stephen > From david.lloyd at redhat.com Tue Nov 27 17:42:56 2012 From: david.lloyd at redhat.com (David M. Lloyd) Date: Tue, 27 Nov 2012 11:42:56 -0600 Subject: JavaDoc for default methods (Was: Re: Request for Review : CR#8004015 : Add interface extends and defaults for basic functional interfaces) In-Reply-To: References: Message-ID: <50B4FBA0.9060204@redhat.com> On 11/27/2012 05:56 AM, Stephen Colebourne wrote: > There is also no Javadoc on the default method override. In this case, > passing a null to either parameter will result in an NPE. This should > be documented. > > More generally, you/Oracle should define a standard form of words for > describing what a default method does. Interfaces have not had them > before, and their behaviour needs documenting (even if it seems > obvious). I think we could/should introduce a JavaDoc taglet to support default method implementations specifically. For example: /** * ... * @default Calls operate(double, double) throwing NPE if either input is null. */ IDEs can use their existing inspection infrastructure to warn if a default method implementation exists without a corresponding @default taglet, just as they might for a missing @param/@return/@throws etc. -- - DML From martinrb at google.com Tue Nov 27 17:45:43 2012 From: martinrb at google.com (Martin Buchholz) Date: Tue, 27 Nov 2012 09:45:43 -0800 Subject: Request for Review: 5049299: (process) Use posix_spawn, not fork, on S10 to avoid swap exhaustion In-Reply-To: <50B49EB1.1060703@oracle.com> References: <50AE98B1.2040200@oracle.com> <50AF646C.4040809@oracle.com> <50B49EB1.1060703@oracle.com> Message-ID: On Tue, Nov 27, 2012 at 3:06 AM, Alan Bateman wrote: > On 27/11/2012 06:47, Martin Buchholz wrote: > > : > > On Solaris bi-arch I think you need only one jprochelper, not two, since > a 32-bit helper can exec a 64-bit subprocess. > > This is a good point, it needs to know if the target program is 32-bit > or 64-bit and chose the appropriate trampoline/helper. > ?? I believe the architecture of the helper and the target program do *not* matter, since execv can cross architecture boundaries, so you only need one helper. From Alan.Bateman at oracle.com Tue Nov 27 17:48:22 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 27 Nov 2012 17:48:22 +0000 Subject: Request for Review: 5049299: (process) Use posix_spawn, not fork, on S10 to avoid swap exhaustion In-Reply-To: References: <50AE98B1.2040200@oracle.com> <50AF646C.4040809@oracle.com> <50B49EB1.1060703@oracle.com> Message-ID: <50B4FCE6.4030908@oracle.com> On 27/11/2012 17:45, Martin Buchholz wrote: > > > On Tue, Nov 27, 2012 at 3:06 AM, Alan Bateman > wrote: > > On 27/11/2012 06:47, Martin Buchholz wrote: >> : >> >> On Solaris bi-arch I think you need only one jprochelper, not >> two, since a 32-bit helper can exec a 64-bit subprocess. >> > This is a good point, it needs to know if the target program is > 32-bit or 64-bit and chose the appropriate trampoline/helper. > > > ?? > > I believe the architecture of the helper and the target program do > *not* matter, since execv can cross architecture boundaries, so you > only need one helper. Ah yes, in any case I think Rob will need a few tests to exercise these cases. -Alan From scolebourne at joda.org Tue Nov 27 17:55:36 2012 From: scolebourne at joda.org (Stephen Colebourne) Date: Tue, 27 Nov 2012 17:55:36 +0000 Subject: Request for Review : CR#8004015 : Add interface extends and defaults for basic functional interfaces In-Reply-To: <54FA2248-91D9-4181-AC30-22FB365D3297@oracle.com> References: <54FA2248-91D9-4181-AC30-22FB365D3297@oracle.com> Message-ID: On 27 November 2012 17:32, Mike Duigou wrote: >> It is vitally important to get this kind of formatting/style correct. > >> Developers the world over will be copying what the style is in these >> classes. > > I totally agree that we should be consistent but I don't believe that there's a consensus yet on what good style is for these cases. What's your rationale for it being "bad style"? These are just methods. There isn't anything different about them other than the default keyword. They act as per a method on an abstract class in most of the ways that a developer cares about. They should therefore look like a normal method. Normal methods are almost always formatted over multiple lines in java/OpenJDK: default void foo() { // body } Default method implementations are not lambdas, so no logic from lambda syntax formatting applies here. >> There is also no Javadoc on the default method override. > That was intentional. The goal was to inherit from the original definition. But where in the specification does it say what the default method implementation does? Sure, you can argue it is obvious, but thats not really sufficient IMO. I proposed a clear way of expressing it in my last email. I really want to see a form of words, such as "The default implementation ..." or similar. That way, the rest of the world can copy the form of words, saving learning and effort in comprehension. It might be argued that a separate Javadoc tag could describe what the default implementation does, but since methods in abtsract classes don't have that, it doesn't seem necessary. >> In this case, >> passing a null to either parameter will result in an NPE. This should >> be documented. > > Agreed. However... The following seems entirely overkill and given how these interfaces are likely to be used the javadoc will not be visible. I don't accept that how it may be used in lambda is an excuse for lack of documentation/specification. These are regular JDK interfaces that can be used by anybody in any way. BTW, my Javadoc standards are here if you didn't see it http://blog.joda.org/2012/11/javadoc-coding-standards.html Stephen From rob.mckenna at oracle.com Tue Nov 27 18:10:00 2012 From: rob.mckenna at oracle.com (Rob McKenna) Date: Tue, 27 Nov 2012 18:10:00 +0000 Subject: Request for Review: 5049299: (process) Use posix_spawn, not fork, on S10 to avoid swap exhaustion In-Reply-To: <50B4FCE6.4030908@oracle.com> References: <50AE98B1.2040200@oracle.com> <50AF646C.4040809@oracle.com> <50B49EB1.1060703@oracle.com> <50B4FCE6.4030908@oracle.com> Message-ID: <50B501F8.80109@oracle.com> I'll put a test together for this before sending out another review. I was sure I had some sort of issue with this in testing before, but perhaps it was IPC related. -Rob On 27/11/12 17:48, Alan Bateman wrote: > On 27/11/2012 17:45, Martin Buchholz wrote: >> >> >> On Tue, Nov 27, 2012 at 3:06 AM, Alan Bateman >> > wrote: >> >> On 27/11/2012 06:47, Martin Buchholz wrote: >>> : >>> >>> On Solaris bi-arch I think you need only one jprochelper, not >>> two, since a 32-bit helper can exec a 64-bit subprocess. >>> >> This is a good point, it needs to know if the target program is >> 32-bit or 64-bit and chose the appropriate trampoline/helper. >> >> >> ?? >> >> I believe the architecture of the helper and the target program do >> *not* matter, since execv can cross architecture boundaries, so you >> only need one helper. > Ah yes, in any case I think Rob will need a few tests to exercise > these cases. > > -Alan From martinrb at google.com Tue Nov 27 18:13:57 2012 From: martinrb at google.com (Martin Buchholz) Date: Tue, 27 Nov 2012 10:13:57 -0800 Subject: Request for Review: 5049299: (process) Use posix_spawn, not fork, on S10 to avoid swap exhaustion In-Reply-To: <50B501F8.80109@oracle.com> References: <50AE98B1.2040200@oracle.com> <50AF646C.4040809@oracle.com> <50B49EB1.1060703@oracle.com> <50B4FCE6.4030908@oracle.com> <50B501F8.80109@oracle.com> Message-ID: $javahome/lib/jexec is a precedent for implementation detail executables not found in $javahome/bin From mandy.chung at oracle.com Tue Nov 27 19:34:11 2012 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 27 Nov 2012 11:34:11 -0800 Subject: Review request: 8003851: MethodHandleNatives dependency on java.sql.DriverManager Message-ID: <50B515B3.10401@oracle.com> java.lang.invoke has a new dependency to java.sql.DriverManager and java.util.logging which are undesirable as they are currently not in jigsaw's base module. This also impacts the Profile work as JDBC is currently proposed in Compact2 and the JDBC dependency means a reference from Compact1 to Compact2 [1]. 8003851: MethodHandleNatives dependency on java.sql.DriverManager 8003869: Eliminate java.lang.invoke.InnerClassLambdaMetafactory dependency on java.util.logging The patch is to eliminate these dependencies. Webrev: http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8003851/webrev.00/ Mandy [1] http://hg.openjd From Alan.Bateman at oracle.com Tue Nov 27 19:46:42 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 27 Nov 2012 19:46:42 +0000 Subject: Review request: 8003851: MethodHandleNatives dependency on java.sql.DriverManager In-Reply-To: <50B515B3.10401@oracle.com> References: <50B515B3.10401@oracle.com> Message-ID: <50B518A2.7080404@oracle.com> On 27/11/2012 19:34, Mandy Chung wrote: > java.lang.invoke has a new dependency to java.sql.DriverManager and > java.util.logging which are undesirable as they are currently not in > jigsaw's base module. This also impacts the Profile work as JDBC is > currently proposed in Compact2 and the JDBC dependency means a > reference from Compact1 to Compact2 [1]. > > 8003851: MethodHandleNatives dependency on java.sql.DriverManager > 8003869: Eliminate java.lang.invoke.InnerClassLambdaMetafactory > dependency on java.util.logging > > The patch is to eliminate these dependencies. > > Webrev: > http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8003851/webrev.00/ This looks fine to me but when we move to module it means a reflection scope dependency on JDBC (but perhaps JDBC might be changed before then so this is needed). -Alan From mandy.chung at oracle.com Tue Nov 27 19:55:01 2012 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 27 Nov 2012 11:55:01 -0800 Subject: Review request: 8003851: MethodHandleNatives dependency on java.sql.DriverManager In-Reply-To: <50B518A2.7080404@oracle.com> References: <50B515B3.10401@oracle.com> <50B518A2.7080404@oracle.com> Message-ID: <50B51A95.6030008@oracle.com> On 11/27/2012 11:46 AM, Alan Bateman wrote: > On 27/11/2012 19:34, Mandy Chung wrote: >> java.lang.invoke has a new dependency to java.sql.DriverManager and >> java.util.logging which are undesirable as they are currently not in >> jigsaw's base module. This also impacts the Profile work as JDBC is >> currently proposed in Compact2 and the JDBC dependency means a >> reference from Compact1 to Compact2 [1]. >> >> 8003851: MethodHandleNatives dependency on java.sql.DriverManager >> 8003869: Eliminate java.lang.invoke.InnerClassLambdaMetafactory >> dependency on java.util.logging >> >> The patch is to eliminate these dependencies. >> >> Webrev: >> http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8003851/webrev.00/ > This looks fine to me but when we move to module it means a reflection > scope dependency on JDBC Right - this only removes the static dependency but the reflection scope dependency from base to JDBC remains. Mandy From jonathan.gibbons at oracle.com Tue Nov 27 21:55:33 2012 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Tue, 27 Nov 2012 21:55:33 +0000 Subject: hg: jdk8/tl/langtools: 8004068: Fix build problems caused by on-demand imports Message-ID: <20121127215536.1550E47B54@hg.openjdk.java.net> Changeset: 4d68e2a05b50 Author: jjg Date: 2012-11-27 13:55 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/4d68e2a05b50 8004068: Fix build problems caused by on-demand imports Reviewed-by: jjg Contributed-by: eric.caspole at amd.com ! src/share/classes/com/sun/tools/javac/code/Types.java From mandy.chung at oracle.com Tue Nov 27 23:18:04 2012 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 27 Nov 2012 15:18:04 -0800 Subject: 8003562: Provide a command-line tool to find static dependencies Message-ID: <50B54A2C.1040907@oracle.com> As part of prepare for modules [1], this RFE is to provide a command-line tool in JDK8 so that developers can understand the static dependencies of their applications and libraries.As part of Project Jigsaw, a useful class analyzer [2] was developed that makes it very easy to identify the dependencies based on the classfile library thathas also been enhanced to support dependency analysis [3]. Inspired by the sample tool that Jon Gibbons developed, we propose this new command-line name as "jdeps". $ ./bin/jdeps -h Usage: jdeps where possible options include: -version Version information -classpath Specify where to find class files -v --verbose Print class-level dependencies -r --reverse Invert the dependencies in the output -p Restrict analysis to classes in this package (may be given multiple times) -e --regex Restrict analysis to packages matching pattern (-p and -e are exclusive) -P --profile Show profile or the file containing a package -d --depth Specify the depth of the transitive dependency analysis Default depth is 1. Set depth to 0 to traverse all dependencies. -all Show all classes and members with no breakdown The jdeps tool shows package-level dependencies of the input files that can be .class files, a directory, or a JAR file. Specify the depth for the transitive dependency analysis; otherwise, it only analyzes the input files. jdeps -P option will show where the class/package comes from. For Java SE API, it will show the Profile name (I implement a workaround for now until the profile work is in jdk8). For JDK internal APIs, they will not be exported in modular world. jdeps will indicate any usage of the JDK internal APIs in the output to help developers prepare for transitioning to modules. See below for a few sample output. Webrev at: http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8003562/ The implementation classes for jdeps are in the langtools repo along with the com.sun.tools.classfile library. I'm working on adding more unit tests. I'd like to get this webrev out to begin the discussion and get review feedback. Thanks Mandy [1] http://openjdk.java.net/jeps/162 [2] http://hg.openjdk.java.net/jigsaw/jigsaw/jdk/raw-file/543b0d24a920/make/tools/classanalyzer/classanalyzer.html [3] http://bugs.sun.com/view_bug.do?bug_id=6907575 Sample Output $./bin/jdeps demo/jfc/Notepad/Notepad.jar (demo/jfc/Notepad/Notepad.jar) -> java.awt -> java.awt.event -> java.beans -> java.io -> java.lang -> java.net -> java.util -> java.util.logging -> javax.swing -> javax.swing.border -> javax.swing.event -> javax.swing.text -> javax.swing.tree -> javax.swing.undo $ ./bin/jdeps -P demo/jfc/Notepad/Notepad.jar (demo/jfc/Notepad/Notepad.jar) -> java.awt compact4 -> java.awt.event compact4 -> java.beans compact4 -> java.io compact1 -> java.lang compact1 -> java.net compact1 -> java.util compact1 -> java.util.logging compact1 -> javax.swing compact4 -> javax.swing.border compact4 -> javax.swing.event compact4 -> javax.swing.text compact4 -> javax.swing.tree compact4 -> javax.swing.undo compact4 $ ./bin/jdeps -d 10 demo/jfc/Notepad/Notepad.jar (demo/jfc/Notepad/Notepad.jar) -> java.awt -> java.awt.event -> java.beans -> java.io -> java.lang -> java.net -> java.util -> java.util.logging -> javax.swing -> javax.swing.border -> javax.swing.event -> javax.swing.text -> javax.swing.tree -> javax.swing.undo java.security (/export/mchung/ws/jdeps-repo/build/macosx-x86_64/j2sdk-image/jre/lib/rt.jar) -> javax.crypto javax.crypto (/export/mchung/ws/jdeps-repo/build/macosx-x86_64/j2sdk-image/jre/lib/jce.jar) -> java.io -> java.lang -> java.lang.reflect -> java.net -> java.nio -> java.security -> java.security.cert -> java.security.spec -> java.util -> java.util.concurrent -> java.util.jar -> java.util.regex -> java.util.zip -> sun.security.jca JDK internal API -> sun.security.util JDK internal API javax.crypto.spec (/export/mchung/ws/jdeps-repo/build/macosx-x86_64/j2sdk-image/jre/lib/jce.jar) -> java.lang -> java.security.spec -> java.util From rob.mckenna at oracle.com Wed Nov 28 00:45:53 2012 From: rob.mckenna at oracle.com (rob.mckenna at oracle.com) Date: Wed, 28 Nov 2012 00:45:53 +0000 Subject: hg: jdk8/tl/jdk: 8003597: TEST_BUG: Eliminate dependency on javaweb from closed net tests Message-ID: <20121128004604.AB77B47B59@hg.openjdk.java.net> Changeset: 40311b5f478f Author: robm Date: 2012-11-28 00:47 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/40311b5f478f 8003597: TEST_BUG: Eliminate dependency on javaweb from closed net tests Reviewed-by: chegar + test/java/net/ResponseCache/Test.java + test/java/net/Socket/B6210227.java From david.holmes at oracle.com Wed Nov 28 02:39:58 2012 From: david.holmes at oracle.com (David Holmes) Date: Wed, 28 Nov 2012 12:39:58 +1000 Subject: Review request: 8003851: MethodHandleNatives dependency on java.sql.DriverManager In-Reply-To: <50B515B3.10401@oracle.com> References: <50B515B3.10401@oracle.com> Message-ID: <50B5797E.2020909@oracle.com> On 28/11/2012 5:34 AM, Mandy Chung wrote: > java.lang.invoke has a new dependency to java.sql.DriverManager and > java.util.logging which are undesirable as they are currently not in > jigsaw's base module. This also impacts the Profile work as JDBC is > currently proposed in Compact2 and the JDBC dependency means a reference > from Compact1 to Compact2 [1]. > > 8003851: MethodHandleNatives dependency on java.sql.DriverManager > 8003869: Eliminate java.lang.invoke.InnerClassLambdaMetafactory > dependency on java.util.logging > > The patch is to eliminate these dependencies. > > Webrev: > http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8003851/webrev.00/ Kind of scary that we have all these hard-wired dependencies in the first place :( Who is going to know they have to update this? Fix looks fine of course. David > Mandy > [1] http://hg.openjd From xueming.shen at oracle.com Wed Nov 28 05:31:19 2012 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Wed, 28 Nov 2012 05:31:19 +0000 Subject: hg: jdk8/tl/jdk: 4235519: Make sun.misc.BASE64{De, En}coder classes public Message-ID: <20121128053138.E602747B61@hg.openjdk.java.net> Changeset: 39b25d5880c6 Author: sherman Date: 2012-11-27 21:51 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/39b25d5880c6 4235519: Make sun.misc.BASE64{De,En}coder classes public Summary: to add java.util.Base64 Reviewed-by: alanb, mduigou ! make/java/java/FILES_java.gmk From xueming.shen at oracle.com Wed Nov 28 05:46:44 2012 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Wed, 28 Nov 2012 05:46:44 +0000 Subject: hg: jdk8/tl/jdk: 8004088: hg push for bug#4235519 failed to push all files Message-ID: <20121128054655.9C87B47B62@hg.openjdk.java.net> Changeset: c6ed2c238d4f Author: sherman Date: 2012-11-27 22:07 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c6ed2c238d4f 8004088: hg push for bug#4235519 failed to push all files Summary: pushed all base64 files Reviewed-by: alanb, mduigou + src/share/classes/java/util/Base64.java + test/java/util/Base64/TestBase64.java + test/java/util/Base64/TestBase64Golden.java + test/java/util/Base64/baseEncode.txt + test/java/util/Base64/mimeEncode.txt + test/java/util/Base64/plain.txt + test/java/util/Base64/urlEncode.txt From fweimer at redhat.com Wed Nov 28 09:05:35 2012 From: fweimer at redhat.com (Florian Weimer) Date: Wed, 28 Nov 2012 10:05:35 +0100 Subject: Review request: 8003851: MethodHandleNatives dependency on java.sql.DriverManager In-Reply-To: <50B51A95.6030008@oracle.com> References: <50B515B3.10401@oracle.com> <50B518A2.7080404@oracle.com> <50B51A95.6030008@oracle.com> Message-ID: <50B5D3DF.8050809@redhat.com> On 11/27/2012 08:55 PM, Mandy Chung wrote: > On 11/27/2012 11:46 AM, Alan Bateman wrote: >> This looks fine to me but when we move to module it means a reflection >> scope dependency on JDBC > > Right - this only removes the static dependency but the reflection scope > dependency from base to JDBC remains. Are all the classes involved expected to be loaded by the bootstrap class loader? Perhaps we could just check that, and then compare the class name only. -- Florian Weimer / Red Hat Product Security Team From Alan.Bateman at oracle.com Wed Nov 28 11:10:57 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 28 Nov 2012 11:10:57 +0000 Subject: CFV: New core-libs Group Member: Mike Duigou Message-ID: <50B5F141.8050902@oracle.com> I hereby nominate Mike Duigou to membership of the core-libs group. Mike doesn't need any introduction as he has been active in this group and this mailing list for the last 2 years. Mike has Committer role in the jdk8, jdk7u and lamdba projects and almost all of the changes that he has pushed, co-reviewed, or sponsored have been in the core libs area. Votes are due by Dec 12, 2012, 08.59 PST. Only current members of the core-libs group [1] are eligible to vote on this nomination. For lazy consensus voting instructions, see [2]. -Alan. [1] http://openjdk.java.net/census#core-libs [2] http://openjdk.java.net/groups/#member-vote From Alan.Bateman at oracle.com Wed Nov 28 11:11:16 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 28 Nov 2012 11:11:16 +0000 Subject: CFV: New core-libs Group Member: Stuart Marks Message-ID: <50B5F154.40702@oracle.com> I hereby nominate Stuart Marks to membership of the core-libs group. Stuart doesn't need any introduction as he has been active in this group and this mailing list for more than 2 years. Stuart has Committer role in the jdk8, jdk7u and lamdba projects and all of the changes that he has pushed, co-reviewed, or sponsored have been in the core libs area. Votes are due by Dec 12, 2012, 08.59 PST. Only current members of the core-libs group [1] are eligible to vote on this nomination. For lazy consensus voting instructions, see [2]. -Alan. [1] http://openjdk.java.net/census#core-libs [2] http://openjdk.java.net/groups/#member-vote From chris.hegarty at oracle.com Wed Nov 28 11:14:00 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 28 Nov 2012 11:14:00 +0000 Subject: CFV: New core-libs Group Member: Mike Duigou In-Reply-To: <50B5F141.8050902@oracle.com> References: <50B5F141.8050902@oracle.com> Message-ID: <50B5F1F8.8090603@oracle.com> Vote: yes. -Chris. On 28/11/2012 11:10, Alan Bateman wrote: > I hereby nominate Mike Duigou to membership of the core-libs group. > > Mike doesn't need any introduction as he has been active in this group > and this mailing list for the last 2 years. Mike has Committer role in > the jdk8, jdk7u and lamdba projects and almost all of the changes that > he has pushed, co-reviewed, or sponsored have been in the core libs area. > > Votes are due by Dec 12, 2012, 08.59 PST. > > Only current members of the core-libs group [1] are eligible to vote on > this nomination. For lazy consensus voting instructions, see [2]. > > -Alan. > > [1] http://openjdk.java.net/census#core-libs > [2] http://openjdk.java.net/groups/#member-vote From Alan.Bateman at oracle.com Wed Nov 28 11:21:02 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 28 Nov 2012 11:21:02 +0000 Subject: CFV: New core-libs Group Member: Mandy Chung Message-ID: <50B5F39E.1030705@oracle.com> I hereby nominate Mandy Chung to membership of the core-libs group. Mandy doesn't need any introduction as she has been active in this group and on this mailing list almost since the start of OpenJDK. This includes changes to code in the core libraries area, reviewing changes for others in this area, and also sponsoring changes from authors and contributors in this area. Mandy has Reviewer and Committer role on several projects and is also a member of the serviceability and members groups. Votes are due by Dec 12, 2012, 08.59 PST. Only current members of the core-libs group [1] are eligible to vote on this nomination. For lazy consensus voting instructions, see [2]. -Alan. [1] http://openjdk.java.net/census#core-libs [2] http://openjdk.java.net/groups/#member-vote From chris.hegarty at oracle.com Wed Nov 28 11:26:59 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 28 Nov 2012 11:26:59 +0000 Subject: CFV: New core-libs Group Member: Mandy Chung In-Reply-To: <50B5F39E.1030705@oracle.com> References: <50B5F39E.1030705@oracle.com> Message-ID: <50B5F503.9090206@oracle.com> Vote: yes -Chris. On 28/11/2012 11:21, Alan Bateman wrote: > > I hereby nominate Mandy Chung to membership of the core-libs group. > > Mandy doesn't need any introduction as she has been active in this group > and on this mailing list almost since the start of OpenJDK. This > includes changes to code in the core libraries area, reviewing changes > for others in this area, and also sponsoring changes from authors and > contributors in this area. Mandy has Reviewer and Committer role on > several projects and is also a member of the serviceability and members > groups. > > Votes are due by Dec 12, 2012, 08.59 PST. > > Only current members of the core-libs group [1] are eligible to vote on > this nomination. For lazy consensus voting instructions, see [2]. > > -Alan. > > [1] http://openjdk.java.net/census#core-libs > [2] http://openjdk.java.net/groups/#member-vote From chris.hegarty at oracle.com Wed Nov 28 11:27:15 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 28 Nov 2012 11:27:15 +0000 Subject: CFV: New core-libs Group Member: Stuart Marks In-Reply-To: <50B5F154.40702@oracle.com> References: <50B5F154.40702@oracle.com> Message-ID: <50B5F513.2080807@oracle.com> Vote: yes -Chris. On 28/11/2012 11:11, Alan Bateman wrote: > I hereby nominate Stuart Marks to membership of the core-libs group. > > Stuart doesn't need any introduction as he has been active in this group > and this mailing list for more than 2 years. Stuart has Committer role > in the jdk8, jdk7u and lamdba projects and all of the changes that he > has pushed, co-reviewed, or sponsored have been in the core libs area. > > Votes are due by Dec 12, 2012, 08.59 PST. > > Only current members of the core-libs group [1] are eligible to vote on > this nomination. For lazy consensus voting instructions, see [2]. > > -Alan. > > [1] http://openjdk.java.net/census#core-libs > [2] http://openjdk.java.net/groups/#member-vote From staffan.larsen at oracle.com Wed Nov 28 12:59:45 2012 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 28 Nov 2012 13:59:45 +0100 Subject: RFR (S): 7155168: java/util/TimeZone/Bug6912560.java: expected Asia/Tokyo In-Reply-To: <50B4E414.3060500@oracle.com> References: <715B07EA-8FCC-4701-8B56-B69F7F9CA7DE@oracle.com> <50B49DD2.9000509@oracle.com> <50B4E414.3060500@oracle.com> Message-ID: <202EF436-70AB-4E7E-939E-0A68B95668D5@oracle.com> Did we conclude that my original change was good, or was there an alternative? Thanks, /Staffan On 27 nov 2012, at 17:02, Se?n Coffey wrote: >> I suspect this test will fail with java agents too, say when doing code coverage during test runs. >> >> It might be better to just change the @run tag to specify -D user.timezone= Asia/Tokyo, assuming this solves the problem too. > This test runs in othervm mode by default. Any java agents calling into this would already have been causing an issue. Right ? > Is this outside the scope of the fix we need in 7155168 ? > > regards, > Sean. > > On 27/11/2012 11:02, Alan Bateman wrote: >> On 27/11/2012 10:22, Staffan Larsen wrote: >>> Please review this fix for the java/util/TimeZone/Bug6912560.java test. >>> >>> The problem with the test is that it fails when running with Java Flight Recorder enabled. This is because JFR will call TimeZone.getDefault() when it starts up, before the main() method is called. This will cause TimeZone to cache the value so that when the test calls TimeZone.getDefault() it will get the old value. The solution here is to reset the value in the beginning of the test. >>> >>> Webrev: http://cr.openjdk.java.net/~sla/7155168/webrev.00/test/java/util/TimeZone/Bug6912560.java.sdiff.html >>> >> I suspect this test will fail with java agents too, say when doing code coverage during test runs. >> >> It might be better to just change the @run tag to specify -D user.timezone= Asia/Tokyo, assuming this solves the problem too. >> >> -Alan. > From peter.levart at gmail.com Wed Nov 28 13:17:03 2012 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 28 Nov 2012 14:17:03 +0100 Subject: race in java.lang.reflect.Field could make UnsafeStaticFieldAccessorImpl#base seen as null Message-ID: <50B60ECF.7090700@gmail.com> Hi all, There're two fields in java.lang.reflect.Field that are used to cache FieldAccessors: // Cached field accessor created without override private FieldAccessor fieldAccessor; // Cached field accessor created with override private FieldAccessor overrideFieldAccessor; Lazy initialization and caching is performed without any synchronization. The FieldAccessor instance is cached on both: the Field instance that can be seen outside the Class object and the "root" field instance that is referenced by the former instance. FieldAccessor can therefore be dereferenced by a thread that did not construct it via a race. All fields in various FieldAccessors are final except sun.reflect.UnsafeStaticFieldAccessorImpl#base. It can theoretically happen that accessing a static field via reflection is performed with a null base reference. I haven't been able to reproduce this theoretical possibility, but It may happen in some situations. The fix is simple - transform the field to final - it is only initialized in the constructor. Regards, Peter From xuelei.fan at oracle.com Wed Nov 28 13:21:34 2012 From: xuelei.fan at oracle.com (xuelei.fan at oracle.com) Date: Wed, 28 Nov 2012 13:21:34 +0000 Subject: hg: jdk8/tl/jdk: 8004019: Removes unused method HandshakeHash.setCertificateVerifyAlg() Message-ID: <20121128132156.637FD47B72@hg.openjdk.java.net> Changeset: 46c627801490 Author: xuelei Date: 2012-11-28 05:18 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/46c627801490 8004019: Removes unused method HandshakeHash.setCertificateVerifyAlg() Summary: certification verification in HandshakeHash was abandoned during TLS 1.2 implementation Reviewed-by: xuelei, weijun Contributed-by: Florian Weimer ! src/share/classes/sun/security/ssl/ClientHandshaker.java ! src/share/classes/sun/security/ssl/HandshakeHash.java ! src/share/classes/sun/security/ssl/Handshaker.java ! src/share/classes/sun/security/ssl/MAC.java ! src/share/classes/sun/security/ssl/ServerHandshaker.java ! src/share/classes/sun/security/ssl/SignatureAndHashAlgorithm.java From sean.coffey at oracle.com Wed Nov 28 13:30:12 2012 From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=) Date: Wed, 28 Nov 2012 13:30:12 +0000 Subject: RFR (S): 7155168: java/util/TimeZone/Bug6912560.java: expected Asia/Tokyo In-Reply-To: <202EF436-70AB-4E7E-939E-0A68B95668D5@oracle.com> References: <715B07EA-8FCC-4701-8B56-B69F7F9CA7DE@oracle.com> <50B49DD2.9000509@oracle.com> <50B4E414.3060500@oracle.com> <202EF436-70AB-4E7E-939E-0A68B95668D5@oracle.com> Message-ID: <50B611E4.6030009@oracle.com> Staffan, perhaps you can leave out the setting of security manager on the @run tags. Security manager can be added through the code as per current testcase. @run main/othervm -Duser.timezone=Asia/Tokyo Bug6912560 should work ? regards, Sean. > --- a/test/java/util/TimeZone/Bug6912560.java > +++ b/test/java/util/TimeZone/Bug6912560.java > @@ -26,7 +26,7 @@ > /* > * @test > * @bug 6912560 > - * @run main/othervm Bug6912560 > + * @run main/othervm -Duser.timezone=Asia/Tokyo Bug6912560 > * @summary Make sure that file path canonicalization in > * sun.util.calendar.ZoneInfoFile works with the default security > * manager. > @@ -37,9 +37,8 @@ import java.util.*; > > public class Bug6912560 { > public static void main(String[] args) { > - // set the user.timezone property > + // expected timezone > String tzname = "Asia/Tokyo"; > - System.setProperty("user.timezone", tzname); > > System.setSecurityManager(new SecurityManager()); On 28/11/2012 12:59, Staffan Larsen wrote: > Did we conclude that my original change was good, or was there an alternative? > > Thanks, > /Staffan > > On 27 nov 2012, at 17:02, Se?n Coffey wrote: > >>> I suspect this test will fail with java agents too, say when doing code coverage during test runs. >>> >>> It might be better to just change the @run tag to specify -D user.timezone= Asia/Tokyo, assuming this solves the problem too. >> This test runs in othervm mode by default. Any java agents calling into this would already have been causing an issue. Right ? >> Is this outside the scope of the fix we need in 7155168 ? >> >> regards, >> Sean. >> >> On 27/11/2012 11:02, Alan Bateman wrote: >>> On 27/11/2012 10:22, Staffan Larsen wrote: >>>> Please review this fix for the java/util/TimeZone/Bug6912560.java test. >>>> >>>> The problem with the test is that it fails when running with Java Flight Recorder enabled. This is because JFR will call TimeZone.getDefault() when it starts up, before the main() method is called. This will cause TimeZone to cache the value so that when the test calls TimeZone.getDefault() it will get the old value. The solution here is to reset the value in the beginning of the test. >>>> >>>> Webrev: http://cr.openjdk.java.net/~sla/7155168/webrev.00/test/java/util/TimeZone/Bug6912560.java.sdiff.html >>>> >>> I suspect this test will fail with java agents too, say when doing code coverage during test runs. >>> >>> It might be better to just change the @run tag to specify -D user.timezone= Asia/Tokyo, assuming this solves the problem too. >>> >>> -Alan. From staffan.larsen at oracle.com Wed Nov 28 14:26:03 2012 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 28 Nov 2012 15:26:03 +0100 Subject: RFR (S): 7155168: java/util/TimeZone/Bug6912560.java: expected Asia/Tokyo In-Reply-To: <50B611E4.6030009@oracle.com> References: <715B07EA-8FCC-4701-8B56-B69F7F9CA7DE@oracle.com> <50B49DD2.9000509@oracle.com> <50B4E414.3060500@oracle.com> <202EF436-70AB-4E7E-939E-0A68B95668D5@oracle.com> <50B611E4.6030009@oracle.com> Message-ID: <102AD127-510E-44B4-94A3-E2A6F52A93C3@oracle.com> On 28 nov 2012, at 14:30, Se?n Coffey wrote: > Staffan, > > perhaps you can leave out the setting of security manager on the @run tags. Security manager can be added through the code as per current testcase. > > @run main/othervm -Duser.timezone=Asia/Tokyo Bug6912560 > > should work ? This only works if I also add the TimeZone.setDefault(null); call from my webrev. The reason is that the security manager needs to be active when TimeZone.getDefault() is called without the timezone being cached. Since the first call to getDefault() will not have a security manager set, I have to reset the cached copy. /Staffan > > regards, > Sean. >> --- a/test/java/util/TimeZone/Bug6912560.java >> +++ b/test/java/util/TimeZone/Bug6912560.java >> @@ -26,7 +26,7 @@ >> /* >> * @test >> * @bug 6912560 >> - * @run main/othervm Bug6912560 >> + * @run main/othervm -Duser.timezone=Asia/Tokyo Bug6912560 >> * @summary Make sure that file path canonicalization in >> * sun.util.calendar.ZoneInfoFile works with the default security >> * manager. >> @@ -37,9 +37,8 @@ import java.util.*; >> >> public class Bug6912560 { >> public static void main(String[] args) { >> - // set the user.timezone property >> + // expected timezone >> String tzname = "Asia/Tokyo"; >> - System.setProperty("user.timezone", tzname); >> >> System.setSecurityManager(new SecurityManager()); > > > > On 28/11/2012 12:59, Staffan Larsen wrote: >> Did we conclude that my original change was good, or was there an alternative? >> >> Thanks, >> /Staffan >> >> On 27 nov 2012, at 17:02, Se?n Coffey wrote: >> >>>> I suspect this test will fail with java agents too, say when doing code coverage during test runs. >>>> >>>> It might be better to just change the @run tag to specify -D user.timezone= Asia/Tokyo, assuming this solves the problem too. >>> This test runs in othervm mode by default. Any java agents calling into this would already have been causing an issue. Right ? >>> Is this outside the scope of the fix we need in 7155168 ? >>> >>> regards, >>> Sean. >>> >>> On 27/11/2012 11:02, Alan Bateman wrote: >>>> On 27/11/2012 10:22, Staffan Larsen wrote: >>>>> Please review this fix for the java/util/TimeZone/Bug6912560.java test. >>>>> >>>>> The problem with the test is that it fails when running with Java Flight Recorder enabled. This is because JFR will call TimeZone.getDefault() when it starts up, before the main() method is called. This will cause TimeZone to cache the value so that when the test calls TimeZone.getDefault() it will get the old value. The solution here is to reset the value in the beginning of the test. >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~sla/7155168/webrev.00/test/java/util/TimeZone/Bug6912560.java.sdiff.html >>>>> >>>> I suspect this test will fail with java agents too, say when doing code coverage during test runs. >>>> >>>> It might be better to just change the @run tag to specify -D user.timezone= Asia/Tokyo, assuming this solves the problem too. >>>> >>>> -Alan. > From masayoshi.okutsu at oracle.com Wed Nov 28 14:41:56 2012 From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu) Date: Wed, 28 Nov 2012 23:41:56 +0900 Subject: RFR (S): 7155168: java/util/TimeZone/Bug6912560.java: expected Asia/Tokyo In-Reply-To: <202EF436-70AB-4E7E-939E-0A68B95668D5@oracle.com> References: <715B07EA-8FCC-4701-8B56-B69F7F9CA7DE@oracle.com> <50B49DD2.9000509@oracle.com> <50B4E414.3060500@oracle.com> <202EF436-70AB-4E7E-939E-0A68B95668D5@oracle.com> Message-ID: <50B622B4.4030608@oracle.com> I was wondering if you plan to address the review comment by David. If that part gets addressed, I think the test case change is no longer required. Otherwise, your change to the test program is fine with me. Thanks, Masayoshi On 2012/11/28 21:59, Staffan Larsen wrote: > Did we conclude that my original change was good, or was there an alternative? > > Thanks, > /Staffan > > On 27 nov 2012, at 17:02, Se?n Coffey wrote: > >>> I suspect this test will fail with java agents too, say when doing code coverage during test runs. >>> >>> It might be better to just change the @run tag to specify -D user.timezone= Asia/Tokyo, assuming this solves the problem too. >> This test runs in othervm mode by default. Any java agents calling into this would already have been causing an issue. Right ? >> Is this outside the scope of the fix we need in 7155168 ? >> >> regards, >> Sean. >> >> On 27/11/2012 11:02, Alan Bateman wrote: >>> On 27/11/2012 10:22, Staffan Larsen wrote: >>>> Please review this fix for the java/util/TimeZone/Bug6912560.java test. >>>> >>>> The problem with the test is that it fails when running with Java Flight Recorder enabled. This is because JFR will call TimeZone.getDefault() when it starts up, before the main() method is called. This will cause TimeZone to cache the value so that when the test calls TimeZone.getDefault() it will get the old value. The solution here is to reset the value in the beginning of the test. >>>> >>>> Webrev: http://cr.openjdk.java.net/~sla/7155168/webrev.00/test/java/util/TimeZone/Bug6912560.java.sdiff.html >>>> >>> I suspect this test will fail with java agents too, say when doing code coverage during test runs. >>> >>> It might be better to just change the @run tag to specify -D user.timezone= Asia/Tokyo, assuming this solves the problem too. >>> >>> -Alan. From joe.darcy at oracle.com Wed Nov 28 15:18:45 2012 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 28 Nov 2012 07:18:45 -0800 Subject: CFV: New core-libs Group Member: Stuart Marks In-Reply-To: <50B5F154.40702@oracle.com> References: <50B5F154.40702@oracle.com> Message-ID: <50B62B55.1020602@oracle.com> Vote: yes -Joe On 11/28/2012 3:11 AM, Alan Bateman wrote: > I hereby nominate Stuart Marks to membership of the core-libs group. > > Stuart doesn't need any introduction as he has been active in this > group and this mailing list for more than 2 years. Stuart has > Committer role in the jdk8, jdk7u and lamdba projects and all of the > changes that he has pushed, co-reviewed, or sponsored have been in the > core libs area. > > Votes are due by Dec 12, 2012, 08.59 PST. > > Only current members of the core-libs group [1] are eligible to vote > on this nomination. For lazy consensus voting instructions, see [2]. > > -Alan. > > [1] http://openjdk.java.net/census#core-libs > [2] http://openjdk.java.net/groups/#member-vote From joe.darcy at oracle.com Wed Nov 28 15:18:11 2012 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 28 Nov 2012 07:18:11 -0800 Subject: CFV: New core-libs Group Member: Mike Duigou In-Reply-To: <50B5F141.8050902@oracle.com> References: <50B5F141.8050902@oracle.com> Message-ID: <50B62B33.7060508@oracle.com> Vote: yes -Joe On 11/28/2012 3:10 AM, Alan Bateman wrote: > I hereby nominate Mike Duigou to membership of the core-libs group. > > Mike doesn't need any introduction as he has been active in this group > and this mailing list for the last 2 years. Mike has Committer role in > the jdk8, jdk7u and lamdba projects and almost all of the changes that > he has pushed, co-reviewed, or sponsored have been in the core libs area. > > Votes are due by Dec 12, 2012, 08.59 PST. > > Only current members of the core-libs group [1] are eligible to vote > on this nomination. For lazy consensus voting instructions, see [2]. > > -Alan. > > [1] http://openjdk.java.net/census#core-libs > [2] http://openjdk.java.net/groups/#member-vote From joe.darcy at oracle.com Wed Nov 28 15:18:32 2012 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 28 Nov 2012 07:18:32 -0800 Subject: CFV: New core-libs Group Member: Mandy Chung In-Reply-To: <50B5F39E.1030705@oracle.com> References: <50B5F39E.1030705@oracle.com> Message-ID: <50B62B48.8020707@oracle.com> Vote: yes -Joe On 11/28/2012 3:21 AM, Alan Bateman wrote: > > I hereby nominate Mandy Chung to membership of the core-libs group. > > Mandy doesn't need any introduction as she has been active in this > group and on this mailing list almost since the start of OpenJDK. This > includes changes to code in the core libraries area, reviewing changes > for others in this area, and also sponsoring changes from authors and > contributors in this area. Mandy has Reviewer and Committer role on > several projects and is also a member of the serviceability and > members groups. > > Votes are due by Dec 12, 2012, 08.59 PST. > > Only current members of the core-libs group [1] are eligible to vote > on this nomination. For lazy consensus voting instructions, see [2]. > > -Alan. > > [1] http://openjdk.java.net/census#core-libs > [2] http://openjdk.java.net/groups/#member-vote From mark.reinhold at oracle.com Wed Nov 28 16:13:27 2012 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 28 Nov 2012 08:13:27 -0800 Subject: CFV: New core-libs Group Member: Mike Duigou In-Reply-To: alan.bateman@oracle.com; Wed, 28 Nov 2012 11:10:57 GMT; <50B5F141.8050902@oracle.com> Message-ID: <20121128161327.8890D61D@eggemoggin.niobe.net> Vote: yes - Mark From mark.reinhold at oracle.com Wed Nov 28 16:14:25 2012 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 28 Nov 2012 08:14:25 -0800 Subject: CFV: New core-libs Group Member: Stuart Marks In-Reply-To: alan.bateman@oracle.com; Wed, 28 Nov 2012 11:11:16 GMT; <50B5F154.40702@oracle.com> Message-ID: <20121128161425.4C9E661D@eggemoggin.niobe.net> Vote: yes - Mark From mark.reinhold at oracle.com Wed Nov 28 16:14:44 2012 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 28 Nov 2012 08:14:44 -0800 Subject: CFV: New core-libs Group Member: Mandy Chung In-Reply-To: alan.bateman@oracle.com; Wed, 28 Nov 2012 11:21:02 GMT; <50B5F39E.1030705@oracle.com> Message-ID: <20121128161444.0BC1361D@eggemoggin.niobe.net> Vote: yes - Mark From staffan.larsen at oracle.com Wed Nov 28 16:23:53 2012 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 28 Nov 2012 17:23:53 +0100 Subject: RFR (S): 7155168: java/util/TimeZone/Bug6912560.java: expected Asia/Tokyo In-Reply-To: <50B622B4.4030608@oracle.com> References: <715B07EA-8FCC-4701-8B56-B69F7F9CA7DE@oracle.com> <50B49DD2.9000509@oracle.com> <50B4E414.3060500@oracle.com> <202EF436-70AB-4E7E-939E-0A68B95668D5@oracle.com> <50B622B4.4030608@oracle.com> Message-ID: <6B76C7D7-4B79-4D9D-AB97-6A81C61CBF87@oracle.com> On 28 nov 2012, at 15:41, Masayoshi Okutsu wrote: > I was wondering if you plan to address the review comment by David. If that part gets addressed, I think the test case change is no longer required. Otherwise, your change to the test program is fine with me. Calling TimeZone.setDefault(null) from JFR turned out to be hard since TimeZone.getDefault() is called from so many places and often indirectly (for example "new Date()"). This made it very hard to make sure it got reset correctly. Thus, I'd like to change the test program instead. /Staffan > > Thanks, > Masayoshi > > On 2012/11/28 21:59, Staffan Larsen wrote: >> Did we conclude that my original change was good, or was there an alternative? >> >> Thanks, >> /Staffan >> >> On 27 nov 2012, at 17:02, Se?n Coffey wrote: >> >>>> I suspect this test will fail with java agents too, say when doing code coverage during test runs. >>>> >>>> It might be better to just change the @run tag to specify -D user.timezone= Asia/Tokyo, assuming this solves the problem too. >>> This test runs in othervm mode by default. Any java agents calling into this would already have been causing an issue. Right ? >>> Is this outside the scope of the fix we need in 7155168 ? >>> >>> regards, >>> Sean. >>> >>> On 27/11/2012 11:02, Alan Bateman wrote: >>>> On 27/11/2012 10:22, Staffan Larsen wrote: >>>>> Please review this fix for the java/util/TimeZone/Bug6912560.java test. >>>>> >>>>> The problem with the test is that it fails when running with Java Flight Recorder enabled. This is because JFR will call TimeZone.getDefault() when it starts up, before the main() method is called. This will cause TimeZone to cache the value so that when the test calls TimeZone.getDefault() it will get the old value. The solution here is to reset the value in the beginning of the test. >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~sla/7155168/webrev.00/test/java/util/TimeZone/Bug6912560.java.sdiff.html >>>>> >>>> I suspect this test will fail with java agents too, say when doing code coverage during test runs. >>>> >>>> It might be better to just change the @run tag to specify -D user.timezone= Asia/Tokyo, assuming this solves the problem too. >>>> >>>> -Alan. > From jonathan.gibbons at oracle.com Wed Nov 28 17:29:14 2012 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Wed, 28 Nov 2012 17:29:14 +0000 Subject: hg: jdk8/tl/jdk: 7154390: Add support for repeating annotations in j.l.r.AnnotatedElement Message-ID: <20121128172933.A1AB547B88@hg.openjdk.java.net> Changeset: 735b93462eed Author: jfranck Date: 2012-11-28 09:21 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/735b93462eed 7154390: Add support for repeating annotations in j.l.r.AnnotatedElement Reviewed-by: darcy ! src/share/classes/java/lang/Class.java ! src/share/classes/java/lang/Package.java ! src/share/classes/java/lang/System.java ! src/share/classes/java/lang/annotation/ContainedBy.java ! src/share/classes/java/lang/annotation/ContainerFor.java + src/share/classes/java/lang/annotation/InvalidContainerAnnotationError.java ! src/share/classes/java/lang/reflect/AccessibleObject.java ! src/share/classes/java/lang/reflect/AnnotatedElement.java ! src/share/classes/java/lang/reflect/Executable.java ! src/share/classes/java/lang/reflect/Field.java ! src/share/classes/sun/misc/JavaLangAccess.java ! src/share/classes/sun/reflect/annotation/AnnotationParser.java + src/share/classes/sun/reflect/annotation/AnnotationSupport.java ! src/share/classes/sun/reflect/generics/reflectiveObjects/TypeVariableImpl.java + test/java/lang/annotation/repeatingAnnotations/RepeatedUnitTest.java + test/java/lang/annotation/repeatingAnnotations/subpackage/Containee.java + test/java/lang/annotation/repeatingAnnotations/subpackage/Container.java + test/java/lang/annotation/repeatingAnnotations/subpackage/InheritedContainee.java + test/java/lang/annotation/repeatingAnnotations/subpackage/InheritedContainer.java + test/java/lang/annotation/repeatingAnnotations/subpackage/InheritedNonRepeated.java + test/java/lang/annotation/repeatingAnnotations/subpackage/NonRepeated.java + test/java/lang/annotation/repeatingAnnotations/subpackage/package-info.java From jonathan.gibbons at oracle.com Wed Nov 28 18:04:03 2012 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Wed, 28 Nov 2012 18:04:03 +0000 Subject: hg: jdk8/tl/langtools: 7144981: javac should ignore ignorable characters in input Message-ID: <20121128180408.2E3ED47B8C@hg.openjdk.java.net> Changeset: 1f41a5758cf7 Author: vromero Date: 2012-11-23 15:13 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/1f41a5758cf7 7144981: javac should ignore ignorable characters in input Reviewed-by: jjg, mcimadamore ! src/share/classes/com/sun/tools/javac/parser/JavaTokenizer.java + test/tools/javac/7144981/IgnoreIgnorableCharactersInInput.java From daniel.fuchs at oracle.com Wed Nov 28 18:09:23 2012 From: daniel.fuchs at oracle.com (daniel.fuchs at oracle.com) Date: Wed, 28 Nov 2012 18:09:23 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20121128180956.C6F0F47B8D@hg.openjdk.java.net> Changeset: 3b6a2fe6d75c Author: dfuchs Date: 2012-11-28 15:14 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3b6a2fe6d75c 8003476: Cleanup warnings in com.sun.jmx.snmp code Reviewed-by: alanb, smarks ! src/share/classes/com/sun/jmx/snmp/EnumRowStatus.java ! src/share/classes/com/sun/jmx/snmp/Enumerated.java ! src/share/classes/com/sun/jmx/snmp/IPAcl/AclImpl.java ! src/share/classes/com/sun/jmx/snmp/IPAcl/JDMAclBlock.java ! src/share/classes/com/sun/jmx/snmp/IPAcl/JDMInformBlock.java ! src/share/classes/com/sun/jmx/snmp/IPAcl/JDMTrapBlock.java ! src/share/classes/com/sun/jmx/snmp/IPAcl/JJTParserState.java ! src/share/classes/com/sun/jmx/snmp/IPAcl/Parser.java ! src/share/classes/com/sun/jmx/snmp/IPAcl/SnmpAcl.java ! src/share/classes/com/sun/jmx/snmp/InetAddressAcl.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpErrorHandlerAgent.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpGenericObjectServer.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpIndex.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpMib.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpMibAgent.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpMibGroup.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpMibOid.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpMibRequest.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpMibRequestImpl.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpMibSubRequest.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpMibTable.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpRequestTree.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpStandardObjectServer.java ! src/share/classes/com/sun/jmx/snmp/daemon/CommunicatorServer.java ! src/share/classes/com/sun/jmx/snmp/daemon/SnmpAdaptorServer.java ! src/share/classes/com/sun/jmx/snmp/daemon/SnmpAdaptorServerMBean.java ! src/share/classes/com/sun/jmx/snmp/daemon/SnmpMibTree.java ! src/share/classes/com/sun/jmx/snmp/daemon/SnmpRequestHandler.java ! src/share/classes/com/sun/jmx/snmp/daemon/SnmpSubBulkRequestHandler.java ! src/share/classes/com/sun/jmx/snmp/defaults/SnmpProperties.java ! src/share/classes/com/sun/jmx/snmp/tasks/ThreadService.java ! src/share/classes/sun/management/snmp/AdaptorBootstrap.java Changeset: 262b3b2f3aa3 Author: dfuchs Date: 2012-11-28 10:08 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/262b3b2f3aa3 Merge From jim.gish at oracle.com Wed Nov 28 18:27:36 2012 From: jim.gish at oracle.com (Jim Gish) Date: Wed, 28 Nov 2012 13:27:36 -0500 Subject: RFR: 8003380 - Compiler warnings in logging test code In-Reply-To: <50A6FE36.8050208@oracle.com> References: <50A40A00.8060106@oracle.com> <50A4CCB3.80305@oracle.com> <50A6F8EC.7080905@oracle.com> <50A6FE36.8050208@oracle.com> Message-ID: <50B65798.8080901@oracle.com> Here's the list of @suppresswarnings values that are recognized by Eclipse Juno: Excluding warnings using @SuppressWarnings Since Java 5.0, you can disable compilation warnings relative to a subset of a compilation unit using the|java.lang.SuppressWarning|annotation. @SuppressWarning("unused") public void foo() { String s; } Without the annotation, the compiler would complain that the local variable|s|is never used. With the annotation, the compiler silently ignores this warning locally to the|foo|method. This enables to keep the warnings in other locations of the same compilation unit or the same project. The list of tokens that can be used inside a|SuppressWarnings|annotation is: * allto suppress all warnings * boxingto suppress warnings relative to boxing/unboxing operations * castto suppress warnings relative to cast operations * dep-annto suppress warnings relative to deprecated annotation * deprecationto suppress warnings relative to deprecation * fallthroughto suppress warnings relative to missing breaks in switch statements * finallyto suppress warnings relative to finally block that don't return * hidingto suppress warnings relative to locals that hide variable * incomplete-switchto suppress warnings relative to missing entries in a switch statement (enum case) * javadocto suppress warnings relative to javadoc warnings * nlsto suppress warnings relative to non-nls string literals * nullto suppress warnings relative to null analysis * rawtypesto suppress warnings relative to usage of raw types * resourceto suppress warnings relative to usage of resources of type Closeable * restrictionto suppress warnings relative to usage of discouraged or forbidden references * serialto suppress warnings relative to missing serialVersionUID field for a serializable class * static-accessto suppress warnings relative to incorrect static access * static-methodto suppress warnings relative to methods that could be declared as static * superto suppress warnings relative to overriding a method without super invocations * synthetic-accessto suppress warnings relative to unoptimized access from inner classes * sync-overrideto suppress warnings because of missing synchronize when overriding a synchronized method * uncheckedto suppress warnings relative to unchecked operations * unqualified-field-accessto suppress warnings relative to field access unqualified * unusedto suppress warnings relative to unused code and dead code (From http://help.eclipse.org/juno/index.jsp?topic=/org.eclipse.jdt.doc.isv/guide/jdt%255Fapi%255Fcompile.htm) Jim On 11/16/2012 10:02 PM, Stuart Marks wrote: > On 11/16/12 6:39 PM, Stuart Marks wrote: >> The background is that the words that can be supplied to >> @SuppressWarnings >> reside in an uncontrolled namespace. The JLS [1] defines only >> "unchecked" and >> any others are compiler-specific. The set of words accepted here by >> javac is >> the same as the words defined for -Xlint. >> >> [1] >> http://docs.oracle.com/javase/specs/jls/se7/html/jls-9.html#jls-9.6.3.5 > > Whoops, the JLS defines "deprecation" as well (as Alan pointed out in > another thread the other day). But the rest of the point stands. > > s'marks -- 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 jim.gish at oracle.com Wed Nov 28 18:51:24 2012 From: jim.gish at oracle.com (Jim Gish) Date: Wed, 28 Nov 2012 13:51:24 -0500 Subject: RFR: 8003380 - Compiler warnings in logging test code In-Reply-To: <50B65798.8080901@oracle.com> References: <50A40A00.8060106@oracle.com> <50A4CCB3.80305@oracle.com> <50A6F8EC.7080905@oracle.com> <50A6FE36.8050208@oracle.com> <50B65798.8080901@oracle.com> Message-ID: <50B65D2C.3070501@oracle.com> Since we don't yet have a resolution on this, I modified the test code in question to remove the @SuppressWarnings("unused") and actually removed the unused references (and retested, of course). Please review http://cr.openjdk.java.net/~jgish/Bug8003380-logging-test-warnings/ and if ok, Chris, could you please go ahead and push the changes? thanks, Jim On 11/28/2012 01:27 PM, Jim Gish wrote: > Here's the list of @suppresswarnings values that are recognized by > Eclipse Juno: > > > Excluding warnings using @SuppressWarnings > > Since Java 5.0, you can disable compilation warnings relative to a > subset of a compilation unit using > the|java.lang.SuppressWarning|annotation. > > @SuppressWarning("unused") public void foo() { > String s; > } > > Without the annotation, the compiler would complain that the local > variable|s|is never used. With the annotation, the compiler silently > ignores this warning locally to the|foo|method. This enables to keep > the warnings in other locations of the same compilation unit or the > same project. > > The list of tokens that can be used inside > a|SuppressWarnings|annotation is: > > * allto suppress all warnings > * boxingto suppress warnings relative to boxing/unboxing operations > * castto suppress warnings relative to cast operations > * dep-annto suppress warnings relative to deprecated annotation > * deprecationto suppress warnings relative to deprecation > * fallthroughto suppress warnings relative to missing breaks in switch > statements > * finallyto suppress warnings relative to finally block that don't > return > * hidingto suppress warnings relative to locals that hide variable > * incomplete-switchto suppress warnings relative to missing entries in > a switch statement (enum case) > * javadocto suppress warnings relative to javadoc warnings > * nlsto suppress warnings relative to non-nls string literals > * nullto suppress warnings relative to null analysis > * rawtypesto suppress warnings relative to usage of raw types > * resourceto suppress warnings relative to usage of resources of type > Closeable > * restrictionto suppress warnings relative to usage of discouraged or > forbidden references > * serialto suppress warnings relative to missing serialVersionUID > field for a serializable class > * static-accessto suppress warnings relative to incorrect static access > * static-methodto suppress warnings relative to methods that could be > declared as static > * superto suppress warnings relative to overriding a method without > super invocations > * synthetic-accessto suppress warnings relative to unoptimized access > from inner classes > * sync-overrideto suppress warnings because of missing synchronize > when overriding a synchronized method > * uncheckedto suppress warnings relative to unchecked operations > * unqualified-field-accessto suppress warnings relative to field > access unqualified > * unusedto suppress warnings relative to unused code and dead code > > (From > http://help.eclipse.org/juno/index.jsp?topic=/org.eclipse.jdt.doc.isv/guide/jdt%255Fapi%255Fcompile.htm) > > Jim > > On 11/16/2012 10:02 PM, Stuart Marks wrote: >> On 11/16/12 6:39 PM, Stuart Marks wrote: >>> The background is that the words that can be supplied to >>> @SuppressWarnings >>> reside in an uncontrolled namespace. The JLS [1] defines only >>> "unchecked" and >>> any others are compiler-specific. The set of words accepted here by >>> javac is >>> the same as the words defined for -Xlint. >>> >>> [1] >>> http://docs.oracle.com/javase/specs/jls/se7/html/jls-9.html#jls-9.6.3.5 >> >> Whoops, the JLS defines "deprecation" as well (as Alan pointed out in >> another thread the other day). But the rest of the point stands. >> >> s'marks > -- 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 mandy.chung at oracle.com Wed Nov 28 18:52:34 2012 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Wed, 28 Nov 2012 18:52:34 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20121128185309.F136A47B95@hg.openjdk.java.net> Changeset: 09bef1e118e3 Author: mchung Date: 2012-11-28 10:49 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/09bef1e118e3 8003851: MethodHandleNatives dependency on java.sql.DriverManager Reviewed-by: alanb, dholmes ! src/share/classes/java/lang/invoke/MethodHandleNatives.java Changeset: 80ddee59a21d Author: mchung Date: 2012-11-28 10:50 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/80ddee59a21d 8003869: Eliminate java.lang.invoke.InnerClassLambdaMetafactory dependency on java.util.logging Reviewed-by: alanb, dholmes ! src/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java From iris.clark at oracle.com Wed Nov 28 18:54:08 2012 From: iris.clark at oracle.com (Iris Clark) Date: Wed, 28 Nov 2012 10:54:08 -0800 (PST) Subject: CFV: New core-libs Group Member: Mike Duigou In-Reply-To: <50B5F141.8050902@oracle.com> References: <50B5F141.8050902@oracle.com> Message-ID: Vote: yes From iris.clark at oracle.com Wed Nov 28 18:54:27 2012 From: iris.clark at oracle.com (Iris Clark) Date: Wed, 28 Nov 2012 10:54:27 -0800 (PST) Subject: CFV: New core-libs Group Member: Mandy Chung In-Reply-To: <50B5F39E.1030705@oracle.com> References: <50B5F39E.1030705@oracle.com> Message-ID: Vote: yes iris From iris.clark at oracle.com Wed Nov 28 18:55:18 2012 From: iris.clark at oracle.com (Iris Clark) Date: Wed, 28 Nov 2012 10:55:18 -0800 (PST) Subject: CFV: New core-libs Group Member: Stuart Marks In-Reply-To: <50B5F154.40702@oracle.com> References: <50B5F154.40702@oracle.com> Message-ID: Vote: yes iris From aleksey.shipilev at oracle.com Wed Nov 28 19:10:54 2012 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Wed, 28 Nov 2012 23:10:54 +0400 Subject: race in java.lang.reflect.Field could make UnsafeStaticFieldAccessorImpl#base seen as null In-Reply-To: <50B60ECF.7090700@gmail.com> References: <50B60ECF.7090700@gmail.com> Message-ID: <50B661BE.2060508@oracle.com> On 11/28/2012 05:17 PM, Peter Levart wrote: > The fix is simple - transform the field to final - it is only > initialized in the constructor. I agree with this conclusion. UnsafeStaticFieldAccessorImpl.base should be final. Peter, will you be able to prepare the webrev? -Aleksey. From xueming.shen at oracle.com Wed Nov 28 19:48:29 2012 From: xueming.shen at oracle.com (Xueming Shen) Date: Wed, 28 Nov 2012 11:48:29 -0800 Subject: CFV: New core-libs Group Member: Mandy Chung In-Reply-To: References: <50B5F39E.1030705@oracle.com> Message-ID: <50B66A8D.6090709@oracle.com> Vote: yes From xueming.shen at oracle.com Wed Nov 28 19:48:48 2012 From: xueming.shen at oracle.com (Xueming Shen) Date: Wed, 28 Nov 2012 11:48:48 -0800 Subject: CFV: New core-libs Group Member: Stuart Marks In-Reply-To: References: <50B5F154.40702@oracle.com> Message-ID: <50B66AA0.2030406@oracle.com> Vote: yes From xueming.shen at oracle.com Wed Nov 28 19:48:12 2012 From: xueming.shen at oracle.com (Xueming Shen) Date: Wed, 28 Nov 2012 11:48:12 -0800 Subject: CFV: New core-libs Group Member: Mike Duigou In-Reply-To: References: <50B5F141.8050902@oracle.com> Message-ID: <50B66A7C.2050607@oracle.com> Vote: yes From Alan.Bateman at oracle.com Wed Nov 28 19:53:31 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 28 Nov 2012 19:53:31 +0000 Subject: 8003562: Provide a command-line tool to find static dependencies In-Reply-To: <50B54A2C.1040907@oracle.com> References: <50B54A2C.1040907@oracle.com> Message-ID: <50B66BBB.5000209@oracle.com> On 27/11/2012 23:18, Mandy Chung wrote: > : > > See below for a few sample output. > > Webrev at: > http://cr.openjdk.java.net/~mchung/jdk8/webrevs/8003562/ > > The implementation classes for jdeps are in the langtools repo along > with the com.sun.tools.classfile library. I'm working on adding more > unit tests. I'd like to get this webrev out to begin the discussion > and get review feedback. Thanks for getting this together. I suspect you will get a lots of feedback on the output once people get a chance to try it out. Personally I think I would print the code source against each of the dependence if it's in a JAR file (might be more than one). That makes inter-dependencies obvious when giving it a list of JAR files. For missing types then I think I would print something like "not found" as the code source rather than a series of warnings at the beginning. The other way I'd probably use is to just give it the application's usual classpath (application and libraries) and have it print the dependencies on the platform and other libraries, ie: don't print intra-dependencies. I think if there were just the two modes -classpath and -d might not be needed. I'm also not sure if -r is needed. I think -v is very useful and arguably should be the default with a -package option to get more terse output (I don't have strong opinion on which should be the default, just good to see that it has both). I realize the profiles.resources is just temporary but just an FYI that there are only 3 profiles proposed at this time: compact1, compact2 and compact3. Otherwise I think it will be great to have this tool in the JDK, will be very useful. -Alan. From mandy.chung at oracle.com Wed Nov 28 20:50:13 2012 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 28 Nov 2012 12:50:13 -0800 Subject: 8003562: Provide a command-line tool to find static dependencies In-Reply-To: <50B66BBB.5000209@oracle.com> References: <50B54A2C.1040907@oracle.com> <50B66BBB.5000209@oracle.com> Message-ID: <50B67905.20304@oracle.com> On 11/28/2012 11:53 AM, Alan Bateman wrote: > > I suspect you will get a lots of feedback on the output once people > get a chance to try it out. That's what I expect too :) > Personally I think I would print the code source against each of the > dependence if it's in a JAR file (might be more than one). That makes > inter-dependencies obvious when giving it a list of JAR files. -P will show the source or profile name. I initially had the default to print the code source but the output looks a bit clutter as it includes the source of the platform API as well. I agree with you that including the code source will make the inter-dependencies obvious especially from JAR files. What about by default printing the code source if the dependence is from the input files or -classpath option but exclude the platform API. So the -P option is to show the platform/profile information (i.e. either the profile name or the code source from JDK). > For missing types then I think I would print something like "not > found" as the code source rather than a series of warnings at the > beginning. It shows "null" currently and s/null/found makes sense. > The other way I'd probably use is to just give it the application's > usual classpath (application and libraries) and have it print the > dependencies on the platform and other libraries, ie: don't print > intra-dependencies. I have been thinking about that use case. It would analyze all classes given in the -classpath option. > I think if there were just the two modes -classpath and -d might not > be needed. I wasn't sure if -d might be needed or not. I would be interested in finding out all transitive dependencies to see what dependencies other libraries may pull in. I think -d 0 and -d 1 (default) would be useful. -d 0 would often give lot of output and I was thinking specifying the depth would help the diagnosis when unexpected dependencies are found and certainly we need to experiment it further to see if we should keep -d or not. > I'm also not sure if -r is needed. I think -r together with -p or -e would be useful to diagnose what classes reference a specific type or package when such dependency is unexpected. > I think -v is very useful and arguably should be the default with a > -package option to get more terse output (I don't have strong opinion > on which should be the default, just good to see that it has both). > We can evaluate the default when we will get more feedback. Essentially there are 3 level of dependency granularity: 1. class level 2. package level 3. code source level (no intra-dependencies) - this is like the cross-module dependencies. I'll leave the package level as the default. > I realize the profiles.resources is just temporary but just an FYI > that there are only 3 profiles proposed at this time: compact1, > compact2 and compact3. > I have overloaded it to include other supported APIs. Perhaps I should rename it to jdk.properties > Otherwise I think it will be great to have this tool in the JDK, will > be very useful. > Thanks for the feedback. Mandy From peter.levart at gmail.com Wed Nov 28 22:12:11 2012 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 28 Nov 2012 23:12:11 +0100 Subject: race in java.lang.reflect.Field could make UnsafeStaticFieldAccessorImpl#base seen as null In-Reply-To: <50B661BE.2060508@oracle.com> References: <50B60ECF.7090700@gmail.com> <50B661BE.2060508@oracle.com> Message-ID: <50B68C3B.9090309@gmail.com> Ok, here it is: http://dl.dropbox.com/u/101777488/jdk8-hacks/UnsafeStaticFieldAccessorImpl.base/webrev/index.html All fields in FieldAccessor implementations should be final because instances can be obtained via a data race in java.lang.reflect.Field. Regards, Peter On 11/28/2012 08:10 PM, Aleksey Shipilev wrote: > On 11/28/2012 05:17 PM, Peter Levart wrote: >> The fix is simple - transform the field to final - it is only >> initialized in the constructor. > I agree with this conclusion. UnsafeStaticFieldAccessorImpl.base should > be final. Peter, will you be able to prepare the webrev? > > -Aleksey. > > From david.holmes at oracle.com Thu Nov 29 01:57:07 2012 From: david.holmes at oracle.com (David Holmes) Date: Thu, 29 Nov 2012 11:57:07 +1000 Subject: CFV: New core-libs Group Member: Mandy Chung In-Reply-To: <50B5F39E.1030705@oracle.com> References: <50B5F39E.1030705@oracle.com> Message-ID: <50B6C0F3.3020205@oracle.com> Vote: yes David On 28/11/2012 9:21 PM, Alan Bateman wrote: > > I hereby nominate Mandy Chung to membership of the core-libs group. > > Mandy doesn't need any introduction as she has been active in this group > and on this mailing list almost since the start of OpenJDK. This > includes changes to code in the core libraries area, reviewing changes > for others in this area, and also sponsoring changes from authors and > contributors in this area. Mandy has Reviewer and Committer role on > several projects and is also a member of the serviceability and members > groups. > > Votes are due by Dec 12, 2012, 08.59 PST. > > Only current members of the core-libs group [1] are eligible to vote on > this nomination. For lazy consensus voting instructions, see [2]. > > -Alan. > > [1] http://openjdk.java.net/census#core-libs > [2] http://openjdk.java.net/groups/#member-vote From david.holmes at oracle.com Thu Nov 29 01:57:42 2012 From: david.holmes at oracle.com (David Holmes) Date: Thu, 29 Nov 2012 11:57:42 +1000 Subject: CFV: New core-libs Group Member: Mike Duigou In-Reply-To: <50B5F141.8050902@oracle.com> References: <50B5F141.8050902@oracle.com> Message-ID: <50B6C116.3000702@oracle.com> Vote: yes David On 28/11/2012 9:10 PM, Alan Bateman wrote: > I hereby nominate Mike Duigou to membership of the core-libs group. > > Mike doesn't need any introduction as he has been active in this group > and this mailing list for the last 2 years. Mike has Committer role in > the jdk8, jdk7u and lamdba projects and almost all of the changes that > he has pushed, co-reviewed, or sponsored have been in the core libs area. > > Votes are due by Dec 12, 2012, 08.59 PST. > > Only current members of the core-libs group [1] are eligible to vote on > this nomination. For lazy consensus voting instructions, see [2]. > > -Alan. > > [1] http://openjdk.java.net/census#core-libs > [2] http://openjdk.java.net/groups/#member-vote From david.holmes at oracle.com Thu Nov 29 01:58:14 2012 From: david.holmes at oracle.com (David Holmes) Date: Thu, 29 Nov 2012 11:58:14 +1000 Subject: CFV: New core-libs Group Member: Stuart Marks In-Reply-To: <50B5F154.40702@oracle.com> References: <50B5F154.40702@oracle.com> Message-ID: <50B6C136.7000302@oracle.com> Vote: yes. David On 28/11/2012 9:11 PM, Alan Bateman wrote: > I hereby nominate Stuart Marks to membership of the core-libs group. > > Stuart doesn't need any introduction as he has been active in this group > and this mailing list for more than 2 years. Stuart has Committer role > in the jdk8, jdk7u and lamdba projects and all of the changes that he > has pushed, co-reviewed, or sponsored have been in the core libs area. > > Votes are due by Dec 12, 2012, 08.59 PST. > > Only current members of the core-libs group [1] are eligible to vote on > this nomination. For lazy consensus voting instructions, see [2]. > > -Alan. > > [1] http://openjdk.java.net/census#core-libs > [2] http://openjdk.java.net/groups/#member-vote From stuart.marks at oracle.com Thu Nov 29 03:11:02 2012 From: stuart.marks at oracle.com (Stuart Marks) Date: Wed, 28 Nov 2012 19:11:02 -0800 Subject: RFR: 8003380 - Compiler warnings in logging test code In-Reply-To: <50B65D2C.3070501@oracle.com> References: <50A40A00.8060106@oracle.com> <50A4CCB3.80305@oracle.com> <50A6F8EC.7080905@oracle.com> <50A6FE36.8050208@oracle.com> <50B65798.8080901@oracle.com> <50B65D2C.3070501@oracle.com> Message-ID: <50B6D246.70607@oracle.com> I'm a bit happier that @SuppressWarnings("unused") has been removed. Note, I only got pulled into this because of the @SuppressWarnings namespace question; I didn't look at the rest of the webrev. s'marks On 11/28/12 10:51 AM, Jim Gish wrote: > Since we don't yet have a resolution on this, I modified the test code in > question to remove the @SuppressWarnings("unused") and actually removed the > unused references (and retested, of course). > > Please review > http://cr.openjdk.java.net/~jgish/Bug8003380-logging-test-warnings/ > and if > ok, Chris, could you please go ahead and push the changes? > > thanks, > Jim > > > On 11/28/2012 01:27 PM, Jim Gish wrote: >> Here's the list of @suppresswarnings values that are recognized by Eclipse Juno: >> >> >> Excluding warnings using @SuppressWarnings >> >> Since Java 5.0, you can disable compilation warnings relative to a subset of >> a compilation unit using the|java.lang.SuppressWarning|annotation. >> >> @SuppressWarning("unused") public void foo() { >> String s; >> } >> >> Without the annotation, the compiler would complain that the local >> variable|s|is never used. With the annotation, the compiler silently ignores >> this warning locally to the|foo|method. This enables to keep the warnings in >> other locations of the same compilation unit or the same project. >> >> The list of tokens that can be used inside a|SuppressWarnings|annotation is: >> >> * allto suppress all warnings >> * boxingto suppress warnings relative to boxing/unboxing operations >> * castto suppress warnings relative to cast operations >> * dep-annto suppress warnings relative to deprecated annotation >> * deprecationto suppress warnings relative to deprecation >> * fallthroughto suppress warnings relative to missing breaks in switch >> statements >> * finallyto suppress warnings relative to finally block that don't return >> * hidingto suppress warnings relative to locals that hide variable >> * incomplete-switchto suppress warnings relative to missing entries in >> a switch statement (enum case) >> * javadocto suppress warnings relative to javadoc warnings >> * nlsto suppress warnings relative to non-nls string literals >> * nullto suppress warnings relative to null analysis >> * rawtypesto suppress warnings relative to usage of raw types >> * resourceto suppress warnings relative to usage of resources of type >> Closeable >> * restrictionto suppress warnings relative to usage of discouraged or >> forbidden references >> * serialto suppress warnings relative to missing serialVersionUID >> field for a serializable class >> * static-accessto suppress warnings relative to incorrect static access >> * static-methodto suppress warnings relative to methods that could be >> declared as static >> * superto suppress warnings relative to overriding a method without >> super invocations >> * synthetic-accessto suppress warnings relative to unoptimized access >> from inner classes >> * sync-overrideto suppress warnings because of missing synchronize >> when overriding a synchronized method >> * uncheckedto suppress warnings relative to unchecked operations >> * unqualified-field-accessto suppress warnings relative to field >> access unqualified >> * unusedto suppress warnings relative to unused code and dead code >> >> (From >> http://help.eclipse.org/juno/index.jsp?topic=/org.eclipse.jdt.doc.isv/guide/jdt%255Fapi%255Fcompile.htm) >> >> Jim >> >> On 11/16/2012 10:02 PM, Stuart Marks wrote: >>> On 11/16/12 6:39 PM, Stuart Marks wrote: >>>> The background is that the words that can be supplied to @SuppressWarnings >>>> reside in an uncontrolled namespace. The JLS [1] defines only "unchecked" and >>>> any others are compiler-specific. The set of words accepted here by javac is >>>> the same as the words defined for -Xlint. >>>> >>>> [1] http://docs.oracle.com/javase/specs/jls/se7/html/jls-9.html#jls-9.6.3.5 >>> >>> Whoops, the JLS defines "deprecation" as well (as Alan pointed out in >>> another thread the other day). But the rest of the point stands. >>> >>> s'marks >> > > -- > 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 david.holmes at oracle.com Thu Nov 29 05:50:57 2012 From: david.holmes at oracle.com (David Holmes) Date: Thu, 29 Nov 2012 15:50:57 +1000 Subject: Request for Review : CR#8004015 : Add interface extends and defaults for basic functional interfaces In-Reply-To: <54FA2248-91D9-4181-AC30-22FB365D3297@oracle.com> References: <54FA2248-91D9-4181-AC30-22FB365D3297@oracle.com> Message-ID: <50B6F7C1.4080606@oracle.com> Mike, On 28/11/2012 3:32 AM, Mike Duigou wrote: > On Nov 27 2012, at 03:56 , Stephen Colebourne wrote: > >> On 27 November 2012 02:12, Mike Duigou wrote: >>> In the original patch which added the basic lambda functional interfaces, CR#8001634 [1], none of the interfaces extended other interfaces. The reason was primarily that the javac compiler did not, at the time that 8001634 was proposed, support extension methods. The compiler now supports adding of method defaults so this patch improves the functional interfaces by filing in the inheritance hierarchy. >>> >>> Adding the parent interfaces and default methods allows each functional interface to be used in more places. It is especially important for the functional interfaces which support primitive types, IntSupplier, IntFunction, IntUnaryOperator, IntBinaryOperator, etc. We expect that eventually standard implementations of these interfaces will be provided for functions like max, min, sum, etc. By extending the reference oriented functional interfaces such as Function, the primitive implementations can be used with the boxed primitive types along with the primitive types for which they are defined. >>> >>> The patch to add parent interfaces and default methods can be found here: >>> >>> http://cr.openjdk.java.net/~mduigou/8004015/0/webrev/ >>> http://cr.openjdk.java.net/~mduigou/8004015/0/specdiff/java/util/function/package-summary.html >> >> Each of the default methods is formatted on a single line. I consider >> this to be bad style, they should be formatted as per "normal" >> methods: >> @Override >> public default Double operate(Double left, Double right) { >> return operateAsDouble((double) left, (double) right); >> } >> >> It is vitally important to get this kind of formatting/style correct. > >> Developers the world over will be copying what the style is in these >> classes. > > I totally agree that we should be consistent but I don't believe that there's a consensus yet on what good style is for these cases. What's your rationale for it being "bad style"? I have to concur with Stephen - these are just method definitions and should follow the same style that is used for method definitions in classes. No need to contemplate introducing a new style just for default methods. >> There is also no Javadoc on the default method override. > > That was intentional. The goal was to inherit from the original definition. I don't think we can just leave it at that. If we are introducing additional constraints over that specified in base method then they need to be documented. We should be able to use implicit doc inheritance plus @{inheritDoc} to bring down what is unchanged and then add what is needed. I don't agree that we need to describe what the default implementation does, for two reasons: 1. Normal methods don't usually specify how they are implemented - it is an implementation detail. The "default" simply indicates that this method does have an implementation and you should expect that implementation to obey the contract of the method. 2. It is not obvious to me that the JDK's choice for a default implementation has to be _the_ only possible implementation choice. In many/most cases there will be a very obvious choice, but that doesn't mean that all suppliers of OpenJDK classes have to be locked in to that choice. Cheers, David ----- >> In this case, >> passing a null to either parameter will result in an NPE. This should >> be documented. > > Agreed. However... The following seems entirely overkill and given how these interfaces are likely to be used the javadoc will not be visible. My inclination is to add the description regarding null behaviour to the class javadoc at the same point where it's described that IntBlock can be used for Block. ie. > > This is the primitive type specialization of Block for int and also may be used as a Block provided that the parameter to accept(Integer) always is non-null. > >> >> More generally, you/Oracle should define a standard form of words for >> describing what a default method does. Interfaces have not had them >> before, and their behaviour needs documenting (even if it seems >> obvious). >> >> /** >> * An operation upon two operands yielding a result. >> * The operands and the result are all of the same type. >> *

>> * The default implementation calls {@link operate(double,double)}, >> * throwing NullPointerException if either input is null. >> * >> * @param left the first operand, not null >> * @param left the first operand, not null >> * @return the result, not null >> */ >> @Override >> public default Double operate(Double left, Double right) { >> return operateAsDouble((double) left, (double) right); >> } >> >> Stephen >> > > From amy.lu at oracle.com Thu Nov 29 07:02:34 2012 From: amy.lu at oracle.com (Amy Lu) Date: Thu, 29 Nov 2012 15:02:34 +0800 Subject: Code review request 8004134: More ProblemList.txt updates (11/2012) Message-ID: <50B7088A.4080106@oracle.com> We have a few test failures on nightly testing, they are failing for known issues and should be excluded until issue is resolved. Please review: https://dl.dropbox.com/u/5812451/yl153753/8004134/webrev.00/index.html Thanks, Amy From zhangshj at linux.vnet.ibm.com Thu Nov 29 07:17:48 2012 From: zhangshj at linux.vnet.ibm.com (Shi Jun) Date: Thu, 29 Nov 2012 15:17:48 +0800 Subject: 7099119: Remove unused dlinfo local variable in launcher code Message-ID: <50B70C1C.50706@linux.vnet.ibm.com> Hi all, Previously 7099119 is fixed in the following changeset: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/dd55467dd1f2, but this change is lost during the Mac port merging changes 7113349 and 7146424. Hereby I raise this thread again. Webrev: http://cr.openjdk.java.net/~zhangshj/7099119/webrev.00/ Previous discuss thread: http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-October/007872.html -- Regards, Shi Jun Zhang From michael.x.mcmahon at oracle.com Thu Nov 29 10:26:32 2012 From: michael.x.mcmahon at oracle.com (michael.x.mcmahon at oracle.com) Date: Thu, 29 Nov 2012 10:26:32 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20121129102724.1680E47BBE@hg.openjdk.java.net> Changeset: 13ec794734f5 Author: michaelm Date: 2012-11-29 09:41 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/13ec794734f5 7200720: crash in net.dll during NTLM authentication Reviewed-by: chegar, dsamersoff ! make/java/net/Makefile ! src/windows/classes/sun/net/www/protocol/http/ntlm/NTLMAuthSequence.java ! src/windows/classes/sun/net/www/protocol/http/ntlm/NTLMAuthentication.java ! src/windows/native/sun/net/www/protocol/http/ntlm/NTLMAuthSequence.c Changeset: ba5eabd6a37b Author: michaelm Date: 2012-11-29 09:47 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ba5eabd6a37b Merge From Alan.Bateman at oracle.com Thu Nov 29 10:40:56 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 29 Nov 2012 10:40:56 +0000 Subject: 7099119: Remove unused dlinfo local variable in launcher code In-Reply-To: <50B70C1C.50706@linux.vnet.ibm.com> References: <50B70C1C.50706@linux.vnet.ibm.com> Message-ID: <50B73BB8.6020808@oracle.com> On 29/11/2012 07:17, Shi Jun wrote: > Hi all, > > Previously 7099119 is fixed in the following changeset: > http://hg.openjdk.java.net/jdk8/tl/jdk/rev/dd55467dd1f2, but this > change is lost during the Mac port merging changes 7113349 and 7146424. > > Hereby I raise this thread again. > > Webrev: http://cr.openjdk.java.net/~zhangshj/7099119/webrev.00/ > Previous discuss thread: > http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-October/007872.html > I don't know this slipped it, perhaps it was due to the refactoring. In any case your change looks fine. -Alan From Alan.Bateman at oracle.com Thu Nov 29 10:42:07 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 29 Nov 2012 10:42:07 +0000 Subject: Code review request 8004134: More ProblemList.txt updates (11/2012) In-Reply-To: <50B7088A.4080106@oracle.com> References: <50B7088A.4080106@oracle.com> Message-ID: <50B73BFF.7010802@oracle.com> On 29/11/2012 07:02, Amy Lu wrote: > We have a few test failures on nightly testing, they are failing for > known issues and should be excluded until issue is resolved. > > Please review: > https://dl.dropbox.com/u/5812451/yl153753/8004134/webrev.00/index.html > > Thanks, > Amy This looks okay to me. Stuart - do you mind sponsoring this? -Alan. From aleksey.shipilev at oracle.com Thu Nov 29 11:05:21 2012 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Thu, 29 Nov 2012 15:05:21 +0400 Subject: RFR (XS) CR 8004141: UnsafeStaticFieldAccessorImpl#base should be final Message-ID: <50B74171.5010202@oracle.com> Hi, Submitted the original issue found by Peter Levart [1] as CR 8004141. Peter had suggested the trivial change [2] to fix this. Please review. Thanks, Aleksey. [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-November/012498.html [2] http://dl.dropbox.com/u/101777488/jdk8-hacks/UnsafeStaticFieldAccessorImpl.base/webrev/index.html From chris.hegarty at oracle.com Thu Nov 29 11:19:43 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 29 Nov 2012 11:19:43 +0000 Subject: RFR (XS) CR 8004141: UnsafeStaticFieldAccessorImpl#base should be final In-Reply-To: <50B74171.5010202@oracle.com> References: <50B74171.5010202@oracle.com> Message-ID: <50B744CF.3070600@oracle.com> Looks fine to me Aleksey. Let me know if you need a sponsor to get this into jdk8. -Chris. On 11/29/2012 11:05 AM, Aleksey Shipilev wrote: > Hi, > > Submitted the original issue found by Peter Levart [1] as CR 8004141. > Peter had suggested the trivial change [2] to fix this. > > Please review. > > Thanks, > Aleksey. > > [1] > http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-November/012498.html > [2] > http://dl.dropbox.com/u/101777488/jdk8-hacks/UnsafeStaticFieldAccessorImpl.base/webrev/index.html > From aleksey.shipilev at oracle.com Thu Nov 29 11:21:35 2012 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Thu, 29 Nov 2012 15:21:35 +0400 Subject: RFR (XS) CR 8004141: UnsafeStaticFieldAccessorImpl#base should be final In-Reply-To: <50B744CF.3070600@oracle.com> References: <50B74171.5010202@oracle.com> <50B744CF.3070600@oracle.com> Message-ID: <50B7453F.9000006@oracle.com> I do, since I do not have the commit rights into OpenJDK repos. Thanks! -Aleksey. On 11/29/2012 03:19 PM, Chris Hegarty wrote: > Looks fine to me Aleksey. Let me know if you need a sponsor to get this > into jdk8. > > -Chris. > > On 11/29/2012 11:05 AM, Aleksey Shipilev wrote: >> Hi, >> >> Submitted the original issue found by Peter Levart [1] as CR 8004141. >> Peter had suggested the trivial change [2] to fix this. >> >> Please review. >> >> Thanks, >> Aleksey. >> >> [1] >> http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-November/012498.html >> >> [2] >> http://dl.dropbox.com/u/101777488/jdk8-hacks/UnsafeStaticFieldAccessorImpl.base/webrev/index.html >> >> From Alan.Bateman at oracle.com Thu Nov 29 11:22:26 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 29 Nov 2012 11:22:26 +0000 Subject: RFR (XS) CR 8004141: UnsafeStaticFieldAccessorImpl#base should be final In-Reply-To: <50B74171.5010202@oracle.com> References: <50B74171.5010202@oracle.com> Message-ID: <50B74572.3040603@oracle.com> On 29/11/2012 11:05, Aleksey Shipilev wrote: > Hi, > > Submitted the original issue found by Peter Levart [1] as CR 8004141. > Peter had suggested the trivial change [2] to fix this. > > Please review. > > Thanks, > Aleksey. > > [1] > http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-November/012498.html > [2] > http://dl.dropbox.com/u/101777488/jdk8-hacks/UnsafeStaticFieldAccessorImpl.base/webrev/index.html It looks fine, are you looking for a sponsor? -Alan From aleksey.shipilev at oracle.com Thu Nov 29 11:28:30 2012 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Thu, 29 Nov 2012 15:28:30 +0400 Subject: RFR (XS) CR 8004141: UnsafeStaticFieldAccessorImpl#base should be final In-Reply-To: <50B74572.3040603@oracle.com> References: <50B74171.5010202@oracle.com> <50B74572.3040603@oracle.com> Message-ID: <50B746DE.4090202@oracle.com> On 11/29/2012 03:22 PM, Alan Bateman wrote: > It looks fine, are you looking for a sponsor? Thanks. Chris had already volunteered for this. -Aleksey. From chris.hegarty at oracle.com Thu Nov 29 12:30:55 2012 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Thu, 29 Nov 2012 12:30:55 +0000 Subject: hg: jdk8/tl/jdk: 8003380: Compiler warnings in logging test code Message-ID: <20121129123111.0D04747BC2@hg.openjdk.java.net> Changeset: 2b829a5a46ee Author: jgish Date: 2012-11-29 12:28 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2b829a5a46ee 8003380: Compiler warnings in logging test code Summary: Use generics, suppress warnings where appropriate, remove unused imports, etc. Reviewed-by: lancea, chegar ! test/java/util/logging/ClassLoaderLeakTest.java ! test/java/util/logging/Listeners.java ! test/java/util/logging/ListenersWithSM.java ! test/java/util/logging/LoggerResourceBundleRace.java ! test/java/util/logging/LoggingDeadlock2.java ! test/java/util/logging/LoggingDeadlock3.java ! test/java/util/logging/LoggingDeadlock4.java ! test/java/util/logging/LoggingMXBeanTest.java ! test/java/util/logging/LoggingMXBeanTest2.java ! test/java/util/logging/MemoryHandlerTest.java ! test/java/util/logging/ParentLoggersTest.java ! test/java/util/logging/SimpleFormatterFormat.java From chris.hegarty at oracle.com Thu Nov 29 12:34:00 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 29 Nov 2012 12:34:00 +0000 Subject: RFR: 8003380 - Compiler warnings in logging test code In-Reply-To: <50B65D2C.3070501@oracle.com> References: <50A40A00.8060106@oracle.com> <50A4CCB3.80305@oracle.com> <50A6F8EC.7080905@oracle.com> <50A6FE36.8050208@oracle.com> <50B65798.8080901@oracle.com> <50B65D2C.3070501@oracle.com> Message-ID: <50B75638.4080506@oracle.com> and pushed... http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2b829a5a46ee -Chris. On 11/28/2012 06:51 PM, Jim Gish wrote: > Since we don't yet have a resolution on this, I modified the test code > in question to remove the @SuppressWarnings("unused") and actually > removed the unused references (and retested, of course). > > Please review > http://cr.openjdk.java.net/~jgish/Bug8003380-logging-test-warnings/ > > and if ok, Chris, could you please go ahead and push the changes? > > thanks, > Jim > > > On 11/28/2012 01:27 PM, Jim Gish wrote: >> Here's the list of @suppresswarnings values that are recognized by >> Eclipse Juno: >> >> >> Excluding warnings using @SuppressWarnings >> >> Since Java 5.0, you can disable compilation warnings relative to a >> subset of a compilation unit using >> the|java.lang.SuppressWarning|annotation. >> >> @SuppressWarning("unused") public void foo() { >> String s; >> } >> >> Without the annotation, the compiler would complain that the local >> variable|s|is never used. With the annotation, the compiler silently >> ignores this warning locally to the|foo|method. This enables to keep >> the warnings in other locations of the same compilation unit or the >> same project. >> >> The list of tokens that can be used inside >> a|SuppressWarnings|annotation is: >> >> * allto suppress all warnings >> * boxingto suppress warnings relative to boxing/unboxing operations >> * castto suppress warnings relative to cast operations >> * dep-annto suppress warnings relative to deprecated annotation >> * deprecationto suppress warnings relative to deprecation >> * fallthroughto suppress warnings relative to missing breaks in switch >> statements >> * finallyto suppress warnings relative to finally block that don't >> return >> * hidingto suppress warnings relative to locals that hide variable >> * incomplete-switchto suppress warnings relative to missing entries in >> a switch statement (enum case) >> * javadocto suppress warnings relative to javadoc warnings >> * nlsto suppress warnings relative to non-nls string literals >> * nullto suppress warnings relative to null analysis >> * rawtypesto suppress warnings relative to usage of raw types >> * resourceto suppress warnings relative to usage of resources of type >> Closeable >> * restrictionto suppress warnings relative to usage of discouraged or >> forbidden references >> * serialto suppress warnings relative to missing serialVersionUID >> field for a serializable class >> * static-accessto suppress warnings relative to incorrect static access >> * static-methodto suppress warnings relative to methods that could be >> declared as static >> * superto suppress warnings relative to overriding a method without >> super invocations >> * synthetic-accessto suppress warnings relative to unoptimized access >> from inner classes >> * sync-overrideto suppress warnings because of missing synchronize >> when overriding a synchronized method >> * uncheckedto suppress warnings relative to unchecked operations >> * unqualified-field-accessto suppress warnings relative to field >> access unqualified >> * unusedto suppress warnings relative to unused code and dead code >> >> (From >> http://help.eclipse.org/juno/index.jsp?topic=/org.eclipse.jdt.doc.isv/guide/jdt%255Fapi%255Fcompile.htm) >> >> Jim >> >> On 11/16/2012 10:02 PM, Stuart Marks wrote: >>> On 11/16/12 6:39 PM, Stuart Marks wrote: >>>> The background is that the words that can be supplied to >>>> @SuppressWarnings >>>> reside in an uncontrolled namespace. The JLS [1] defines only >>>> "unchecked" and >>>> any others are compiler-specific. The set of words accepted here by >>>> javac is >>>> the same as the words defined for -Xlint. >>>> >>>> [1] >>>> http://docs.oracle.com/javase/specs/jls/se7/html/jls-9.html#jls-9.6.3.5 >>> >>> Whoops, the JLS defines "deprecation" as well (as Alan pointed out in >>> another thread the other day). But the rest of the point stands. >>> >>> s'marks >> > > -- > 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 chris.hegarty at oracle.com Thu Nov 29 14:44:40 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 29 Nov 2012 14:44:40 +0000 Subject: Request for Review : CR#8004015 : Add interface extends and defaults for basic functional interfaces In-Reply-To: <50B6F7C1.4080606@oracle.com> References: <54FA2248-91D9-4181-AC30-22FB365D3297@oracle.com> <50B6F7C1.4080606@oracle.com> Message-ID: <50B774D8.60403@oracle.com> On 11/29/2012 05:50 AM, David Holmes wrote: > ... > > I don't agree that we need to describe what the default implementation > does, for two reasons: > > 1. Normal methods don't usually specify how they are implemented - it is > an implementation detail. The "default" simply indicates that this > method does have an implementation and you should expect that > implementation to obey the contract of the method. > > 2. It is not obvious to me that the JDK's choice for a default > implementation has to be _the_ only possible implementation choice. In > many/most cases there will be a very obvious choice, but that doesn't > mean that all suppliers of OpenJDK classes have to be locked in to that > choice. This is certainly interesting, and something I've wondered for a while now. If java.util.Iterator is to ever be fitted with a default implementation of remove ( to throw UnsupportedOperationException ), then it would clearly need to be part of the spec, and not an implementation detail of OpenJDK. Otherwise, what's the point, every developer will still have to implement it because they cannot be guaranteed of it's behavior. -Chris. From chris.hegarty at oracle.com Thu Nov 29 17:05:13 2012 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Thu, 29 Nov 2012 17:05:13 +0000 Subject: hg: jdk8/tl/jdk: 8004141: UnsafeStaticFieldAccessorImpl#base should be final Message-ID: <20121129170547.49D6747BDB@hg.openjdk.java.net> Changeset: d91e6cb1da41 Author: shade Date: 2012-11-29 17:03 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d91e6cb1da41 8004141: UnsafeStaticFieldAccessorImpl#base should be final Reviewed-by: chegar, alanb Contributed-by: peter.levart at gmail.com ! src/share/classes/sun/reflect/UnsafeStaticFieldAccessorImpl.java From mike.duigou at oracle.com Thu Nov 29 22:10:50 2012 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Thu, 29 Nov 2012 22:10:50 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20121129221115.4FF2F47BE5@hg.openjdk.java.net> Changeset: bf6ceb6b8f80 Author: mduigou Date: 2012-11-29 14:07 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bf6ceb6b8f80 7175464: entrySetView field is never updated in NavigableSubMap Summary: The method entrySet() in AscendingSubMap and DescendingSubMap failed to cache the entrySetView. Reviewed-by: alanb, psandoz ! src/share/classes/java/util/TreeMap.java Changeset: 75cb07a7b622 Author: mduigou Date: 2012-11-29 14:09 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/75cb07a7b622 6553074: String{Buffer,Builder}.indexOf(Str, int) contains unnecessary allocation Summary: It is not necessary to extract the value array with toCharArray. The value array can now be used directly. Reviewed-by: alanb ! src/share/classes/java/lang/AbstractStringBuilder.java ! src/share/classes/java/lang/String.java From stuart.marks at oracle.com Thu Nov 29 22:28:29 2012 From: stuart.marks at oracle.com (stuart.marks at oracle.com) Date: Thu, 29 Nov 2012 22:28:29 +0000 Subject: hg: jdk8/tl: 8004131: move jdi tests out of core testset Message-ID: <20121129222829.9601E47BE7@hg.openjdk.java.net> Changeset: ab1ab9b148dd Author: smarks Date: 2012-11-28 17:31 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/ab1ab9b148dd 8004131: move jdi tests out of core testset Reviewed-by: alanb, chegar ! make/jprt.properties From stuart.marks at oracle.com Thu Nov 29 22:29:18 2012 From: stuart.marks at oracle.com (stuart.marks at oracle.com) Date: Thu, 29 Nov 2012 22:29:18 +0000 Subject: hg: jdk8/tl/jdk: 8004131: move jdi tests out of core testset Message-ID: <20121129222933.6F61047BE8@hg.openjdk.java.net> Changeset: 83d9f30ebeed Author: smarks Date: 2012-11-28 17:31 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/83d9f30ebeed 8004131: move jdi tests out of core testset Reviewed-by: alanb, chegar ! make/jprt.properties From stuart.marks at oracle.com Thu Nov 29 22:38:40 2012 From: stuart.marks at oracle.com (Stuart Marks) Date: Thu, 29 Nov 2012 14:38:40 -0800 Subject: Code review request 8004134: More ProblemList.txt updates (11/2012) In-Reply-To: <50B73BFF.7010802@oracle.com> References: <50B7088A.4080106@oracle.com> <50B73BFF.7010802@oracle.com> Message-ID: <50B7E3F0.5070807@oracle.com> On 11/29/12 2:42 AM, Alan Bateman wrote: > On 29/11/2012 07:02, Amy Lu wrote: >> We have a few test failures on nightly testing, they are failing for known >> issues and should be excluded until issue is resolved. >> >> Please review: >> https://dl.dropbox.com/u/5812451/yl153753/8004134/webrev.00/index.html >> >> Thanks, >> Amy > This looks okay to me. > > Stuart - do you mind sponsoring this? Yes, I'll take care of this. Amy, thanks for preparing this. The changes look good. We had also observed some failures in tools/launcher/Arrrghs.java but I guess we'll push on Kumar to fix this up instead of adding it to the problem list. s'marks From stuart.marks at oracle.com Thu Nov 29 22:43:04 2012 From: stuart.marks at oracle.com (stuart.marks at oracle.com) Date: Thu, 29 Nov 2012 22:43:04 +0000 Subject: hg: jdk8/tl/jdk: 8004134: More ProblemList.txt updates (11/2012) Message-ID: <20121129224315.E787047BE9@hg.openjdk.java.net> Changeset: 7ccf93c60c4d Author: smarks Date: 2012-11-29 14:43 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7ccf93c60c4d 8004134: More ProblemList.txt updates (11/2012) Reviewed-by: alanb Contributed-by: amy.lu at oracle.com ! test/ProblemList.txt From kurchi.subhra.hazra at oracle.com Fri Nov 30 02:04:42 2012 From: kurchi.subhra.hazra at oracle.com (Kurchi Hazra) Date: Thu, 29 Nov 2012 18:04:42 -0800 Subject: Code Review Request: 7197662: (prefs) java/util/prefs/AddNodeChangeListener.java fails by timeout or by "couldn't get file lock" In-Reply-To: <505CB69E.1080005@oracle.com> References: <505B8907.2090006@oracle.com> <505BB0EB.2080406@oracle.com> <505C2D76.8000302@oracle.com> <505CB69E.1080005@oracle.com> Message-ID: <50B8143A.3010200@oracle.com> Apologies for the extreme delay. I added the bug id, and checked that setting the userRoot=. will result in the JTwork/scratch directory being used to store the preferences. I think we had concluded that othervm is the correct choice for running a test when setting the -Djava.util.prefs.userRoot property. Updated webrev: http://cr.openjdk.java.net/~khazra/7197662/webrev.01/ Note that the -Djava.util.prefs.userRoot property is only honored by Linux/Solaris implementations. Windows and Mac OS will continue to use the user's home directory, or the default location that the respective platform uses to store preferences. Thanks, Kurchi On 9/21/12 11:49 AM, Kurchi Hazra wrote: > > > On 21.09.2012 02:03, Chris Hegarty wrote: >> On 21/09/12 01:12, Dan Xu wrote: >>> Kurchi, >>> >>> Can you append bug number 7197662 to @bug field in each test so that it >>> is easy to check its history? >> >> Yes, this is always a good idea. > Sure, I missed adding the bug id. >> >>> For your changes, I wonder why you choose to run these tests in othervm >>> mode. Thanks! >> >> The tests need to run in othervm mode as they are now setting a >> system property. We don't want this system property to inadvertently >> effect other tests, if a batch are being run in samevm or agentvm. > Right, I looked at some examples in jdk/src/test of tests which set > system properties, and this is what they were doing. > http://openjdk.java.net/jtreg/tag-spec.txt also hints toward the same. > >> >> Assuming that '.' means the scratch directory when jtreg is running, >> then I'm fine with these changes. > > That is a good question, and while I assumed it will, the Mac code is > clearly doing other things. I am afraid I need to investigate this > for all platforms and see what others do, and whether we need to make > additional changes in the Mac source code to correct its > behavior. I will get back with a newer webrev soon. > > > Thanks! > - Kurchi > >> >> -Chris. >> >>> >>> -Dan >>> >>> On Thu 20 Sep 2012 02:22:15 PM PDT, Kurchi Hazra wrote: >>>> >>>> Hi, >>>> The tests in java/util/prefs creates new nodes under the user's home >>>> directory. >>>> This causes the tests to start out with pre-existing preferences and >>>> sometimes >>>> leads to interference between the tests. This fix is to change the >>>> userRoot >>>> property for each of these tests so these tests create nodes only >>>> under the >>>> current directory. >>>> >>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7197662 >>>> Webrev: http://cr.openjdk.java.net/~khazra/7197662/webrev.00/ >>>> >>>> Thanks, >>>> - Kurchi > From david.holmes at oracle.com Fri Nov 30 02:03:34 2012 From: david.holmes at oracle.com (David Holmes) Date: Fri, 30 Nov 2012 12:03:34 +1000 Subject: Request for Review : CR#8004015 : Add interface extends and defaults for basic functional interfaces In-Reply-To: <50B774D8.60403@oracle.com> References: <54FA2248-91D9-4181-AC30-22FB365D3297@oracle.com> <50B6F7C1.4080606@oracle.com> <50B774D8.60403@oracle.com> Message-ID: <50B813F6.6040602@oracle.com> On 30/11/2012 12:44 AM, Chris Hegarty wrote: > On 11/29/2012 05:50 AM, David Holmes wrote: >> ... >> >> I don't agree that we need to describe what the default implementation >> does, for two reasons: >> >> 1. Normal methods don't usually specify how they are implemented - it is >> an implementation detail. The "default" simply indicates that this >> method does have an implementation and you should expect that >> implementation to obey the contract of the method. >> >> 2. It is not obvious to me that the JDK's choice for a default >> implementation has to be _the_ only possible implementation choice. In >> many/most cases there will be a very obvious choice, but that doesn't >> mean that all suppliers of OpenJDK classes have to be locked in to that >> choice. > > This is certainly interesting, and something I've wondered for a while > now. If java.util.Iterator is to ever be fitted with a default > implementation of remove ( to throw UnsupportedOperationException ), > then it would clearly need to be part of the spec, and not an > implementation detail of OpenJDK. Otherwise, what's the point, every > developer will still have to implement it because they cannot be > guaranteed of it's behavior. I think optional methods are a bit of a special case here because they don't have to work. It's the end user of a class that needs to understand if they can use remove() to actually do a removal. The developer of the class can inherit whatever default implementations Iterator provides, as long as they don't mind what they get. If they do mind ie they need a real remove(), then they will have to implement it themselves and in the process document that fact. The end user has to look at the docs for the concrete class and follow through to determine whether it's iterator().remove() is optional or not. Put another way, a default method is great for adding a new method to types that have not yet been revised to handle the new method. As a developer once you revise your class you should make a conscious implementation choice in my opinion and not rely on the default unless you truly don't care what it does. But maybe we kid ourselves when we give this illusion of flexibility in implementation. David > -Chris. From david.holmes at oracle.com Fri Nov 30 02:31:41 2012 From: david.holmes at oracle.com (David Holmes) Date: Fri, 30 Nov 2012 12:31:41 +1000 Subject: Request for Review: 5049299: (process) Use posix_spawn, not fork, on S10 to avoid swap exhaustion In-Reply-To: <50AE98B1.2040200@oracle.com> References: <50AE98B1.2040200@oracle.com> Message-ID: <50B81A8D.2040403@oracle.com> Hi Rob, This is only a superficial scan. The changes in java/java/makefile look pretty horrible. What are all those -R entries? We will need equivalent changes for the new build system before this is pushed. Is the spawn use BSD specific (as per UnixProcess.java.BSD) or Apple specific (as per __APPLE_ in UNIXProcess_md.c) ? Are the UnixProcess.java files similar enough that we could use a single template and generate the per-OS variants? In UNIXProcess_md.c: 209 #ifdef _CS_PATH 210 char *pathbuf; 211 size_t n; 212 n = confstr(_CS_PATH,NULL,(size_t) 0); 213 pathbuf = malloc(n); 214 if (pathbuf == NULL) 215 abort(); 216 confstr(_CS_PATH, pathbuf, n); 217 return pathbuf; 218 #else what is _CS_PATH and why are we calling abort()? !!!! What is all the xx_ naming ?? David ----- On 23/11/2012 7:27 AM, Rob McKenna wrote: > Hi folks, > > Looking for a review for the webrev below, which also resolves: > > 7175692: (process) Process.exec should use posix_spawn [macosx] > > For additional context and a brief description it would be well worth > looking at the following thread started by Michael McMahon, who did the > brunt of the work for this fix: > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2009-May/thread.html#1644 > > > Basically the fix aims to swap fork for posix_spawn as the default > process launch mechanism on Solaris and Mac OSX in order to avoid swap > exhaustion issues encountered with fork()/exec(). It also offers a flag > (java.lang.useFork) to allow a user to revert to the old behaviour. > > I'm having trouble seeing the wood for the trees at this point so I'm > anticipating plenty of feedback. In particular I'd appreciate some > discussion on: > > - The binary launcher name & property name may need some work. A more > general property ("java.lang.launchMechanism") to allow a user to > specify a particular call was mooted too. It may be more future proof > and I'm completely open to that. (e.g. > launchMechanism=spawn|fork|vfork|clone - we would obviously ignore > inapplicable values on a per-platform basis) > - I'd like a more robust way of checking that someone isn't trying to > use jprochelper outside of the context for which it is meant. > - The decision around which call to use getting moved to the java level > and away from the native preprocessor. > > The webrev is at: > > http://cr.openjdk.java.net/~robm/5049299/webrev.01/ > > > Thanks a lot, > > -Rob > From rob.mckenna at oracle.com Fri Nov 30 03:48:36 2012 From: rob.mckenna at oracle.com (Rob McKenna) Date: Fri, 30 Nov 2012 03:48:36 +0000 Subject: Request for Review: 5049299: (process) Use posix_spawn, not fork, on S10 to avoid swap exhaustion In-Reply-To: <50B81A8D.2040403@oracle.com> References: <50AE98B1.2040200@oracle.com> <50B81A8D.2040403@oracle.com> Message-ID: <50B82C94.90109@oracle.com> Hi David, On 30/11/12 02:31, David Holmes wrote: > Hi Rob, > > This is only a superficial scan. > > The changes in java/java/makefile look pretty horrible. What are all > those -R entries? Library search paths. Currently jprochelper is linked to libjava. I'm hoping to either cut their number (by altering jprochelpers home) or get rid of them altogether (by avoiding linking at all) in the next draft, they are indeed ungainly. > > We will need equivalent changes for the new build system before this > is pushed. > Indeed. > Is the spawn use BSD specific (as per UnixProcess.java.BSD) or Apple > specific (as per __APPLE_ in UNIXProcess_md.c) ? > Eesh, thanks, it applies to both platforms. > Are the UnixProcess.java files similar enough that we could use a > single template and generate the per-OS variants? > Before this change .bsd & .linux were identical (iirc) unfortunately, no longer. Solaris has differences. When you say "generate the per-OS variants" how do you mean? I'd like to keep it as straightforward as possible from a sustaining perspective. (personally I'd like to just extend a base class and try to get away from the makefiles as much as possible - we can discuss this in 8000975 which I'll revisit once I get through this) > In UNIXProcess_md.c: > > 209 #ifdef _CS_PATH > 210 char *pathbuf; > 211 size_t n; > 212 n = confstr(_CS_PATH,NULL,(size_t) 0); > 213 pathbuf = malloc(n); > 214 if (pathbuf == NULL) > 215 abort(); > 216 confstr(_CS_PATH, pathbuf, n); > 217 return pathbuf; > 218 #else > > what is _CS_PATH and why are we calling abort()? !!!! > As per Martins comments I'm going to separate this into another change. See: http://mail.openjdk.java.net/pipermail/core-libs-dev/2009-May/001686.html and http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-November/012456.html for context. I'll look to fall back to the previous code if the pathbuf malloc fails. > What is all the xx_ naming ?? > I believe Michael was using it to denote shared calls. (functions called from both jprochelper and within UNIXProcess_md.c). I presumed it was placeholder text actually, in any case it may go away in the next iteration as per previous comments. If not, I'm happy to replace it with whatever gets it past codereview. -Rob > David > ----- > > > On 23/11/2012 7:27 AM, Rob McKenna wrote: >> Hi folks, >> >> Looking for a review for the webrev below, which also resolves: >> >> 7175692: (process) Process.exec should use posix_spawn [macosx] >> >> For additional context and a brief description it would be well worth >> looking at the following thread started by Michael McMahon, who did the >> brunt of the work for this fix: >> >> http://mail.openjdk.java.net/pipermail/core-libs-dev/2009-May/thread.html#1644 >> >> >> >> Basically the fix aims to swap fork for posix_spawn as the default >> process launch mechanism on Solaris and Mac OSX in order to avoid swap >> exhaustion issues encountered with fork()/exec(). It also offers a flag >> (java.lang.useFork) to allow a user to revert to the old behaviour. >> >> I'm having trouble seeing the wood for the trees at this point so I'm >> anticipating plenty of feedback. In particular I'd appreciate some >> discussion on: >> >> - The binary launcher name & property name may need some work. A more >> general property ("java.lang.launchMechanism") to allow a user to >> specify a particular call was mooted too. It may be more future proof >> and I'm completely open to that. (e.g. >> launchMechanism=spawn|fork|vfork|clone - we would obviously ignore >> inapplicable values on a per-platform basis) >> - I'd like a more robust way of checking that someone isn't trying to >> use jprochelper outside of the context for which it is meant. >> - The decision around which call to use getting moved to the java level >> and away from the native preprocessor. >> >> The webrev is at: >> >> http://cr.openjdk.java.net/~robm/5049299/webrev.01/ >> >> >> Thanks a lot, >> >> -Rob >> From dingxmin at linux.vnet.ibm.com Fri Nov 30 05:26:02 2012 From: dingxmin at linux.vnet.ibm.com (Frank Ding) Date: Fri, 30 Nov 2012 13:26:02 +0800 Subject: JDBC bug: Incorrect number of conflicts is reported by CachedRowSetWriter.writeData In-Reply-To: References: <509C7218.4020807@linux.vnet.ibm.com> <50A1AFA6.8010905@linux.vnet.ibm.com> Message-ID: <50B8436A.3000107@linux.vnet.ibm.com> Hi Lance, Sorry for late response and thanks for your comment. You mean I can write a jtreg test case that connects to Java DB? I can do that. Best regards, Frank On 11/13/2012 10:13 PM, Lance Andersen - Oracle wrote: > Hi Frank, > > > Thank you for the note > If you could in the future, please provide a complete test program to repro the issue as it would save time with the reviews. Ideally if the issue is not database specific it would be good to leverage Java DB as it is included within Oracle JDK > > I will look at this sometime this week > > Best > Lance > On Nov 12, 2012, at 9:25 PM, Frank Ding wrote: > >> Hi Lance >> Thanks for your quick response. Please find the bug info below. >> >> The problem: >> When CachedRowSetImpl.acceptChanges() is called, incorrect number of conflicts, if any, is reported. The number of conflicts is the actual number of existing rows in database, which is the size of variable 'status' defined in CachedRowSetWriter.writeData(). It's not the conflict number that is supposed to be. >> >> Test case: >> The bug can be easily manifested in all SQL server environment. Here take PostgreSQL for example. >> 1. The sql script to create a table >> CREATE TABLE ressystem.roomdescription >> ( >> roomdescription_id serial NOT NULL, >> roomdescription character varying NOT NULL, >> CONSTRAINT roomdescription_pkey PRIMARY KEY (roomdescription_id) >> ) >> >> 2. Manually insert 3 rows >> (1, "Test 1") >> (2, "Test 2") >> (3, "Test 3") >> >> 3. Create a Java class that connects the established database and then execute the following code snippet. >> String query = "select roomdescription_id, roomdescription from ressystem.roomdescription"; >> Object[] values = {2, "Test2"}; >> rs.setCommand(query); >> rs.execute(conn); >> rs.moveToInsertRow(); >> for(int i=0; i> rs.updateObject(i+1,values[i]); >> } >> rs.insertRow(); >> rs.moveToCurrentRow(); >> rs.acceptChanges(conn); >> >> 4. An exception occurs with following output. >> javax.sql.rowset.spi.SyncProviderException: 4conflicts while synchronizing >> at com.sun.rowset.internal.CachedRowSetWriter.writeData(CachedRowSetWriter.java:412) >> at com.sun.rowset.CachedRowSetImpl.acceptChanges(CachedRowSetImpl.java:880) >> >> 5. In fact, there is only one conflicting row but 4 were reported. >> >> Best regards, >> Frank >> >> On 11/9/2012 7:41 PM, Lance Andersen - Oracle wrote: >>> Frank, >>> >>> If you can please post the bug info here, I will take a look at your patch >>> >>> Best >>> Lance >>> On Nov 8, 2012, at 10:01 PM, Frank Ding wrote: >>> >>>> Hi guys, >>>> We discovered a bug in CachedRowSetWriter.writeData method where incorrect number of conflicts is reported. I searched in Oracle bug database and no similar record was found. So I submitted a new one whose internal review ID is 2376620. A test case with code is illustrated in the bug submission that leverages PostgreSQL server but the issue is platform independent and easy to reproduce. >>>> I provided a patch review, available @ >>>> http://cr.openjdk.java.net/~dingxmin/2376620/webrev.01/ >>>> Is there anybody who is interested in patch and can also review bug 2376620? Your reply is appreciated. >>>> >>>> Best regards, >>>> Frank >>>> >>>> >>> >>> 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 jonathan.gibbons at oracle.com Fri Nov 30 06:10:24 2012 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Fri, 30 Nov 2012 06:10:24 +0000 Subject: hg: jdk8/tl/langtools: 7153958: add constant pool reference to class containing inlined constants Message-ID: <20121130061030.7451A47C1E@hg.openjdk.java.net> Changeset: 969c96b980b7 Author: vromero Date: 2012-11-29 09:41 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/969c96b980b7 7153958: add constant pool reference to class containing inlined constants Reviewed-by: jjg, mcimadamore ! src/share/classes/com/sun/tools/javac/comp/Lower.java ! src/share/classes/com/sun/tools/javac/jvm/Gen.java + test/tools/javac/7153958/CPoolRefClassContainingInlinedCts.java + test/tools/javac/7153958/pkg/ClassToBeStaticallyImported.java From zhangshj at linux.vnet.ibm.com Fri Nov 30 07:10:42 2012 From: zhangshj at linux.vnet.ibm.com (Shi Jun) Date: Fri, 30 Nov 2012 15:10:42 +0800 Subject: 7099119: Remove unused dlinfo local variable in launcher code In-Reply-To: <50B73BB8.6020808@oracle.com> References: <50B70C1C.50706@linux.vnet.ibm.com> <50B73BB8.6020808@oracle.com> Message-ID: <50B85BF2.1020405@linux.vnet.ibm.com> On 11/29/2012 6:40 PM, Alan Bateman wrote: > On 29/11/2012 07:17, Shi Jun wrote: >> Hi all, >> >> Previously 7099119 is fixed in the following changeset: >> http://hg.openjdk.java.net/jdk8/tl/jdk/rev/dd55467dd1f2, but this >> change is lost during the Mac port merging changes 7113349 and 7146424. >> >> Hereby I raise this thread again. >> >> Webrev: http://cr.openjdk.java.net/~zhangshj/7099119/webrev.00/ >> Previous discuss thread: >> http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-October/007872.html >> > I don't know this slipped it, perhaps it was due to the refactoring. > In any case your change looks fine. > > -Alan > Thanks, Alan. Hi Jonathan, Could you help to push the change? -- Regards, Shi Jun Zhang From staffan.larsen at oracle.com Fri Nov 30 07:20:01 2012 From: staffan.larsen at oracle.com (staffan.larsen at oracle.com) Date: Fri, 30 Nov 2012 07:20:01 +0000 Subject: hg: jdk8/tl/jdk: 7155168: java/util/TimeZone/Bug6912560.java: expected Asia/Tokyo Message-ID: <20121130072037.120A447C22@hg.openjdk.java.net> Changeset: 55f8ddc2f9c6 Author: sla Date: 2012-11-30 08:17 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/55f8ddc2f9c6 7155168: java/util/TimeZone/Bug6912560.java: expected Asia/Tokyo Reviewed-by: okutsu ! test/java/util/TimeZone/Bug6912560.java From luchsh at linux.vnet.ibm.com Fri Nov 30 08:49:17 2012 From: luchsh at linux.vnet.ibm.com (Jonathan Lu) Date: Fri, 30 Nov 2012 16:49:17 +0800 Subject: 7099119: Remove unused dlinfo local variable in launcher code In-Reply-To: <50B85BF2.1020405@linux.vnet.ibm.com> References: <50B70C1C.50706@linux.vnet.ibm.com> <50B73BB8.6020808@oracle.com> <50B85BF2.1020405@linux.vnet.ibm.com> Message-ID: <50B8730D.4070509@linux.vnet.ibm.com> On 11/30/2012 03:10 PM, Shi Jun wrote: > On 11/29/2012 6:40 PM, Alan Bateman wrote: >> On 29/11/2012 07:17, Shi Jun wrote: >>> Hi all, >>> >>> Previously 7099119 is fixed in the following changeset: >>> http://hg.openjdk.java.net/jdk8/tl/jdk/rev/dd55467dd1f2, but this >>> change is lost during the Mac port merging changes 7113349 and 7146424. >>> >>> Hereby I raise this thread again. >>> >>> Webrev: http://cr.openjdk.java.net/~zhangshj/7099119/webrev.00/ >>> Previous discuss thread: >>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-October/007872.html >>> >> I don't know this slipped it, perhaps it was due to the refactoring. >> In any case your change looks fine. >> >> -Alan >> > Thanks, Alan. > > Hi Jonathan, > > Could you help to push the change? > Hi Chance, I'm getting an error of, "remote: Bugid 7099119 already used in this repository, in revision 4607" Could you please create another sun bug for this issue? Thanks and best regards! - Jonathan From Alan.Bateman at oracle.com Fri Nov 30 08:58:58 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 30 Nov 2012 08:58:58 +0000 Subject: 7099119: Remove unused dlinfo local variable in launcher code In-Reply-To: <50B8730D.4070509@linux.vnet.ibm.com> References: <50B70C1C.50706@linux.vnet.ibm.com> <50B73BB8.6020808@oracle.com> <50B85BF2.1020405@linux.vnet.ibm.com> <50B8730D.4070509@linux.vnet.ibm.com> Message-ID: <50B87552.6060100@oracle.com> On 30/11/2012 08:49, Jonathan Lu wrote: > > Hi Chance, > > I'm getting an error of, > "remote: Bugid 7099119 already used in this repository, in revision 4607" > > Could you please create another sun bug for this issue? Right, you can't use a bug/issue number in more than one change-set in the same repository. I've submitted another one that you can use: JDK-8004211: Remove unused dlinfo local variable in launcher code -Alan From luchsh at linux.vnet.ibm.com Fri Nov 30 09:26:07 2012 From: luchsh at linux.vnet.ibm.com (luchsh at linux.vnet.ibm.com) Date: Fri, 30 Nov 2012 09:26:07 +0000 Subject: hg: jdk8/tl/jdk: 8004211: Remove unused dlinfo local variable in launcher code Message-ID: <20121130092624.E937A47C27@hg.openjdk.java.net> Changeset: e988de7465d4 Author: zhangshj Date: 2012-11-30 17:24 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e988de7465d4 8004211: Remove unused dlinfo local variable in launcher code Reviewed-by: alanb ! src/solaris/bin/java_md_solinux.c From luchsh at linux.vnet.ibm.com Fri Nov 30 09:27:41 2012 From: luchsh at linux.vnet.ibm.com (Jonathan Lu) Date: Fri, 30 Nov 2012 17:27:41 +0800 Subject: 7099119: Remove unused dlinfo local variable in launcher code In-Reply-To: <50B87552.6060100@oracle.com> References: <50B70C1C.50706@linux.vnet.ibm.com> <50B73BB8.6020808@oracle.com> <50B85BF2.1020405@linux.vnet.ibm.com> <50B8730D.4070509@linux.vnet.ibm.com> <50B87552.6060100@oracle.com> Message-ID: <50B87C0D.6010904@linux.vnet.ibm.com> On 11/30/2012 04:58 PM, Alan Bateman wrote: > On 30/11/2012 08:49, Jonathan Lu wrote: >> >> Hi Chance, >> >> I'm getting an error of, >> "remote: Bugid 7099119 already used in this repository, in revision >> 4607" >> >> Could you please create another sun bug for this issue? > Right, you can't use a bug/issue number in more than one change-set in > the same repository. I've submitted another one that you can use: > > JDK-8004211: Remove unused dlinfo local variable in launcher code > > -Alan > Thanks, Alan. The patch has been pushed to http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e988de7465d4 Best regards! - Jonathan From zhangshj at linux.vnet.ibm.com Fri Nov 30 09:42:47 2012 From: zhangshj at linux.vnet.ibm.com (Shi Jun) Date: Fri, 30 Nov 2012 17:42:47 +0800 Subject: 7099119: Remove unused dlinfo local variable in launcher code In-Reply-To: <50B87C0D.6010904@linux.vnet.ibm.com> References: <50B70C1C.50706@linux.vnet.ibm.com> <50B73BB8.6020808@oracle.com> <50B85BF2.1020405@linux.vnet.ibm.com> <50B8730D.4070509@linux.vnet.ibm.com> <50B87552.6060100@oracle.com> <50B87C0D.6010904@linux.vnet.ibm.com> Message-ID: <50B87F97.1080906@linux.vnet.ibm.com> On 11/30/2012 5:27 PM, Jonathan Lu wrote: > On 11/30/2012 04:58 PM, Alan Bateman wrote: >> On 30/11/2012 08:49, Jonathan Lu wrote: >>> >>> Hi Chance, >>> >>> I'm getting an error of, >>> "remote: Bugid 7099119 already used in this repository, in revision >>> 4607" >>> >>> Could you please create another sun bug for this issue? >> Right, you can't use a bug/issue number in more than one change-set >> in the same repository. I've submitted another one that you can use: >> >> JDK-8004211: Remove unused dlinfo local variable in launcher code >> >> -Alan >> > Thanks, Alan. > > The patch has been pushed to > http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e988de7465d4 > > Best regards! > - Jonathan Thanks, Alan and Jonathan. -- Regards, Shi Jun Zhang From chris.hegarty at oracle.com Fri Nov 30 09:58:57 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 30 Nov 2012 09:58:57 +0000 Subject: Request for Review : CR#8004015 : Add interface extends and defaults for basic functional interfaces In-Reply-To: <50B813F6.6040602@oracle.com> References: <54FA2248-91D9-4181-AC30-22FB365D3297@oracle.com> <50B6F7C1.4080606@oracle.com> <50B774D8.60403@oracle.com> <50B813F6.6040602@oracle.com> Message-ID: <50B88361.7060705@oracle.com> On 30/11/2012 02:03, David Holmes wrote: > On 30/11/2012 12:44 AM, Chris Hegarty wrote: >> On 11/29/2012 05:50 AM, David Holmes wrote: >>> ... >>> >>> I don't agree that we need to describe what the default implementation >>> does, for two reasons: >>> >>> 1. Normal methods don't usually specify how they are implemented - it is >>> an implementation detail. The "default" simply indicates that this >>> method does have an implementation and you should expect that >>> implementation to obey the contract of the method. >>> >>> 2. It is not obvious to me that the JDK's choice for a default >>> implementation has to be _the_ only possible implementation choice. In >>> many/most cases there will be a very obvious choice, but that doesn't >>> mean that all suppliers of OpenJDK classes have to be locked in to that >>> choice. >> >> This is certainly interesting, and something I've wondered for a while >> now. If java.util.Iterator is to ever be fitted with a default >> implementation of remove ( to throw UnsupportedOperationException ), >> then it would clearly need to be part of the spec, and not an >> implementation detail of OpenJDK. Otherwise, what's the point, every >> developer will still have to implement it because they cannot be >> guaranteed of it's behavior. > > I think optional methods are a bit of a special case here because they > don't have to work. > > It's the end user of a class that needs to understand if they can use > remove() to actually do a removal. The developer of the class can > inherit whatever default implementations Iterator provides, as long as > they don't mind what they get. If they do mind ie they need a real > remove(), then they will have to implement it themselves and in the > process document that fact. The end user has to look at the docs for the > concrete class and follow through to determine whether it's > iterator().remove() is optional or not. > > Put another way, a default method is great for adding a new method to > types that have not yet been revised to handle the new method. As a > developer once you revise your class you should make a conscious > implementation choice in my opinion and not rely on the default unless > you truly don't care what it does. Sorry David, I've not been following lambda that closely, but (in my opinion) if default methods do not, or cannot, have defined semantics then I really think it is limiting. Maybe Iterator is a bad example, but I will continue with it anyway. In many cases developers of iterator().remove() want it to throw, if this is not defined in Iterator's default remove method then every Iterator subclass will still have to define its own remove that throws. For this particular case at least (if it were to ever happen), I would like to see specification added to remove that defines the default implementation. -Chris. > > But maybe we kid ourselves when we give this illusion of flexibility in > implementation. > > David > >> -Chris. From david.holmes at oracle.com Fri Nov 30 10:09:29 2012 From: david.holmes at oracle.com (David Holmes) Date: Fri, 30 Nov 2012 20:09:29 +1000 Subject: Request for Review : CR#8004015 : Add interface extends and defaults for basic functional interfaces In-Reply-To: <50B88361.7060705@oracle.com> References: <54FA2248-91D9-4181-AC30-22FB365D3297@oracle.com> <50B6F7C1.4080606@oracle.com> <50B774D8.60403@oracle.com> <50B813F6.6040602@oracle.com> <50B88361.7060705@oracle.com> Message-ID: <50B885D9.5060008@oracle.com> On 30/11/2012 7:58 PM, Chris Hegarty wrote: > On 30/11/2012 02:03, David Holmes wrote: >> On 30/11/2012 12:44 AM, Chris Hegarty wrote: >>> On 11/29/2012 05:50 AM, David Holmes wrote: >>>> ... >>>> >>>> I don't agree that we need to describe what the default implementation >>>> does, for two reasons: >>>> >>>> 1. Normal methods don't usually specify how they are implemented - >>>> it is >>>> an implementation detail. The "default" simply indicates that this >>>> method does have an implementation and you should expect that >>>> implementation to obey the contract of the method. >>>> >>>> 2. It is not obvious to me that the JDK's choice for a default >>>> implementation has to be _the_ only possible implementation choice. In >>>> many/most cases there will be a very obvious choice, but that doesn't >>>> mean that all suppliers of OpenJDK classes have to be locked in to that >>>> choice. >>> >>> This is certainly interesting, and something I've wondered for a while >>> now. If java.util.Iterator is to ever be fitted with a default >>> implementation of remove ( to throw UnsupportedOperationException ), >>> then it would clearly need to be part of the spec, and not an >>> implementation detail of OpenJDK. Otherwise, what's the point, every >>> developer will still have to implement it because they cannot be >>> guaranteed of it's behavior. >> >> I think optional methods are a bit of a special case here because they >> don't have to work. >> >> It's the end user of a class that needs to understand if they can use >> remove() to actually do a removal. The developer of the class can >> inherit whatever default implementations Iterator provides, as long as >> they don't mind what they get. If they do mind ie they need a real >> remove(), then they will have to implement it themselves and in the >> process document that fact. The end user has to look at the docs for the >> concrete class and follow through to determine whether it's >> iterator().remove() is optional or not. >> >> Put another way, a default method is great for adding a new method to >> types that have not yet been revised to handle the new method. As a >> developer once you revise your class you should make a conscious >> implementation choice in my opinion and not rely on the default unless >> you truly don't care what it does. > > Sorry David, I've not been following lambda that closely, but (in my > opinion) if default methods do not, or cannot, have defined semantics > then I really think it is limiting. Maybe Iterator is a bad example, but > I will continue with it anyway. In many cases developers of > iterator().remove() want it to throw, if this is not defined in > Iterator's default remove method then every Iterator subclass will still > have to define its own remove that throws. For this particular case at > least (if it were to ever happen), I would like to see specification > added to remove that defines the default implementation. The supplied default implementation will document that it throws. But does that mean it is the only possible default implementation, ever? Again Iterator.remove() is not a great example. default methods are no different to other concrete methods in my opinion. David ------ > -Chris. > >> >> But maybe we kid ourselves when we give this illusion of flexibility in >> implementation. >> >> David >> >>> -Chris. From alan.bateman at oracle.com Fri Nov 30 11:19:16 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Fri, 30 Nov 2012 11:19:16 +0000 Subject: hg: jdk8/tl/jdk: 8003949: LogManager, downgrade normative reference to ${java.home}/lib/logging.properties Message-ID: <20121130112005.2955B47C29@hg.openjdk.java.net> Changeset: 72d3d07b625d Author: alanb Date: 2012-11-30 11:18 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/72d3d07b625d 8003949: LogManager, downgrade normative reference to ${java.home}/lib/logging.properties Reviewed-by: psandoz, mchung ! src/share/classes/java/util/logging/LogManager.java From chris.hegarty at oracle.com Fri Nov 30 12:25:48 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 30 Nov 2012 12:25:48 +0000 Subject: Code Review Request: 7197662: (prefs) java/util/prefs/AddNodeChangeListener.java fails by timeout or by "couldn't get file lock" In-Reply-To: <50B8143A.3010200@oracle.com> References: <505B8907.2090006@oracle.com> <505BB0EB.2080406@oracle.com> <505C2D76.8000302@oracle.com> <505CB69E.1080005@oracle.com> <50B8143A.3010200@oracle.com> Message-ID: <50B8A5CC.1060406@oracle.com> I'm fine with this change Kurchi. -Chris. On 30/11/2012 02:04, Kurchi Hazra wrote: > Apologies for the extreme delay. I added the bug id, and checked that > setting the userRoot=. will result in the JTwork/scratch > directory being used to store the preferences. I think we had concluded > that othervm is the correct choice for running a test > when setting the -Djava.util.prefs.userRoot property. > > Updated webrev: > http://cr.openjdk.java.net/~khazra/7197662/webrev.01/ > > Note that the -Djava.util.prefs.userRoot property is only honored by > Linux/Solaris implementations. Windows and Mac OS > will continue to use the user's home directory, or the default location > that the respective platform uses to store > preferences. > > Thanks, > Kurchi > > On 9/21/12 11:49 AM, Kurchi Hazra wrote: >> >> >> On 21.09.2012 02:03, Chris Hegarty wrote: >>> On 21/09/12 01:12, Dan Xu wrote: >>>> Kurchi, >>>> >>>> Can you append bug number 7197662 to @bug field in each test so that it >>>> is easy to check its history? >>> >>> Yes, this is always a good idea. >> Sure, I missed adding the bug id. >>> >>>> For your changes, I wonder why you choose to run these tests in othervm >>>> mode. Thanks! >>> >>> The tests need to run in othervm mode as they are now setting a >>> system property. We don't want this system property to inadvertently >>> effect other tests, if a batch are being run in samevm or agentvm. >> Right, I looked at some examples in jdk/src/test of tests which set >> system properties, and this is what they were doing. >> http://openjdk.java.net/jtreg/tag-spec.txt also hints toward the same. >> >>> >>> Assuming that '.' means the scratch directory when jtreg is running, >>> then I'm fine with these changes. >> >> That is a good question, and while I assumed it will, the Mac code is >> clearly doing other things. I am afraid I need to investigate this >> for all platforms and see what others do, and whether we need to make >> additional changes in the Mac source code to correct its >> behavior. I will get back with a newer webrev soon. >> >> >> Thanks! >> - Kurchi >> >>> >>> -Chris. >>> >>>> >>>> -Dan >>>> >>>> On Thu 20 Sep 2012 02:22:15 PM PDT, Kurchi Hazra wrote: >>>>> >>>>> Hi, >>>>> The tests in java/util/prefs creates new nodes under the user's home >>>>> directory. >>>>> This causes the tests to start out with pre-existing preferences and >>>>> sometimes >>>>> leads to interference between the tests. This fix is to change the >>>>> userRoot >>>>> property for each of these tests so these tests create nodes only >>>>> under the >>>>> current directory. >>>>> >>>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7197662 >>>>> Webrev: http://cr.openjdk.java.net/~khazra/7197662/webrev.00/ >>>>> >>>>> Thanks, >>>>> - Kurchi >> > From Alan.Bateman at oracle.com Fri Nov 30 12:31:57 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 30 Nov 2012 12:31:57 +0000 Subject: Code Review Request: 7197662: (prefs) java/util/prefs/AddNodeChangeListener.java fails by timeout or by "couldn't get file lock" In-Reply-To: <50B8143A.3010200@oracle.com> References: <505B8907.2090006@oracle.com> <505BB0EB.2080406@oracle.com> <505C2D76.8000302@oracle.com> <505CB69E.1080005@oracle.com> <50B8143A.3010200@oracle.com> Message-ID: <50B8A73D.5010600@oracle.com> On 30/11/2012 02:04, Kurchi Hazra wrote: > Apologies for the extreme delay. I added the bug id, and checked that > setting the userRoot=. will result in the JTwork/scratch > directory being used to store the preferences. I think we had > concluded that othervm is the correct choice for running a test > when setting the -Djava.util.prefs.userRoot property. > > Updated webrev: > http://cr.openjdk.java.net/~khazra/7197662/webrev.01/ > > Note that the -Djava.util.prefs.userRoot property is only honored by > Linux/Solaris implementations. Windows and Mac OS > will continue to use the user's home directory, or the default > location that the respective platform uses to store > preferences. I think what you have is fine as it will address the case where the user's home directory is NFS/auto-mounted (which I think is where this issue comes up periodically). -Alan From Lance.Andersen at oracle.com Fri Nov 30 12:40:47 2012 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Fri, 30 Nov 2012 07:40:47 -0500 Subject: JDBC bug: Incorrect number of conflicts is reported by CachedRowSetWriter.writeData In-Reply-To: <50B8436A.3000107@linux.vnet.ibm.com> References: <509C7218.4020807@linux.vnet.ibm.com> <50A1AFA6.8010905@linux.vnet.ibm.com> <50B8436A.3000107@linux.vnet.ibm.com> Message-ID: Hi Frank, Thank you for the email. No we do not want tests that require database access in jtreg. What I was trying to say, albeit not probably as clear as it could have been is that it would be helpful to provide a complete example and to use Java DB as the database if it is a generic data access issue as while it is not a required part of the Java SE specification, we do provide it with the Oracle JDK so it makes it easier to test against for developers vs finding an instance of DB2, Sybase or even Oracle to test against. Best Lance On Nov 30, 2012, at 12:26 AM, Frank Ding wrote: > Hi Lance, > Sorry for late response and thanks for your comment. You mean I can write a jtreg test case that connects to Java DB? I can do that. > > Best regards, > Frank > > On 11/13/2012 10:13 PM, Lance Andersen - Oracle wrote: >> Hi Frank, >> >> >> Thank you for the note >> If you could in the future, please provide a complete test program to repro the issue as it would save time with the reviews. Ideally if the issue is not database specific it would be good to leverage Java DB as it is included within Oracle JDK >> >> I will look at this sometime this week >> >> Best >> Lance >> On Nov 12, 2012, at 9:25 PM, Frank Ding wrote: >> >>> Hi Lance >>> Thanks for your quick response. Please find the bug info below. >>> >>> The problem: >>> When CachedRowSetImpl.acceptChanges() is called, incorrect number of conflicts, if any, is reported. The number of conflicts is the actual number of existing rows in database, which is the size of variable 'status' defined in CachedRowSetWriter.writeData(). It's not the conflict number that is supposed to be. >>> >>> Test case: >>> The bug can be easily manifested in all SQL server environment. Here take PostgreSQL for example. >>> 1. The sql script to create a table >>> CREATE TABLE ressystem.roomdescription >>> ( >>> roomdescription_id serial NOT NULL, >>> roomdescription character varying NOT NULL, >>> CONSTRAINT roomdescription_pkey PRIMARY KEY (roomdescription_id) >>> ) >>> >>> 2. Manually insert 3 rows >>> (1, "Test 1") >>> (2, "Test 2") >>> (3, "Test 3") >>> >>> 3. Create a Java class that connects the established database and then execute the following code snippet. >>> String query = "select roomdescription_id, roomdescription from ressystem.roomdescription"; >>> Object[] values = {2, "Test2"}; >>> rs.setCommand(query); >>> rs.execute(conn); >>> rs.moveToInsertRow(); >>> for(int i=0; i>> rs.updateObject(i+1,values[i]); >>> } >>> rs.insertRow(); >>> rs.moveToCurrentRow(); >>> rs.acceptChanges(conn); >>> >>> 4. An exception occurs with following output. >>> javax.sql.rowset.spi.SyncProviderException: 4conflicts while synchronizing >>> at com.sun.rowset.internal.CachedRowSetWriter.writeData(CachedRowSetWriter.java:412) >>> at com.sun.rowset.CachedRowSetImpl.acceptChanges(CachedRowSetImpl.java:880) >>> >>> 5. In fact, there is only one conflicting row but 4 were reported. >>> >>> Best regards, >>> Frank >>> >>> On 11/9/2012 7:41 PM, Lance Andersen - Oracle wrote: >>>> Frank, >>>> >>>> If you can please post the bug info here, I will take a look at your patch >>>> >>>> Best >>>> Lance >>>> On Nov 8, 2012, at 10:01 PM, Frank Ding wrote: >>>> >>>>> Hi guys, >>>>> We discovered a bug in CachedRowSetWriter.writeData method where incorrect number of conflicts is reported. I searched in Oracle bug database and no similar record was found. So I submitted a new one whose internal review ID is 2376620. A test case with code is illustrated in the bug submission that leverages PostgreSQL server but the issue is platform independent and easy to reproduce. >>>>> I provided a patch review, available @ >>>>> http://cr.openjdk.java.net/~dingxmin/2376620/webrev.01/ >>>>> Is there anybody who is interested in patch and can also review bug 2376620? Your reply is appreciated. >>>>> >>>>> Best regards, >>>>> Frank >>>>> >>>>> >>>> >>>> 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 >> > -------------- next part -------------- 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 Fri Nov 30 12:50:39 2012 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Fri, 30 Nov 2012 07:50:39 -0500 Subject: Request for Review : CR#8004015 : Add interface extends and defaults for basic functional interfaces In-Reply-To: <50B88361.7060705@oracle.com> References: <54FA2248-91D9-4181-AC30-22FB365D3297@oracle.com> <50B6F7C1.4080606@oracle.com> <50B774D8.60403@oracle.com> <50B813F6.6040602@oracle.com> <50B88361.7060705@oracle.com> Message-ID: <4FA6AA43-D3AF-419D-9325-1C71C94CC2BA@oracle.com> On Nov 30, 2012, at 4:58 AM, Chris Hegarty wrote: > > > On 30/11/2012 02:03, David Holmes wrote: >> On 30/11/2012 12:44 AM, Chris Hegarty wrote: >>> On 11/29/2012 05:50 AM, David Holmes wrote: >>>> ... >>>> >>>> I don't agree that we need to describe what the default implementation >>>> does, for two reasons: >>>> >>>> 1. Normal methods don't usually specify how they are implemented - it is >>>> an implementation detail. The "default" simply indicates that this >>>> method does have an implementation and you should expect that >>>> implementation to obey the contract of the method. >>>> >>>> 2. It is not obvious to me that the JDK's choice for a default >>>> implementation has to be _the_ only possible implementation choice. In >>>> many/most cases there will be a very obvious choice, but that doesn't >>>> mean that all suppliers of OpenJDK classes have to be locked in to that >>>> choice. >>> >>> This is certainly interesting, and something I've wondered for a while >>> now. If java.util.Iterator is to ever be fitted with a default >>> implementation of remove ( to throw UnsupportedOperationException ), >>> then it would clearly need to be part of the spec, and not an >>> implementation detail of OpenJDK. Otherwise, what's the point, every >>> developer will still have to implement it because they cannot be >>> guaranteed of it's behavior. >> >> I think optional methods are a bit of a special case here because they >> don't have to work. >> >> It's the end user of a class that needs to understand if they can use >> remove() to actually do a removal. The developer of the class can >> inherit whatever default implementations Iterator provides, as long as >> they don't mind what they get. If they do mind ie they need a real >> remove(), then they will have to implement it themselves and in the >> process document that fact. The end user has to look at the docs for the >> concrete class and follow through to determine whether it's >> iterator().remove() is optional or not. >> >> Put another way, a default method is great for adding a new method to >> types that have not yet been revised to handle the new method. As a >> developer once you revise your class you should make a conscious >> implementation choice in my opinion and not rely on the default unless >> you truly don't care what it does. > > Sorry David, I've not been following lambda that closely, but (in my opinion) if default methods do not, or cannot, have defined semantics then I really think it is limiting. Maybe Iterator is a bad example, but I will continue with it anyway. In many cases developers of iterator().remove() want it to throw, if this is not defined in Iterator's default remove method then every Iterator subclass will still have to define its own remove that throws. For this particular case at least (if it were to ever happen), I would like to see specification added to remove that defines the default implementation. I had wondered about this as well and had a brief email exchange with Mike. I thought a new javadoc tag might also be something to consider. For JDBC, I am thinking of leveraging default methods to throw a specific exception (maybe IllegalStateException?) if the method must be implemented by the driver vendor or a SQLFeatureNotSupportedException for methods which may be optional based on the backend support. > > -Chris. > >> >> But maybe we kid ourselves when we give this illusion of flexibility in >> implementation. >> >> David >> >>> -Chris. -------------- next part -------------- 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 forax at univ-mlv.fr Fri Nov 30 12:56:54 2012 From: forax at univ-mlv.fr (Remi Forax) Date: Fri, 30 Nov 2012 13:56:54 +0100 Subject: Request for Review : CR#8004015 : Add interface extends and defaults for basic functional interfaces In-Reply-To: <4FA6AA43-D3AF-419D-9325-1C71C94CC2BA@oracle.com> References: <54FA2248-91D9-4181-AC30-22FB365D3297@oracle.com> <50B6F7C1.4080606@oracle.com> <50B774D8.60403@oracle.com> <50B813F6.6040602@oracle.com> <50B88361.7060705@oracle.com> <4FA6AA43-D3AF-419D-9325-1C71C94CC2BA@oracle.com> Message-ID: <50B8AD16.40106@univ-mlv.fr> On 11/30/2012 01:50 PM, Lance Andersen - Oracle wrote: > On Nov 30, 2012, at 4:58 AM, Chris Hegarty wrote: > >> >> On 30/11/2012 02:03, David Holmes wrote: >>> On 30/11/2012 12:44 AM, Chris Hegarty wrote: >>>> On 11/29/2012 05:50 AM, David Holmes wrote: >>>>> ... >>>>> >>>>> I don't agree that we need to describe what the default implementation >>>>> does, for two reasons: >>>>> >>>>> 1. Normal methods don't usually specify how they are implemented - it is >>>>> an implementation detail. The "default" simply indicates that this >>>>> method does have an implementation and you should expect that >>>>> implementation to obey the contract of the method. >>>>> >>>>> 2. It is not obvious to me that the JDK's choice for a default >>>>> implementation has to be _the_ only possible implementation choice. In >>>>> many/most cases there will be a very obvious choice, but that doesn't >>>>> mean that all suppliers of OpenJDK classes have to be locked in to that >>>>> choice. >>>> This is certainly interesting, and something I've wondered for a while >>>> now. If java.util.Iterator is to ever be fitted with a default >>>> implementation of remove ( to throw UnsupportedOperationException ), >>>> then it would clearly need to be part of the spec, and not an >>>> implementation detail of OpenJDK. Otherwise, what's the point, every >>>> developer will still have to implement it because they cannot be >>>> guaranteed of it's behavior. >>> I think optional methods are a bit of a special case here because they >>> don't have to work. >>> >>> It's the end user of a class that needs to understand if they can use >>> remove() to actually do a removal. The developer of the class can >>> inherit whatever default implementations Iterator provides, as long as >>> they don't mind what they get. If they do mind ie they need a real >>> remove(), then they will have to implement it themselves and in the >>> process document that fact. The end user has to look at the docs for the >>> concrete class and follow through to determine whether it's >>> iterator().remove() is optional or not. >>> >>> Put another way, a default method is great for adding a new method to >>> types that have not yet been revised to handle the new method. As a >>> developer once you revise your class you should make a conscious >>> implementation choice in my opinion and not rely on the default unless >>> you truly don't care what it does. >> Sorry David, I've not been following lambda that closely, but (in my opinion) if default methods do not, or cannot, have defined semantics then I really think it is limiting. Maybe Iterator is a bad example, but I will continue with it anyway. In many cases developers of iterator().remove() want it to throw, if this is not defined in Iterator's default remove method then every Iterator subclass will still have to define its own remove that throws. For this particular case at least (if it were to ever happen), I would like to see specification added to remove that defines the default implementation. > I had wondered about this as well and had a brief email exchange with Mike. I thought a new javadoc tag might also be something to consider. @implementation ? > > For JDBC, I am thinking of leveraging default methods to throw a specific exception (maybe IllegalStateException?) if the method must be implemented by the driver vendor an UnsupportedOperationException is better for that. > or a SQLFeatureNotSupportedException for methods which may be optional based on the backend support. R?mi From Lance.Andersen at oracle.com Fri Nov 30 13:20:24 2012 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Fri, 30 Nov 2012 08:20:24 -0500 Subject: Request for Review : CR#8004015 : Add interface extends and defaults for basic functional interfaces In-Reply-To: References: <54FA2248-91D9-4181-AC30-22FB365D3297@oracle.com> <50B6F7C1.4080606@oracle.com> <50B774D8.60403@oracle.com> <50B813F6.6040602@oracle.com> <50B88361.7060705@oracle.com> <4FA6AA43-D3AF-419D-9325-1C71C94CC2BA@oracle.com> Message-ID: <89DF6D6C-5D12-4A1B-9A74-EDD2525451C6@oracle.com> The problem for an API such as JDBC is that the implementation is going to be specific to the driver and backend so providing a default implementation just won't work. This allows existing drivers to compile as they finish their implementation and complete their migration to the new version of the API. On Nov 30, 2012, at 8:14 AM, Ricky Clarkson wrote: > What is the benefit of throwing an IllegalStateException in a default method over not providing any default method so that the compiler and runtime make sure concrete subtypes provide an implementation? > > On Nov 30, 2012 9:54 AM, "Lance Andersen - Oracle" wrote: > > On Nov 30, 2012, at 4:58 AM, Chris Hegarty wrote: > > > > > > > On 30/11/2012 02:03, David Holmes wrote: > >> On 30/11/2012 12:44 AM, Chris Hegarty wrote: > >>> On 11/29/2012 05:50 AM, David Holmes wrote: > >>>> ... > >>>> > >>>> I don't agree that we need to describe what the default implementation > >>>> does, for two reasons: > >>>> > >>>> 1. Normal methods don't usually specify how they are implemented - it is > >>>> an implementation detail. The "default" simply indicates that this > >>>> method does have an implementation and you should expect that > >>>> implementation to obey the contract of the method. > >>>> > >>>> 2. It is not obvious to me that the JDK's choice for a default > >>>> implementation has to be _the_ only possible implementation choice. In > >>>> many/most cases there will be a very obvious choice, but that doesn't > >>>> mean that all suppliers of OpenJDK classes have to be locked in to that > >>>> choice. > >>> > >>> This is certainly interesting, and something I've wondered for a while > >>> now. If java.util.Iterator is to ever be fitted with a default > >>> implementation of remove ( to throw UnsupportedOperationException ), > >>> then it would clearly need to be part of the spec, and not an > >>> implementation detail of OpenJDK. Otherwise, what's the point, every > >>> developer will still have to implement it because they cannot be > >>> guaranteed of it's behavior. > >> > >> I think optional methods are a bit of a special case here because they > >> don't have to work. > >> > >> It's the end user of a class that needs to understand if they can use > >> remove() to actually do a removal. The developer of the class can > >> inherit whatever default implementations Iterator provides, as long as > >> they don't mind what they get. If they do mind ie they need a real > >> remove(), then they will have to implement it themselves and in the > >> process document that fact. The end user has to look at the docs for the > >> concrete class and follow through to determine whether it's > >> iterator().remove() is optional or not. > >> > >> Put another way, a default method is great for adding a new method to > >> types that have not yet been revised to handle the new method. As a > >> developer once you revise your class you should make a conscious > >> implementation choice in my opinion and not rely on the default unless > >> you truly don't care what it does. > > > > Sorry David, I've not been following lambda that closely, but (in my opinion) if default methods do not, or cannot, have defined semantics then I really think it is limiting. Maybe Iterator is a bad example, but I will continue with it anyway. In many cases developers of iterator().remove() want it to throw, if this is not defined in Iterator's default remove method then every Iterator subclass will still have to define its own remove that throws. For this particular case at least (if it were to ever happen), I would like to see specification added to remove that defines the default implementation. > > I had wondered about this as well and had a brief email exchange with Mike. I thought a new javadoc tag might also be something to consider. > > For JDBC, I am thinking of leveraging default methods to throw a specific exception (maybe IllegalStateException?) if the method must be implemented by the driver vendor or a SQLFeatureNotSupportedException for methods which may be optional based on the backend support. > > > > -Chris. > > > >> > >> But maybe we kid ourselves when we give this illusion of flexibility in > >> implementation. > >> > >> David > >> > >>> -Chris. > > > > 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 Fri Nov 30 13:22:41 2012 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Fri, 30 Nov 2012 08:22:41 -0500 Subject: Request for Review : CR#8004015 : Add interface extends and defaults for basic functional interfaces In-Reply-To: <50B8AD16.40106@univ-mlv.fr> References: <54FA2248-91D9-4181-AC30-22FB365D3297@oracle.com> <50B6F7C1.4080606@oracle.com> <50B774D8.60403@oracle.com> <50B813F6.6040602@oracle.com> <50B88361.7060705@oracle.com> <4FA6AA43-D3AF-419D-9325-1C71C94CC2BA@oracle.com> <50B8AD16.40106@univ-mlv.fr> Message-ID: <3006D1AD-2538-4ABD-8201-6F67877A3A33@oracle.com> On Nov 30, 2012, at 7:56 AM, Remi Forax wrote: > On 11/30/2012 01:50 PM, Lance Andersen - Oracle wrote: >> On Nov 30, 2012, at 4:58 AM, Chris Hegarty wrote: >> >>> >>> On 30/11/2012 02:03, David Holmes wrote: >>>> On 30/11/2012 12:44 AM, Chris Hegarty wrote: >>>>> On 11/29/2012 05:50 AM, David Holmes wrote: >>>>>> ... >>>>>> >>>>>> I don't agree that we need to describe what the default implementation >>>>>> does, for two reasons: >>>>>> >>>>>> 1. Normal methods don't usually specify how they are implemented - it is >>>>>> an implementation detail. The "default" simply indicates that this >>>>>> method does have an implementation and you should expect that >>>>>> implementation to obey the contract of the method. >>>>>> >>>>>> 2. It is not obvious to me that the JDK's choice for a default >>>>>> implementation has to be _the_ only possible implementation choice. In >>>>>> many/most cases there will be a very obvious choice, but that doesn't >>>>>> mean that all suppliers of OpenJDK classes have to be locked in to that >>>>>> choice. >>>>> This is certainly interesting, and something I've wondered for a while >>>>> now. If java.util.Iterator is to ever be fitted with a default >>>>> implementation of remove ( to throw UnsupportedOperationException ), >>>>> then it would clearly need to be part of the spec, and not an >>>>> implementation detail of OpenJDK. Otherwise, what's the point, every >>>>> developer will still have to implement it because they cannot be >>>>> guaranteed of it's behavior. >>>> I think optional methods are a bit of a special case here because they >>>> don't have to work. >>>> >>>> It's the end user of a class that needs to understand if they can use >>>> remove() to actually do a removal. The developer of the class can >>>> inherit whatever default implementations Iterator provides, as long as >>>> they don't mind what they get. If they do mind ie they need a real >>>> remove(), then they will have to implement it themselves and in the >>>> process document that fact. The end user has to look at the docs for the >>>> concrete class and follow through to determine whether it's >>>> iterator().remove() is optional or not. >>>> >>>> Put another way, a default method is great for adding a new method to >>>> types that have not yet been revised to handle the new method. As a >>>> developer once you revise your class you should make a conscious >>>> implementation choice in my opinion and not rely on the default unless >>>> you truly don't care what it does. >>> Sorry David, I've not been following lambda that closely, but (in my opinion) if default methods do not, or cannot, have defined semantics then I really think it is limiting. Maybe Iterator is a bad example, but I will continue with it anyway. In many cases developers of iterator().remove() want it to throw, if this is not defined in Iterator's default remove method then every Iterator subclass will still have to define its own remove that throws. For this particular case at least (if it were to ever happen), I would like to see specification added to remove that defines the default implementation. >> I had wondered about this as well and had a brief email exchange with Mike. I thought a new javadoc tag might also be something to consider. > > @implementation ? > >> >> For JDBC, I am thinking of leveraging default methods to throw a specific exception (maybe IllegalStateException?) if the method must be implemented by the driver vendor > > an UnsupportedOperationException is better for that. Agree that could be a better choice > >> or a SQLFeatureNotSupportedException for methods which may be optional based on the backend support. > > R?mi > -------------- next part -------------- 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 bill.pittore at oracle.com Fri Nov 30 15:16:28 2012 From: bill.pittore at oracle.com (BILL PITTORE) Date: Fri, 30 Nov 2012 10:16:28 -0500 Subject: RFR- 7200297 jdwp and hprof code do not handle multiple sun.boot.library.path elements correctly Message-ID: <50B8CDCC.90702@oracle.com> This bug was reviewed by serviceability and hotspot-runtime-dev lists since it dealt with jvmti agent code. Comments welcome. The intent is to push into tl/jdk tree and then eventually back into jdk7u-dev hopefully. Webrev here: http://cr.openjdk.java.net/~bpittore/7200297/webrev.04/ And previous reviews here: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2012-November/004801.html thanks, bill From maurizio.cimadamore at oracle.com Fri Nov 30 15:15:50 2012 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Fri, 30 Nov 2012 15:15:50 +0000 Subject: hg: jdk8/tl/langtools: 4 new changesets Message-ID: <20121130151602.08B3C47C38@hg.openjdk.java.net> Changeset: 4f9853659bf1 Author: mcimadamore Date: 2012-11-30 15:14 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/4f9853659bf1 8004105: Expression statement lambdas should be void-compatible Summary: Fix lambda compatibility rules as per latest EDR Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java ! test/tools/javac/lambda/LambdaConv21.java ! test/tools/javac/lambda/LambdaConv21.out ! test/tools/javac/lambda/VoidCompatibility.out Changeset: 34d1ebaf4645 Author: mcimadamore Date: 2012-11-30 15:14 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/34d1ebaf4645 8004102: Add support for generic functional descriptors Summary: Method references are allowed to have a generic functional interface descriptor target Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties - test/tools/javac/diags/examples/InvalidGenericDescInFunctionalInterface.java + test/tools/javac/diags/examples/InvalidGenericLambdaTarget.java + test/tools/javac/lambda/FunctionalInterfaceConversionTest.java - test/tools/javac/lambda/LambdaConversionTest.java + test/tools/javac/lambda/MethodReference57.java + test/tools/javac/lambda/MethodReference58.java + test/tools/javac/lambda/MethodReference58.out Changeset: 9b26c96f5138 Author: mcimadamore Date: 2012-11-30 15:14 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/9b26c96f5138 8004101: Add checks for method reference well-formedness Summary: Bring method reference type-checking in sync with latest EDR Reviewed-by: jjg ! 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/comp/Resolve.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/StaticBoundMref.java + test/tools/javac/diags/examples/StaticMrefWithTargs.java ! test/tools/javac/lambda/MethodReference30.java + test/tools/javac/lambda/MethodReference55.java + test/tools/javac/lambda/MethodReference55.out + test/tools/javac/lambda/MethodReference56.java + test/tools/javac/lambda/MethodReference56.out ! test/tools/javac/lambda/methodReference/MethodRef1.java ! test/tools/javac/lambda/methodReference/SamConversion.java ! test/tools/javac/lambda/methodReferenceExecution/MethodReferenceTestKinds.java Changeset: f6f1fd261f57 Author: mcimadamore Date: 2012-11-30 15:14 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/f6f1fd261f57 8002099: Add support for intersection types in cast expression Summary: Add parser and type-checking support for intersection types in cast expressions Reviewed-by: jjg + src/share/classes/com/sun/source/tree/IntersectionTypeTree.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/util/SimpleTreeVisitor.java ! src/share/classes/com/sun/source/util/TreeScanner.java ! src/share/classes/com/sun/tools/javac/code/Source.java ! src/share/classes/com/sun/tools/javac/code/Type.java ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/TransTypes.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/model/JavacTypes.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/tree/JCTree.java ! src/share/classes/com/sun/tools/javac/tree/Pretty.java ! src/share/classes/com/sun/tools/javac/tree/TreeCopier.java ! src/share/classes/com/sun/tools/javac/tree/TreeMaker.java ! src/share/classes/com/sun/tools/javac/tree/TreeScanner.java ! src/share/classes/com/sun/tools/javac/tree/TreeTranslator.java + src/share/classes/javax/lang/model/type/IntersectionType.java ! src/share/classes/javax/lang/model/type/TypeKind.java ! src/share/classes/javax/lang/model/type/TypeVisitor.java ! src/share/classes/javax/lang/model/util/AbstractTypeVisitor6.java ! src/share/classes/javax/lang/model/util/AbstractTypeVisitor8.java + test/tools/javac/cast/intersection/IntersectionTypeCastTest.java + test/tools/javac/cast/intersection/IntersectionTypeParserTest.java + test/tools/javac/cast/intersection/model/Check.java + test/tools/javac/cast/intersection/model/IntersectionTypeInfo.java + test/tools/javac/cast/intersection/model/Member.java + test/tools/javac/cast/intersection/model/Model01.java + test/tools/javac/cast/intersection/model/ModelChecker.java + test/tools/javac/diags/examples/IntersectionTypesInCastNotSupported.java + test/tools/javac/diags/examples/SecondaryBoundMustBeMarkerIntf.java + test/tools/javac/lambda/Intersection01.java + test/tools/javac/lambda/Intersection01.out ! test/tools/javac/lambda/LambdaParserTest.java + test/tools/javac/lambda/intersection/IntersectionTargetTypeTest.java From Alan.Bateman at oracle.com Fri Nov 30 15:37:45 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 30 Nov 2012 15:37:45 +0000 Subject: RFR- 7200297 jdwp and hprof code do not handle multiple sun.boot.library.path elements correctly In-Reply-To: <50B8CDCC.90702@oracle.com> References: <50B8CDCC.90702@oracle.com> Message-ID: <50B8D2C9.30502@oracle.com> On 30/11/2012 15:16, BILL PITTORE wrote: > This bug was reviewed by serviceability and hotspot-runtime-dev lists > since it dealt with jvmti agent code. > Comments welcome. The intent is to push into tl/jdk tree and then > eventually back into jdk7u-dev hopefully. Webrev here: > > http://cr.openjdk.java.net/~bpittore/7200297/webrev.04/ > > And previous reviews here: > http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2012-November/004801.html > > > thanks, > bill > Bill - if you already have a reviewer then just go ahead and push the fix, you don't need to get an additional review here. -Alan From bill.pittore at oracle.com Fri Nov 30 15:46:54 2012 From: bill.pittore at oracle.com (BILL PITTORE) Date: Fri, 30 Nov 2012 10:46:54 -0500 Subject: RFR- 7200297 jdwp and hprof code do not handle multiple sun.boot.library.path elements correctly In-Reply-To: <50B8D2C9.30502@oracle.com> References: <50B8CDCC.90702@oracle.com> <50B8D2C9.30502@oracle.com> Message-ID: <50B8D4EE.3080607@oracle.com> Ok, Thanks. David Holmes asked that I send to this alias and he would re-review then push it for me. bill | On 11/30/2012 10:37 AM, Alan Bateman wrote: | > On 30/11/2012 15:16, BILL PITTORE wrote: >> This bug was reviewed by serviceability and hotspot-runtime-dev lists >> since it dealt with jvmti agent code. >> Comments welcome. The intent is to push into tl/jdk tree and then >> eventually back into jdk7u-dev hopefully. Webrev here: >> >> http://cr.openjdk.java.net/~bpittore/7200297/webrev.04/ >> >> And previous reviews here: >> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2012-November/004801.html >> >> >> thanks, >> bill >> > Bill - if you already have a reviewer then just go ahead and push the > fix, you don't need to get an additional review here. > > -Alan From alan.bateman at oracle.com Fri Nov 30 16:32:31 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Fri, 30 Nov 2012 16:32:31 +0000 Subject: hg: jdk8/tl/jdk: 7165762: (aio) Default thread pool should be configured so that threads terminated after a timeout period Message-ID: <20121130163244.7681447C3C@hg.openjdk.java.net> Changeset: c370048be8fc Author: alanb Date: 2012-11-30 16:29 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c370048be8fc 7165762: (aio) Default thread pool should be configured so that threads terminated after a timeout period Reviewed-by: chegar ! src/share/classes/sun/nio/ch/ThreadPool.java From jonathan.gibbons at oracle.com Fri Nov 30 17:08:49 2012 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Fri, 30 Nov 2012 17:08:49 +0000 Subject: hg: jdk8/tl/jdk: 8004110: Remove debug code form sun/reflect/annotation/AnnotationSupport.java Message-ID: <20121130170901.BB34B47C3F@hg.openjdk.java.net> Changeset: e7edb0da9c6a Author: jfranck Date: 2012-11-30 09:47 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e7edb0da9c6a 8004110: Remove debug code form sun/reflect/annotation/AnnotationSupport.java Reviewed-by: jjg, darcy ! src/share/classes/sun/reflect/annotation/AnnotationSupport.java From peter.levart at gmail.com Fri Nov 30 18:36:09 2012 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 30 Nov 2012 19:36:09 +0100 Subject: bottleneck by java.lang.Class.getAnnotations() - rebased patch In-Reply-To: <50AFADB4.9000204@gmail.com> References: <924D06EC-F603-4E6A-A7FE-7A05C77B1217@gmail.com> <23313EDE-3AB7-4E53-8EB1-A6F6CC9383B9@gmail.com> <5093A8D3.4030800@gmail.com> <5096CFBD.2010604@gmail.com> <5096F5B0.8070304@gmail.com> <50974D3D.1040502@oracle.com> <50990CB8.2040400@gmail.com> <5099C2FA.2020202@oracle.com> <509A3A63.5010102@gmail.com> <50AF5930.5010903@gmail.com> <50AFADB4.9000204@gmail.com> Message-ID: <50B8FC99.401@gmail.com> Hi Alan, David, Alexander and others, I noticed the push of Joe Darcy's code for repeating annotations which makes my proposed patch not entirely compatible with new code. So I rebased the patch to current code in jdk8/tl/jdk repository. I had to revert my last improvement (the replacement of Map with array for Class's declaredAnnotations) since repeating annotations need per-key access to declared annotations. I also did a simplification in the area of delegating the caching of annotations on Field/Method/Constructor to a root instance. Here's the webrev of this patch: http://dl.dropbox.com/u/101777488/jdk8-tl/JEP-149/webrev.01/index.html And here're the results of the benchmarks: https://raw.github.com/plevart/jdk8-tl/JEP-149/test/benchmark_results_i7-2600K.txt It is interesting to compare these results with the results I got on the codebase prior to the repeating annotations push: https://raw.github.com/plevart/jdk8-hacks/annotation-arrays/benchmark_results_i7-2600K.txt Test2 results for the unpatched code (first run in each file) show that this test running on the repeating annotations is almost 4x slower in the single threaded case and almost 20x slower in the heavy-threaded (128 threads on 4 core i7) case then the pre-repeating annotations version. May I restate that this is comparing unpatched code. I must also mention that the pre-repeating annotations results were obtained by running on a JVM that was build from the jdk8/jdk8 forest: openjdk version "1.8.0-internal" OpenJDK Runtime Environment (build 1.8.0-internal-peter_2012_11_21_08_55-b00) OpenJDK 64-Bit Server VM (build 25.0-b09, mixed mode) while the repeating annotations version results were obtained by running on the todays build of jdk8/tl forest: openjdk version "1.8.0-internal" OpenJDK Runtime Environment (build 1.8.0-internal-peter_2012_11_30_14_19-b00) OpenJDK 64-Bit Server VM (build 25.0-b09, mixed mode) Test2 results for the patched code (second run in each file) show that this test running on the repeating annotations is about 2x slower in the single threaded case and also 2x slower in the heavy-threaded (128 threads on 4 core i7) case. I haven't yet established why this is so. It might be that code differences (for example another method call in the code-path with repeating annotations) cause different optimizations by JIT. It is also interesting to note that with repeating annotations, Test 2 is even less scalable for the unpatched code while with the patched code it shows same scalability. Test3 shows the same speed for the unpatched variants of pre-repeating annotations vs. repeating annotations, while with patched code it shows 2x increase in speed. The scalability of test3 is about the same pre-repeating annotations vs. repeating annotations. Test1 is out of the league because it only demonstrates the cache hit improvements when keeping the caches of annotations on the root instances of Field/Constructor/Method instead of on the copied instances. So, what do you think? What kind of tests should I prepare in addidion to those 3 so that the patch might get a consideration? Regards, Peter P.S. The source for tests is here: https://raw.github.com/plevart/jdk8-tl/JEP-149/test/src/test/ReflectionTest.java On 11/23/2012 06:09 PM, Peter Levart wrote: > Hi again, > > I have found an inconsistency in the last patch I posted. Specifically > the Method.getAnnotation(Class) and Constructor.getAnnotation(Class) > did not delegate to the root instance as .getAnnotations() did. I > corrected that in new revision of the patch: > > http://dl.dropbox.com/u/101777488/jdk8-hacks/JEP-149/webrev.03/index.html > > I also modified the benchmarks somewhat so that now they exercise the > .getAnnotation(Class) methods on various objects instead of bulk > getAnnotations() methods: > > https://raw.github.com/plevart/jdk8-hacks/annotation-arrays/src/test/ReflectionTest.java > > I got results for 2 different machines: > > Desktop PC (one socket i7-2600K, 4 cores), Linux 3.6 64bit: > https://raw.github.com/plevart/jdk8-hacks/annotation-arrays/benchmark_results_i7-2600K.txt > > and: > > Sun Blade T6320 (one socket T2, 8 cores), Solaris 10 64bit: > https://raw.github.com/plevart/jdk8-hacks/annotation-arrays/benchmark_results_T2.txt > > On the T2, the concurrency bottleneck is even more visible. > > > Regards, Peter > > > On 11/23/2012 12:08 PM, Peter Levart wrote: >> Hi David, Alan, Alexander and others, >> >> Here's a refinement of a patch I proposed in this thread a couple of >> weeks ago: >> >> http://dl.dropbox.com/u/101777488/jdk8-hacks/JEP-149/webrev.02/index.html >> >> The changed sources can be browsed here: >> >> https://github.com/plevart/jdk8-hacks/tree/annotation-arrays/src/java/lang >> >> The main improvement is the replacement of a filed: >> >> Map, Annotation> declaredAnnotations; >> >> with plain: >> >> Annotation[] declaredAnnotations; >> >> ...in the Class.VolatileData structure. It can be seen from the >> public API that caching a HashMap of declared annotations is never >> needed since the only public method (getDeclaredAnnotations()) >> returns an array. Therefore it is much more efficient to cache the >> array and only clone it on every public method invocation. >> >> Unfortunately it is not so with "annotations" field. There is a >> public method (getAnnotation(Class)) that has >> O(1) time complexity because of keeping a HashMap in the cache. >> >> I did an experiment with keeping annotations (declared + inherited) >> in an array, sorted by the hashCode of annotationType and the lookup >> then was a binary search by hashCode of annotationType followed by >> linear search of the equal hashCode neighborhood. This has O(log N) >> time complexity, which is not so bad, but the constant factor was >> pretty high because invoking Annotation.annotationType() method goes >> through dynamic Proxy to an InvocationHandler... >> >> Speaking of that, I think there's plenty of opportunity for JEP-149 >> related optimization in the field of annotations. For example, >> generating a special class for every annotationType that would hold >> it's own annotation data and answer to method requests directly would >> give a large time and space gain. >> >> It can also be noticed that there's a discrepancy of how lookup is >> implemented for example: >> - lookup of Annotation by annotationType on a class is a >> HashMap.get() which has O(1) time complexity >> - lookup of a of Field by fieldName on a class is a linear search in >> an array which has O(N) time complexity >> - similar for Method by methodName and argumentTypes - O(N) >> >> The time complexity improvement for Field and Method lookup could be >> performed by keeping some cached arrays pre-sorted by the name of >> Field or Method and employing a binary search to locate or >> almost-locate the object. Since public API explicitly states that >> methods returning arrays of Fields and Methods do not specify any >> order, pre-sorting the arrays would not break the contract. >> >> Regards, Peter >> >> On 11/07/2012 11:39 AM, Peter Levart wrote: >>> On 11/07/2012 03:10 AM, David Holmes wrote: >>>> Hi Peter, >>>> >>>> The movement of the reflection caches to a helper object is exactly >>>> what I had previously proposed here (some differences in the >>>> details of course): >>>> >>>> http://cr.openjdk.java.net/~dholmes/JEP-149/webrev/ >>>> >>>> and discussed here: >>>> >>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-April/009749.html >>>> >>>> >>>> but this did not touch the annotations fields. >>>> >>>> David >>> >>> Hi David, >>> >>> Thanks for the pointer. There is a discussion between Brian and you >>> (to quote some of it): >>> >>> On 5/04/2012 1:28 PM, Brian Goetz wrote: >>> >/ Reducing the number of SoftReferences in ReflectionHelper also seems an >>> />/ attractive target for memory reduction. Rather than eight soft >>> />/ references (eight extra objects), maintaining a SoftRef to the entire >>> />/ RH, or at least to the part of the RH that is currently SR'ed if the two >>> />/ non-SR'ed fields can't be recomputed, would save you a whole pile of >>> />/ objects per class (and might also reduce pressure on GC, having 8x fewer >>> />/ SRs to process.) >>> / >>> I'd have to consider the intended semantics of these soft references >>> before considering any change here. It would hard to predict how this >>> might impact runtime performance if we have coarser-grained soft >>> references. The current changes should be semantically null. >>> >>> >/ Finally, you may be able save an extra field per Class by storing the >>> />/ ReflectionHelper in a ClassValue on Java SE 8, rather than a field. >>> / >>> ClassValue is something I'm keeping an eye on, but an entry in >>> ClassValue is going to consume more dynamic memory than a single direct >>> field. >>> >>> Thanks, >>> David >>> >>> >>> ...the 8 SoftReferences refer to arrays which are never hard >>> referenced by the outside world (arrays are always defensively >>> copied), so it's reasonable to expect that all SoftReferences would >>> be cleared at the same time anyway. And if 8 SoftReferences are >>> replaced with 1, the worst case scenario (to quote Hinkmond Wong): >>> >>> Hi Brian, >>> >>> One of the issues we have in the Java Embedded group (as David points >>> out in his summary), is that while on paper the theoretical max savings >>> seems great (as you point out also), in practice as David points out in >>> his note, this might be a wash if there are a lot more reflection using >>> classes vs. non-reflection using classes in "typical" real-world >>> applications, not the low or zero reflection using class ratio that >>> happens in the theoretical "best case". >>> >>> So, a question comes up if we should judge the merit of this change on >>> the theoretical "best case" scenario, or should we judge it on >>> real-world applicability to "typical" apps (such as a finite set of >>> customer surveyed embedded apps that we feel represent a real-world >>> scenario). >>> >>> >>> Thanks, >>> Hinkmond >>> >>> >>> ...actually becomes even more favourable. We reduce huge overhead >>> (each SoftReference is 4 OOPs and 1 long). And if this single >>> SoftReference is ever cleared, more memory is released - the whole >>> structure (ReflectionHelper / VolatileData) >>> >>> Other differences in details between your proposal and mine: >>> >>> In your proposal, the method ReflectionHelper rh() is equivalent to >>> mine VolatileData volatileData() - it lazily constructs the >>> structure and returns it. My implementation also incorporates the >>> logic of clearCachesOnClassRedefinition() by returning and >>> installing a new instance of the structure in case a redefinition is >>> detected. This has a profound impact on the correctness of the >>> cached data in face of races that can occur. >>> >>> In your proposal, even if the VM could atomically publish changes to >>> raw reflection data and the classRedefinitionCount at the same time >>> (we hope that at least the order of publishing is such that >>> classRedefinitionCount is updated last), it can theoretically be >>> that 2 or more redefinitions of the same class happen in close >>> proximity: >>> >>> VM thread: redefines the class to version=1 >>> thread 1: clears the cache and takes version=1 raw data and >>> computes derived data but gets pre-empted before installing it >>> VM thread: redefines the class to version=2 >>> thread 2: clears the cache and takes version=2 raw data and >>> computes derived data and installs it >>> thread 1: ...gets back and installs version=1 derived data over >>> version=2 data >>> >>> ...if there are no more class redefinitions, the stale version of >>> derived data can persist indefinitely. >>> >>> In my proposal, each thread will get it's own copy of the structure >>> in the above scenario and install the derived data into it. It can >>> happen that a particular instance of the structure does not >>> represent a "snapshot" view of the world, but that is not important, >>> since that particular inconsistent instance is only used for the >>> in-flight call and only in that part that is consistent. Other >>> callers will get a fresh instance. >>> >>> There is also one thing I overlooked and you haven't: the >>> cachedConstructor and newInstanceCallerCache fields. >>> >>> I'll have to look at how to incorporate them into my scheme. They >>> are currently neither SoftReferenced nor cleared at class >>> redefinition. As the cachedConstructor is only used to implement the >>> .newInstance() method, I wonder if it is safe not to clear it when >>> the class is redefined. Are old versions of Constructors still valid >>> for invoking in a redefined class? I guess they must be, since user >>> code is free to cache it's own versions and class redefinition >>> should not prevent invoking them... >>> >>> Since cachedConstructor/newInstanceCallerCache are used to optimize >>> .newInstance() method. That alone suggests that calling this method >>> is more common use-case than others. Perhaps leaving this pair of >>> fields out of the game is a better approach space-saving wise. >>> >>> Regards, Peter >>> >>>> >>>> On 6/11/2012 11:12 PM, Peter Levart wrote: >>>>> On 11/05/2012 06:23 AM, David Holmes wrote: >>>>>> Hi Peter, >>>>>> >>>>>> Moving the annotations fields into a helper object would tie in with >>>>>> the Class-instance size reduction effort that was investigated as >>>>>> part >>>>>> of "JEP 149: Reduce Core-Library Memory Usage": >>>>>> >>>>>> http://openjdk.java.net/jeps/149 >>>>>> >>>>>> The investigations there to date only looked at relocating the >>>>>> reflection related fields, though the JEP mentions the >>>>>> annotations as >>>>>> well. >>>>>> >>>>>> Any such effort requires extensive benchmarking and performance >>>>>> analysis before being accepted though. >>>>>> >>>>>> David >>>>>> ----- >>>>>> >>>>> >>>>> On 11/05/2012 10:25 AM, Alan Bateman wrote: >>>>>> Here's a good starting place on the interaction of runtime visible >>>>>> attributes and RedefineClasses/RetransformClasses: >>>>>> >>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5002251 >>>>>> >>>>>> -Alan. >>>>> >>>>> Hi all, >>>>> >>>>> Presented here is a patch mainly against java.lang.Class and also >>>>> against java.lang.reflect.[Field,Method,Constructor,Executable] >>>>> classes. >>>>> >>>>> Currently java.lang.Class uses the following fields to maintain >>>>> caches >>>>> of reflection data that are invalidated as a result of class or >>>>> superclass redefinition/re-transformation: >>>>> >>>>> private volatile transient SoftReference declaredFields; >>>>> private volatile transient SoftReference publicFields; >>>>> private volatile transient SoftReference declaredMethods; >>>>> private volatile transient SoftReference publicMethods; >>>>> private volatile transient SoftReference[]> >>>>> declaredConstructors; >>>>> private volatile transient SoftReference[]> >>>>> publicConstructors; >>>>> private volatile transient SoftReference >>>>> declaredPublicFields; >>>>> private volatile transient SoftReference >>>>> declaredPublicMethods; >>>>> >>>>> // Value of classRedefinedCount when we last cleared the cached >>>>> values >>>>> // that are sensitive to class redefinition. >>>>> private volatile transient int lastRedefinedCount = 0; >>>>> >>>>> // Annotations cache >>>>> private transient Map, Annotation> >>>>> annotations; >>>>> private transient Map, Annotation> >>>>> declaredAnnotations; >>>>> >>>>> If I understand Alan's references correctly, current VM can >>>>> redefine the >>>>> class in a way that changes method bodies. Also new methods can be >>>>> added. And the set of annotations can also be altered. And future >>>>> improvements could allow even more. >>>>> >>>>> Because annotations are cached on Field/Method/Constructor instances, >>>>> all the above fields must be invalidated when the class or >>>>> superclass is >>>>> redefined. >>>>> >>>>> It can also be observed that Field/Method/Constructor caches are >>>>> maintained using SoftReferences but annotations are hard >>>>> references. I >>>>> don't know if this is intentional. I believe that annotations >>>>> could also >>>>> be SoftReferenced, so that in the event of memory pressure they get >>>>> cleared. Many applications retrieve annotations only in the early >>>>> stages >>>>> of their life-cycle and then either cache them themselves or forget >>>>> about them. >>>>> >>>>> So I designed the patch to equalize this. If this is undesirable, the >>>>> patch could be modified to make a distinction again. >>>>> >>>>> The patch replaces the above-mentioned java.lang.Class fields with a >>>>> single field: >>>>> >>>>> private volatile transient SoftReference> >>>>> volatileData; >>>>> >>>>> ...which is a SoftReference to the following structure: >>>>> >>>>> // volatile data that might get invalid when JVM TI >>>>> RedefineClasses() is >>>>> called >>>>> static class VolatileData { >>>>> volatile Field[] declaredFields; >>>>> volatile Field[] publicFields; >>>>> volatile Method[] declaredMethods; >>>>> volatile Method[] publicMethods; >>>>> volatile Constructor[] declaredConstructors; >>>>> volatile Constructor[] publicConstructors; >>>>> // Intermediate results for getFields and getMethods >>>>> volatile Field[] declaredPublicFields; >>>>> volatile Method[] declaredPublicMethods; >>>>> // Annotations >>>>> volatile Map, Annotation> annotations; >>>>> volatile Map, Annotation> >>>>> declaredAnnotations; >>>>> // Value of classRedefinedCount when we created this VolatileData >>>>> instance >>>>> final int redefinedCount; >>>>> >>>>> So let's look at static overhead differences using 64 bit addressing >>>>> (useful load - arrays, Maps not counted since the patched code >>>>> uses the >>>>> same amount of same types of each). >>>>> >>>>> * Fresh java.lang.Class instance: >>>>> >>>>> current JDK8 code: >>>>> >>>>> 10 OOPs + 1 int = 10*8+4 = 84 bytes in 1 instance >>>>> >>>>> vs. patched code : >>>>> >>>>> 1 OOP = 8 bytes in 1 instance >>>>> >>>>> * Fully loaded java.lang.Class (Fields, Methods, Constructors, >>>>> annotations): >>>>> >>>>> current JDK8 code: >>>>> >>>>> 10 OOPs + 1 int = 84 bytes >>>>> 8 SoftReference instances = 8*(header + 4 OOPs + 1 long) = >>>>> 8*(24+32+8) = >>>>> 8*64 = 512 bytes >>>>> total: 84+512 = 596 bytes in 9 instances >>>>> >>>>> vs. patched code : >>>>> >>>>> 1 OOP = 8 bytes >>>>> 1 SoftReference = 64 bytes >>>>> 1 VolatileData = header + 10 OOPs + 1 int = 24+84 = 108 bytes >>>>> total: 8+64+108 = 180 bytes in 3 instances >>>>> >>>>> So we have 84 vs. 8 (empty) or 596 vs. 180 (fully loaded) byte >>>>> overheads and >>>>> 1 vs. 1 (empty) or 9 vs. 3 (fully loaded) instance overheads >>>>> >>>>> Other than that, the patch also removes synchronized blocks for lazy >>>>> initialization of annotations in Class, Field, Method and Constructor >>>>> and replaces them with volatile fields. In case of >>>>> Class.volatileData, >>>>> this field is initialized using a CAS so there is no race which could >>>>> install an already stale instance over more recent. Although such >>>>> race >>>>> would quickly be corrected at next call to any retrieval method, >>>>> because >>>>> redefinedCount is now an integral part of the cached structure not an >>>>> individual volatile field. >>>>> >>>>> There is also a change in how annotations are cached in Field, Method >>>>> and Constructor. Originally they are cached in each copy of the >>>>> Field/Method/Constructor that is returned to the outside world at >>>>> each >>>>> invocation of Class.getFields() etc. Such caching is not very >>>>> effective >>>>> if the annotations are only retrieved once per instance. The patch >>>>> changes this and delegates caching to the "root" instance which is >>>>> held >>>>> inside Class so caching becomes more effective in certain usage >>>>> patterns. There's now a possible hot-spot on the "root" instance but >>>>> that seems not to be a bottleneck since the fast-path does not >>>>> involve >>>>> blocking synchronization (just volatile read). The effects of this >>>>> change are clearly visible in one of the benchmarks. >>>>> >>>>> I have tried to create 3 micro benchmarks which exercise >>>>> concurrent load >>>>> on 3 Class instances. >>>>> >>>>> Here's the benchmark code: >>>>> >>>>> https://raw.github.com/plevart/jdk8-hacks/master/src/test/ReflectionTest.java >>>>> >>>>> >>>>> And here are the results when run on an Intel i7 CPU (4 cores, 2 >>>>> threads/core) Linux machine using -Xmx4G VM option: >>>>> >>>>> https://raw.github.com/plevart/jdk8-hacks/master/benchmark_results.txt >>>>> >>>>> >>>>> >>>>> The huge difference of Test1 results is a direct consequence of >>>>> patched >>>>> code delegating caching of annotations in Field/Method/Constructor to >>>>> the "root" instance. >>>>> >>>>> Test2 results show no noticeable difference between original and >>>>> patched >>>>> code. This, I believe, is the most common usage of the API, so >>>>> another >>>>> level of indirection does not appear to present any noticeable >>>>> performance overhead. >>>>> >>>>> The Test3 on the other hand shows the synchronization overhead of >>>>> current jdk8 code in comparison with non-blocking synchronization in >>>>> patched code. >>>>> >>>>> JEP 149 also mentions testing with SPECjbb2005 and SPECjvm98, but >>>>> that >>>>> exceeds my possibilities. >>>>> >>>>> The patch against jdk8/jdk8/jdk hg repository is here: >>>>> >>>>> https://raw.github.com/plevart/jdk8-hacks/master/volatile_class_data_caching.patch >>>>> >>>>> >>>>> You can also browse the changed sources: >>>>> >>>>> https://github.com/plevart/jdk8-hacks >>>>> >>>>> >>>>> Regards, Peter >>>>> >> > From akhil.arora at oracle.com Fri Nov 30 18:44:26 2012 From: akhil.arora at oracle.com (Akhil Arora) Date: Fri, 30 Nov 2012 10:44:26 -0800 Subject: Review Request: 8004201: add reducers to primitive type wrappers Message-ID: <50B8FE8A.2030403@oracle.com> Hi Requesting review for some basic functionality related to lambdas - Add min, max, sum methods to the primitive wrapper classes - Byte, Short, Integer, Long, Float, Double and Character so as to be able to use them as reducers in lambda expressions. Add and, or, xor methods to Boolean. http://cr.openjdk.java.net/~akhil/8004201.0/webrev/ http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8004201 Thanks From krystal.mo at oracle.com Fri Nov 30 18:48:11 2012 From: krystal.mo at oracle.com (Krystal Mo) Date: Sat, 01 Dec 2012 02:48:11 +0800 Subject: Request for review (XXS): JDK-8004066: TEST_BUG: test/java/lang/Math/DivModTests.java assumes ArithmeticException message Message-ID: <50B8FF6B.8040406@oracle.com> Hi all, Could I get a couple of review for this small change, please? And could someone from the JDK side sponsor this change? Bug: https://jbs.oracle.com/bugs/browse/JDK-8004066 Webrev: http://cr.openjdk.java.net/~kmo/8004066/webrev.00/ The DivModTest introduced in JDK-6282196 [1] checks the contents of the exception message, but that message isn't specified in JavaDoc and thus may vary between VM implementations (or even in the same VM). The issue has affected HotSpot Server VM in nightlies, and the Shark VM. As OpenJDK library code may receive broader adoption in the future, this issue may affect other VM implementations in the future as well. (Details: The HotSpot Server Compiler may recompile hot throw sites to throw a preallocated exception object, with null exception message, leading to a NPE in the test; The bytecode interpreter in Zero/Shark VM throws the ArithmeticException with "/ by long zero" for ldiv, which is different from normal HotSpot behavior (which is expected by the test) where the exception message is "/ by zero".) This change relaxes the test so that it's more lenient and less sensitive to the error message produced by the VM. I don't think there's a good/reliable way of verifying whether an ArithmeticException came from "division by zero", checking the type should be enough for now. Tested with the failing nightly test case and jprt. $ java -Xcomp -showversion -XX:DefaultMaxRAMFraction=8 -XX:-TieredCompilation -XX:CompileThreshold=100 -XX:+UnlockExperimentalVMOptions -XX:+IgnoreUnrecognizedVMOptions -XX:+AggressiveOpts -XX:+IgnoreUnrecognizedVMOptions -XX:-UseCompressedOops DivModTests java version "1.8.0-ea" Java(TM) SE Runtime Environment (build 1.8.0-ea-b65) Java HotSpot(TM) 64-Bit Server VM (build 25.0-b11-internal-fastdebug, compiled mode) Exception in thread "main" java.lang.NullPointerException at DivModTests.resultEquals(DivModTests.java:390) at DivModTests.testIntFloorMod(DivModTests.java:126) at DivModTests.testIntFloorDivMod(DivModTests.java:103) at DivModTests.testIntFloorDivMod(DivModTests.java:68) at DivModTests.main(DivModTests.java:45) Description from the bug report: ~/jdk/test/java/lang/Math$ java -Xint -showversion DivModTests java version "1.8.0-ea" Java(TM) SE Runtime Environment (build 1.8.0-ea-b65) OpenJDK 64-Bit Shark VM (build 25.0-b11-internal, interpreted mode) FAIL: long Math.floorDiv(4, 0) = java.lang.ArithmeticException: / by long zero; expected java.lang.ArithmeticException: / by zero FAIL: long StrictMath.floorDiv(4, 0) = java.lang.ArithmeticException: / by long zero; expected java.lang.ArithmeticException: / by zero FAIL: long Math.floorMod(4, 0) = java.lang.ArithmeticException: / by long zero; expected java.lang.ArithmeticException: / by zero FAIL: long StrictMath.floorMod(4, 0) = java.lang.ArithmeticException: / by long zero; expected java.lang.ArithmeticException: / by zero Exception in thread "main" java.lang.RuntimeException: 4 errors found in DivMod methods. at DivModTests.main(DivModTests.java:49) Regards, Kris [1]: https://jbs.oracle.com/bugs/browse/JDK-6282196 From Alan.Bateman at oracle.com Fri Nov 30 18:54:42 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 30 Nov 2012 18:54:42 +0000 Subject: bottleneck by java.lang.Class.getAnnotations() - rebased patch In-Reply-To: <50B8FC99.401@gmail.com> References: <924D06EC-F603-4E6A-A7FE-7A05C77B1217@gmail.com> <23313EDE-3AB7-4E53-8EB1-A6F6CC9383B9@gmail.com> <5093A8D3.4030800@gmail.com> <5096CFBD.2010604@gmail.com> <5096F5B0.8070304@gmail.com> <50974D3D.1040502@oracle.com> <50990CB8.2040400@gmail.com> <5099C2FA.2020202@oracle.com> <509A3A63.5010102@gmail.com> <50AF5930.5010903@gmail.com> <50AFADB4.9000204@gmail.com> <50B8FC99.401@gmail.com> Message-ID: <50B900F2.9060902@oracle.com> On 30/11/2012 18:36, Peter Levart wrote: > : > > So, what do you think? What kind of tests should I prepare in addidion > to those 3 so that the patch might get a consideration? I think this is good work and thanks for re-basing your patch. I know David plans to do a detail review. I think it will require extensive performance testing too, perhaps with some large applications. -Alan From krystal.mo at oracle.com Fri Nov 30 18:56:21 2012 From: krystal.mo at oracle.com (Krystal Mo) Date: Sat, 01 Dec 2012 02:56:21 +0800 Subject: Request for review (XXS): JDK-8004066: TEST_BUG: test/java/lang/Math/DivModTests.java assumes ArithmeticException message In-Reply-To: <50B8FF6B.8040406@oracle.com> References: <50B8FF6B.8040406@oracle.com> Message-ID: <50B90155.8030602@oracle.com> Forgot to mention: the two runs of the test in the last mail were examples of test failures before the fix. They would run fine after the fix. - Kris On 12/01/2012 02:48 AM, Krystal Mo wrote: > Hi all, > > Could I get a couple of review for this small change, please? > And could someone from the JDK side sponsor this change? > > Bug: https://jbs.oracle.com/bugs/browse/JDK-8004066 > Webrev: http://cr.openjdk.java.net/~kmo/8004066/webrev.00/ > > The DivModTest introduced in JDK-6282196 [1] checks the contents of > the exception message, but that message isn't specified in JavaDoc and > thus may vary between VM implementations (or even in the same VM). > > The issue has affected HotSpot Server VM in nightlies, and the Shark > VM. As OpenJDK library code may receive broader adoption in the > future, this issue may affect other VM implementations in the future > as well. > > (Details: > The HotSpot Server Compiler may recompile hot throw sites to throw a > preallocated exception object, with null exception message, leading to > a NPE in the test; > The bytecode interpreter in Zero/Shark VM throws the > ArithmeticException with "/ by long zero" for ldiv, which is different > from normal HotSpot behavior (which is expected by the test) where the > exception message is "/ by zero".) > > This change relaxes the test so that it's more lenient and less > sensitive to the error message produced by the VM. > I don't think there's a good/reliable way of verifying whether an > ArithmeticException came from "division by zero", checking the type > should be enough for now. > > Tested with the failing nightly test case and jprt. > > $ java -Xcomp -showversion -XX:DefaultMaxRAMFraction=8 > -XX:-TieredCompilation -XX:CompileThreshold=100 > -XX:+UnlockExperimentalVMOptions -XX:+IgnoreUnrecognizedVMOptions > -XX:+AggressiveOpts -XX:+IgnoreUnrecognizedVMOptions > -XX:-UseCompressedOops DivModTests > java version "1.8.0-ea" > Java(TM) SE Runtime Environment (build 1.8.0-ea-b65) > Java HotSpot(TM) 64-Bit Server VM (build 25.0-b11-internal-fastdebug, > compiled mode) > > Exception in thread "main" java.lang.NullPointerException > at DivModTests.resultEquals(DivModTests.java:390) > at DivModTests.testIntFloorMod(DivModTests.java:126) > at DivModTests.testIntFloorDivMod(DivModTests.java:103) > at DivModTests.testIntFloorDivMod(DivModTests.java:68) > at DivModTests.main(DivModTests.java:45) > > > Description from the bug report: > ~/jdk/test/java/lang/Math$ java -Xint -showversion DivModTests > java version "1.8.0-ea" > Java(TM) SE Runtime Environment (build 1.8.0-ea-b65) > OpenJDK 64-Bit Shark VM (build 25.0-b11-internal, interpreted mode) > > FAIL: long Math.floorDiv(4, 0) = java.lang.ArithmeticException: / by > long zero; expected java.lang.ArithmeticException: / by zero > FAIL: long StrictMath.floorDiv(4, 0) = java.lang.ArithmeticException: > / by long zero; expected java.lang.ArithmeticException: / by zero > FAIL: long Math.floorMod(4, 0) = java.lang.ArithmeticException: / by > long zero; expected java.lang.ArithmeticException: / by zero > FAIL: long StrictMath.floorMod(4, 0) = java.lang.ArithmeticException: > / by long zero; expected java.lang.ArithmeticException: / by zero > Exception in thread "main" java.lang.RuntimeException: 4 errors found > in DivMod methods. > at DivModTests.main(DivModTests.java:49) > > Regards, > Kris > > [1]: https://jbs.oracle.com/bugs/browse/JDK-6282196 From vitalyd at gmail.com Fri Nov 30 18:59:39 2012 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Fri, 30 Nov 2012 13:59:39 -0500 Subject: Review Request: 8004201: add reducers to primitive type wrappers In-Reply-To: <50B8FE8A.2030403@oracle.com> References: <50B8FE8A.2030403@oracle.com> Message-ID: Hi Akhil, At least for Integer.min/max you may want to use Math.min/max - these are jit intrinsics. I'd probably use the Math methods for all matching types (int, long, float, double) to cover the bases. Thanks Sent from my phone On Nov 30, 2012 1:45 PM, "Akhil Arora" wrote: > Hi > > Requesting review for some basic functionality related to lambdas - > > Add min, max, sum methods to the primitive wrapper classes - Byte, Short, > Integer, Long, Float, Double and Character so as to be able to use them as > reducers in lambda expressions. Add and, or, xor methods to Boolean. > > http://cr.openjdk.java.net/~**akhil/8004201.0/webrev/ > http://bugs.sun.com/**bugdatabase/view_bug.do?bug_**id=8004201 > > Thanks > From christian.thalinger at oracle.com Fri Nov 30 19:03:00 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 30 Nov 2012 11:03:00 -0800 Subject: Request for review (XXS): JDK-8004066: TEST_BUG: test/java/lang/Math/DivModTests.java assumes ArithmeticException message In-Reply-To: <50B8FF6B.8040406@oracle.com> References: <50B8FF6B.8040406@oracle.com> Message-ID: On Nov 30, 2012, at 10:48 AM, Krystal Mo wrote: > Hi all, > > Could I get a couple of review for this small change, please? > And could someone from the JDK side sponsor this change? > > Bug: https://jbs.oracle.com/bugs/browse/JDK-8004066 > Webrev: http://cr.openjdk.java.net/~kmo/8004066/webrev.00/ Looks good to me. -- Chris > > The DivModTest introduced in JDK-6282196 [1] checks the contents of the exception message, but that message isn't specified in JavaDoc and thus may vary between VM implementations (or even in the same VM). > > The issue has affected HotSpot Server VM in nightlies, and the Shark VM. As OpenJDK library code may receive broader adoption in the future, this issue may affect other VM implementations in the future as well. > > (Details: > The HotSpot Server Compiler may recompile hot throw sites to throw a preallocated exception object, with null exception message, leading to a NPE in the test; > The bytecode interpreter in Zero/Shark VM throws the ArithmeticException with "/ by long zero" for ldiv, which is different from normal HotSpot behavior (which is expected by the test) where the exception message is "/ by zero".) > > This change relaxes the test so that it's more lenient and less sensitive to the error message produced by the VM. > I don't think there's a good/reliable way of verifying whether an ArithmeticException came from "division by zero", checking the type should be enough for now. > > Tested with the failing nightly test case and jprt. > > $ java -Xcomp -showversion -XX:DefaultMaxRAMFraction=8 -XX:-TieredCompilation -XX:CompileThreshold=100 -XX:+UnlockExperimentalVMOptions -XX:+IgnoreUnrecognizedVMOptions -XX:+AggressiveOpts -XX:+IgnoreUnrecognizedVMOptions -XX:-UseCompressedOops DivModTests > java version "1.8.0-ea" > Java(TM) SE Runtime Environment (build 1.8.0-ea-b65) > Java HotSpot(TM) 64-Bit Server VM (build 25.0-b11-internal-fastdebug, compiled mode) > > Exception in thread "main" java.lang.NullPointerException > at DivModTests.resultEquals(DivModTests.java:390) > at DivModTests.testIntFloorMod(DivModTests.java:126) > at DivModTests.testIntFloorDivMod(DivModTests.java:103) > at DivModTests.testIntFloorDivMod(DivModTests.java:68) > at DivModTests.main(DivModTests.java:45) > > > Description from the bug report: > ~/jdk/test/java/lang/Math$ java -Xint -showversion DivModTests > java version "1.8.0-ea" > Java(TM) SE Runtime Environment (build 1.8.0-ea-b65) > OpenJDK 64-Bit Shark VM (build 25.0-b11-internal, interpreted mode) > > FAIL: long Math.floorDiv(4, 0) = java.lang.ArithmeticException: / by long zero; expected java.lang.ArithmeticException: / by zero > FAIL: long StrictMath.floorDiv(4, 0) = java.lang.ArithmeticException: / by long zero; expected java.lang.ArithmeticException: / by zero > FAIL: long Math.floorMod(4, 0) = java.lang.ArithmeticException: / by long zero; expected java.lang.ArithmeticException: / by zero > FAIL: long StrictMath.floorMod(4, 0) = java.lang.ArithmeticException: / by long zero; expected java.lang.ArithmeticException: / by zero > Exception in thread "main" java.lang.RuntimeException: 4 errors found in DivMod methods. > at DivModTests.main(DivModTests.java:49) > > Regards, > Kris > > [1]: https://jbs.oracle.com/bugs/browse/JDK-6282196 From krystal.mo at oracle.com Fri Nov 30 19:19:46 2012 From: krystal.mo at oracle.com (Krystal Mo) Date: Sat, 01 Dec 2012 03:19:46 +0800 Subject: Review Request: 8004201: add reducers to primitive type wrappers In-Reply-To: References: <50B8FE8A.2030403@oracle.com> Message-ID: <50B906D2.9050408@oracle.com> Hi Vitaly, Right now HotSpot only declares and implements the (int,int)->int version of Math.min/max as intrinsics. Nevertheless, it wouldn't hurt to use the Math methods, in hope that they'll get more love in the future :-) - Kris On 12/01/2012 02:59 AM, Vitaly Davidovich wrote: > Hi Akhil, > > At least for Integer.min/max you may want to use Math.min/max - these are > jit intrinsics. I'd probably use the Math methods for all matching types > (int, long, float, double) to cover the bases. > > Thanks > > Sent from my phone > On Nov 30, 2012 1:45 PM, "Akhil Arora" wrote: > >> Hi >> >> Requesting review for some basic functionality related to lambdas - >> >> Add min, max, sum methods to the primitive wrapper classes - Byte, Short, >> Integer, Long, Float, Double and Character so as to be able to use them as >> reducers in lambda expressions. Add and, or, xor methods to Boolean. >> >> http://cr.openjdk.java.net/~**akhil/8004201.0/webrev/ >> http://bugs.sun.com/**bugdatabase/view_bug.do?bug_**id=8004201 >> >> Thanks >> From vitalyd at gmail.com Fri Nov 30 19:22:35 2012 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Fri, 30 Nov 2012 14:22:35 -0500 Subject: Review Request: 8004201: add reducers to primitive type wrappers In-Reply-To: <50B906D2.9050408@oracle.com> References: <50B8FE8A.2030403@oracle.com> <50B906D2.9050408@oracle.com> Message-ID: Yup, exactly. I specifically called out the int version as the one to at least change over to Math since I know that's intrinsified. Thanks Kris Sent from my phone On Nov 30, 2012 2:19 PM, "Krystal Mo" wrote: > Hi Vitaly, > > Right now HotSpot only declares and implements the (int,int)->int version > of Math.min/max as intrinsics. > Nevertheless, it wouldn't hurt to use the Math methods, in hope that > they'll get more love in the future :-) > > - Kris > > On 12/01/2012 02:59 AM, Vitaly Davidovich wrote: > >> Hi Akhil, >> >> At least for Integer.min/max you may want to use Math.min/max - these are >> jit intrinsics. I'd probably use the Math methods for all matching types >> (int, long, float, double) to cover the bases. >> >> Thanks >> >> Sent from my phone >> On Nov 30, 2012 1:45 PM, "Akhil Arora" wrote: >> >> Hi >>> >>> Requesting review for some basic functionality related to lambdas - >>> >>> Add min, max, sum methods to the primitive wrapper classes - Byte, Short, >>> Integer, Long, Float, Double and Character so as to be able to use them >>> as >>> reducers in lambda expressions. Add and, or, xor methods to Boolean. >>> >>> http://cr.openjdk.java.net/~****akhil/8004201.0/webrev/ >>> >>> > >>> http://bugs.sun.com/****bugdatabase/view_bug.do?bug_****id=8004201 >>> >>> > >>> >>> Thanks >>> >>> > From krystal.mo at oracle.com Fri Nov 30 19:25:32 2012 From: krystal.mo at oracle.com (Krystal Mo) Date: Sat, 01 Dec 2012 03:25:32 +0800 Subject: Request for review (XXS): JDK-8004066: TEST_BUG: test/java/lang/Math/DivModTests.java assumes ArithmeticException message In-Reply-To: <50B90155.8030602@oracle.com> References: <50B8FF6B.8040406@oracle.com> <50B90155.8030602@oracle.com> Message-ID: <50B9082C.5090302@oracle.com> The open bug URL is: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8004066 Sorry for the noise. - Kris On 12/01/2012 02:56 AM, Krystal Mo wrote: > Forgot to mention: the two runs of the test in the last mail were > examples of test failures before the fix. They would run fine after > the fix. > > - Kris > > On 12/01/2012 02:48 AM, Krystal Mo wrote: >> Hi all, >> >> Could I get a couple of review for this small change, please? >> And could someone from the JDK side sponsor this change? >> >> Bug: https://jbs.oracle.com/bugs/browse/JDK-8004066 >> Webrev: http://cr.openjdk.java.net/~kmo/8004066/webrev.00/ >> >> The DivModTest introduced in JDK-6282196 [1] checks the contents of >> the exception message, but that message isn't specified in JavaDoc >> and thus may vary between VM implementations (or even in the same VM). >> >> The issue has affected HotSpot Server VM in nightlies, and the Shark >> VM. As OpenJDK library code may receive broader adoption in the >> future, this issue may affect other VM implementations in the future >> as well. >> >> (Details: >> The HotSpot Server Compiler may recompile hot throw sites to throw a >> preallocated exception object, with null exception message, leading >> to a NPE in the test; >> The bytecode interpreter in Zero/Shark VM throws the >> ArithmeticException with "/ by long zero" for ldiv, which is >> different from normal HotSpot behavior (which is expected by the >> test) where the exception message is "/ by zero".) >> >> This change relaxes the test so that it's more lenient and less >> sensitive to the error message produced by the VM. >> I don't think there's a good/reliable way of verifying whether an >> ArithmeticException came from "division by zero", checking the type >> should be enough for now. >> >> Tested with the failing nightly test case and jprt. >> >> $ java -Xcomp -showversion -XX:DefaultMaxRAMFraction=8 >> -XX:-TieredCompilation -XX:CompileThreshold=100 >> -XX:+UnlockExperimentalVMOptions -XX:+IgnoreUnrecognizedVMOptions >> -XX:+AggressiveOpts -XX:+IgnoreUnrecognizedVMOptions >> -XX:-UseCompressedOops DivModTests >> java version "1.8.0-ea" >> Java(TM) SE Runtime Environment (build 1.8.0-ea-b65) >> Java HotSpot(TM) 64-Bit Server VM (build 25.0-b11-internal-fastdebug, >> compiled mode) >> >> Exception in thread "main" java.lang.NullPointerException >> at DivModTests.resultEquals(DivModTests.java:390) >> at DivModTests.testIntFloorMod(DivModTests.java:126) >> at DivModTests.testIntFloorDivMod(DivModTests.java:103) >> at DivModTests.testIntFloorDivMod(DivModTests.java:68) >> at DivModTests.main(DivModTests.java:45) >> >> >> Description from the bug report: >> ~/jdk/test/java/lang/Math$ java -Xint -showversion DivModTests >> java version "1.8.0-ea" >> Java(TM) SE Runtime Environment (build 1.8.0-ea-b65) >> OpenJDK 64-Bit Shark VM (build 25.0-b11-internal, interpreted mode) >> >> FAIL: long Math.floorDiv(4, 0) = java.lang.ArithmeticException: / by >> long zero; expected java.lang.ArithmeticException: / by zero >> FAIL: long StrictMath.floorDiv(4, 0) = java.lang.ArithmeticException: >> / by long zero; expected java.lang.ArithmeticException: / by zero >> FAIL: long Math.floorMod(4, 0) = java.lang.ArithmeticException: / by >> long zero; expected java.lang.ArithmeticException: / by zero >> FAIL: long StrictMath.floorMod(4, 0) = java.lang.ArithmeticException: >> / by long zero; expected java.lang.ArithmeticException: / by zero >> Exception in thread "main" java.lang.RuntimeException: 4 errors found >> in DivMod methods. >> at DivModTests.main(DivModTests.java:49) >> >> Regards, >> Kris >> >> [1]: https://jbs.oracle.com/bugs/browse/JDK-6282196 > From kurchi.subhra.hazra at oracle.com Fri Nov 30 19:53:13 2012 From: kurchi.subhra.hazra at oracle.com (kurchi.subhra.hazra at oracle.com) Date: Fri, 30 Nov 2012 19:53:13 +0000 Subject: hg: jdk8/tl/jdk: 7197662: (prefs) java/util/prefs/AddNodeChangeListener.java fails by timeout or by "couldn't get file lock" Message-ID: <20121130195325.683A147C45@hg.openjdk.java.net> Changeset: 43d2e02c4098 Author: khazra Date: 2012-11-30 12:00 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/43d2e02c4098 7197662: (prefs) java/util/prefs/AddNodeChangeListener.java fails by timeout or by "couldn't get file lock" Summary: Set -Djava.util.prefs.userRoot to current working directory of user in the prefs tests Reviewed-by: alanb, chegar, weijun, dxu ! test/java/util/prefs/AddNodeChangeListener.java ! test/java/util/prefs/CheckUserPrefsStorage.sh ! test/java/util/prefs/CommentsInXml.java ! test/java/util/prefs/ConflictInFlush.java ! test/java/util/prefs/ExportNode.java ! test/java/util/prefs/ExportSubtree.java ! test/java/util/prefs/PrefsSpi.sh ! test/java/util/prefs/RemoveNullKeyCheck.java ! test/java/util/prefs/RemoveReadOnlyNode.java ! test/java/util/prefs/RemoveUnregedListener.java From xueming.shen at oracle.com Fri Nov 30 21:03:52 2012 From: xueming.shen at oracle.com (Xueming Shen) Date: Fri, 30 Nov 2012 13:03:52 -0800 Subject: Request for review for [JBS] (JDK-8004212) java.util.Base64 methods decodeArray and decodeBuffer should return the number of bytes written Message-ID: <50B91F38.40907@oracle.com> Alan, It appears the return value is not correct in decode(Bytebuffer...) case if the buffer is overflow. Here is the webrev for that. http://cr.openjdk.java.net/~sherman/8004212/webrev/ Thanks, -Sherman From Ulf.Zibis at CoSoCo.de Fri Nov 30 22:01:09 2012 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Fri, 30 Nov 2012 23:01:09 +0100 Subject: Review/comment needed for the new public java.util.Base64 class In-Reply-To: <50957FA6.6050806@CoSoCo.de> References: <5075B65D.1020709@oracle.com> <5076F68A.3020501@oracle.com> <1349980256.10396.140661139477733.7A0FEBA3@webmail.messagingengine.com> <5077F75D.2020003@oracle.com> <507F6511.10309@oracle.com> <508695CC.1080408@oracle.com> <508758C7.5030703@oracle.com> <508FFA32.1090206@CoSoCo.de> <5090576A.4080709@oracle.com> <50957FA6.6050806@CoSoCo.de> Message-ID: <50B92CA5.9020109@CoSoCo.de> Hi Sherman, is this ssue still open ? -Ulf Am 03.11.2012 21:33, schrieb Ulf Zibis: > Am 30.10.2012 23:40, schrieb Xueming Shen: >>> I'm "confused" about the order of xxcode() and Xxcoder. >>> In other places e.g. charsets, we have de... before en..., which is also true alphabetical >>> >> should not be an issue. javadoc output should be in alphabetic order. If it is really >> concerns you, I can do a copy/paste:-) > > Yes, it doesn't matter much, but would be a nice conform style, so for me "personally" I would > like the copy/paste:-) > >>> - What (should) happen(s), if lineSeparator.length == 0 ? >> do nothing. expected? > > I would say, empty line separator should not be allowed, so you might check: > Objects.requireNonEmpty(lineSeparator); > >>> 603 static { >>> 604 Arrays.fill(fromBase64, -1); >>> 605 for (int i = 0; i < Encoder.toBase64.length; i++) >>> 606 fromBase64[Encoder.toBase64[i]] = i; >>> 607 fromBase64['='] = -2; >>> 608 } >>> This causes the inner Encoder class to be loaded, even if not needed. So maybe move the toBase64 >>> table to the outer class. >>> Have you compared performance with fromBase64 as byte[] (including local 'b' in decode() as byte)? >> >> understood. > > It seems you have mixed 2 tweaks to one. ;-) See additional paragraph at the end ... > >> but it appears the hotspot likes it the constant/fixed length lookup >> table is inside encoder. > Yes, but see my suggestion 12 lines below. > >> Same as you suggestion in your previous email to use >> String in source and expand it during runtime. It saves about 500 bytes but slows >> the server vm. > > Are you really sure? As it only runs once at class init, JIT should not compile this code. > Executing the bytecode to init the final int[], value for value, by interpreter should not be > faster as expanding a String source in a loop. > >> Those repeating lines of "isURL? ...." is also supposed to be a >> performance tweak to eliminate the array boundary check in loop. > > Yep, so I was thinking about: > 653 private final int[] base64; > 654 private final boolean isMIME; > 655 > 656 private Decoder(boolean isURL, boolean isMIME) { > 657 base64 = isURL ? fromBase64URL : fromBase64; > 658 this.isMIME = isMIME; > 659 } > ..... > 911 private int decodeBuffer(ByteBuffer src, ByteBuffer dst) { > 912 int[] base64 = this.base64; // local copy for performance reasons (but maybe > superfluous if HotSpot is intelligent enough) > or: > 911 private int decodeBuffer(ByteBuffer src, ByteBuffer dst, int[] base64) { > ..... > >>> Why you mix the algorithms to check the padding? : >>> 824 if (b == -2) { // padding byte >>> 890 if (b == '=') { >>> >> It is supposed reduce one "if" check for normal base64 character inside the >> loop. I'm not that sure it really helps though. > > 925 if (b == '=') { > --> causes one additional "if" in the _main_ path of the loop, so should be slower for regular input > > 859 if (b == -2) { // padding byte > --> causes one additional "if" in the _side_ path of the loop, so should only affect irregular input > Maybe the following code is little faster as no loading of the constant '-2' is required: > 858 if ((b = base64[b]) < 0) { > 859 if (++b < 0) { // padding byte '=' > > > Once again (the following was meant for the decode algorithm, not initialisation): > Have you compared performance with fromBase64 as byte[] (including local 'b' in decode() as byte)? > Retrieving the bytes by b = base64[x] then could be done without address-shift and smaller/faster > LoadB operations could be used by JIT. In an int[] table, the index offset must be shifted by 2 > before. Maybe this doesn't directly affect the performance on x86/IA64 CPU, but wastes space in > CPU cache for other tasks as a side effect. On ARM architectures I imagine, directly addressing a > byte-stepped table could be faster than addressing a 4-byte-stepped table. At least the footprint > of the table would be smaller. > > Little nit: > You could delete line 641 for conformity with 629. > > -Ulf > > From vikram.aroskar at oracle.com Wed Nov 21 05:41:20 2012 From: vikram.aroskar at oracle.com (vikram.aroskar at oracle.com) Date: Wed, 21 Nov 2012 05:41:20 +0000 Subject: hg: jdk8/tl/jdk: 7198904: (alt-rt) TreeMap.clone is broken Message-ID: <20121121054132.0CF5547AAD@hg.openjdk.java.net> Changeset: f389bf27fc4f Author: dbuck Date: 2012-11-20 21:35 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f389bf27fc4f 7198904: (alt-rt) TreeMap.clone is broken Summary: Test case for cr7198904. Issue only found in OracleJDK, but test case is valid for OpenJDK as well Reviewed-by: mduigou, dholmes + test/java/util/TreeMap/Clone.java From howard.lovatt at gmail.com Wed Nov 21 21:55:10 2012 From: howard.lovatt at gmail.com (Howard Lovatt) Date: Thu, 22 Nov 2012 08:55:10 +1100 Subject: Request for Review (#4) : CR#8001634 : Initial set of lambda functional interfaces In-Reply-To: <50AB23CE.2030104@oracle.com> References: <8733618F-C751-414F-ACE2-D1C9B6E70257@oracle.com> <50AB23CE.2030104@oracle.com> Message-ID: <7E3666AA-8196-4B01-A749-B0A61979C155@gmail.com> Couple of quick comments: 1. I think the naming is inconsistent between class and method, e.g. IntFunction has an applyAsInt method. Why not either IntFunction and intApply or FunctionAsInt and applyAsInt? 2. It would be good to have a description of the stream library, perhaps an expanded for of Brian's State of Streams document referenced throughout the API like the Collections API has. Sent from my iPad On 20/11/2012, at 5:31 PM, David Holmes wrote: > Hi Mike, > > Minor typos and inconsistencies: > > DoubleBinaryOperator.java > > 28 * Combines two {@code double} operands producing an {@code double} > result. > > an -> a > > 51 * @param rightvalue used as the right operand > > Need space after right > > 52 * @return result value of the operation > > "result value" doesn't read right - just "@return the result of ..." - > as for BinaryOperator.operate > > General consistency: all like methods in a family of interfaces should > use the same wording. Eg BinaryOperator.operate says "upon the provided > operands" whereas DoubleBinaryOperator.* says "upon the operands". Ditto > across families ie UnaryOperator and BinaryOperator should use > consistent terminology for operands and results. > > --- > > DoubleBlock.java: > > 31 * @param The type of input objects to {@code accept}. > > DoubleBlock is not a generic type. (Surely this should be generating a > javadoc warning?) > > --- > > DoubleFunction.java > > 32 * @param the type of input objects to the {@code apply} operation. > > You now potentially have multiple operation methods, and T refers to the > input of all of them. > > ---- > > General consistency comments across everything: > - Use of operand versus provided operand versus input value etc > - Use of result vs computed result vs result value vs output etc > > --- > > Function.java > > 33 * @param the type of output objects from {@code apply} operation. > > from -> from the > > 43 * @param t the input object to be to which the function will > be applied. > > delete "to be" ? Or else re-word. > > --- > > UnaryOperator.java > > 28 * Operator on a single operand. > > Operator -> operate ? > > 30 * @param the type of input objects to {@code operate} and of > the result. > > objects -> object > > --- > > Cheers, > David > > > On 20/11/2012 2:55 PM, Mike Duigou wrote: >> I have posted another revision at >> >> http://cr.openjdk.java.net/~mduigou/8001634/5/webrev/ >> >> This version contains some method remaining in the {I|L|D}UnaryOperation and {I|L|D}BinaryOperator and a few Javadoc fixes. >> >> The package javadoc ie. package-info.java, is known to be a weak point right now. We're still debating what must be said here and what would be better said attached to the APIs which consume these functional interfaces. >> >> We don't anticipate many (any?) further changes to the naming before commit at this point. >> >> Mike >> >> On Nov 13 2012, at 17:19 , Mike Duigou wrote: >> >>> Hello all; >>> >>> I apologize for the quick turnaround from the second review request [1] but I've updated the webrev again: >>> >>> http://cr.openjdk.java.net/~mduigou/8001634/4/webrev/ >>> >>> Blame a busy Paul Sandoz who his making significant progress on the primitive specializations implementation. ;-) >>> >>> This update includes: >>> >>> - Block.apply renamed to Block.accept >>> - {Int|Long|Double}Block specializations added. >>> - Commented out "extends Combiner" in BinaryOperator was removed for now since Combiner is out of scope for this review. >>> - The {Int|Long|Double} specializations of BinaryOperator and UnaryOperator now show commented out extends of the generic version along with commented out default methods. This change will not be part of the commit but is meant to show where the implementation will be going. >>> - The {Int|Long|Double} specializations of Supplier now extend generic Supplier, have getAs{Int|Long|Double} as their abstract method and provide a commented out default get() method to satisfy the need for a get implementation. >>> - The {Int|Long|Double} specializations of Function now extend generic Function, have applyAs{Int|Long|Double} as their abstract method and provide a commented out default apply() method to satisfy the need for an apply implementation. >>> >>> Mike >>> >>> [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-November/012225.html > From talden at gmail.com Thu Nov 29 08:21:40 2012 From: talden at gmail.com (Talden) Date: Thu, 29 Nov 2012 21:21:40 +1300 Subject: Request for Review : CR#8004015 : Add interface extends and defaults for basic functional interfaces In-Reply-To: <50B6F7C1.4080606@oracle.com> References: <54FA2248-91D9-4181-AC30-22FB365D3297@oracle.com> <50B6F7C1.4080606@oracle.com> Message-ID: On Thu, Nov 29, 2012 at 6:50 PM, David Holmes wrote: > Mike, > > On 28/11/2012 3:32 AM, Mike Duigou wrote: > > On Nov 27 2012, at 03:56 , Stephen Colebourne wrote: > > > >> On 27 November 2012 02:12, Mike Duigou wrote: > >>> In the original patch which added the basic lambda functional > interfaces, CR#8001634 [1], none of the interfaces extended other > interfaces. The reason was primarily that the javac compiler did not, at > the time that 8001634 was proposed, support extension methods. The compiler > now supports adding of method defaults so this patch improves the > functional interfaces by filing in the inheritance hierarchy. > >>> > >>> Adding the parent interfaces and default methods allows each > functional interface to be used in more places. It is especially important > for the functional interfaces which support primitive types, IntSupplier, > IntFunction, IntUnaryOperator, IntBinaryOperator, etc. We expect that > eventually standard implementations of these interfaces will be provided > for functions like max, min, sum, etc. By extending the reference oriented > functional interfaces such as Function, the primitive implementations can > be used with the boxed primitive types along with the primitive types for > which they are defined. > >>> > >>> The patch to add parent interfaces and default methods can be found > here: > >>> > >>> http://cr.openjdk.java.net/~mduigou/8004015/0/webrev/ > >>> > http://cr.openjdk.java.net/~mduigou/8004015/0/specdiff/java/util/function/package-summary.html > >> > >> Each of the default methods is formatted on a single line. I consider > >> this to be bad style, they should be formatted as per "normal" > >> methods: > >> @Override > >> public default Double operate(Double left, Double right) { > >> return operateAsDouble((double) left, (double) right); > >> } > >> > >> It is vitally important to get this kind of formatting/style correct. > > > >> Developers the world over will be copying what the style is in these > >> classes. > > > > I totally agree that we should be consistent but I don't believe that > there's a consensus yet on what good style is for these cases. What's your > rationale for it being "bad style"? > > I have to concur with Stephen - these are just method definitions and > should follow the same style that is used for method definitions in > classes. No need to contemplate introducing a new style just for default > methods. > I've personally never a one-style-to-rule-them-all kinda guy and I usual format trivial methods this way - that is, trivial getters, setters and delegating implementations. I've considered the vertical brevity a readability benefit in these cases and the absence of 'abstract' (for class methods) or the presence of default (for interfaces) seems cue enough. Still, at least it's not the opposite extreme. While I'm happy with (though 2-space vs 4-space indentations are my preference)... @Override public default Double operate(Double left, Double right) { return operateAsDouble((double) left, (double) right); } I've worked with those that think this is necessary (assume a fixed width font to understand the indentation)... @Override public default Double operate( Double left, Double right ) { return operateAsDouble( ( double ) left, ( double ) right ); } Monitor aspects are getting relatively wider and screens larger overall. IMO longer lines and fewer content-less lines simply fits the medium better. >> There is also no Javadoc on the default method override. > > That was intentional. The goal was to inherit from the original definition. I don't think we can just leave it at that. If we are introducing > additional constraints over that specified in base method then they need > to be documented. We should be able to use implicit doc inheritance plus > @{inheritDoc} to bring down what is unchanged and then add what is needed. > Agreed. Don't put superfluous {@inheritDoc} in there but please don't omit the Javadoc entirely if the contract is further constrained. I don't agree that we need to describe what the default implementation > does, for two reasons: > > 1. Normal methods don't usually specify how they are implemented - it is > an implementation detail. The "default" simply indicates that this > method does have an implementation and you should expect that > implementation to obey the contract of the method. > > 2. It is not obvious to me that the JDK's choice for a default > implementation has to be _the_ only possible implementation choice. In > many/most cases there will be a very obvious choice, but that doesn't > mean that all suppliers of OpenJDK classes have to be locked in to that > choice. > I have a dilemma, I disagree with the first point but not the second. Describing the complexity of the algorithm selected by default is useful information - It's saying how it scales, not how it's implemented. Documentation on how methods scale in a library is definitely beneficial. However, you're right, that documentation should be specific to the JavaSEimplementation not the JavaSE spec. It should state that the behaviour could vary with the supplier and the documentation for another JavaSE implementation should be checked or the behaviour tested. The spec could specify that it's the reference implementation and note that other implementations might use alternate implementations with different scaling characteristics - then it's easy, implementers need only alter that documentation when they deviate from the reference algorithm (though that opens a small future compatibility can-o-worms if the spec wants to use a different reference implementation in future releases). Surely the JDK has precedent for this in overridable methods of classes expecting to be extended. I'm guessing such details are omitted which makes for some potentially confusing performance differences Java implementations. -- Aaron Scott-Boddendijk From bill.pittore at oracle.com Fri Nov 30 03:22:34 2012 From: bill.pittore at oracle.com (BILL PITTORE) Date: Thu, 29 Nov 2012 22:22:34 -0500 Subject: RFR- 7200297 jdwp and hprof code do not handle multiple sun.boot.library.path elements correctly Message-ID: <50B8267A.4000403@oracle.com> This bug was reviewed by serviceability and hotspot-runtime-dev lists since it dealt with jvmti agent code. Comments welcome. The intent is to push into tl/jdk tree and then eventually back into jdk7u-dev hopefully. Webrev here: http://cr.openjdk.java.net/~bpittore/7200297/webrev.04/ And previous reviews here: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2012-November/004801.html thanks, bill From ricky.clarkson at gmail.com Fri Nov 30 13:14:46 2012 From: ricky.clarkson at gmail.com (Ricky Clarkson) Date: Fri, 30 Nov 2012 10:14:46 -0300 Subject: Request for Review : CR#8004015 : Add interface extends and defaults for basic functional interfaces In-Reply-To: <4FA6AA43-D3AF-419D-9325-1C71C94CC2BA@oracle.com> References: <54FA2248-91D9-4181-AC30-22FB365D3297@oracle.com> <50B6F7C1.4080606@oracle.com> <50B774D8.60403@oracle.com> <50B813F6.6040602@oracle.com> <50B88361.7060705@oracle.com> <4FA6AA43-D3AF-419D-9325-1C71C94CC2BA@oracle.com> Message-ID: What is the benefit of throwing an IllegalStateException in a default method over not providing any default method so that the compiler and runtime make sure concrete subtypes provide an implementation? On Nov 30, 2012 9:54 AM, "Lance Andersen - Oracle" < Lance.Andersen at oracle.com> wrote: > > On Nov 30, 2012, at 4:58 AM, Chris Hegarty wrote: > > > > > > > On 30/11/2012 02:03, David Holmes wrote: > >> On 30/11/2012 12:44 AM, Chris Hegarty wrote: > >>> On 11/29/2012 05:50 AM, David Holmes wrote: > >>>> ... > >>>> > >>>> I don't agree that we need to describe what the default implementation > >>>> does, for two reasons: > >>>> > >>>> 1. Normal methods don't usually specify how they are implemented - it > is > >>>> an implementation detail. The "default" simply indicates that this > >>>> method does have an implementation and you should expect that > >>>> implementation to obey the contract of the method. > >>>> > >>>> 2. It is not obvious to me that the JDK's choice for a default > >>>> implementation has to be _the_ only possible implementation choice. In > >>>> many/most cases there will be a very obvious choice, but that doesn't > >>>> mean that all suppliers of OpenJDK classes have to be locked in to > that > >>>> choice. > >>> > >>> This is certainly interesting, and something I've wondered for a while > >>> now. If java.util.Iterator is to ever be fitted with a default > >>> implementation of remove ( to throw UnsupportedOperationException ), > >>> then it would clearly need to be part of the spec, and not an > >>> implementation detail of OpenJDK. Otherwise, what's the point, every > >>> developer will still have to implement it because they cannot be > >>> guaranteed of it's behavior. > >> > >> I think optional methods are a bit of a special case here because they > >> don't have to work. > >> > >> It's the end user of a class that needs to understand if they can use > >> remove() to actually do a removal. The developer of the class can > >> inherit whatever default implementations Iterator provides, as long as > >> they don't mind what they get. If they do mind ie they need a real > >> remove(), then they will have to implement it themselves and in the > >> process document that fact. The end user has to look at the docs for the > >> concrete class and follow through to determine whether it's > >> iterator().remove() is optional or not. > >> > >> Put another way, a default method is great for adding a new method to > >> types that have not yet been revised to handle the new method. As a > >> developer once you revise your class you should make a conscious > >> implementation choice in my opinion and not rely on the default unless > >> you truly don't care what it does. > > > > Sorry David, I've not been following lambda that closely, but (in my > opinion) if default methods do not, or cannot, have defined semantics then > I really think it is limiting. Maybe Iterator is a bad example, but I will > continue with it anyway. In many cases developers of iterator().remove() > want it to throw, if this is not defined in Iterator's default remove > method then every Iterator subclass will still have to define its own > remove that throws. For this particular case at least (if it were to ever > happen), I would like to see specification added to remove that defines the > default implementation. > > I had wondered about this as well and had a brief email exchange with > Mike. I thought a new javadoc tag might also be something to consider. > > For JDBC, I am thinking of leveraging default methods to throw a > specific exception (maybe IllegalStateException?) if the method must be > implemented by the driver vendor or a SQLFeatureNotSupportedException for > methods which may be optional based on the backend support. > > > > -Chris. > > > >> > >> But maybe we kid ourselves when we give this illusion of flexibility in > >> implementation. > >> > >> David > >> > >>> -Chris. > > > > 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 xueming.shen at oracle.com Fri Nov 30 22:13:40 2012 From: xueming.shen at oracle.com (Xueming Shen) Date: Fri, 30 Nov 2012 14:13:40 -0800 Subject: Review/comment needed for the new public java.util.Base64 class In-Reply-To: <50B92CA5.9020109@CoSoCo.de> References: <5075B65D.1020709@oracle.com> <5076F68A.3020501@oracle.com> <1349980256.10396.140661139477733.7A0FEBA3@webmail.messagingengine.com> <5077F75D.2020003@oracle.com> <507F6511.10309@oracle.com> <508695CC.1080408@oracle.com> <508758C7.5030703@oracle.com> <508FFA32.1090206@CoSoCo.de> <5090576A.4080709@oracle.com> <50957FA6.6050806@CoSoCo.de> <50B92CA5.9020109@CoSoCo.de> Message-ID: <50B92F94.9060900@oracle.com> Ulf, The base64 implementation is in TL right now. It does address some of the issue you suggested in this email. And I remember I did try use "byte[]" alphabets, which I don't recall bring us any benefit, but I'm not sure in which setup. The latest is at http://cr.openjdk.java.net/~sherman/8004212/webrev/ in which I'm trying to fix a corner case of incorrect return value from decode(buf, buf). The Base64 now is in TL does not necessary mean "the issue is closed". You can continue suggest/comment on the latest version for any possible performance improvement, bug fix and even API change, if necessary. -Sherman On 11/30/2012 02:01 PM, Ulf Zibis wrote: > Hi Sherman, > > is this ssue still open ? > > -Ulf > > > Am 03.11.2012 21:33, schrieb Ulf Zibis: >> Am 30.10.2012 23:40, schrieb Xueming Shen: >>>> I'm "confused" about the order of xxcode() and Xxcoder. >>>> In other places e.g. charsets, we have de... before en..., which is also true alphabetical >>>> >>> should not be an issue. javadoc output should be in alphabetic order. If it is really >>> concerns you, I can do a copy/paste:-) >> >> Yes, it doesn't matter much, but would be a nice conform style, so for me "personally" I would like the copy/paste:-) >> >>>> - What (should) happen(s), if lineSeparator.length == 0 ? >>> do nothing. expected? >> >> I would say, empty line separator should not be allowed, so you might check: >> Objects.requireNonEmpty(lineSeparator); >> >>>> 603 static { >>>> 604 Arrays.fill(fromBase64, -1); >>>> 605 for (int i = 0; i < Encoder.toBase64.length; i++) >>>> 606 fromBase64[Encoder.toBase64[i]] = i; >>>> 607 fromBase64['='] = -2; >>>> 608 } >>>> This causes the inner Encoder class to be loaded, even if not needed. So maybe move the toBase64 table to the outer class. >>>> Have you compared performance with fromBase64 as byte[] (including local 'b' in decode() as byte)? >>> >>> understood. >> >> It seems you have mixed 2 tweaks to one. ;-) See additional paragraph at the end ... >> >>> but it appears the hotspot likes it the constant/fixed length lookup >>> table is inside encoder. >> Yes, but see my suggestion 12 lines below. >> >>> Same as you suggestion in your previous email to use >>> String in source and expand it during runtime. It saves about 500 bytes but slows >>> the server vm. >> >> Are you really sure? As it only runs once at class init, JIT should not compile this code. >> Executing the bytecode to init the final int[], value for value, by interpreter should not be faster as expanding a String source in a loop. >> >>> Those repeating lines of "isURL? ...." is also supposed to be a >>> performance tweak to eliminate the array boundary check in loop. >> >> Yep, so I was thinking about: >> 653 private final int[] base64; >> 654 private final boolean isMIME; >> 655 >> 656 private Decoder(boolean isURL, boolean isMIME) { >> 657 base64 = isURL ? fromBase64URL : fromBase64; >> 658 this.isMIME = isMIME; >> 659 } >> ..... >> 911 private int decodeBuffer(ByteBuffer src, ByteBuffer dst) { >> 912 int[] base64 = this.base64; // local copy for performance reasons (but maybe superfluous if HotSpot is intelligent enough) >> or: >> 911 private int decodeBuffer(ByteBuffer src, ByteBuffer dst, int[] base64) { >> ..... >> >>>> Why you mix the algorithms to check the padding? : >>>> 824 if (b == -2) { // padding byte >>>> 890 if (b == '=') { >>>> >>> It is supposed reduce one "if" check for normal base64 character inside the >>> loop. I'm not that sure it really helps though. >> >> 925 if (b == '=') { >> --> causes one additional "if" in the _main_ path of the loop, so should be slower for regular input >> >> 859 if (b == -2) { // padding byte >> --> causes one additional "if" in the _side_ path of the loop, so should only affect irregular input >> Maybe the following code is little faster as no loading of the constant '-2' is required: >> 858 if ((b = base64[b]) < 0) { >> 859 if (++b < 0) { // padding byte '=' >> >> >> Once again (the following was meant for the decode algorithm, not initialisation): >> Have you compared performance with fromBase64 as byte[] (including local 'b' in decode() as byte)? >> Retrieving the bytes by b = base64[x] then could be done without address-shift and smaller/faster LoadB operations could be used by JIT. In an int[] table, the index offset must be shifted by 2 before. Maybe this doesn't directly affect the performance on x86/IA64 CPU, but wastes space in CPU cache for other tasks as a side effect. On ARM architectures I imagine, directly addressing a byte-stepped table could be faster than addressing a 4-byte-stepped table. At least the footprint of the table would be smaller. >> >> Little nit: >> You could delete line 641 for conformity with 629. >> >> -Ulf >> >> > From jim.gish at oracle.com Fri Nov 30 23:19:20 2012 From: jim.gish at oracle.com (Jim Gish) Date: Fri, 30 Nov 2012 18:19:20 -0500 Subject: RFR: 8003596 CheckLockLocationTest-Windows-fix Message-ID: <50B93EF8.3050109@oracle.com> Please review http://cr.openjdk.java.net/~jgish/Bug8003596-CheckLockLocationTest-Windows-fix/ Summary: fixes test when running on Windows so that test that requires setWritable is not run, because Windows does not support setWritable. 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