From joe.darcy at oracle.com Tue Jul 1 03:12:07 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Mon, 30 Jun 2014 20:12:07 -0700 Subject: FYI, change to opt-out in Xlint option in build of JDK 9 jdk 9 Message-ID: <53B22707.9040005@oracle.com> Hello, FYI, the javac Xlint option for building the jdk repo in JDK 9 has been changed to "-Xlint:all" and then explicitly opting-out of lint categories which are not met: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/78290d029b4d Therefore, to avoid breaking the jdk build whenever a new lint category is added to javac, care will need to be taken that the JDK is either clear of such warnings or that the jdk makefile is updated to exclude the new option until its checks are met. Thanks, -Joe From andreas.lundblad at oracle.com Thu Jul 3 12:45:29 2014 From: andreas.lundblad at oracle.com (Andreas Lundblad) Date: Thu, 3 Jul 2014 14:45:29 +0200 Subject: RFR: 8044131: Restructure sjavac client / server protocol code Message-ID: <20140703124527.GA18098@e6430> Hi compiler-dev, Feel free to review this sjavac patch which addresses JDK-8044131. Description: The patch changes the following: - replaces the manual (de)serialization with ObjectOutputStream/ObjectInputStream - unifies the interfaces of local ("background=false") compilation and remote ("background=true") compilation - factors out thread pooling, idleness detection and port file monitoring into their own classes for better modularity The new, more modular, structure allows for better unit testing of the functionality. (See for instance the tests IdleShutdown.java and PooledExecution.java.) As part of the refactoring, JDK-8048457 was also solved. Link to webrev: http://cr.openjdk.java.net/~alundblad/8044131/ Links to bug report: https://bugs.openjdk.java.net/browse/JDK-8044131 https://bugs.openjdk.java.net/browse/JDK-8048457 -- Andreas From oehrstroem at gmail.com Thu Jul 3 14:44:20 2014 From: oehrstroem at gmail.com (=?UTF-8?B?RnJlZHJpayDDlmhyc3Ryw7Zt?=) Date: Thu, 3 Jul 2014 16:44:20 +0200 Subject: RFR: 8044131: Restructure sjavac client / server protocol code In-Reply-To: <20140703124527.GA18098@e6430> References: <20140703124527.GA18098@e6430> Message-ID: Looks very nice, but: did you drop the id supplied from the commandline? Its very useful for debugging the openjdk build. The implementation classes IdleResetSJavac and friends should not be public. //Fredrik 2014-07-03 14:45 GMT+02:00 Andreas Lundblad : > Hi compiler-dev, > > Feel free to review this sjavac patch which addresses JDK-8044131. > > Description: > The patch changes the following: > > - replaces the manual (de)serialization with > ObjectOutputStream/ObjectInputStream > > - unifies the interfaces of local ("background=false") compilation and > remote ("background=true") compilation > > - factors out thread pooling, idleness detection and port file monitoring > into their own classes for better modularity > > The new, more modular, structure allows for better unit testing of the > functionality. (See for instance the tests IdleShutdown.java and > PooledExecution.java.) > > As part of the refactoring, JDK-8048457 was also solved. > > > Link to webrev: > http://cr.openjdk.java.net/~alundblad/8044131/ > > Links to bug report: > https://bugs.openjdk.java.net/browse/JDK-8044131 > https://bugs.openjdk.java.net/browse/JDK-8048457 > > -- Andreas > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andreas.lundblad at oracle.com Thu Jul 3 19:09:07 2014 From: andreas.lundblad at oracle.com (Andreas Lundblad) Date: Thu, 3 Jul 2014 21:09:07 +0200 Subject: RFR: 8044131: Restructure sjavac client / server protocol code In-Reply-To: References: <20140703124527.GA18098@e6430> Message-ID: <20140703190906.GA18176@e6430> On Thu, Jul 03, 2014 at 04:44:20PM +0200, Fredrik ?hrstr?m wrote: > Looks very nice, but: > did you drop the id supplied from the commandline? Its very useful for > debugging the openjdk build. Wops. Forgot. Now it's back in. New revision up: http://cr.openjdk.java.net/~alundblad/8044131/webrev.01 Highlights being: SjavacClient: oos.writeObject(id); in two places RequestHandler: 65 String id = (String) oin.readObject(); 66 String cmd = (String) oin.readObject(); 67 Log.info("Handling request, id: " + id + " cmd: " + cmd); > The implementation classes IdleResetSJavac and friends should not be > public. Hmm. They are currently accessed outside of their package. I intend to split up Main in SjavacClientMain and SjavacServerMain. Once that is done it should be possible to haver stricter access on these classes. I'll leave it as is for now. From ChrisPhi at LGonQn.Org Thu Jul 10 15:18:29 2014 From: ChrisPhi at LGonQn.Org (Chris Phillips @ T O) Date: Thu, 10 Jul 2014 11:18:29 -0400 Subject: Java Bytecode assembler Message-ID: <53BEAEC5.5060207@LGonQn.Org> Hi I am looking for the tool that is used to "assemble" .jasm files. Is it available and where would I find it if so ? Chris PS Mentioned here : http://openjdk.java.net/groups/conformance/docs/JCK6bUsersGuide/html/p10.html For runtime tests, the source field contains the names of the files previously compiled to create the test's class files. Precompiled class files are included with the JCK. Source files are included for reference only. Source files are often .java files, but can also be .jasm or .jcod files. * .jasmis a low level bytecode assembler designed to assemble class files containing sets of bytecodes that are unusual or invalid for use in runtime tests * .jcod is a class level assembler designed to build classes with unusual or invalid structure for use in runtime tests These tools are used to generate class files that cannot be reliably generated by a Java compiler. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Thu Jul 10 15:35:53 2014 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 10 Jul 2014 08:35:53 -0700 Subject: Java Bytecode assembler In-Reply-To: <53BEAEC5.5060207@LGonQn.Org> References: <53BEAEC5.5060207@LGonQn.Org> Message-ID: <53BEB2D9.2090806@oracle.com> Chris, Regrettably, the tools are not yet generally available. -- Jon On 07/10/2014 08:18 AM, Chris Phillips @ T O wrote: > Hi > I am looking for the tool that is used to "assemble" .jasm files. Is > it available and where would > I find it if so ? > > Chris > PS > Mentioned here : > > http://openjdk.java.net/groups/conformance/docs/JCK6bUsersGuide/html/p10.html > > > For runtime tests, the source field contains the names of the files > previously compiled to create the test's class files. Precompiled > class files are included with the JCK. Source files are included for > reference only. Source files are often .java files, but can also be > .jasm or .jcod files. > > * > > .jasmis a low level bytecode assembler designed to assemble class > files containing sets of bytecodes that are unusual or invalid for > use in runtime tests > > * > > .jcod is a class level assembler designed to build classes with > unusual or invalid structure for use in runtime tests > > These tools are used to generate class files that cannot be reliably > generated by a Java compiler. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From forax at univ-mlv.fr Sun Jul 13 12:15:38 2014 From: forax at univ-mlv.fr (Remi Forax) Date: Sun, 13 Jul 2014 14:15:38 +0200 Subject: Serializable lambda and bytecode rewriters Message-ID: <53C2786A.5080609@univ-mlv.fr> Hi guys, there is, i think, a serious issue in the way the deserialization of lambda is done by javac (or ecj which uses the same scheme), exactly in the code of the generated method $deserializeLambda$. Bytecode rewriting tools like jarjar or proguard works by rewriting all reference to types in class files so they need to distinguish if a reference is let say a String of a method descriptor. The actual code of $deserializeLambda$ generated by javac breaks that assumption, all parameters of a deserialized lambda are checked as String thus are not rewritten correctly by the bytecode rewriters. So currently, it's no possible to use a bytecode rewriting tools with the jdk8 if there is a serializable lambda somewhere in the code. My bad on that, I should have figure out that before the release of 8. To fix this issue, the parameters that reference a lambda inside $deserializeLambda$ should be typed as constant method handles and constant method types but given that the serializable form a lambda is a bunch of strings, doing the mapping between the two forms is not that obvious. Moreover, there is maybe a performance problem because - the switch on the String that represent the name of the implementation method can not be used because it encodes the hashCode of a name that should be rewritten by the static tools. - constant method handles and constant method types are not required to be interned by the VM thus may be re-created each time $deserializeLambda$ is called if the code use ldc. The invokedynamic evangelist in me think that $deserializeLambda$ can be implemented as a unique invokedynamic call taking a SerializedLambda as parameter with all the parameters of all the serializable lambdas declared in the current class as bootstrap arguments. The bootstrap method will create a HashMap of a all methods names, and at runtime check if a serialized lambda is valid or not. Something like: static class LambdaParameters { ... public boolean verify(SerializedLambda serializedLambda) { // check all parameters } } public static CallSite deserializeLambda(Lookup lookup, String name, MethodType type, Object[] lambdaParameters) { HashMap map = new HashMap<>(); for(int i=0; i < lambdaParameters.length; i+=3) { ... MethodHandle mh = (MethodHandle) lambdaParameters[i + 1]; String name = lookup.revealDirect(mh).getName(); ... map.put(name, new LambdaParameters(...)); } return new ConstantCallSite(CHECK.bindTo(map)); } private static final MethodHandle = ::check; private static boolean check(HashMap map, SerializedLambda serializedLambda) { LambdaParameters parameters = map.get(serializedLambda.getImplMethodName()); return parameters != null && parameters.verify(serializedLambda); } A bootstrap method can not have more than 252 arguments, so you can not encode more than 84 (252 / 3) serializable lambdas, but I think that current scheme because it generated a lot of bytecodes will hit the 65 535 bytecodes near that number too. Anyway, if there is more than 84 serializable lambdas, $deserializableLambda$ can call more than one invokedynamic in chain. As you can see, the solution seems complex but may be somebody has a better solution :) regards, R?mi From otaviopolianasantana at gmail.com Fri Jul 11 01:36:03 2014 From: otaviopolianasantana at gmail.com (=?UTF-8?Q?Ot=C3=A1vio_Gon=C3=A7alves_de_Santana?=) Date: Thu, 10 Jul 2014 22:36:03 -0300 Subject: RFR: 8049892: Replace uses of 'new Integer()' with appropriate alternative across core classes Message-ID: https://bugs.openjdk.java.net/browse/JDK-8049892 http://cr.openjdk.java.net/~prr/8049892/ -- Cheers!. Ot?vio Gon?alves de Santana blog: http://otaviosantana.blogspot.com.br/ twitter: http://twitter.com/otaviojava site: *http://about.me/otaviojava * 55 (11) 98255-3513 -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrej.golovnin at gmail.com Fri Jul 11 06:41:14 2014 From: andrej.golovnin at gmail.com (Andrej Golovnin) Date: Fri, 11 Jul 2014 08:41:14 +0200 Subject: RFR: 8049892: Replace uses of 'new Integer()' with appropriate alternative across core classes In-Reply-To: References: Message-ID: Hi Ot?vio, changes to the classes in the package "jdk.internal.org.objectweb.asm" should be done directly in the ASM library. Please exclude following classes from the patch: src/share/classes/jdk/internal/org/objectweb/asm/ClassReader.java src/share/classes/jdk/internal/org/objectweb/asm/Opcodes.java src/share/classes/jdk/internal/org/objectweb/asm/commons/GeneratorAdapter.java src/share/classes/jdk/internal/org/objectweb/asm/commons/InstructionAdapter.java src/share/classes/jdk/internal/org/objectweb/asm/tree/LookupSwitchInsnNode.java src/share/classes/jdk/internal/org/objectweb/asm/util/CheckMethodAdapter.java src/share/classes/jdk/internal/org/objectweb/asm/util/Textifier.java And please exclude following classes from the patch too: src/share/classes/sun/reflect/UnsafeIntegerFieldAccessorImpl.java src/share/classes/sun/reflect/UnsafeQualifiedIntegerFieldAccessorImpl.java src/share/classes/sun/reflect/UnsafeQualifiedStaticIntegerFieldAccessorImpl.java src/share/classes/sun/reflect/UnsafeStaticIntegerFieldAccessorImpl.java This classes will be fixed by the patch for the issue 5043030. Otherwise it looks good. Best regards, Andrej Golovnin On Fri, Jul 11, 2014 at 3:36 AM, Ot?vio Gon?alves de Santana < otaviopolianasantana at gmail.com> wrote: > https://bugs.openjdk.java.net/browse/JDK-8049892 > http://cr.openjdk.java.net/~prr/8049892/ > > -- > Cheers!. > > Ot?vio Gon?alves de Santana > > blog: http://otaviosantana.blogspot.com.br/ > twitter: http://twitter.com/otaviojava > site: *http://about.me/otaviojava * > 55 (11) 98255-3513 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wieland at testingtech.com Mon Jul 14 20:10:27 2014 From: wieland at testingtech.com (Jacob Wieland) Date: Mon, 14 Jul 2014 22:10:27 +0200 Subject: Javac performance degradation of JDK 7 vs. 6 Message-ID: Hello folks, Some time ago, I have raised the issue https://bugs.openjdk.java.net/browse/JDK-8039262 and now have been referred to you gentle people in the hope that someone might have some ideas and the time and energy to resolve it. It is about a serious javac performance degradation in the 64 bit version of Java 7 (and higher) in comparison to the 64 bit version of Java 6. If annotation processing is not specifically turned off (which helps somewhat, even though performance is still 10% or so worse than for Java 6), the same java code very often takes several minutes instead of 40 to 50 seconds to compile. Also, it uses much more CPU (all 4 cores of my computer seem to be fully busy) and memory in the process. My guess is that there is some paralellization optimization going on that in our case is a pessimization, probably involving garbage collection (as that is where the compiler seems to be spending its time mainly, regardless how much memory I throw at it (more memory actually seems to make it worse) if looking at -verbose:gc is to be believed. Also, there seems to be a serious problem regarding source-file-lookup in large packages (containing thousands of source files). If there are any further questions that are not covered by the bug in the mentioned link, I'm happy to answer them. Thanks for your help, Jacob -- -- ------------------------------ ------------------------------------------- Dr. Jacob Wieland Senior Software Engineer Testing Technologies IST GmbH Michaelkirchstra?e 17/18 10179 Berlin, Germany Phone +49 30 726 19 19 34 Email wieland at testingtech.com Fax +49 30 726 19 19 20 Internet www.testingtech.com --------------------------------------------------------------------------------------------------------------- ----------------------------------------------------------------------------------------------------------------- UPCOMING EVENTS Sep 7-11, 2014 | World Congress on Intelligent Transport Systems Detroit, Michigan, USA www.itsworldcongress.org/ Sep 16-18, 2014 | User Conference on Advanced Automated Testing Munich, Germany www.ucaat.etsi.org/2014/index.html Sep 23-25, 2014 | Accredited TTCN-3 Training Berlin, Germany www.testingtech.com/services/ttcn3_training.php ----------------------------------------------------------------------------------------------------------------- Gesch?ftsf?hrung: Theofanis Vassiliou-Gioles, Stephan Pietsch, Pete Nicholson Handelsregister HRB 77805 B, Amtsgericht Charlottenburg Ust ID Nr.: DE 813 143 070 This Email may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply Email and delete all copies of this message. -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe.darcy at oracle.com Tue Jul 15 18:09:34 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 15 Jul 2014 11:09:34 -0700 Subject: JDK 9 RFR of 8050430: Provided new utility visitors supporting SourceVersion.RELEASE_9 Message-ID: <53C56E5E.2030002@oracle.com> Hello, Please review my changes for 8050430: Provided new utility visitors supporting SourceVersion.RELEASE_9 http://cr.openjdk.java.net/~darcy/8050430.0/ A few items of note: * As proposed, this change deprecates all the FooVisitor6 classes. This is meant to be consistent with making -source/-target 6 obsolete in javac in JDK 9. * A few @SupportedSourceVersion annotations missed in earlier releases have been added Otherwise, as of today, the FooVisitor9 classes are straightforward extensions of existing classes. I went through the langtools src and test directories and updated existing visitor usages as appropriate. A few more tests were added to the JavacTestingAbstractProcessor fold or were updated to use the facilities of JavacTestingAbstractProcessor more effectively, such as by subclassing the latest-version utility visitors in that class. Thanks, -Joe From jonathan.gibbons at oracle.com Tue Jul 15 18:12:49 2014 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 15 Jul 2014 11:12:49 -0700 Subject: JDK 9 RFR of 8050430: Provided new utility visitors supporting SourceVersion.RELEASE_9 In-Reply-To: <53C56E5E.2030002@oracle.com> References: <53C56E5E.2030002@oracle.com> Message-ID: <53C56F21.5060104@oracle.com> Looks good to me. -- Jon On 07/15/2014 11:09 AM, Joe Darcy wrote: > Hello, > > Please review my changes for > > 8050430: Provided new utility visitors supporting > SourceVersion.RELEASE_9 > http://cr.openjdk.java.net/~darcy/8050430.0/ > > A few items of note: > > * As proposed, this change deprecates all the FooVisitor6 classes. > This is meant to be consistent with making -source/-target 6 obsolete > in javac in JDK 9. > > * A few @SupportedSourceVersion annotations missed in earlier releases > have been added > > Otherwise, as of today, the FooVisitor9 classes are straightforward > extensions of existing classes. I went through the langtools src and > test directories and updated existing visitor usages as appropriate. A > few more tests were added to the JavacTestingAbstractProcessor fold or > were updated to use the facilities of JavacTestingAbstractProcessor > more effectively, such as by subclassing the latest-version utility > visitors in that class. > > Thanks, > > -Joe From jan.lahoda at oracle.com Wed Jul 16 13:54:25 2014 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Wed, 16 Jul 2014 15:54:25 +0200 Subject: Javac performance degradation of JDK 7 vs. 6 In-Reply-To: References: Message-ID: <53C68411.4000209@oracle.com> Hello Jacob, I am looking at the issue a little bit. This will probably need a deeper investigation, but there indeed seems to be a considerable difference in compilation times of the testcase between JDK 6 64bit and JDK 7 64 bit when the annotation processing is enabled, even if given enough heap size. I am not yet clear on what is the cause. Thanks, Jan On 14.7.2014 22:10, Jacob Wieland wrote: > Hello folks, > > Some time ago, I have raised the issue > https://bugs.openjdk.java.net/browse/JDK-8039262 and now have been > referred to you > gentle people in the hope that someone might have some ideas and the > time and energy to resolve it. > > It is about a serious javac performance degradation in the 64 bit > version of Java 7 (and higher) in comparison to the 64 bit version > of Java 6. If annotation processing is not specifically turned off > (which helps somewhat, even though performance is still 10% or so worse > than for Java 6), the same java code very often takes several minutes > instead of 40 to 50 seconds to compile. Also, it uses much more CPU (all > 4 cores of my computer seem to be fully busy) and memory in the process. > My guess is that there is some paralellization optimization going on > that in our case is a pessimization, probably involving garbage > collection (as that is where the compiler seems to be spending its time > mainly, regardless how much memory I throw at it (more memory actually > seems to make it worse) if looking at -verbose:gc is to be believed. > > Also, there seems to be a serious problem regarding source-file-lookup > in large packages (containing thousands of source files). > > If there are any further questions that are not covered by the bug in > the mentioned link, I'm happy to answer them. > > Thanks for your help, > > Jacob > > -- > -- > ------------------------------ > ------------------------------------------- > Dr. Jacob Wieland > Senior Software Engineer > > Testing Technologies IST GmbH > Michaelkirchstra?e 17/18 > 10179 Berlin, Germany > > Phone +49 30 726 19 19 34 Email wieland at testingtech.com > > Fax +49 30 726 19 19 20 Internet www.testingtech.com > > --------------------------------------------------------------------------------------------------------------- > > ----------------------------------------------------------------------------------------------------------------- > > UPCOMING EVENTS > > Sep 7-11, 2014 | World Congress on Intelligent Transport Systems > > Detroit, Michigan, USA > > www.itsworldcongress.org/ > > > Sep 16-18, 2014 | User Conference on Advanced Automated Testing > > Munich, Germany > > www.ucaat.etsi.org/2014/index.html > > > > Sep 23-25, 2014 | Accredited TTCN-3 Training > > Berlin, Germany > > www.testingtech.com/services/ttcn3_training.php > > > > ----------------------------------------------------------------------------------------------------------------- > > Gesch?ftsf?hrung: Theofanis Vassiliou-Gioles, Stephan Pietsch, Pete > Nicholson > Handelsregister HRB 77805 B, Amtsgericht Charlottenburg > Ust ID Nr.: DE 813 143 070 > > This Email may contain confidential and privileged material for the sole > use of the intended recipient. Any review, use, distribution or > disclosure by others is strictly prohibited. If you are not the intended > recipient (or authorized to receive for the recipient), please contact > the sender by reply Email and delete all copies of this message. From joe.darcy at oracle.com Mon Jul 21 19:25:36 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Mon, 21 Jul 2014 12:25:36 -0700 Subject: JDK 9 RFR of JDK-8051482: Fix deprecation warnings in javax.lang.model.util Message-ID: <53CD6930.3030402@oracle.com> Hello, Please review the fix below for JDK-8051482: Fix deprecation warnings in javax.lang.model.util In brief, when the 9-era visitors were recently added under 8050430: Provided new utility visitors supporting SourceVersion.RELEASE_9, the 6-era visitors were deprecated. This caused the 7-era visitors which extend the 6-era visitors to suffer spurious deprecation warnings when compiled. (The langtools build uses -Xlint:all so I thought any new deprecation warnings would be caught there, but IIRC javax.lang.model.* is compiled as part of the core libs as it ends up on rt.jar.) Thanks, -Joe diff -r bfed975590b9 src/share/classes/javax/lang/model/util/AbstractAnnotationValueVisitor7.java --- a/src/share/classes/javax/lang/model/util/AbstractAnnotationValueVisitor7.java Thu Jul 17 16:46:29 2014 -0700 +++ b/src/share/classes/javax/lang/model/util/AbstractAnnotationValueVisitor7.java Mon Jul 21 12:22:47 2014 -0700 @@ -68,6 +68,7 @@ * @see AbstractAnnotationValueVisitor9 * @since 1.7 */ + at SuppressWarnings("deprecation") // Superclass deprecated @SupportedSourceVersion(RELEASE_7) public abstract class AbstractAnnotationValueVisitor7 extends AbstractAnnotationValueVisitor6 { diff -r bfed975590b9 src/share/classes/javax/lang/model/util/AbstractElementVisitor7.java --- a/src/share/classes/javax/lang/model/util/AbstractElementVisitor7.java Thu Jul 17 16:46:29 2014 -0700 +++ b/src/share/classes/javax/lang/model/util/AbstractElementVisitor7.java Mon Jul 21 12:22:47 2014 -0700 @@ -72,6 +72,7 @@ * @see AbstractElementVisitor9 * @since 1.7 */ + at SuppressWarnings("deprecation") // Superclass deprecated @SupportedSourceVersion(RELEASE_7) public abstract class AbstractElementVisitor7 extends AbstractElementVisitor6 { /** diff -r bfed975590b9 src/share/classes/javax/lang/model/util/AbstractTypeVisitor7.java --- a/src/share/classes/javax/lang/model/util/AbstractTypeVisitor7.java Thu Jul 17 16:46:29 2014 -0700 +++ b/src/share/classes/javax/lang/model/util/AbstractTypeVisitor7.java Mon Jul 21 12:22:47 2014 -0700 @@ -72,6 +72,7 @@ * @see AbstractTypeVisitor9 * @since 1.7 */ + at SuppressWarnings("deprecation") // Superclass deprecated @SupportedSourceVersion(RELEASE_7) public abstract class AbstractTypeVisitor7 extends AbstractTypeVisitor6 { /** diff -r bfed975590b9 src/share/classes/javax/lang/model/util/ElementKindVisitor7.java --- a/src/share/classes/javax/lang/model/util/ElementKindVisitor7.java Thu Jul 17 16:46:29 2014 -0700 +++ b/src/share/classes/javax/lang/model/util/ElementKindVisitor7.java Mon Jul 21 12:22:47 2014 -0700 @@ -85,6 +85,7 @@ * @see ElementKindVisitor9 * @since 1.7 */ + at SuppressWarnings("deprecation") // Superclass deprecated @SupportedSourceVersion(RELEASE_7) public class ElementKindVisitor7 extends ElementKindVisitor6 { /** diff -r bfed975590b9 src/share/classes/javax/lang/model/util/ElementScanner7.java --- a/src/share/classes/javax/lang/model/util/ElementScanner7.java Thu Jul 17 16:46:29 2014 -0700 +++ b/src/share/classes/javax/lang/model/util/ElementScanner7.java Mon Jul 21 12:22:47 2014 -0700 @@ -89,6 +89,7 @@ * @see ElementScanner9 * @since 1.7 */ + at SuppressWarnings("deprecation") // Superclass deprecated @SupportedSourceVersion(RELEASE_7) public class ElementScanner7 extends ElementScanner6 { /** diff -r bfed975590b9 src/share/classes/javax/lang/model/util/SimpleAnnotationValueVisitor7.java --- a/src/share/classes/javax/lang/model/util/SimpleAnnotationValueVisitor7.java Thu Jul 17 16:46:29 2014 -0700 +++ b/src/share/classes/javax/lang/model/util/SimpleAnnotationValueVisitor7.java Mon Jul 21 12:22:47 2014 -0700 @@ -75,6 +75,7 @@ * @see SimpleAnnotationValueVisitor9 * @since 1.7 */ + at SuppressWarnings("deprecation") // Superclass deprecated @SupportedSourceVersion(RELEASE_7) public class SimpleAnnotationValueVisitor7 extends SimpleAnnotationValueVisitor6 { /** diff -r bfed975590b9 src/share/classes/javax/lang/model/util/SimpleElementVisitor7.java --- a/src/share/classes/javax/lang/model/util/SimpleElementVisitor7.java Thu Jul 17 16:46:29 2014 -0700 +++ b/src/share/classes/javax/lang/model/util/SimpleElementVisitor7.java Mon Jul 21 12:22:47 2014 -0700 @@ -81,6 +81,7 @@ * @see SimpleElementVisitor9 * @since 1.7 */ + at SuppressWarnings("deprecation") // Superclass deprecated @SupportedSourceVersion(RELEASE_7) public class SimpleElementVisitor7 extends SimpleElementVisitor6 { /** diff -r bfed975590b9 src/share/classes/javax/lang/model/util/SimpleTypeVisitor7.java --- a/src/share/classes/javax/lang/model/util/SimpleTypeVisitor7.java Thu Jul 17 16:46:29 2014 -0700 +++ b/src/share/classes/javax/lang/model/util/SimpleTypeVisitor7.java Mon Jul 21 12:22:47 2014 -0700 @@ -81,6 +81,7 @@ * @see SimpleTypeVisitor9 * @since 1.7 */ + at SuppressWarnings("deprecation") // Superclass deprecated @SupportedSourceVersion(RELEASE_7) public class SimpleTypeVisitor7 extends SimpleTypeVisitor6 { /** diff -r bfed975590b9 src/share/classes/javax/lang/model/util/TypeKindVisitor7.java --- a/src/share/classes/javax/lang/model/util/TypeKindVisitor7.java Thu Jul 17 16:46:29 2014 -0700 +++ b/src/share/classes/javax/lang/model/util/TypeKindVisitor7.java Mon Jul 21 12:22:47 2014 -0700 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2010, 2013, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2010, 2014, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -82,6 +82,7 @@ * @see TypeKindVisitor8 * @since 1.7 */ + at SuppressWarnings("deprecation") // Superclass deprecated @SupportedSourceVersion(RELEASE_7) public class TypeKindVisitor7 extends TypeKindVisitor6 { /** From kumar.x.srinivasan at oracle.com Mon Jul 21 22:24:32 2014 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Mon, 21 Jul 2014 15:24:32 -0700 Subject: JDK 9 RFR of JDK-8051482: Fix deprecation warnings in javax.lang.model.util In-Reply-To: <53CD6930.3030402@oracle.com> References: <53CD6930.3030402@oracle.com> Message-ID: <53CD9320.4010309@oracle.com> Hi Joe, The changes look fine, I ran into this problem while I was experimenting with javax.lang.model. Thanks Kumar On 7/21/2014 12:25 PM, Joe Darcy wrote: > Hello, > > Please review the fix below for > > JDK-8051482: Fix deprecation warnings in javax.lang.model.util > > In brief, when the 9-era visitors were recently added under 8050430: > Provided new utility visitors supporting SourceVersion.RELEASE_9, the > 6-era visitors were deprecated. This caused the 7-era visitors which > extend the 6-era visitors to suffer spurious deprecation warnings when > compiled. (The langtools build uses -Xlint:all so I thought any new > deprecation warnings would be caught there, but IIRC > javax.lang.model.* is compiled as part of the core libs as it ends up > on rt.jar.) > > Thanks, > > -Joe > > diff -r bfed975590b9 > src/share/classes/javax/lang/model/util/AbstractAnnotationValueVisitor7.java > --- > a/src/share/classes/javax/lang/model/util/AbstractAnnotationValueVisitor7.java > Thu Jul 17 16:46:29 2014 -0700 > +++ > b/src/share/classes/javax/lang/model/util/AbstractAnnotationValueVisitor7.java > Mon Jul 21 12:22:47 2014 -0700 > @@ -68,6 +68,7 @@ > * @see AbstractAnnotationValueVisitor9 > * @since 1.7 > */ > + at SuppressWarnings("deprecation") // Superclass deprecated > @SupportedSourceVersion(RELEASE_7) > public abstract class AbstractAnnotationValueVisitor7 extends > AbstractAnnotationValueVisitor6 { > > diff -r bfed975590b9 > src/share/classes/javax/lang/model/util/AbstractElementVisitor7.java > --- > a/src/share/classes/javax/lang/model/util/AbstractElementVisitor7.java > Thu Jul 17 16:46:29 2014 -0700 > +++ > b/src/share/classes/javax/lang/model/util/AbstractElementVisitor7.java > Mon Jul 21 12:22:47 2014 -0700 > @@ -72,6 +72,7 @@ > * @see AbstractElementVisitor9 > * @since 1.7 > */ > + at SuppressWarnings("deprecation") // Superclass deprecated > @SupportedSourceVersion(RELEASE_7) > public abstract class AbstractElementVisitor7 extends > AbstractElementVisitor6 { > /** > diff -r bfed975590b9 > src/share/classes/javax/lang/model/util/AbstractTypeVisitor7.java > --- > a/src/share/classes/javax/lang/model/util/AbstractTypeVisitor7.java > Thu Jul 17 16:46:29 2014 -0700 > +++ > b/src/share/classes/javax/lang/model/util/AbstractTypeVisitor7.java > Mon Jul 21 12:22:47 2014 -0700 > @@ -72,6 +72,7 @@ > * @see AbstractTypeVisitor9 > * @since 1.7 > */ > + at SuppressWarnings("deprecation") // Superclass deprecated > @SupportedSourceVersion(RELEASE_7) > public abstract class AbstractTypeVisitor7 extends > AbstractTypeVisitor6 { > /** > diff -r bfed975590b9 > src/share/classes/javax/lang/model/util/ElementKindVisitor7.java > --- a/src/share/classes/javax/lang/model/util/ElementKindVisitor7.java > Thu Jul 17 16:46:29 2014 -0700 > +++ b/src/share/classes/javax/lang/model/util/ElementKindVisitor7.java > Mon Jul 21 12:22:47 2014 -0700 > @@ -85,6 +85,7 @@ > * @see ElementKindVisitor9 > * @since 1.7 > */ > + at SuppressWarnings("deprecation") // Superclass deprecated > @SupportedSourceVersion(RELEASE_7) > public class ElementKindVisitor7 extends ElementKindVisitor6 P> { > /** > diff -r bfed975590b9 > src/share/classes/javax/lang/model/util/ElementScanner7.java > --- a/src/share/classes/javax/lang/model/util/ElementScanner7.java Thu > Jul 17 16:46:29 2014 -0700 > +++ b/src/share/classes/javax/lang/model/util/ElementScanner7.java Mon > Jul 21 12:22:47 2014 -0700 > @@ -89,6 +89,7 @@ > * @see ElementScanner9 > * @since 1.7 > */ > + at SuppressWarnings("deprecation") // Superclass deprecated > @SupportedSourceVersion(RELEASE_7) > public class ElementScanner7 extends ElementScanner6 { > /** > diff -r bfed975590b9 > src/share/classes/javax/lang/model/util/SimpleAnnotationValueVisitor7.java > --- > a/src/share/classes/javax/lang/model/util/SimpleAnnotationValueVisitor7.java > Thu Jul 17 16:46:29 2014 -0700 > +++ > b/src/share/classes/javax/lang/model/util/SimpleAnnotationValueVisitor7.java > Mon Jul 21 12:22:47 2014 -0700 > @@ -75,6 +75,7 @@ > * @see SimpleAnnotationValueVisitor9 > * @since 1.7 > */ > + at SuppressWarnings("deprecation") // Superclass deprecated > @SupportedSourceVersion(RELEASE_7) > public class SimpleAnnotationValueVisitor7 extends > SimpleAnnotationValueVisitor6 { > /** > diff -r bfed975590b9 > src/share/classes/javax/lang/model/util/SimpleElementVisitor7.java > --- > a/src/share/classes/javax/lang/model/util/SimpleElementVisitor7.java > Thu Jul 17 16:46:29 2014 -0700 > +++ > b/src/share/classes/javax/lang/model/util/SimpleElementVisitor7.java > Mon Jul 21 12:22:47 2014 -0700 > @@ -81,6 +81,7 @@ > * @see SimpleElementVisitor9 > * @since 1.7 > */ > + at SuppressWarnings("deprecation") // Superclass deprecated > @SupportedSourceVersion(RELEASE_7) > public class SimpleElementVisitor7 extends > SimpleElementVisitor6 { > /** > diff -r bfed975590b9 > src/share/classes/javax/lang/model/util/SimpleTypeVisitor7.java > --- a/src/share/classes/javax/lang/model/util/SimpleTypeVisitor7.java > Thu Jul 17 16:46:29 2014 -0700 > +++ b/src/share/classes/javax/lang/model/util/SimpleTypeVisitor7.java > Mon Jul 21 12:22:47 2014 -0700 > @@ -81,6 +81,7 @@ > * @see SimpleTypeVisitor9 > * @since 1.7 > */ > + at SuppressWarnings("deprecation") // Superclass deprecated > @SupportedSourceVersion(RELEASE_7) > public class SimpleTypeVisitor7 extends SimpleTypeVisitor6 { > /** > diff -r bfed975590b9 > src/share/classes/javax/lang/model/util/TypeKindVisitor7.java > --- a/src/share/classes/javax/lang/model/util/TypeKindVisitor7.java > Thu Jul 17 16:46:29 2014 -0700 > +++ b/src/share/classes/javax/lang/model/util/TypeKindVisitor7.java > Mon Jul 21 12:22:47 2014 -0700 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2010, 2013, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 2010, 2014, Oracle and/or its affiliates. All rights > reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -82,6 +82,7 @@ > * @see TypeKindVisitor8 > * @since 1.7 > */ > + at SuppressWarnings("deprecation") // Superclass deprecated > @SupportedSourceVersion(RELEASE_7) > public class TypeKindVisitor7 extends TypeKindVisitor6 { > /** > From mark.reinhold at oracle.com Mon Jul 28 21:27:36 2014 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Mon, 28 Jul 2014 14:27:36 -0700 (PDT) Subject: JEP 199: Smart Java Compilation, Phase Two Message-ID: <20140728212736.33CFD31A03@eggemoggin.niobe.net> New JEP Candidate: http://openjdk.java.net/jeps/199 - Mark From alex.buckley at oracle.com Thu Jul 31 22:33:14 2014 From: alex.buckley at oracle.com (Alex Buckley) Date: Thu, 31 Jul 2014 15:33:14 -0700 Subject: Spec mailing lists Message-ID: <53DAC42A.4050205@oracle.com> Jon, Readers of The Java Language Specification and The JVM Specification can presently send feedback about errors, omissions, and ambiguities in each spec to jls-comments_ww at oracle.com and jvms-comments_ww at oracle.com. While this is a useful alternative to filing spec bugs at bugs.java.com, it is still rather unsatisfactory because the addresses go to private mailboxes. This makes it difficult for engineers to discuss the feedback, and there is no public archive. I would like to request that the Compiler Group sponsors a mailing list: jls-jvms-spec-comments at openjdk.java.net where anyone can send feedback about either spec, and where Oracle engineers who maintain the specs can discuss the best course of action. Some particulars: 1. Anyone can post to the list without subscribing. All posts will be held for moderation. An on-topic post might, say, claim that a rule in the JLS performs an incomplete case analysis, or note a problem with the files at http://docs.oracle.com/javase/specs/. An off-topic post, such as a proposal for a new Java language feature, would be discarded. 2. The initial subscribers will be myself and Dan Smith. Where we use the list to discuss a piece of feedback, we will cc the original poster. 3. The list will be licensed under comment-and-evaluation terms, and publicly archived at http://mail.openjdk.java.net/mailman/listinfo. 4. The list is preferred to various JSR lists that were used to specify Java SE 8 and are still occasionally used to raise spec issues (eventually they will be disabled) : lambda-spec-{experts,observers,comments} type-annotations-spec-{experts,observers,comments} enhanced-metadata-spec-discuss Alex From wieland at testingtech.com Thu Jul 17 06:55:58 2014 From: wieland at testingtech.com (Jacob Wieland) Date: Thu, 17 Jul 2014 06:55:58 -0000 Subject: Javac performance degradation of JDK 7 vs. 6 In-Reply-To: <53C68411.4000209@oracle.com> References: <53C68411.4000209@oracle.com> Message-ID: Thank you for investigating. I'm glad that it can be reproduced and does not only happen to me. I'm sure that a fix for this will greatly benefit everyone. BR, Jacob 2014-07-16 15:54 GMT+02:00 Jan Lahoda : > Hello Jacob, > > I am looking at the issue a little bit. This will probably need a deeper > investigation, but there indeed seems to be a considerable difference in > compilation times of the testcase between JDK 6 64bit and JDK 7 64 bit when > the annotation processing is enabled, even if given enough heap size. I am > not yet clear on what is the cause. > > Thanks, > Jan > > > On 14.7.2014 22:10, Jacob Wieland wrote: > >> Hello folks, >> >> Some time ago, I have raised the issue >> https://bugs.openjdk.java.net/browse/JDK-8039262 and now have been >> referred to you >> gentle people in the hope that someone might have some ideas and the >> time and energy to resolve it. >> >> It is about a serious javac performance degradation in the 64 bit >> version of Java 7 (and higher) in comparison to the 64 bit version >> of Java 6. If annotation processing is not specifically turned off >> (which helps somewhat, even though performance is still 10% or so worse >> than for Java 6), the same java code very often takes several minutes >> instead of 40 to 50 seconds to compile. Also, it uses much more CPU (all >> 4 cores of my computer seem to be fully busy) and memory in the process. >> My guess is that there is some paralellization optimization going on >> that in our case is a pessimization, probably involving garbage >> collection (as that is where the compiler seems to be spending its time >> mainly, regardless how much memory I throw at it (more memory actually >> seems to make it worse) if looking at -verbose:gc is to be believed. >> >> Also, there seems to be a serious problem regarding source-file-lookup >> in large packages (containing thousands of source files). >> >> If there are any further questions that are not covered by the bug in >> the mentioned link, I'm happy to answer them. >> >> Thanks for your help, >> >> Jacob >> >> -- >> -- >> ------------------------------ >> ------------------------------------------- >> Dr. Jacob Wieland >> Senior Software Engineer >> >> Testing Technologies IST GmbH >> Michaelkirchstra?e 17/18 >> 10179 Berlin, Germany >> >> Phone +49 30 726 19 19 34 Email wieland at testingtech.com >> >> >> Fax +49 30 726 19 19 20 Internet www.testingtech.com >> >> >> ------------------------------------------------------------ >> --------------------------------------------------- >> >> ------------------------------------------------------------ >> ----------------------------------------------------- >> >> UPCOMING EVENTS >> >> Sep 7-11, 2014 | World Congress on Intelligent Transport Systems >> >> Detroit, Michigan, USA >> >> www.itsworldcongress.org/ >> >> >> >> Sep 16-18, 2014 | User Conference on Advanced Automated Testing >> >> Munich, Germany >> >> www.ucaat.etsi.org/2014/index.html >> >> >> >> >> Sep 23-25, 2014 | Accredited TTCN-3 Training >> >> Berlin, Germany >> >> www.testingtech.com/services/ttcn3_training.php >> >> >> >> >> ------------------------------------------------------------ >> ----------------------------------------------------- >> >> Gesch?ftsf?hrung: Theofanis Vassiliou-Gioles, Stephan Pietsch, Pete >> Nicholson >> Handelsregister HRB 77805 B, Amtsgericht Charlottenburg >> Ust ID Nr.: DE 813 143 070 >> >> This Email may contain confidential and privileged material for the sole >> use of the intended recipient. Any review, use, distribution or >> disclosure by others is strictly prohibited. If you are not the intended >> recipient (or authorized to receive for the recipient), please contact >> the sender by reply Email and delete all copies of this message. >> > -- -- ------------------------------ ------------------------------------------- Dr. Jacob Wieland Senior Software Engineer Testing Technologies IST GmbH Michaelkirchstra?e 17/18 10179 Berlin, Germany Phone +49 30 726 19 19 34 Email wieland at testingtech.com Fax +49 30 726 19 19 20 Internet www.testingtech.com --------------------------------------------------------------------------------------------------------------- ----------------------------------------------------------------------------------------------------------------- UPCOMING EVENTS Sep 7-11, 2014 | World Congress on Intelligent Transport Systems Detroit, Michigan, USA www.itsworldcongress.org/ Sep 16-18, 2014 | User Conference on Advanced Automated Testing Munich, Germany www.ucaat.etsi.org/2014/index.html Sep 23-25, 2014 | Accredited TTCN-3 Training Berlin, Germany www.testingtech.com/services/ttcn3_training.php ----------------------------------------------------------------------------------------------------------------- Gesch?ftsf?hrung: Theofanis Vassiliou-Gioles, Stephan Pietsch, Pete Nicholson Handelsregister HRB 77805 B, Amtsgericht Charlottenburg Ust ID Nr.: DE 813 143 070 This Email may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply Email and delete all copies of this message. -------------- next part -------------- An HTML attachment was scrubbed... URL: