August 2015 - core-libs-dev

How to write test requiring a specific locale?
by Weijun Wang 28 Aug '15

28 Aug '15

Hi All In https://bugs.openjdk.java.net/browse/JDK-8133910, the test tries to grep certain text from tool output, but when the default locale is not "en_US" it might fail. I don't want to rewrite the test to check localized text so there are only 2 ways: 1. Force the text to run with "en_US". In Unix, seems setting LANG or LC_ALL to "en_US.UTF-8" (these are script tests), but it does not work on Windows. I can only think of adding "-J-Duser.language=en -J-Duser.country=US" into TESTTOOLVMOPTS. 2. Ignore the text when locale is not en_US. The @requires tag does not support user.encoding. Shall I check $LANG or $LC_ALL? Should they contain "en_US" on most test machines? Or it's "C"? Thanks Max

1 0

@Finalized
by Doug Lea 26 Aug '15

26 Aug '15

In the course of JEP 188/193 related efforts, it has been pointed out a few times that, as part of these efforts, finally adding method reachabilityFence(ref) with tentative spec pasted below should be the first of two steps in helping developers avoid premature finalization and reclamation. The second part seems to escape scope of these JEPs: Supporting an annotation (most likely named @Finalized) that would enable tools and/or compilers to convert methods of classes in danger of premature finalization from { body } to try { body } finally { Reference.reachabilityFence(this); } And/or some variants, some of which were explored on the jmm-dev list mainly in August 2014 -- see archives at http://mail.openjdk.java.net/pipermail/jmm-dev/2014-August/thread.html This is an issue of large importance to a small audience, and is at the moment an orphan. To work out, I think it requires at least some involvement from compiler and/or IDE developers. If you are or know of someone who might be interested in pursuing, please encourage them/yourself to consider it. -Doug class java.lang.ref.Reference { // add: /** * Ensures that the object referenced by the given reference * remains <em>strongly reachable</em> (as defined in the {@link * java.lang.ref} package documentation), regardless of any prior * actions of the program that might otherwise cause the object to * become unreachable. A reachabilityFence for a given reference * happens before the referenced object is reclaimed by garbage * collection, finalized, or added to a java.lang.ref queue. * Invocation of this method does not itself initiate garbage * collection or finalization. * * @param ref the reference. If null, this method has no effect. */ public static void reachabilityFence(Object ref) {} }

4 4

Re: U60 change makes annotations visible in synthesized methods, causes CDI to see lambdas as observer methods
by arjan tijms 26 Aug '15

26 Aug '15

Hi, On Wed, Aug 26, 2015 at 4:28 PM, Remi Forax <remi.forax(a)u-pem.fr> wrote: > IMO, it seems to be a bug of the CDI implementation, > as you said the method corresponding to the lambda body is synthetized so it should be ignored by the CDI implementation, no ? Yes I agree that might be another possibility. I'll bring this to the attention of the CDI and/or Weld people as well. Still, it's a somewhat sudden change and there are many CDI implementations out there. > BTW, it's the wrong list, lambdas are delivered so you should have use core-lib-dev instead (in CC). core-lib-dev, hmm, who would have thought? But I'll keep it in mind for future messages. Thanks! Kind regards, Arjan Tijms > > cheers, > Rémi > > ----- Mail original ----- > De: "arjan tijms" <arjan.tijms(a)gmail.com> > À: lambda-dev(a)openjdk.java.net > Envoyé: Mercredi 26 Août 2015 16:04:22 > Objet: U60 change makes annotations visible in synthesized methods, causes CDI to see lambdas as observer methods > > Hi, > > I'm with the JSF EG/Mojarra team and we're seeing what looks like a > problematic regression in JDK8 u60. > > In a CDI extension we have the following observer method: > > public <T> void processBean(@Observes ProcessBean<T> event, > BeanManager beanManager) { > getAnnotation(beanManager, event.getAnnotated(), FacesDataModel.class) > .ifPresent(d -> > forClassToDataModelClass.put( > d.forClass(), > (Class<? extends DataModel<?>>) > event.getBean().getBeanClass() > ) > ); > } > > With u45 and below this will generate the following (decompiled the > class with javap -v -p -s -c) > > private void lambda$processBean$4(javax.enterprise.inject.spi.ProcessBean, > javax.faces.model.FacesDataModel); > descriptor: > (Ljavax/enterprise/inject/spi/ProcessBean;Ljavax/faces/model/FacesDataModel;)V > flags: ACC_PRIVATE, ACC_SYNTHETIC > Code: > stack=3, locals=3, args_size=3 > 0: aload_0 > 1: getfield #4 // Field > forClassToDataModelClass:Ljava/util/Map; > 4: aload_2 > 5: invokeinterface #57, 1 // InterfaceMethod > javax/faces/model/FacesDataModel.forClass:()Ljava/lang/Class; > 10: aload_1 > 11: invokeinterface #58, 1 // InterfaceMethod > javax/enterprise/inject/spi/ProcessBean.getBean:()Ljavax/enterprise/inject/spi/Bean; > 16: invokeinterface #59, 1 // InterfaceMethod > javax/enterprise/inject/spi/Bean.getBeanClass:()Ljava/lang/Class; > 21: invokeinterface #55, 3 // InterfaceMethod > java/util/Map.put:(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object; > 26: checkcast #45 // class java/lang/Class > 29: pop > 30: return > LineNumberTable: > line 110: 0 > line 111: 5 > line 112: 11 > line 110: 21 > LocalVariableTable: > Start Length Slot Name Signature > 0 31 0 this Lcom/sun/faces/cdi/CdiExtension; > 0 31 2 d Ljavax/faces/model/FacesDataModel; > > > U60 however generates the following: > > private void lambda$processBean$4(javax.enterprise.inject.spi.ProcessBean, > javax.faces.model.FacesDataModel); > descriptor: > (Ljavax/enterprise/inject/spi/ProcessBean;Ljavax/faces/model/FacesDataModel;)V > flags: ACC_PRIVATE, ACC_SYNTHETIC > Code: > stack=3, locals=3, args_size=3 > 0: aload_0 > 1: getfield #4 // Field > forClassToDataModelClass:Ljava/util/Map; > 4: aload_2 > 5: invokeinterface #57, 1 // InterfaceMethod > javax/faces/model/FacesDataModel.forClass:()Ljava/lang/Class; > 10: aload_1 > 11: invokeinterface #58, 1 // InterfaceMethod > javax/enterprise/inject/spi/ProcessBean.getBean:()Ljavax/enterprise/inject/spi/Bean; > 16: invokeinterface #59, 1 // InterfaceMethod > javax/enterprise/inject/spi/Bean.getBeanClass:()Ljava/lang/Class; > 21: invokeinterface #55, 3 // InterfaceMethod > java/util/Map.put:(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object; > 26: checkcast #45 // class java/lang/Class > 29: pop > 30: return > LineNumberTable: > line 110: 0 > line 111: 5 > line 112: 11 > line 110: 21 > LocalVariableTable: > Start Length Slot Name Signature > 0 31 0 this Lcom/sun/faces/cdi/CdiExtension; > 0 31 1 event Ljavax/enterprise/inject/spi/ProcessBean; > 0 31 2 d Ljavax/faces/model/FacesDataModel; > RuntimeVisibleParameterAnnotations: > parameter 0: > 0: #79() > parameter 1: > > The difference is that the parameter annotation is made visible for > this synthesized method. The result is that CDI subsequently scans > this class and sees the synthesized method for the lambda as an > observer method, which is of course not the intention. In this > particular case it will result in a definition error: > > "Error occurred during deployment: Exception while loading the app : > > CDI definition failure: > > WELD-000409: Observer method for container lifecycle event > [[BackedAnnotatedMethod] > > private com.sun.faces.cdi.CdiExtension.lambda$processBean$4(@Observes > ProcessBean<Object>, FacesDataModel)] can only inject BeanManager.." > > I think that if the synthesized method happened to be a correct > observer method, e.g. for a no-parameter lambda or one that happens to > have the BeanManager as its first and only parameter, then CDI would > silently start to call this method in response to events, which too is > highly undesirable. > > Kind regards, > Arjan Tijms >

2 1

jtreg test failure
by Maurizio Cimadamore 26 Aug '15

26 Aug '15

Hi, the test for: https://bugs.openjdk.java.net/browse/JDK-8134250 Which has been recently pushed is failing for me: java.lang.RuntimeException: FULL date format of Islamic Um-Alqura calendar in en_US is incorrect. Got: Tuesday 12 Safar 1400 AH, expected: Tuesday, Safar 12, 1400 AH at Bug8134250.main(Bug8134250.java:68) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:519) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:92) at java.lang.Thread.run(Thread.java:746) JavaTest Message: Test threw exception: java.lang.RuntimeException: FULL date format of Islamic Um-Alqura calendar in en_US is incorrect. Got: Tuesday 12 Safar 1400 AH, expected: Tuesday, Safar 12, 1400 AH JavaTest Message: shutting down test I couldn't find any related entries on JBS. Any thoughts? Maurizio

2 5

[9] RFR: 8134520: Bug8134250 test fails in en_IE locale
by Naoto Sato 26 Aug '15

26 Aug '15

Hello, Please review a simple fix for the following issue: https://bugs.openjdk.java.net/browse/JDK-8134520 The proposed change is located at: http://cr.openjdk.java.net/~naoto/8134520/webrev.00/ The fix is to simply set the en_US locale to the formatter. Naoto

2 1

Re: U60 change makes annotations visible in synthesized methods, causes CDI to see lambdas as observer methods
by Remi Forax 26 Aug '15

26 Aug '15

IMO, it seems to be a bug of the CDI implementation, as you said the method corresponding to the lambda body is synthetized so it should be ignored by the CDI implementation, no ? BTW, it's the wrong list, lambdas are delivered so you should have use core-lib-dev instead (in CC). cheers, Rémi ----- Mail original ----- De: "arjan tijms" <arjan.tijms(a)gmail.com> À: lambda-dev(a)openjdk.java.net Envoyé: Mercredi 26 Août 2015 16:04:22 Objet: U60 change makes annotations visible in synthesized methods, causes CDI to see lambdas as observer methods Hi, I'm with the JSF EG/Mojarra team and we're seeing what looks like a problematic regression in JDK8 u60. In a CDI extension we have the following observer method: public <T> void processBean(@Observes ProcessBean<T> event, BeanManager beanManager) { getAnnotation(beanManager, event.getAnnotated(), FacesDataModel.class) .ifPresent(d -> forClassToDataModelClass.put( d.forClass(), (Class<? extends DataModel<?>>) event.getBean().getBeanClass() ) ); } With u45 and below this will generate the following (decompiled the class with javap -v -p -s -c) private void lambda$processBean$4(javax.enterprise.inject.spi.ProcessBean, javax.faces.model.FacesDataModel); descriptor: (Ljavax/enterprise/inject/spi/ProcessBean;Ljavax/faces/model/FacesDataModel;)V flags: ACC_PRIVATE, ACC_SYNTHETIC Code: stack=3, locals=3, args_size=3 0: aload_0 1: getfield #4 // Field forClassToDataModelClass:Ljava/util/Map; 4: aload_2 5: invokeinterface #57, 1 // InterfaceMethod javax/faces/model/FacesDataModel.forClass:()Ljava/lang/Class; 10: aload_1 11: invokeinterface #58, 1 // InterfaceMethod javax/enterprise/inject/spi/ProcessBean.getBean:()Ljavax/enterprise/inject/spi/Bean; 16: invokeinterface #59, 1 // InterfaceMethod javax/enterprise/inject/spi/Bean.getBeanClass:()Ljava/lang/Class; 21: invokeinterface #55, 3 // InterfaceMethod java/util/Map.put:(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object; 26: checkcast #45 // class java/lang/Class 29: pop 30: return LineNumberTable: line 110: 0 line 111: 5 line 112: 11 line 110: 21 LocalVariableTable: Start Length Slot Name Signature 0 31 0 this Lcom/sun/faces/cdi/CdiExtension; 0 31 2 d Ljavax/faces/model/FacesDataModel; U60 however generates the following: private void lambda$processBean$4(javax.enterprise.inject.spi.ProcessBean, javax.faces.model.FacesDataModel); descriptor: (Ljavax/enterprise/inject/spi/ProcessBean;Ljavax/faces/model/FacesDataModel;)V flags: ACC_PRIVATE, ACC_SYNTHETIC Code: stack=3, locals=3, args_size=3 0: aload_0 1: getfield #4 // Field forClassToDataModelClass:Ljava/util/Map; 4: aload_2 5: invokeinterface #57, 1 // InterfaceMethod javax/faces/model/FacesDataModel.forClass:()Ljava/lang/Class; 10: aload_1 11: invokeinterface #58, 1 // InterfaceMethod javax/enterprise/inject/spi/ProcessBean.getBean:()Ljavax/enterprise/inject/spi/Bean; 16: invokeinterface #59, 1 // InterfaceMethod javax/enterprise/inject/spi/Bean.getBeanClass:()Ljava/lang/Class; 21: invokeinterface #55, 3 // InterfaceMethod java/util/Map.put:(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object; 26: checkcast #45 // class java/lang/Class 29: pop 30: return LineNumberTable: line 110: 0 line 111: 5 line 112: 11 line 110: 21 LocalVariableTable: Start Length Slot Name Signature 0 31 0 this Lcom/sun/faces/cdi/CdiExtension; 0 31 1 event Ljavax/enterprise/inject/spi/ProcessBean; 0 31 2 d Ljavax/faces/model/FacesDataModel; RuntimeVisibleParameterAnnotations: parameter 0: 0: #79() parameter 1: The difference is that the parameter annotation is made visible for this synthesized method. The result is that CDI subsequently scans this class and sees the synthesized method for the lambda as an observer method, which is of course not the intention. In this particular case it will result in a definition error: "Error occurred during deployment: Exception while loading the app : CDI definition failure: WELD-000409: Observer method for container lifecycle event [[BackedAnnotatedMethod] private com.sun.faces.cdi.CdiExtension.lambda$processBean$4(@Observes ProcessBean<Object>, FacesDataModel)] can only inject BeanManager.." I think that if the synthesized method happened to be a correct observer method, e.g. for a no-parameter lambda or one that happens to have the BeanManager as its first and only parameter, then CDI would silently start to call this method in response to events, which too is highly undesirable. Kind regards, Arjan Tijms

1 0

RFR 8134426: Add serialVersionUID field to relevant javax.transaction classes
by Lance Andersen 26 Aug '15

26 Aug '15

Hi, Looking for a reviewer for 8134426 This change adds a serialVersionUID field to the required javax.transaction classes as well as some basic tests. Once approved, I will work to push the same changes to the relevant JTA project working with the Java EE team output from serialver: ---------------- jdk 1.6 (OSX) serialver -classpath classes.jar javax.transaction.InvalidTransactionException javax.transaction.InvalidTransactionException: private static final long serialVersionUID = 3597320220337691496L; ljanders-mac:Classes ljanders$ serialver -classpath classes.jar javax.transaction.TransactionRequiredException javax.transaction.TransactionRequiredException: private static final long serialVersionUID = -1898806419937446439L; ljanders-mac:Classes ljanders$ serialver -classpath classes.jar javax.transaction.TransactionRolledbackException javax.transaction.TransactionRolledbackException: private static final long serialVersionUID = -3142798139623020577L; java ee 6 serialver -classpath javaee.jar javax.transaction.InvalidTransactionException javax.transaction.InvalidTransactionException: private static final long serialVersionUID = 3597320220337691496L; ljanders-mac:lib ljanders$ serialver -classpath javaee.jar javax.transaction.TransactionRequiredException javax.transaction.TransactionRequiredException: private static final long serialVersionUID = -1898806419937446439L; ljanders-mac:lib ljanders$ serialver -classpath javaee.jar javax.transaction.TransactionRolledbackException javax.transaction.TransactionRolledbackException: private static final long serialVersionUID = -3142798139623020577L; --------------- The webrev can be found at http://cr.openjdk.java.net/~lancea/8134426/webrev/. Also waiting on a JPRT run to complete to verify tests run outside of my environment. Best Lance Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen(a)oracle.com

3 5

Review request for JDK-8133924: NPE may be thrown when xsltc select a non-existing node after JDK-8062518
by Frank Yuan 26 Aug '15

26 Aug '15

Hi, Joe and all Would you like to have a review for bug https://bugs.openjdk.java.net/browse/JDK-8133924? The webrev is at: http://cr.openjdk.java.net/~fyuan/8133924/webrev.00/. I have verified this fix, the corresponding test(it will be pushed with another test suite) and jaxp test are passed in JPRT. Thanks, Frank

4 4

RFR [XXS] 8134356: {@code} tag contains < and > sequences
by Ivan Gerasimov 25 Aug '15

25 Aug '15

Hi! In a few places {@code } block contains < and > sequences, which are displayed verbatim in the doc. Would you please help review the trivial cleanup? BUGURL: https://bugs.openjdk.java.net/browse/JDK-8134356 WEBREV: http://cr.openjdk.java.net/~igerasim/8134356/00/webrev/ Sincerely yours, Ivan

2 6

RFR 8073056: Repeating annotations throws java.security.AccessControlException with a SecurityManager
by Joel Borggrén-Franck 24 Aug '15

24 Aug '15

Hi, Here is a fix for an issue with repeating annotations when a security manager is set. Fix is to use the Proxy invocation handler to unwrap the array containing the repeating annotations. In theory it might be possible to have instances of Annotations that are not implemented using Proxies, so the old code which is independent of implementation is kept as a fall-back, but the user or these theoretical annotations will have to configure the security policy accordingly. http://cr.openjdk.java.net/~jfranck/8073056/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8073056 cheers /Joel

5 25