From javalists at cbfiddle.com Tue May 2 21:15:09 2017 From: javalists at cbfiddle.com (Alan Snyder) Date: Tue, 2 May 2017 14:15:09 -0700 Subject: VisualVM CPU sampling not working Message-ID: <97CDC8E9-A588-4DA7-B5AF-289D8402505D@cbfiddle.com> Is this a known problem? It resembles JDK-8165005. Makes it hard to investigate performance problems if the tools don't work. Are there other tools that work? This is VisualVM 1.39 on an application running under jdk9-ea+166. It reports: Cannot access threads in target application. The log file shows: java.lang.IllegalArgumentException: Unexpected composite type for ThreadInfo at sun.management.ThreadInfoCompositeData.validateCompositeData(ThreadInfoCompositeData.java:372) at sun.management.ThreadInfoCompositeData.getInstance(ThreadInfoCompositeData.java:68) at java.lang.management.ThreadInfo.(ThreadInfo.java:263) at java.lang.management.ThreadInfo.from(ThreadInfo.java:794) Caused: java.lang.reflect.InvocationTargetException 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:498) at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:71) at sun.reflect.GeneratedMethodAccessor6.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:275) at com.sun.jmx.mbeanserver.DefaultMXBeanMappingFactory$CompositeBuilderViaFrom.fromCompositeData(DefaultMXBeanMappingFactory.java:1018) Caused: java.io.InvalidObjectException: Failed to invoke from(CompositeData) at com.sun.jmx.mbeanserver.DefaultMXBeanMappingFactory.invalidObjectException(DefaultMXBeanMappingFactory.java:1457) at com.sun.jmx.mbeanserver.DefaultMXBeanMappingFactory$CompositeBuilderViaFrom.fromCompositeData(DefaultMXBeanMappingFactory.java:1021) at com.sun.jmx.mbeanserver.DefaultMXBeanMappingFactory$CompositeMapping.fromNonNullOpenValue(DefaultMXBeanMappingFactory.java:919) at com.sun.jmx.mbeanserver.DefaultMXBeanMappingFactory$NonNullMXBeanMapping.fromOpenValue(DefaultMXBeanMappingFactory.java:133) at com.sun.jmx.mbeanserver.DefaultMXBeanMappingFactory$ArrayMapping.fromNonNullOpenValue(DefaultMXBeanMappingFactory.java:584) at com.sun.jmx.mbeanserver.DefaultMXBeanMappingFactory$NonNullMXBeanMapping.fromOpenValue(DefaultMXBeanMappingFactory.java:133) at com.sun.jmx.mbeanserver.ConvertingMethod.fromOpenReturnValue(ConvertingMethod.java:131) at com.sun.jmx.mbeanserver.MXBeanProxy.invoke(MXBeanProxy.java:168) at javax.management.MBeanServerInvocationHandler.invoke(MBeanServerInvocationHandler.java:258) Caused: java.lang.reflect.UndeclaredThrowableException at com.sun.proxy.$Proxy16.dumpAllThreads(Unknown Source) at com.sun.tools.visualvm.sampler.cpu.ThreadInfoProvider.dumpAllThreads(ThreadInfoProvider.java:103) [catch] at com.sun.tools.visualvm.sampler.cpu.ThreadInfoProvider.initialize(ThreadInfoProvider.java:88) at com.sun.tools.visualvm.sampler.cpu.ThreadInfoProvider.(ThreadInfoProvider.java:54) at com.sun.tools.visualvm.sampler.SamplerImpl$11.run(SamplerImpl.java:485) at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:1423) at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:2033) From stephen.felts at oracle.com Tue May 2 21:39:29 2017 From: stephen.felts at oracle.com (Stephen Felts) Date: Tue, 2 May 2017 14:39:29 -0700 (PDT) Subject: VisualVM CPU sampling not working In-Reply-To: <97CDC8E9-A588-4DA7-B5AF-289D8402505D@cbfiddle.com> References: <97CDC8E9-A588-4DA7-B5AF-289D8402505D@cbfiddle.com> Message-ID: <3d8677fe-a371-4f02-b332-4fc9eee8f57f@default> It was reported at https://github.com/oracle/visualvm/issues/20 CPU sampling not available - cannot access threads. -----Original Message----- From: Alan Snyder [mailto:javalists at cbfiddle.com] Sent: Tuesday, May 2, 2017 5:15 PM To: jdk9-dev at openjdk.java.net Subject: VisualVM CPU sampling not working Is this a known problem? It resembles JDK-8165005. Makes it hard to investigate performance problems if the tools don't work. Are there other tools that work? This is VisualVM 1.39 on an application running under jdk9-ea+166. It reports: Cannot access threads in target application. The log file shows: java.lang.IllegalArgumentException: Unexpected composite type for ThreadInfo at sun.management.ThreadInfoCompositeData.validateCompositeData(ThreadInfoCompositeData.java:372) at sun.management.ThreadInfoCompositeData.getInstance(ThreadInfoCompositeData.java:68) at java.lang.management.ThreadInfo.(ThreadInfo.java:263) at java.lang.management.ThreadInfo.from(ThreadInfo.java:794) Caused: java.lang.reflect.InvocationTargetException 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:498) at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:71) at sun.reflect.GeneratedMethodAccessor6.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:275) at com.sun.jmx.mbeanserver.DefaultMXBeanMappingFactory$CompositeBuilderViaFrom.fromCompositeData(DefaultMXBeanMappingFactory.java:1018) Caused: java.io.InvalidObjectException: Failed to invoke from(CompositeData) at com.sun.jmx.mbeanserver.DefaultMXBeanMappingFactory.invalidObjectException(DefaultMXBeanMappingFactory.java:1457) at com.sun.jmx.mbeanserver.DefaultMXBeanMappingFactory$CompositeBuilderViaFrom.fromCompositeData(DefaultMXBeanMappingFactory.java:1021) at com.sun.jmx.mbeanserver.DefaultMXBeanMappingFactory$CompositeMapping.fromNonNullOpenValue(DefaultMXBeanMappingFactory.java:919) at com.sun.jmx.mbeanserver.DefaultMXBeanMappingFactory$NonNullMXBeanMapping.fromOpenValue(DefaultMXBeanMappingFactory.java:133) at com.sun.jmx.mbeanserver.DefaultMXBeanMappingFactory$ArrayMapping.fromNonNullOpenValue(DefaultMXBeanMappingFactory.java:584) at com.sun.jmx.mbeanserver.DefaultMXBeanMappingFactory$NonNullMXBeanMapping.fromOpenValue(DefaultMXBeanMappingFactory.java:133) at com.sun.jmx.mbeanserver.ConvertingMethod.fromOpenReturnValue(ConvertingMethod.java:131) at com.sun.jmx.mbeanserver.MXBeanProxy.invoke(MXBeanProxy.java:168) at javax.management.MBeanServerInvocationHandler.invoke(MBeanServerInvocationHandler.java:258) Caused: java.lang.reflect.UndeclaredThrowableException at com.sun.proxy.$Proxy16.dumpAllThreads(Unknown Source) at com.sun.tools.visualvm.sampler.cpu.ThreadInfoProvider.dumpAllThreads(ThreadInfoProvider.java:103) [catch] at com.sun.tools.visualvm.sampler.cpu.ThreadInfoProvider.initialize(ThreadInfoProvider.java:88) at com.sun.tools.visualvm.sampler.cpu.ThreadInfoProvider.(ThreadInfoProvider.java:54) at com.sun.tools.visualvm.sampler.SamplerImpl$11.run(SamplerImpl.java:485) at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:1423) at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:2033) From javalists at cbfiddle.com Tue May 2 22:46:04 2017 From: javalists at cbfiddle.com (Alan Snyder) Date: Tue, 2 May 2017 15:46:04 -0700 Subject: VisualVM CPU sampling not working In-Reply-To: <3d8677fe-a371-4f02-b332-4fc9eee8f57f@default> References: <97CDC8E9-A588-4DA7-B5AF-289D8402505D@cbfiddle.com> <3d8677fe-a371-4f02-b332-4fc9eee8f57f@default> Message-ID: <3E79CB1D-CF38-478F-80AE-AD245FF07CEC@cbfiddle.com> Very funny. That was my report, as a comment to a different issue. As there has been no response to that comment, I still have no idea whether this problem is known to the people who would need to fix it. My questions remain unanswered. Am I the only one who is unable to do any analysis of performance problems on JDK 9? Alan > On May 2, 2017, at 2:39 PM, Stephen Felts wrote: > > It was reported at https://github.com/oracle/visualvm/issues/20 CPU sampling not available - cannot access threads. > > -----Original Message----- > From: Alan Snyder [mailto:javalists at cbfiddle.com] > Sent: Tuesday, May 2, 2017 5:15 PM > To: jdk9-dev at openjdk.java.net > Subject: VisualVM CPU sampling not working > > Is this a known problem? It resembles JDK-8165005. Makes it hard to investigate performance problems if the tools don't work. Are there other tools that work? > > This is VisualVM 1.39 on an application running under jdk9-ea+166. > > It reports: > > Cannot access threads in target application. > > The log file shows: > > java.lang.IllegalArgumentException: Unexpected composite type for ThreadInfo > at sun.management.ThreadInfoCompositeData.validateCompositeData(ThreadInfoCompositeData.java:372) > at sun.management.ThreadInfoCompositeData.getInstance(ThreadInfoCompositeData.java:68) > at java.lang.management.ThreadInfo.(ThreadInfo.java:263) > at java.lang.management.ThreadInfo.from(ThreadInfo.java:794) > > Caused: java.lang.reflect.InvocationTargetException > 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:498) > at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:71) > at sun.reflect.GeneratedMethodAccessor6.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:275) > at com.sun.jmx.mbeanserver.DefaultMXBeanMappingFactory$CompositeBuilderViaFrom.fromCompositeData(DefaultMXBeanMappingFactory.java:1018) > > Caused: java.io.InvalidObjectException: Failed to invoke from(CompositeData) > at com.sun.jmx.mbeanserver.DefaultMXBeanMappingFactory.invalidObjectException(DefaultMXBeanMappingFactory.java:1457) > at com.sun.jmx.mbeanserver.DefaultMXBeanMappingFactory$CompositeBuilderViaFrom.fromCompositeData(DefaultMXBeanMappingFactory.java:1021) > at com.sun.jmx.mbeanserver.DefaultMXBeanMappingFactory$CompositeMapping.fromNonNullOpenValue(DefaultMXBeanMappingFactory.java:919) > at com.sun.jmx.mbeanserver.DefaultMXBeanMappingFactory$NonNullMXBeanMapping.fromOpenValue(DefaultMXBeanMappingFactory.java:133) > at com.sun.jmx.mbeanserver.DefaultMXBeanMappingFactory$ArrayMapping.fromNonNullOpenValue(DefaultMXBeanMappingFactory.java:584) > at com.sun.jmx.mbeanserver.DefaultMXBeanMappingFactory$NonNullMXBeanMapping.fromOpenValue(DefaultMXBeanMappingFactory.java:133) > at com.sun.jmx.mbeanserver.ConvertingMethod.fromOpenReturnValue(ConvertingMethod.java:131) > at com.sun.jmx.mbeanserver.MXBeanProxy.invoke(MXBeanProxy.java:168) > at javax.management.MBeanServerInvocationHandler.invoke(MBeanServerInvocationHandler.java:258) > > Caused: java.lang.reflect.UndeclaredThrowableException > at com.sun.proxy.$Proxy16.dumpAllThreads(Unknown Source) > at com.sun.tools.visualvm.sampler.cpu.ThreadInfoProvider.dumpAllThreads(ThreadInfoProvider.java:103) > > [catch] at com.sun.tools.visualvm.sampler.cpu.ThreadInfoProvider.initialize(ThreadInfoProvider.java:88) > at com.sun.tools.visualvm.sampler.cpu.ThreadInfoProvider.(ThreadInfoProvider.java:54) > at com.sun.tools.visualvm.sampler.SamplerImpl$11.run(SamplerImpl.java:485) > at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:1423) > at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:2033) > From mandy.chung at oracle.com Wed May 3 00:39:08 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 2 May 2017 17:39:08 -0700 Subject: VisualVM CPU sampling not working In-Reply-To: <97CDC8E9-A588-4DA7-B5AF-289D8402505D@cbfiddle.com> References: <97CDC8E9-A588-4DA7-B5AF-289D8402505D@cbfiddle.com> Message-ID: serviceability-dev (cc?ed) is the proper mailing list for this issue and so bcc jdk9-dev. https://bugs.openjdk.java.net/browse/JDK-8167121 has been pushed to jdk8u-dev. We will need to get this fix in a 8u release. Mandy > On May 2, 2017, at 2:15 PM, Alan Snyder wrote: > > Is this a known problem? It resembles JDK-8165005. Makes it hard to investigate performance problems if the tools don't work. Are there other tools that work? > > This is VisualVM 1.39 on an application running under jdk9-ea+166. > > It reports: > > Cannot access threads in target application. > > The log file shows: > > java.lang.IllegalArgumentException: Unexpected composite type for ThreadInfo > at sun.management.ThreadInfoCompositeData.validateCompositeData(ThreadInfoCompositeData.java:372) > at sun.management.ThreadInfoCompositeData.getInstance(ThreadInfoCompositeData.java:68) > at java.lang.management.ThreadInfo.(ThreadInfo.java:263) > at java.lang.management.ThreadInfo.from(ThreadInfo.java:794) > > Caused: java.lang.reflect.InvocationTargetException > 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:498) > at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:71) > at sun.reflect.GeneratedMethodAccessor6.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:275) > at com.sun.jmx.mbeanserver.DefaultMXBeanMappingFactory$CompositeBuilderViaFrom.fromCompositeData(DefaultMXBeanMappingFactory.java:1018) > > Caused: java.io.InvalidObjectException: Failed to invoke from(CompositeData) > at com.sun.jmx.mbeanserver.DefaultMXBeanMappingFactory.invalidObjectException(DefaultMXBeanMappingFactory.java:1457) > at com.sun.jmx.mbeanserver.DefaultMXBeanMappingFactory$CompositeBuilderViaFrom.fromCompositeData(DefaultMXBeanMappingFactory.java:1021) > at com.sun.jmx.mbeanserver.DefaultMXBeanMappingFactory$CompositeMapping.fromNonNullOpenValue(DefaultMXBeanMappingFactory.java:919) > at com.sun.jmx.mbeanserver.DefaultMXBeanMappingFactory$NonNullMXBeanMapping.fromOpenValue(DefaultMXBeanMappingFactory.java:133) > at com.sun.jmx.mbeanserver.DefaultMXBeanMappingFactory$ArrayMapping.fromNonNullOpenValue(DefaultMXBeanMappingFactory.java:584) > at com.sun.jmx.mbeanserver.DefaultMXBeanMappingFactory$NonNullMXBeanMapping.fromOpenValue(DefaultMXBeanMappingFactory.java:133) > at com.sun.jmx.mbeanserver.ConvertingMethod.fromOpenReturnValue(ConvertingMethod.java:131) > at com.sun.jmx.mbeanserver.MXBeanProxy.invoke(MXBeanProxy.java:168) > at javax.management.MBeanServerInvocationHandler.invoke(MBeanServerInvocationHandler.java:258) > > Caused: java.lang.reflect.UndeclaredThrowableException > at com.sun.proxy.$Proxy16.dumpAllThreads(Unknown Source) > at com.sun.tools.visualvm.sampler.cpu.ThreadInfoProvider.dumpAllThreads(ThreadInfoProvider.java:103) > > [catch] at com.sun.tools.visualvm.sampler.cpu.ThreadInfoProvider.initialize(ThreadInfoProvider.java:88) > at com.sun.tools.visualvm.sampler.cpu.ThreadInfoProvider.(ThreadInfoProvider.java:54) > at com.sun.tools.visualvm.sampler.SamplerImpl$11.run(SamplerImpl.java:485) > at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:1423) > at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:2033) > From volker.simonis at gmail.com Wed May 3 08:33:36 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 3 May 2017 10:33:36 +0200 Subject: Why does 'javac' still support "-Xbootclasspath" in jdk9 ? Message-ID: Hi, I've just realized, that in jdk9, javac still supports the following three non-standard options: -Xbootclasspath: Override location of bootstrap class files -Xbootclasspath/a: Append to the bootstrap class path -Xbootclasspath/p: Prepend to the bootstrap class path In jdk9, only "-Xbootclasspath/a:" is still supported by the standard "java" launcher. The other two versions have been removed from "java". For "javac", the "-Xbootclasspath" options have a different semantics anyway - they don't specify the location of the bootstrap class files for the compiler, but the location where the compiler finds the bootstrap classes for the sour code it compiles. Therefore they are only meaningful in combination with the -source/-target option. Now jdk9 comes with a new "--release" option, which doesn't require a boot class path anymore. Additionally, "javac" supports the standard "-bootclasspath" option since long time and it is the recommended way of setting the boot class path if using the -source/-target option ("-Xbootclasspath:" is actually mapped to "-bootclasspath" internally). Wouldn't it therefore make sense to completely remove the three non-standard versions of the "-Xbootclasspath" option from "javac" in jdk9? Thank you and best regards, Volker From jonathan.gibbons at oracle.com Wed May 3 16:07:27 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 3 May 2017 09:07:27 -0700 Subject: Why does 'javac' still support "-Xbootclasspath" in jdk9 ? In-Reply-To: References: Message-ID: Volker, Options to set the platform class path are still reasonable to use in conjunction with -target N, for older values of N. javac will give an error if you try and use these options when compiling for a version that supports modules (i.e. 9 or greater.) -- Jon On 5/3/17 1:33 AM, Volker Simonis wrote: > Hi, > > I've just realized, that in jdk9, javac still supports the following > three non-standard options: > > -Xbootclasspath: Override location of bootstrap class files > -Xbootclasspath/a: Append to the bootstrap class path > -Xbootclasspath/p: Prepend to the bootstrap class path > > In jdk9, only "-Xbootclasspath/a:" is still supported by the > standard "java" launcher. The other two versions have been removed > from "java". > > For "javac", the "-Xbootclasspath" options have a different semantics > anyway - they don't specify the location of the bootstrap class files > for the compiler, but the location where the compiler finds the > bootstrap classes for the sour code it compiles. Therefore they are > only meaningful in combination with the -source/-target option. > > Now jdk9 comes with a new "--release" option, which doesn't require a > boot class path anymore. Additionally, "javac" supports the standard > "-bootclasspath" option since long time and it is the recommended way > of setting the boot class path if using the -source/-target option > ("-Xbootclasspath:" is actually mapped to "-bootclasspath" > internally). > > Wouldn't it therefore make sense to completely remove the three > non-standard versions of the "-Xbootclasspath" option from "javac" in > jdk9? > > Thank you and best regards, > Volker From volker.simonis at gmail.com Wed May 3 19:02:58 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 3 May 2017 21:02:58 +0200 Subject: Why does 'javac' still support "-Xbootclasspath" in jdk9 ? In-Reply-To: References: Message-ID: Sure, but for this we have the standard "-bootclasspath" option. Why do we need to additionally keep the unsupported "-Xbootclasspath" versions? I think that's just confusing (by the way, they always have been confusing :) Also, I don't see how "-Xbootclasspath/p" and "-Xbootclasspath/a" would make any sense on Java 9? On Wed, May 3, 2017 at 6:07 PM, Jonathan Gibbons wrote: > Volker, > > Options to set the platform class path are still reasonable to use in > conjunction with -target N, for older values of N. javac will give an error > if you try and use these options when compiling for a version that supports > modules (i.e. 9 or greater.) > > -- Jon > > > > On 5/3/17 1:33 AM, Volker Simonis wrote: >> >> Hi, >> >> I've just realized, that in jdk9, javac still supports the following >> three non-standard options: >> >> -Xbootclasspath: Override location of bootstrap class files >> -Xbootclasspath/a: Append to the bootstrap class path >> -Xbootclasspath/p: Prepend to the bootstrap class path >> >> In jdk9, only "-Xbootclasspath/a:" is still supported by the >> standard "java" launcher. The other two versions have been removed >> from "java". >> >> For "javac", the "-Xbootclasspath" options have a different semantics >> anyway - they don't specify the location of the bootstrap class files >> for the compiler, but the location where the compiler finds the >> bootstrap classes for the sour code it compiles. Therefore they are >> only meaningful in combination with the -source/-target option. >> >> Now jdk9 comes with a new "--release" option, which doesn't require a >> boot class path anymore. Additionally, "javac" supports the standard >> "-bootclasspath" option since long time and it is the recommended way >> of setting the boot class path if using the -source/-target option >> ("-Xbootclasspath:" is actually mapped to "-bootclasspath" >> internally). >> >> Wouldn't it therefore make sense to completely remove the three >> non-standard versions of the "-Xbootclasspath" option from "javac" in >> jdk9? >> >> Thank you and best regards, >> Volker > > From jonathan.gibbons at oracle.com Wed May 3 19:43:13 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 3 May 2017 12:43:13 -0700 Subject: Why does 'javac' still support "-Xbootclasspath" in jdk9 ? In-Reply-To: References: Message-ID: <0d0e7575-c6f6-eb8d-baf5-2d342d184202@oracle.com> Volker, The general motivation was as much compatibility as possible with pre-existing command lines and scripts. It has never been a goal for JDK 9 javac to simplify/cleanup/remove options for the platform class path. Note we didn't add any new options for the platform class path; we just restricted their use to meaningful scenarios. (i.e. it doesn't make sense to use them when compiling against modules.) All of these options will go away in the fullness of time, as a result of the 1 + "3 back" policy of JEP 247. -Xbootclasspath: has always been a synonym for -bootclasspath. See JDK 8 javac -X. -Xbootclasspath/p: only has a meaning when compiling for older releases, and means the same as it always has. -Xbootclasspath/a: has meaning for all releases. On older releases it means what it always has; on 9, it can be used in the runtime for adding agent classes, and because it makes sense for the runtime, it makes sense to continue to allow it for javac. -- Jon On 5/3/17 12:02 PM, Volker Simonis wrote: > Sure, but for this we have the standard "-bootclasspath" option. > > Why do we need to additionally keep the unsupported "-Xbootclasspath" > versions? I think that's just confusing (by the way, they always have > been confusing :) > > Also, I don't see how "-Xbootclasspath/p" and "-Xbootclasspath/a" > would make any sense on Java 9? > > > On Wed, May 3, 2017 at 6:07 PM, Jonathan Gibbons > wrote: >> Volker, >> >> Options to set the platform class path are still reasonable to use in >> conjunction with -target N, for older values of N. javac will give an error >> if you try and use these options when compiling for a version that supports >> modules (i.e. 9 or greater.) >> >> -- Jon >> >> >> >> On 5/3/17 1:33 AM, Volker Simonis wrote: >>> Hi, >>> >>> I've just realized, that in jdk9, javac still supports the following >>> three non-standard options: >>> >>> -Xbootclasspath: Override location of bootstrap class files >>> -Xbootclasspath/a: Append to the bootstrap class path >>> -Xbootclasspath/p: Prepend to the bootstrap class path >>> >>> In jdk9, only "-Xbootclasspath/a:" is still supported by the >>> standard "java" launcher. The other two versions have been removed >>> from "java". >>> >>> For "javac", the "-Xbootclasspath" options have a different semantics >>> anyway - they don't specify the location of the bootstrap class files >>> for the compiler, but the location where the compiler finds the >>> bootstrap classes for the sour code it compiles. Therefore they are >>> only meaningful in combination with the -source/-target option. >>> >>> Now jdk9 comes with a new "--release" option, which doesn't require a >>> boot class path anymore. Additionally, "javac" supports the standard >>> "-bootclasspath" option since long time and it is the recommended way >>> of setting the boot class path if using the -source/-target option >>> ("-Xbootclasspath:" is actually mapped to "-bootclasspath" >>> internally). >>> >>> Wouldn't it therefore make sense to completely remove the three >>> non-standard versions of the "-Xbootclasspath" option from "javac" in >>> jdk9? >>> >>> Thank you and best regards, >>> Volker >> From jonathan.gibbons at oracle.com Wed May 3 19:46:16 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 3 May 2017 12:46:16 -0700 Subject: Why does 'javac' still support "-Xbootclasspath" in jdk9 ? In-Reply-To: <0d0e7575-c6f6-eb8d-baf5-2d342d184202@oracle.com> References: <0d0e7575-c6f6-eb8d-baf5-2d342d184202@oracle.com> Message-ID: <7be8a503-4ce5-2632-08f6-bb852dc8439b@oracle.com> On 5/3/17 12:43 PM, Jonathan Gibbons wrote: > Volker, > > The general motivation was as much compatibility as possible with > pre-existing command lines and scripts. It has never been a goal for > JDK 9 javac to simplify/cleanup/remove options for the platform class > path. Note we didn't add any new options for the platform class path; > we just restricted their use to meaningful scenarios. (i.e. it doesn't > make sense to use them when compiling against modules.) All of these > options will go away in the fullness of time, as a result of the 1 + > "3 back" policy of JEP 247. Sorry, that should have been JEP 182. > > -Xbootclasspath: has always been a synonym for -bootclasspath. See JDK > 8 javac -X. > > -Xbootclasspath/p: only has a meaning when compiling for older > releases, and means the same as it always has. > > -Xbootclasspath/a: has meaning for all releases. On older releases it > means what it always has; on 9, it can be used in the runtime for > adding agent classes, and because it makes sense for the runtime, it > makes sense to continue to allow it for javac. > > -- Jon > > > > On 5/3/17 12:02 PM, Volker Simonis wrote: >> Sure, but for this we have the standard "-bootclasspath" option. >> >> Why do we need to additionally keep the unsupported "-Xbootclasspath" >> versions? I think that's just confusing (by the way, they always have >> been confusing :) >> >> Also, I don't see how "-Xbootclasspath/p" and "-Xbootclasspath/a" >> would make any sense on Java 9? >> >> >> On Wed, May 3, 2017 at 6:07 PM, Jonathan Gibbons >> wrote: >>> Volker, >>> >>> Options to set the platform class path are still reasonable to use in >>> conjunction with -target N, for older values of N. javac will give >>> an error >>> if you try and use these options when compiling for a version that >>> supports >>> modules (i.e. 9 or greater.) >>> >>> -- Jon >>> >>> >>> >>> On 5/3/17 1:33 AM, Volker Simonis wrote: >>>> Hi, >>>> >>>> I've just realized, that in jdk9, javac still supports the following >>>> three non-standard options: >>>> >>>> -Xbootclasspath: Override location of bootstrap >>>> class files >>>> -Xbootclasspath/a: Append to the bootstrap class path >>>> -Xbootclasspath/p: Prepend to the bootstrap class path >>>> >>>> In jdk9, only "-Xbootclasspath/a:" is still supported by the >>>> standard "java" launcher. The other two versions have been removed >>>> from "java". >>>> >>>> For "javac", the "-Xbootclasspath" options have a different semantics >>>> anyway - they don't specify the location of the bootstrap class files >>>> for the compiler, but the location where the compiler finds the >>>> bootstrap classes for the sour code it compiles. Therefore they are >>>> only meaningful in combination with the -source/-target option. >>>> >>>> Now jdk9 comes with a new "--release" option, which doesn't require a >>>> boot class path anymore. Additionally, "javac" supports the standard >>>> "-bootclasspath" option since long time and it is the recommended way >>>> of setting the boot class path if using the -source/-target option >>>> ("-Xbootclasspath:" is actually mapped to "-bootclasspath" >>>> internally). >>>> >>>> Wouldn't it therefore make sense to completely remove the three >>>> non-standard versions of the "-Xbootclasspath" option from "javac" in >>>> jdk9? >>>> >>>> Thank you and best regards, >>>> Volker >>> > From lana.steuck at oracle.com Wed May 3 19:51:50 2017 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 3 May 2017 19:51:50 GMT Subject: jdk9-b168: dev Message-ID: <201705031951.v43Jpo3t014277@scaaa563.us.oracle.com> http://hg.openjdk.java.net/jdk9/jdk9/rev/143d4c87bc1e http://hg.openjdk.java.net/jdk9/jdk9/nashorn/rev/0f81cde5a1f7 http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/bc21e5ba6bf1 http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/e78da9db6299 http://hg.openjdk.java.net/jdk9/jdk9/jaxws/rev/2746716dcc5a http://hg.openjdk.java.net/jdk9/jdk9/jaxp/rev/23a87f409371 http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/fbb9c8026495 http://hg.openjdk.java.net/jdk9/jdk9/corba/rev/03a2cc9c8a1e --- All the fixes will be tested during promotion (no PIT testing at this point): List of all fixes: =================== JDK-8150488 core-libs Scanner.findAll() can return infinite stream if regex matches zero cha JDK-8158270 core-libs MulticastSendReceiveTests.java failed with "Expected message not recei JDK-8167229 core-libs Improve VarHandle documentation JDK-8175814 core-libs Update default HttpClient protocol version and optional request versio JDK-8177146 core-libs MethodHandles.Lookup::bind allows illegal protected access JDK-8179025 core-libs Exclude deployment modules from FieldSetAccessibleTest.java and Verify JDK-8179247 core-libs java/util/zip/TestExtraTime.java: add some instrumentation which might JDK-8179304 core-libs Fix HTML 5 errors in jdk.scripting.nashorn and jdk.dynalink module JDK-8179364 core-libs update " References: <0d0e7575-c6f6-eb8d-baf5-2d342d184202@oracle.com> Message-ID: On Wed, May 3, 2017 at 9:43 PM, Jonathan Gibbons wrote: > Volker, > > The general motivation was as much compatibility as possible with > pre-existing command lines and scripts. It has never been a goal for JDK 9 > javac to simplify/cleanup/remove options for the platform class path. Note > we didn't add any new options for the platform class path; we just > restricted their use to meaningful scenarios. (i.e. it doesn't make sense to > use them when compiling against modules.) All of these options will go away > in the fullness of time, as a result of the 1 + "3 back" policy of JEP 247. > So be it :) Thanks, Volker > -Xbootclasspath: has always been a synonym for -bootclasspath. See JDK 8 > javac -X. > > -Xbootclasspath/p: only has a meaning when compiling for older releases, and > means the same as it always has. > > -Xbootclasspath/a: has meaning for all releases. On older releases it means > what it always has; on 9, it can be used in the runtime for adding agent > classes, and because it makes sense for the runtime, it makes sense to > continue to allow it for javac. > > -- Jon > > > > > On 5/3/17 12:02 PM, Volker Simonis wrote: >> >> Sure, but for this we have the standard "-bootclasspath" option. >> >> Why do we need to additionally keep the unsupported "-Xbootclasspath" >> versions? I think that's just confusing (by the way, they always have >> been confusing :) >> >> Also, I don't see how "-Xbootclasspath/p" and "-Xbootclasspath/a" >> would make any sense on Java 9? >> >> >> On Wed, May 3, 2017 at 6:07 PM, Jonathan Gibbons >> wrote: >>> >>> Volker, >>> >>> Options to set the platform class path are still reasonable to use in >>> conjunction with -target N, for older values of N. javac will give an >>> error >>> if you try and use these options when compiling for a version that >>> supports >>> modules (i.e. 9 or greater.) >>> >>> -- Jon >>> >>> >>> >>> On 5/3/17 1:33 AM, Volker Simonis wrote: >>>> >>>> Hi, >>>> >>>> I've just realized, that in jdk9, javac still supports the following >>>> three non-standard options: >>>> >>>> -Xbootclasspath: Override location of bootstrap class >>>> files >>>> -Xbootclasspath/a: Append to the bootstrap class path >>>> -Xbootclasspath/p: Prepend to the bootstrap class path >>>> >>>> In jdk9, only "-Xbootclasspath/a:" is still supported by the >>>> standard "java" launcher. The other two versions have been removed >>>> from "java". >>>> >>>> For "javac", the "-Xbootclasspath" options have a different semantics >>>> anyway - they don't specify the location of the bootstrap class files >>>> for the compiler, but the location where the compiler finds the >>>> bootstrap classes for the sour code it compiles. Therefore they are >>>> only meaningful in combination with the -source/-target option. >>>> >>>> Now jdk9 comes with a new "--release" option, which doesn't require a >>>> boot class path anymore. Additionally, "javac" supports the standard >>>> "-bootclasspath" option since long time and it is the recommended way >>>> of setting the boot class path if using the -source/-target option >>>> ("-Xbootclasspath:" is actually mapped to "-bootclasspath" >>>> internally). >>>> >>>> Wouldn't it therefore make sense to completely remove the three >>>> non-standard versions of the "-Xbootclasspath" option from "javac" in >>>> jdk9? >>>> >>>> Thank you and best regards, >>>> Volker >>> >>> > From cantalou89 at gmail.com Fri May 5 08:34:38 2017 From: cantalou89 at gmail.com (zhiwei lin) Date: Fri, 5 May 2017 16:34:38 +0800 Subject: The problem about compile JDK9 for Android Platform with x86 Message-ID: Hi all, I encounter a problem when compile JDK9 for Android Platform with x86 arch.I operated from the tutotrial http://openjdk.java.net/projects/mobile/android.html, but when I execute congifure cmd , I got the error below: configure: Found freetype include files at /home/linzhiwei/work/freetype-2.6.2/build_android-i686/include/freetype2 using --with-freetype checking for freetype includes... /home/linzhiwei/work/freetype-2.6.2/build_android-i686/include/freetype2 checking for freetype libraries... /home/linzhiwei/work/freetype-2.6.2/build_android-i686/lib checking if we can compile and link with freetype... no configure: Could not compile and link with freetype. This might be a 32/64-bit mismatch. configure: Using FREETYPE_CFLAGS=-I/home/linzhiwei/work/freetype-2.6.2/build_android-i686/include/freetype2 and FREETYPE_LIBS=-L/home/linzhiwei/work/freetype-2.6.2/build_android-i686/lib -lfreetype configure: error: Can not continue without freetype. You might be able to fix this by running 'sudo apt-get install libfreetype6-dev'. The detail log is in the config.log file. Build mechime : Linux ubuntu 4.4.0-75-generic #96-Ubuntu SMP Thu Apr 20 09:56:33 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux NDK:android-ndk-r10c Please give some me advise to solve the problem Thx From bob.vandette at oracle.com Fri May 5 19:24:23 2017 From: bob.vandette at oracle.com (Bob Vandette) Date: Fri, 5 May 2017 15:24:23 -0400 Subject: The problem about compile JDK9 for Android Platform with x86 In-Reply-To: References: Message-ID: <4048707D-A7DD-4BC2-8BA5-E4A335E1E6CA@oracle.com> Could you send me your config.log file? Are you certain that you have an x86 version of your freetype libraries in this directory (/home/linzhiwei/work/freetype-2.6.2/build_android-i686/lib) and the freetype header files are located here (/home/linzhiwei/work/freetype-2.6.2/build_android-i686/include/freetype2)? For questions related to the JDK 9 Mobile project, please use this email alias. mobile-dev at openjdk.java.net Bob Vandette > On May 5, 2017, at 4:34 AM, zhiwei lin wrote: > > Hi all, > I encounter a problem when compile JDK9 for Android Platform with x86 > arch.I operated from the tutotrial > http://openjdk.java.net/projects/mobile/android.html, but when I > execute congifure cmd , I got the error below: > configure: Found freetype include files at > /home/linzhiwei/work/freetype-2.6.2/build_android-i686/include/freetype2 > using --with-freetype > checking for freetype includes... > /home/linzhiwei/work/freetype-2.6.2/build_android-i686/include/freetype2 > checking for freetype libraries... > /home/linzhiwei/work/freetype-2.6.2/build_android-i686/lib > checking if we can compile and link with freetype... no > configure: Could not compile and link with freetype. This might be a > 32/64-bit mismatch. > configure: Using > FREETYPE_CFLAGS=-I/home/linzhiwei/work/freetype-2.6.2/build_android-i686/include/freetype2 > and FREETYPE_LIBS=-L/home/linzhiwei/work/freetype-2.6.2/build_android-i686/lib > -lfreetype > configure: error: Can not continue without freetype. You might be able > to fix this by running 'sudo apt-get install libfreetype6-dev'. > > > The detail log is in the config.log file. > Build mechime : Linux ubuntu 4.4.0-75-generic #96-Ubuntu SMP Thu Apr > 20 09:56:33 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux > NDK:android-ndk-r10c > > Please give some me advise to solve the problem > Thx From sadhak001 at gmail.com Fri May 5 23:14:17 2017 From: sadhak001 at gmail.com (Mani Sarkar) Date: Fri, 05 May 2017 23:14:17 +0000 Subject: Become an early Java 9 expert: LJC + vJUG + JUGs Worldwide Hackday Feedback on JDK 9 EA Message-ID: +adding adoption-discuss mailing list Hi all, Last month (22nd April 2017) LJC and a number of JUGs worldwide with the help and support from vJUG hosted a 5-6 hour long hack day (see event details at https://www.meetup.com/virtualJUG/events/238981339/ - we called it "Become an early Java 9 expert"). Social media channels are a witness to the outcome of the hack day, we got great feedback and was able to gather a great deal of feedback, and put them together in this Google Doc: https://goo.gl/oytFzX and would like to share it with the OpenJDK team especially those working on Jigsaw/Java 9. I hope you will be able to make good use of the feedback, if you have any questions please feel free to get in touch with us. Points that need addressing are marked with a rightwards arrowhead ( ? ) - we have had two categories of feedbacks namely *Potential bugs* and *Queries* about the different aspects of Jigsaw & Java 9. Please let me know if any other individuals or lists need to be informed about this. Thanks. Cheers, Mani -- @theNeomatrix369 * | **Blog ** | *LJC Associate & LJC Advocate (@adoptopenjdk & @adoptajsr programs) *Meet-a-Project - *MutabilityDetector * | **Bitbucket * * | **Github * * | **LinkedIn * *Come to Devoxx UK 2017:* http://www.devoxx.co.uk/ *Don't chase success, rather aim for "Excellence", and success will come chasing after you!* From alex.buckley at oracle.com Fri May 5 23:37:43 2017 From: alex.buckley at oracle.com (Alex Buckley) Date: Fri, 05 May 2017 16:37:43 -0700 Subject: Become an early Java 9 expert: LJC + vJUG + JUGs Worldwide Hackday Feedback on JDK 9 EA In-Reply-To: References: Message-ID: <590D0CC7.2040809@oracle.com> On 5/5/2017 4:14 PM, Mani Sarkar wrote: > I hope you will be able to make good use of the feedback, if you have any > questions please feel free to get in touch with us. Points that need > addressing are marked with a rightwards arrowhead ( ? ) - we have had two > categories of feedbacks namely *Potential bugs* and *Queries* about the > different aspects of Jigsaw & Java 9. LOTS of activity here! Some info that may be of interest: ? Query about ServiceLoader class I think you're looking for https://youtu.be/u8Hbdo-u-88?t=9m56s ? Query on module export conflict Hard to figure out what's being asked, but I guess it's a versioning question, so see https://youtu.be/rfOjch4p0Po?t=20m12s ? Query: HttpRequest cannot be used in JShell despite in documentation HttpRequest is an incubating feature, so the module that it lives in will not be resolved by default, see http://openjdk.java.net/jeps/11 ? Query: multiple command-line switched available with java and javac Fair question, see http://openjdk.java.net/jeps/293 Alex From david.holmes at oracle.com Fri May 5 23:04:48 2017 From: david.holmes at oracle.com (David Holmes) Date: Sat, 6 May 2017 09:04:48 +1000 Subject: The problem about compile JDK9 for Android Platform with x86 In-Reply-To: References: Message-ID: Hi, Moving this to mobile-dev and bcc'ing jdk9-dev. David On 5/05/2017 6:34 PM, zhiwei lin wrote: > Hi all, > I encounter a problem when compile JDK9 for Android Platform with x86 > arch.I operated from the tutotrial > http://openjdk.java.net/projects/mobile/android.html, but when I > execute congifure cmd , I got the error below: > configure: Found freetype include files at > /home/linzhiwei/work/freetype-2.6.2/build_android-i686/include/freetype2 > using --with-freetype > checking for freetype includes... > /home/linzhiwei/work/freetype-2.6.2/build_android-i686/include/freetype2 > checking for freetype libraries... > /home/linzhiwei/work/freetype-2.6.2/build_android-i686/lib > checking if we can compile and link with freetype... no > configure: Could not compile and link with freetype. This might be a > 32/64-bit mismatch. > configure: Using > FREETYPE_CFLAGS=-I/home/linzhiwei/work/freetype-2.6.2/build_android-i686/include/freetype2 > and FREETYPE_LIBS=-L/home/linzhiwei/work/freetype-2.6.2/build_android-i686/lib > -lfreetype > configure: error: Can not continue without freetype. You might be able > to fix this by running 'sudo apt-get install libfreetype6-dev'. > > > The detail log is in the config.log file. > Build mechime : Linux ubuntu 4.4.0-75-generic #96-Ubuntu SMP Thu Apr > 20 09:56:33 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux > NDK:android-ndk-r10c > > Please give some me advise to solve the problem > Thx > From sadhak001 at gmail.com Sat May 6 04:42:01 2017 From: sadhak001 at gmail.com (Mani Sarkar) Date: Sat, 06 May 2017 04:42:01 +0000 Subject: Become an early Java 9 expert: LJC + vJUG + JUGs Worldwide Hackday Feedback on JDK 9 EA In-Reply-To: <590D0CC7.2040809@oracle.com> References: <590D0CC7.2040809@oracle.com> Message-ID: Thanks Alex for the responses, could you please place your comments inside the document as comments by the questions and we will accept them - thanks. On Sat, 6 May 2017 at 00:38 Alex Buckley wrote: > On 5/5/2017 4:14 PM, Mani Sarkar wrote: > > I hope you will be able to make good use of the feedback, if you have any > > questions please feel free to get in touch with us. Points that need > > addressing are marked with a rightwards arrowhead ( ? ) - we have had two > > categories of feedbacks namely *Potential bugs* and *Queries* about the > > different aspects of Jigsaw & Java 9. > > LOTS of activity here! Some info that may be of interest: > > ? Query about ServiceLoader class > > I think you're looking for https://youtu.be/u8Hbdo-u-88?t=9m56s > > ? Query on module export conflict > > Hard to figure out what's being asked, but I guess it's a versioning > question, so see https://youtu.be/rfOjch4p0Po?t=20m12s > > ? Query: HttpRequest cannot be used in JShell despite in documentation > > HttpRequest is an incubating feature, so the module that it lives in > will not be resolved by default, see http://openjdk.java.net/jeps/11 > > ? Query: multiple command-line switched available with java and javac > > Fair question, see http://openjdk.java.net/jeps/293 > > Alex > -- @theNeomatrix369 * | **Blog ** | *LJC Associate & LJC Advocate (@adoptopenjdk & @adoptajsr programs) *Meet-a-Project - *MutabilityDetector * | **Bitbucket * * | **Github * * | **LinkedIn * *Come to Devoxx UK 2017:* http://www.devoxx.co.uk/ *Don't chase success, rather aim for "Excellence", and success will come chasing after you!* From aguibert at us.ibm.com Sat May 6 23:55:01 2017 From: aguibert at us.ibm.com (Andrew Guibert) Date: Sat, 6 May 2017 18:55:01 -0500 Subject: Proposal: javax.naming.spi.NamingManager.clearInitialContextFactoryBuilder() Message-ID: Hi all, I've been cleaning up code that I work on to be Java 9 compatible, but have ran into a blocker due to limitations of the Naming API. I could work around the blocker with an --add-opens, but I'd rather find a proper solution. *** Background Currently the javax.naming.spi.NamingManager allows for setting a JVM-wide InitialContextFactoryBuilder (ICFB) once and only once by using the static NamingManager.setInitialContextFactoryBuilder() method [1]. The javadoc clearly states: > Once installed, the builder cannot be replaced. If the set ICFB method is called after a ICFB is set, it will throw an IllegalStateException. This seems to be an overly-aggressive restriction of the API. Currently my product has code that reflects into the NamingManager class in order to clear out the ICFB field using reflection. To be Java 9 compliant, we would like to remove this usage of deep reflection, but there are no clear alternatives for doing so. *** Use case We have a JNDI server that may be started/stopped by other java code in the same JVM. If users stop the JNDI server we clear out the ICFB (using reflection) when the JNDI server OSGi bundle deactivates, so that if a user decides to start the JNDI server again in the same JVM, they may do so and we simply set the ICFB when the JNDI server bundle activates. *** Proposed Solution: I could add a layer of indirection by creating an ICFB wrapper that supports re-setting what ICFB it wraps. However, this would cause the ICFB wrapper and all other classes loaded using that bundle's classloader to be leaked (since it can't be fully deactivated and garbage collected). To sort of work around this classloader leak, we would need to load the ICFB wrapper using its own classloader. Although the wrapper classloader would still be leaked, it would have minimal impact because only the one wrapper class would be leaked. I am not sure why the "no resetting" restriction is on the NamingManager API in the first place. Is anyone aware why the API has this restriction? In any case, the solution outlined above seems rather messy (as it only solves the problem by mitigating a classloader leak), so I would like to propose the following addition to the NamingManager API: /** * Clears the InitialContextFactoryBuilder that was previously installed, if any, so that a different one may be set at a later time. * @throws SecurityException - the builder cannot be cleared for security reasons. * @see SecurityManager.checkSetFactory() */ public static void clearInitialContextFactoryBuilder() [1] http://download.java.net/java/jdk9/docs/api/javax/naming/spi/NamingManager.html#setInitialContextFactoryBuilder-javax.naming.spi.InitialContextFactoryBuilder- - Andy From isaac.r.levy at gmail.com Mon May 8 00:16:09 2017 From: isaac.r.levy at gmail.com (Isaac Levy) Date: Sun, 7 May 2017 20:16:09 -0400 Subject: Long.bitCount micro-optimization Message-ID: Apologies if this is the wrong forum, I'm new to the OpenJDK project. The JDK impl of bitCount can be improved -- though most users will get the hotspot intrinsic. The best source I could find for the suggestion below is page 195: http://support.amd.com/techdocs/25112.pdf Cheers, Isaac Levy Proposed Long.bitCount and Integer.bitCount: public static int bitCount(long i) { i -= (i >>> 1) & 0x5555555555555555L; i = (i & 0x3333333333333333L) + ((i >>> 2) & 0x3333333333333333L); i = (i + (i >>> 4)) & 0x0f0f0f0f0f0f0f0fL; return (i * 0x0101010101010101L) >>> 56; } public static int bitCount(int i) { i -= (i >>> 1) & 0x55555555; i = (i & 0x33333333) + ((i >>> 2) & 0x33333333); i = (i + (i >>> 4)) & 0x0f0f0f0f; return (i * 0x01010101) >>> 24; } From Alan.Bateman at oracle.com Mon May 8 06:27:18 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 8 May 2017 07:27:18 +0100 Subject: Proposal: javax.naming.spi.NamingManager.clearInitialContextFactoryBuilder() In-Reply-To: References: Message-ID: On 07/05/2017 00:55, Andrew Guibert wrote: > : > This seems to be an overly-aggressive restriction of the API. Currently my > product has code that reflects into the NamingManager class in order to > clear out the ICFB field using reflection. To be Java 9 compliant, we > would like to remove this usage of deep reflection, but there are no clear > alternatives for doing so. > There isn't a mailing list specifically for JNDI so it's probably best to start a discussion on core-libs-dev on this topic. -Alan From chris.hegarty at oracle.com Mon May 8 09:47:52 2017 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 8 May 2017 10:47:52 +0100 Subject: Become an early Java 9 expert: LJC + vJUG + JUGs Worldwide Hackday Feedback on JDK 9 EA In-Reply-To: References: <590D0CC7.2040809@oracle.com> Message-ID: <3844ce2c-6279-9459-1e53-d4f39c795ad3@oracle.com> Mani, Expanding a little on Alex's comment regarding the new HTTP Client. I added the following comment as a suggestion to the online doc. On 06/05/17 05:42, Mani Sarkar wrote: > .. >> ? Query: HttpRequest cannot be used in JShell despite in documentation >> >> HttpRequest is an incubating feature, so the module that it lives in >> will not be resolved by default, see http://openjdk.java.net/jeps/11 The new HTTP Client is being delivered in JDK 9 as an incubating feature. It was previous proposed to be included in Java SE, but later moved to incubating in JDK 9 b149. The link above to the javadoc for HttpRequest clearly shows its previous package location. This link is out of date. It is a bug in the documentation that this link still works ( I?ll get that fixed ). JShell can be used with the new HTTP Client as follows: $ ./jdk-9_168/bin/java -version java version "9-ea" Java(TM) SE Runtime Environment (build 9-ea+168) Java HotSpot(TM) Server VM (build 9-ea+168, mixed mode) $ ./jdk-9_168/bin/jshell --add-modules jdk.incubator.httpclient | Welcome to JShell -- Version 9-ea | For an introduction type: /help intro jshell> import jdk.incubator.http.*; jshell> import static jdk.incubator.http.HttpResponse.BodyHandler.*; jshell> URI uri = new URI("http://openjdk.java.net/projects/jigsaw/"); uri ==> http://openjdk.java.net/projects/jigsaw/ jshell> HttpRequest request = HttpRequest.newBuilder(uri).build(); request ==> http://openjdk.java.net/projects/jigsaw/ GET jshell> HttpResponse response = HttpClient.newBuilder().build().send(request, discard(null)); response ==> jdk.incubator.http.HttpResponseImpl at 133814f jshell> response.statusCode(); $6 ==> 200 -Chris. From aph at redhat.com Mon May 8 10:48:06 2017 From: aph at redhat.com (Andrew Haley) Date: Mon, 8 May 2017 11:48:06 +0100 Subject: CFV: New JDK 9 Reviewer: Andrew Dinn Message-ID: <31d3afd6-a89d-43c3-f5f8-13c001a576ca@redhat.com> I hereby nominate Andrew Dinn (adinn) to JDK 9 Reviewer. Andrew co-wrote the original AArch64 port. He is the author of 15 patches in the HotSpot sources, but that does not reflect the true extent of his contribution because he is the author of 341 patches in the aarch64-port project which I merged into OpenJDK. His considerable expertise, particularly with the C2 compiler, will be of great value to the project. Votes are due by 22 May, 2017. Only current Open|JDK 9 Reviewers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Three-Vote Consensus voting instructions, see [2]. Andrew Haley. [1] http://openjdk.java.net/census [2] http://openjdk.java.net/projects/#reviewer-vote From shade at redhat.com Mon May 8 10:57:30 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 8 May 2017 12:57:30 +0200 Subject: CFV: New JDK 9 Reviewer: Andrew Dinn In-Reply-To: <31d3afd6-a89d-43c3-f5f8-13c001a576ca@redhat.com> References: <31d3afd6-a89d-43c3-f5f8-13c001a576ca@redhat.com> Message-ID: Vote: yes On 05/08/2017 12:48 PM, Andrew Haley wrote: > I hereby nominate Andrew Dinn (adinn) to JDK 9 Reviewer. > > Andrew co-wrote the original AArch64 port. He is the author of 15 > patches in the HotSpot sources, but that does not reflect the true > extent of his contribution because he is the author of 341 patches in > the aarch64-port project which I merged into OpenJDK. His > considerable expertise, particularly with the C2 compiler, will be of > great value to the project. > > Votes are due by 22 May, 2017. > > Only current Open|JDK 9 Reviewers [1] are eligible to vote > on this nomination. Votes must be cast in the open by replying > to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Andrew Haley. > > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > From volker.simonis at gmail.com Mon May 8 12:37:45 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 08 May 2017 12:37:45 +0000 Subject: CFV: New JDK 9 Reviewer: Andrew Dinn In-Reply-To: References: <31d3afd6-a89d-43c3-f5f8-13c001a576ca@redhat.com> Message-ID: Vote: yes Aleksey Shipilev schrieb am Mo. 8. Mai 2017 um 05:57: > Vote: yes > > On 05/08/2017 12:48 PM, Andrew Haley wrote: > > I hereby nominate Andrew Dinn (adinn) to JDK 9 Reviewer. > > > > Andrew co-wrote the original AArch64 port. He is the author of 15 > > patches in the HotSpot sources, but that does not reflect the true > > extent of his contribution because he is the author of 341 patches in > > the aarch64-port project which I merged into OpenJDK. His > > considerable expertise, particularly with the C2 compiler, will be of > > great value to the project. > > > > Votes are due by 22 May, 2017. > > > > Only current Open|JDK 9 Reviewers [1] are eligible to vote > > on this nomination. Votes must be cast in the open by replying > > to this mailing list. > > > > For Three-Vote Consensus voting instructions, see [2]. > > > > Andrew Haley. > > > > > > [1] http://openjdk.java.net/census > > [2] http://openjdk.java.net/projects/#reviewer-vote > > > > > From james.laskey at oracle.com Mon May 8 13:05:12 2017 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Mon, 8 May 2017 10:05:12 -0300 Subject: Result: New JDK 9/10 Committer: Srinivas Dama Message-ID: Voting for Srinivas Dama [1] is now closed. Yes: 10 Veto: 0 Abstain: 0 According to the Bylaws definition of Three-Vote Consensus, this is sufficient to approve the nomination. ? Jim Laskey [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2017-April/005777.html From zoltan.majo at oracle.com Mon May 8 14:37:15 2017 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Mon, 8 May 2017 16:37:15 +0200 Subject: CFV: New JDK 9 Reviewer: Andrew Dinn In-Reply-To: <31d3afd6-a89d-43c3-f5f8-13c001a576ca@redhat.com> References: <31d3afd6-a89d-43c3-f5f8-13c001a576ca@redhat.com> Message-ID: <26d3ac71-39e0-cfaf-2721-eaef32c2f620@oracle.com> Vote: yes. Best regards, Zolta'n On 05/08/2017 12:48 PM, Andrew Haley wrote: > I hereby nominate Andrew Dinn (adinn) to JDK 9 Reviewer. > > Andrew co-wrote the original AArch64 port. He is the author of 15 > patches in the HotSpot sources, but that does not reflect the true > extent of his contribution because he is the author of 341 patches in > the aarch64-port project which I merged into OpenJDK. His > considerable expertise, particularly with the C2 compiler, will be of > great value to the project. > > Votes are due by 22 May, 2017. > > Only current Open|JDK 9 Reviewers [1] are eligible to vote > on this nomination. Votes must be cast in the open by replying > to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Andrew Haley. > > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote From karen.kinnear at oracle.com Mon May 8 14:39:20 2017 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Mon, 8 May 2017 10:39:20 -0400 Subject: CFV: New JDK 9 Reviewer: Andrew Dinn In-Reply-To: <31d3afd6-a89d-43c3-f5f8-13c001a576ca@redhat.com> References: <31d3afd6-a89d-43c3-f5f8-13c001a576ca@redhat.com> Message-ID: <694EA066-6731-4AFA-A2FA-36826FF4C635@oracle.com> vote: yes thanks, Karen > On May 8, 2017, at 6:48 AM, Andrew Haley wrote: > > I hereby nominate Andrew Dinn (adinn) to JDK 9 Reviewer. > > Andrew co-wrote the original AArch64 port. He is the author of 15 > patches in the HotSpot sources, but that does not reflect the true > extent of his contribution because he is the author of 341 patches in > the aarch64-port project which I merged into OpenJDK. His > considerable expertise, particularly with the C2 compiler, will be of > great value to the project. > > Votes are due by 22 May, 2017. > > Only current Open|JDK 9 Reviewers [1] are eligible to vote > on this nomination. Votes must be cast in the open by replying > to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Andrew Haley. > > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote From tobias.hartmann at oracle.com Mon May 8 15:01:15 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 8 May 2017 17:01:15 +0200 Subject: CFV: New JDK 9 Reviewer: Andrew Dinn In-Reply-To: <31d3afd6-a89d-43c3-f5f8-13c001a576ca@redhat.com> References: <31d3afd6-a89d-43c3-f5f8-13c001a576ca@redhat.com> Message-ID: <1488135b-5ba4-d207-c393-9e982b107dca@oracle.com> Vote: yes Best regards, Tobias On 08.05.2017 12:48, Andrew Haley wrote: > I hereby nominate Andrew Dinn (adinn) to JDK 9 Reviewer. > > Andrew co-wrote the original AArch64 port. He is the author of 15 > patches in the HotSpot sources, but that does not reflect the true > extent of his contribution because he is the author of 341 patches in > the aarch64-port project which I merged into OpenJDK. His > considerable expertise, particularly with the C2 compiler, will be of > great value to the project. > > Votes are due by 22 May, 2017. > > Only current Open|JDK 9 Reviewers [1] are eligible to vote > on this nomination. Votes must be cast in the open by replying > to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Andrew Haley. > > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > From omajid at redhat.com Mon May 8 15:12:36 2017 From: omajid at redhat.com (Omair Majid) Date: Mon, 8 May 2017 11:12:36 -0400 Subject: CFV: New JDK 9 Reviewer: Andrew Dinn In-Reply-To: <31d3afd6-a89d-43c3-f5f8-13c001a576ca@redhat.com> References: <31d3afd6-a89d-43c3-f5f8-13c001a576ca@redhat.com> Message-ID: <20170508151236.GB10803@redhat.com> Vote: Yes * Andrew Haley [2017-05-08 06:50]: > I hereby nominate Andrew Dinn (adinn) to JDK 9 Reviewer. Thanks, Omair -- PGP Key: 66484681 (http://pgp.mit.edu/) Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 From vladimir.kozlov at oracle.com Mon May 8 16:44:36 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 8 May 2017 09:44:36 -0700 Subject: CFV: New JDK 9 Reviewer: Andrew Dinn In-Reply-To: <31d3afd6-a89d-43c3-f5f8-13c001a576ca@redhat.com> References: <31d3afd6-a89d-43c3-f5f8-13c001a576ca@redhat.com> Message-ID: Vote: yes On 5/8/17 3:48 AM, Andrew Haley wrote: > I hereby nominate Andrew Dinn (adinn) to JDK 9 Reviewer. > > Andrew co-wrote the original AArch64 port. He is the author of 15 > patches in the HotSpot sources, but that does not reflect the true > extent of his contribution because he is the author of 341 patches in > the aarch64-port project which I merged into OpenJDK. His > considerable expertise, particularly with the C2 compiler, will be of > great value to the project. > > Votes are due by 22 May, 2017. > > Only current Open|JDK 9 Reviewers [1] are eligible to vote > on this nomination. Votes must be cast in the open by replying > to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Andrew Haley. > > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > From paul.sandoz at oracle.com Mon May 8 17:36:40 2017 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 8 May 2017 10:36:40 -0700 Subject: CFV: New JDK 9 Reviewer: Andrew Dinn In-Reply-To: <31d3afd6-a89d-43c3-f5f8-13c001a576ca@redhat.com> References: <31d3afd6-a89d-43c3-f5f8-13c001a576ca@redhat.com> Message-ID: <3E455FB6-153A-4EC3-9F83-93312EFBF587@oracle.com> Vote: yes Paul. From brian.burkhalter at oracle.com Mon May 8 17:37:47 2017 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 8 May 2017 10:37:47 -0700 Subject: Long.bitCount micro-optimization In-Reply-To: References: Message-ID: <8FC4835A-6585-4EE9-B31D-14E6AA1C3C4A@oracle.com> Thanks for the patch. The correct forum is core-libs-dev at openjdk.java.net, which I have CCed. Brian On May 7, 2017, at 5:16 PM, Isaac Levy wrote: > Apologies if this is the wrong forum, I'm new to the OpenJDK project. From david.holmes at oracle.com Mon May 8 20:50:56 2017 From: david.holmes at oracle.com (David Holmes) Date: Tue, 9 May 2017 06:50:56 +1000 Subject: CFV: New JDK 9 Reviewer: Andrew Dinn In-Reply-To: <31d3afd6-a89d-43c3-f5f8-13c001a576ca@redhat.com> References: <31d3afd6-a89d-43c3-f5f8-13c001a576ca@redhat.com> Message-ID: <9edd06cb-1e5b-5399-6a13-4300a5b3378f@oracle.com> Vote: yes David On 8/05/2017 8:48 PM, Andrew Haley wrote: > I hereby nominate Andrew Dinn (adinn) to JDK 9 Reviewer. > > Andrew co-wrote the original AArch64 port. He is the author of 15 > patches in the HotSpot sources, but that does not reflect the true > extent of his contribution because he is the author of 341 patches in > the aarch64-port project which I merged into OpenJDK. His > considerable expertise, particularly with the C2 compiler, will be of > great value to the project. > > Votes are due by 22 May, 2017. > > Only current Open|JDK 9 Reviewers [1] are eligible to vote > on this nomination. Votes must be cast in the open by replying > to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Andrew Haley. > > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > From serguei.spitsyn at oracle.com Tue May 9 00:16:17 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 8 May 2017 17:16:17 -0700 Subject: CFV: New JDK 9 Reviewer: Andrew Dinn In-Reply-To: <31d3afd6-a89d-43c3-f5f8-13c001a576ca@redhat.com> References: <31d3afd6-a89d-43c3-f5f8-13c001a576ca@redhat.com> Message-ID: <9d12cb9f-147c-f240-596c-7fd40204ccfc@oracle.com> Vote: yes From rwestrel at redhat.com Tue May 9 09:10:39 2017 From: rwestrel at redhat.com (Roland Westrelin) Date: Tue, 09 May 2017 11:10:39 +0200 Subject: CFV: New JDK 9 Reviewer: Andrew Dinn In-Reply-To: <31d3afd6-a89d-43c3-f5f8-13c001a576ca@redhat.com> References: <31d3afd6-a89d-43c3-f5f8-13c001a576ca@redhat.com> Message-ID: Vote: yes Roland. From thomas.stuefe at gmail.com Tue May 9 10:54:07 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 9 May 2017 12:54:07 +0200 Subject: CFV: New JDK 9 Reviewer: Andrew Dinn In-Reply-To: References: <31d3afd6-a89d-43c3-f5f8-13c001a576ca@redhat.com> Message-ID: Vote: yes On Tue, May 9, 2017 at 11:10 AM, Roland Westrelin wrote: > > Vote: yes > > Roland. > From goetz.lindenmaier at sap.com Tue May 9 10:57:28 2017 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 9 May 2017 10:57:28 +0000 Subject: New JDK 9 Reviewer: Andrew Dinn In-Reply-To: <31d3afd6-a89d-43c3-f5f8-13c001a576ca@redhat.com> References: <31d3afd6-a89d-43c3-f5f8-13c001a576ca@redhat.com> Message-ID: <372426d770614b6f9706ceecc20ca9a5@sap.com> Vote: yes Goetz > -----Original Message----- > From: jdk9-dev [mailto:jdk9-dev-bounces at openjdk.java.net] On Behalf Of > Andrew Haley > Sent: Montag, 8. Mai 2017 12:48 > To: jdk9-dev at openjdk.java.net > Subject: CFV: New JDK 9 Reviewer: Andrew Dinn > > I hereby nominate Andrew Dinn (adinn) to JDK 9 Reviewer. > > Andrew co-wrote the original AArch64 port. He is the author of 15 > patches in the HotSpot sources, but that does not reflect the true > extent of his contribution because he is the author of 341 patches in > the aarch64-port project which I merged into OpenJDK. His > considerable expertise, particularly with the C2 compiler, will be of > great value to the project. > > Votes are due by 22 May, 2017. > > Only current Open|JDK 9 Reviewers [1] are eligible to vote > on this nomination. Votes must be cast in the open by replying > to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Andrew Haley. > > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote From kim.barrett at oracle.com Tue May 9 14:17:51 2017 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 9 May 2017 10:17:51 -0400 Subject: CFV: New JDK 9 Reviewer: Andrew Dinn In-Reply-To: <31d3afd6-a89d-43c3-f5f8-13c001a576ca@redhat.com> References: <31d3afd6-a89d-43c3-f5f8-13c001a576ca@redhat.com> Message-ID: <4108556A-2924-42F4-B0F1-B34E65EFAD9F@oracle.com> vote: yes > On May 8, 2017, at 6:48 AM, Andrew Haley wrote: > > I hereby nominate Andrew Dinn (adinn) to JDK 9 Reviewer. > > Andrew co-wrote the original AArch64 port. He is the author of 15 > patches in the HotSpot sources, but that does not reflect the true > extent of his contribution because he is the author of 341 patches in > the aarch64-port project which I merged into OpenJDK. His > considerable expertise, particularly with the C2 compiler, will be of > great value to the project. > > Votes are due by 22 May, 2017. > > Only current Open|JDK 9 Reviewers [1] are eligible to vote > on this nomination. Votes must be cast in the open by replying > to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Andrew Haley. > > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote From Roger.Riggs at Oracle.com Tue May 9 14:21:48 2017 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Tue, 9 May 2017 10:21:48 -0400 Subject: CFV: New JDK 9 Reviewer: Andrew Dinn In-Reply-To: <31d3afd6-a89d-43c3-f5f8-13c001a576ca@redhat.com> References: <31d3afd6-a89d-43c3-f5f8-13c001a576ca@redhat.com> Message-ID: <797fd942-2dcf-aed1-cd65-6e6d6bd0e748@Oracle.com> Vote: Yes On 5/8/2017 6:48 AM, Andrew Haley wrote: > I hereby nominate Andrew Dinn (adinn) to JDK 9 Reviewer. From daniel.fuchs at oracle.com Tue May 9 14:52:09 2017 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 9 May 2017 15:52:09 +0100 Subject: CFV: New JDK 9 Reviewer: Andrew Dinn In-Reply-To: <31d3afd6-a89d-43c3-f5f8-13c001a576ca@redhat.com> References: <31d3afd6-a89d-43c3-f5f8-13c001a576ca@redhat.com> Message-ID: <2e8eb2c1-7998-8f5f-1b36-3b9cce5f338a@oracle.com> Vote: yes On 08/05/2017 11:48, Andrew Haley wrote: > I hereby nominate Andrew Dinn (adinn) to JDK 9 Reviewer. > > Andrew co-wrote the original AArch64 port. He is the author of 15 > patches in the HotSpot sources, but that does not reflect the true > extent of his contribution because he is the author of 341 patches in > the aarch64-port project which I merged into OpenJDK. His > considerable expertise, particularly with the C2 compiler, will be of > great value to the project. > > Votes are due by 22 May, 2017. > > Only current Open|JDK 9 Reviewers [1] are eligible to vote > on this nomination. Votes must be cast in the open by replying > to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Andrew Haley. > > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > From claes.redestad at oracle.com Tue May 9 17:14:01 2017 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 9 May 2017 19:14:01 +0200 Subject: CFV: New JDK 9 Reviewer: Andrew Dinn In-Reply-To: <31d3afd6-a89d-43c3-f5f8-13c001a576ca@redhat.com> References: <31d3afd6-a89d-43c3-f5f8-13c001a576ca@redhat.com> Message-ID: <93b37d85-72de-fe35-e72d-6705d6150a3d@oracle.com> Vote: yes On 2017-05-08 12:48, Andrew Haley wrote: > I hereby nominate Andrew Dinn (adinn) to JDK 9 Reviewer. > > Andrew co-wrote the original AArch64 port. He is the author of 15 > patches in the HotSpot sources, but that does not reflect the true > extent of his contribution because he is the author of 341 patches in > the aarch64-port project which I merged into OpenJDK. His > considerable expertise, particularly with the C2 compiler, will be of > great value to the project. > > Votes are due by 22 May, 2017. > > Only current Open|JDK 9 Reviewers [1] are eligible to vote > on this nomination. Votes must be cast in the open by replying > to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Andrew Haley. > > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote From mandy.chung at oracle.com Tue May 9 17:26:41 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 9 May 2017 10:26:41 -0700 Subject: CFV: New JDK 9 Reviewer: Andrew Dinn In-Reply-To: References: <31d3afd6-a89d-43c3-f5f8-13c001a576ca@redhat.com> Message-ID: <7F0708AE-AC18-4125-9073-3994841F94C1@oracle.com> Vote: yes Mandy From coleen.phillimore at oracle.com Tue May 9 17:29:50 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 9 May 2017 13:29:50 -0400 Subject: CFV: New JDK 9 Reviewer: Andrew Dinn In-Reply-To: <31d3afd6-a89d-43c3-f5f8-13c001a576ca@redhat.com> References: <31d3afd6-a89d-43c3-f5f8-13c001a576ca@redhat.com> Message-ID: Vote: yes On 5/8/17 6:48 AM, Andrew Haley wrote: > I hereby nominate Andrew Dinn (adinn) to JDK 9 Reviewer. > > Andrew co-wrote the original AArch64 port. He is the author of 15 > patches in the HotSpot sources, but that does not reflect the true > extent of his contribution because he is the author of 341 patches in > the aarch64-port project which I merged into OpenJDK. His > considerable expertise, particularly with the C2 compiler, will be of > great value to the project. > > Votes are due by 22 May, 2017. > > Only current Open|JDK 9 Reviewers [1] are eligible to vote > on this nomination. Votes must be cast in the open by replying > to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Andrew Haley. > > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote From vladimir.x.ivanov at oracle.com Wed May 10 15:07:09 2017 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 10 May 2017 18:07:09 +0300 Subject: CFV: New JDK 9 Reviewer: Andrew Dinn In-Reply-To: <31d3afd6-a89d-43c3-f5f8-13c001a576ca@redhat.com> References: <31d3afd6-a89d-43c3-f5f8-13c001a576ca@redhat.com> Message-ID: Vote: yes Best regards, Vladimir Ivanov On 5/8/17 1:48 PM, Andrew Haley wrote: > I hereby nominate Andrew Dinn (adinn) to JDK 9 Reviewer. > From gnu.andrew at redhat.com Wed May 10 16:27:15 2017 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 10 May 2017 12:27:15 -0400 (EDT) Subject: CFV: New JDK 9 Reviewer: Andrew Dinn In-Reply-To: <31d3afd6-a89d-43c3-f5f8-13c001a576ca@redhat.com> References: <31d3afd6-a89d-43c3-f5f8-13c001a576ca@redhat.com> Message-ID: <774703551.9762884.1494433635470.JavaMail.zimbra@redhat.com> ----- Original Message ----- > I hereby nominate Andrew Dinn (adinn) to JDK 9 Reviewer. > > Andrew co-wrote the original AArch64 port. He is the author of 15 > patches in the HotSpot sources, but that does not reflect the true > extent of his contribution because he is the author of 341 patches in > the aarch64-port project which I merged into OpenJDK. His > considerable expertise, particularly with the C2 compiler, will be of > great value to the project. > > Votes are due by 22 May, 2017. > > Only current Open|JDK 9 Reviewers [1] are eligible to vote > on this nomination. Votes must be cast in the open by replying > to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Andrew Haley. > > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > Vote: Yes -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Web Site: http://fuseyism.com Twitter: https://twitter.com/gnu_andrew_java PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From lana.steuck at oracle.com Wed May 10 20:02:11 2017 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 10 May 2017 20:02:11 GMT Subject: jdk9-b169: dev Message-ID: <201705102002.v4AK2BQl026287@scaaa563.us.oracle.com> http://hg.openjdk.java.net/jdk9/jdk9/rev/b25838a28195 http://hg.openjdk.java.net/jdk9/jdk9/nashorn/rev/131e25008015 http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/0e522ff8b9f5 http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/177436a54ca1 http://hg.openjdk.java.net/jdk9/jdk9/jaxws/rev/912cf69806d5 http://hg.openjdk.java.net/jdk9/jdk9/jaxp/rev/5d9d2a65fb26 http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/16d692be099c http://hg.openjdk.java.net/jdk9/jdk9/corba/rev/b2218d41edef --- All the fixes will be tested during promotion (no PIT testing at this point): List of all fixes: =================== JDK-8140237 client-libs [TEST_BUG]Test javax/swing/plaf/nimbus/8041642/bug8041642.java fails JDK-8159902 client-libs OGL surfaces are not HiDPI compatible on Linux/Solaris JDK-8160530 client-libs [TEST-BUG] Consistent failure of java/awt/dnd/MissingEventsOnModalDial JDK-8178905 client-libs Undecorated frame is not painted on OEL7(Gnome3). JDK-8178971 client-libs Uncommon formatting and typos in java.desktop module JDK-8178984 client-libs Unnecessary angle brackets in the Line2D::intersectsLine() javadoc. JDK-8179027 client-libs JComboBox too small under Windows LAF JDK-8179365 client-libs JAWT (AWT Native Interface) specification needs to be updated for JDK JDK-8179596 client-libs Update java.desktop to be HTML-5 friendly JDK-8020801 core-libs Apply the restriction of invoking MethodHandles.lookup to j.l.r.Method JDK-8023897 core-libs Replace/update/rename executeAndCatch in various tests to assertThrows JDK-8178380 core-libs Module system implementation refresh (5/2017) JDK-8179634 core-libs Add JDBC 4.2 to builet list in package.html JDK-8179645 core-libs java.util.jar.Packer.newPacker and newUnpacker fails when running with JDK-8179662 core-libs OutputStreamWriter javadocs states that you can set the buffer size bu JDK-8179950 core-libs Custom system class loader using Enum.valueOf in its initialization tr JDK-8177721 core-svc Improve diagnostics in sun.management.Agent#startAgent() JDK-8179538 core-svc Update jdk.jdi to be HTML-5 friendly JDK-8179566 globalization Jaxws 2.2 API msg update : wrapperTask.needEndorsed and runtime.modele JDK-8179070 hotspot nashorn+octane's box2d causes c2 to crash with "Bad graph detected in JDK-8179438 infrastructure Incremental builds broken on Windows JDK-8179453 infrastructure Add a proper SetupProcessMarkdown JDK-8179557 infrastructure Update generated Javadoc footer documentation link JDK-8179658 infrastructure Build failed on Linux64 after JDK-8179453 Add a proper SetupProcessMar JDK-8179879 infrastructure Clarify install.sh JDK-8179889 infrastructure Fix typographic errors in copyright headers JDK-8178912 other-libs Remove sample/chatserver/ChatTest.java and sample/mergesort/MergeSortT JDK-8179852 other-libs Remove references to demo tests from TEST.groups JDK-8178014 security-libs CryptoPolicyParser's API comment contains < and > characters JDK-8179451 security-libs Confidential copyright header in openjdk JDK-8179531 tools JShell: fails to provide bytecode for dynamically created lambdas JDK-8150256 xml removing xerces-related dead code From li.jiang at oracle.com Thu May 11 08:39:25 2017 From: li.jiang at oracle.com (Leo Jiang) Date: Thu, 11 May 2017 16:39:25 +0800 Subject: RFR: JDK-8180167 : JDK9 msg drop 40 l10n resource file update Message-ID: <574551a9-832b-b64e-297c-41cd8844f542@oracle.com> Hi, Please help to CR resource update of JDK9 msg drop 40. As usual, some keys are added/updated, and some values are changed to fix the bugs. Bug: https://bugs.openjdk.java.net/browse/JDK-8180167 CR: http://cr.openjdk.java.net/~ljiang/MsgDrop-8180167/webrev.00/ http://cr.openjdk.java.net/~ljiang/MsgDrop-8180167/webrev.00/jaxp/ http://cr.openjdk.java.net/~ljiang/MsgDrop-8180167/webrev.00/jdk/ http://cr.openjdk.java.net/~ljiang/MsgDrop-8180167/webrev.00/langtools/ Thanks, Leo From Alan.Bateman at oracle.com Thu May 11 10:11:42 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 11 May 2017 11:11:42 +0100 Subject: RFR: JDK-8180167 : JDK9 msg drop 40 l10n resource file update In-Reply-To: <574551a9-832b-b64e-297c-41cd8844f542@oracle.com> References: <574551a9-832b-b64e-297c-41cd8844f542@oracle.com> Message-ID: <8469b897-2391-b2e2-91d8-9d4636f6e79d@oracle.com> On 11/05/2017 09:39, Leo Jiang wrote: > Hi, > > Please help to CR resource update of JDK9 msg drop 40. As usual, some > keys are added/updated, and some values are changed to fix the bugs. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8180167 > > CR: > http://cr.openjdk.java.net/~ljiang/MsgDrop-8180167/webrev.00/ > > http://cr.openjdk.java.net/~ljiang/MsgDrop-8180167/webrev.00/jaxp/ > http://cr.openjdk.java.net/~ljiang/MsgDrop-8180167/webrev.00/jdk/ > http://cr.openjdk.java.net/~ljiang/MsgDrop-8180167/webrev.00/langtools/ I looked through the translations for the launcher and jar tool resources. In the French translation then "" is translated to "" in most places but the text for `--limit-modules` is still in English. In the Spanish translation I see that "-m " and "--module " have been translated to "-m " and "--module ". Maybe we should use "module name" in the master but the translation should at least be consistent. Also is the "_" needed? In the German translation then module/mainclass had been translated to "Modulname/Hauptklasse", now it is switched back to English. Is that intentional? -Alan. From daniel.fuchs at oracle.com Thu May 11 10:59:09 2017 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 11 May 2017 11:59:09 +0100 Subject: RFR: JDK-8180167 : JDK9 msg drop 40 l10n resource file update In-Reply-To: <8469b897-2391-b2e2-91d8-9d4636f6e79d@oracle.com> References: <574551a9-832b-b64e-297c-41cd8844f542@oracle.com> <8469b897-2391-b2e2-91d8-9d4636f6e79d@oracle.com> Message-ID: Hi Leo, On 11/05/2017 11:11, Alan Bateman wrote: > In the French translation then "" is translated to " module>" in most places but the text for `--limit-modules` is still in > English. Alan's comment prompted me to have a look at the french properties files: 1. for sun/launcher/resources/launcher_fr.properties I see that and [args...] line 27 were not translated in the french file, but were translated in the italian one. Maybe should be translated into like it seems to have been translated lines 49 and 58 in the same file? And [args...] could be [arguments...] 2. Also in sun/tools/jar/resources/jar_fr.properties 66 error.validator.info.requires.transitive=module-info.class dans un r?pertoire avec num?ro de version contient des "exigences transitives" suppl?mentaires I'm not sure "requires transitive" should be translated: it sounds really weird. I suspect: << module-info.class dans un r?pertoire avec num?ro de version contient des clauses "requires transitives" suppl?mentaires >> would be a better translation. ditto for (same file): 70 error.validator.info.opens.notequal=module-info.class dans un r?pertoire avec num?ro de version contient des "ouvertures" diff?rentes des "ouvertures" diff?rentes => des clause "open" diff?rentes I haven't checked whether "opens" and "requires transitive" have also been translated for other languages, but if they have then I would advise to revisit there as well. best regards, -- daniel From daniel.fuchs at oracle.com Thu May 11 11:06:53 2017 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 11 May 2017 12:06:53 +0100 Subject: RFR: JDK-8180167 : JDK9 msg drop 40 l10n resource file update In-Reply-To: References: <574551a9-832b-b64e-297c-41cd8844f542@oracle.com> <8469b897-2391-b2e2-91d8-9d4636f6e79d@oracle.com> Message-ID: On 11/05/2017 11:59, Daniel Fuchs wrote: > des "ouvertures" diff?rentes => des clause "open" diff?rentes des "ouvertures" diff?rentes => des clauses "open" diff?rentes Oh dear - I forgot the 's' for 'clauses' ... My mother who was a French teacher would scowl at me for this... best regards -- daniel From robert.field at oracle.com Thu May 11 23:25:06 2017 From: robert.field at oracle.com (Robert Field) Date: Thu, 11 May 2017 16:25:06 -0700 Subject: RFR: JDK-8180167 : JDK9 msg drop 40 l10n resource file update In-Reply-To: <574551a9-832b-b64e-297c-41cd8844f542@oracle.com> References: <574551a9-832b-b64e-297c-41cd8844f542@oracle.com> Message-ID: <5914F2D2.8020202@oracle.com> To the limited extent that I can tell, the updates to the Japanese and Chinese jshell tool translations look fine. As before, the example in help.set.mode uses "myformat" which is just a random "user" mode name, choosing a localized might make this clearer. -Robert On 05/11/17 01:39, Leo Jiang wrote: > Hi, > > Please help to CR resource update of JDK9 msg drop 40. As usual, some > keys are added/updated, and some values are changed to fix the bugs. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8180167 > > CR: > http://cr.openjdk.java.net/~ljiang/MsgDrop-8180167/webrev.00/ > > http://cr.openjdk.java.net/~ljiang/MsgDrop-8180167/webrev.00/jaxp/ > http://cr.openjdk.java.net/~ljiang/MsgDrop-8180167/webrev.00/jdk/ > http://cr.openjdk.java.net/~ljiang/MsgDrop-8180167/webrev.00/langtools/ > > Thanks, > Leo From weijun.wang at oracle.com Fri May 12 01:19:05 2017 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 12 May 2017 09:19:05 +0800 Subject: RFR: JDK-8180167 : JDK9 msg drop 40 l10n resource file update In-Reply-To: <574551a9-832b-b64e-297c-41cd8844f542@oracle.com> References: <574551a9-832b-b64e-297c-41cd8844f542@oracle.com> Message-ID: <9d36423e-9ae0-3145-85ff-ae68ecfe8339@oracle.com> keytool/Resources.java: 1. {"verified.by.s.in.s.weak", "Verified by %s in %s with a %s"}, The Chinese translations ?traditional and simplified? are: {"verified.by.s.in.s.weak", "?? %s ? %s ? %s ??"}, {"verified.by.s.in.s.weak", "? %s ?? (? %s ?, ?? %s)"}, Both sounds a little strange, and I'd suggest something like "? %2$s ?? %1$s ? %3$s ??" 2. In simplified Chinese: + {"whose.sigalg.risk", "%s ?? %s ????, ???????????"}, + {"whose.key.risk", "%s ?? %s, ???????????"}, I prefer the traditional Chinese style: + {"whose.sigalg.risk", "%s ??? %s ????????????"}, + {"whose.key.risk", "%s ??? %s ???????"}, Thanks Max On 05/11/2017 04:39 PM, Leo Jiang wrote: > Hi, > > Please help to CR resource update of JDK9 msg drop 40. As usual, some > keys are added/updated, and some values are changed to fix the bugs. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8180167 > > CR: > http://cr.openjdk.java.net/~ljiang/MsgDrop-8180167/webrev.00/ > > http://cr.openjdk.java.net/~ljiang/MsgDrop-8180167/webrev.00/jaxp/ > http://cr.openjdk.java.net/~ljiang/MsgDrop-8180167/webrev.00/jdk/ > http://cr.openjdk.java.net/~ljiang/MsgDrop-8180167/webrev.00/langtools/ > > Thanks, > Leo From mandy.chung at oracle.com Fri May 12 02:46:53 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 11 May 2017 19:46:53 -0700 Subject: RFR: JDK-8180167 : JDK9 msg drop 40 l10n resource file update In-Reply-To: <574551a9-832b-b64e-297c-41cd8844f542@oracle.com> References: <574551a9-832b-b64e-297c-41cd8844f542@oracle.com> Message-ID: > On May 11, 2017, at 1:39 AM, Leo Jiang wrote: > > Hi, > > Please help to CR resource update of JDK9 msg drop 40. As usual, some keys are added/updated, and some values are changed to fix the bugs. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8180167 > > CR: > http://cr.openjdk.java.net/~ljiang/MsgDrop-8180167/webrev.00/ > > http://cr.openjdk.java.net/~ljiang/MsgDrop-8180167/webrev.00/jaxp/ > http://cr.openjdk.java.net/~ljiang/MsgDrop-8180167/webrev.00/jdk/ > http://cr.openjdk.java.net/~ljiang/MsgDrop-8180167/webrev.00/langtools/ I skimmed on jdeps and jlink tool resources. They seem fine. Mandy From li.jiang at oracle.com Fri May 12 02:49:20 2017 From: li.jiang at oracle.com (Leo Jiang) Date: Fri, 12 May 2017 10:49:20 +0800 Subject: RFR: JDK-8180167 : JDK9 msg drop 40 l10n resource file update In-Reply-To: <9d36423e-9ae0-3145-85ff-ae68ecfe8339@oracle.com> References: <574551a9-832b-b64e-297c-41cd8844f542@oracle.com> <9d36423e-9ae0-3145-85ff-ae68ecfe8339@oracle.com> Message-ID: <39e0c36e-1516-e39d-6af6-f37938395e9e@oracle.com> Thank you Max! Have asked the translation team to update. Thanks, Leo On 05/12/2017 09:19 AM, Weijun Wang wrote: > keytool/Resources.java: > > > 1. {"verified.by.s.in.s.weak", "Verified by %s in %s with a %s"}, > > The Chinese translations ?traditional and simplified? are: > > {"verified.by.s.in.s.weak", "?? %s ? %s ? %s ??"}, > {"verified.by.s.in.s.weak", "? %s ?? (? %s ?, ?? %s)"}, > > Both sounds a little strange, and I'd suggest something like > > "? %2$s ?? %1$s ? %3$s ??" > > > 2. In simplified Chinese: > > + {"whose.sigalg.risk", "%s ?? %s ????, ???????????"}, > + {"whose.key.risk", "%s ?? %s, ???????????"}, > > I prefer the traditional Chinese style: > > + {"whose.sigalg.risk", "%s ??? %s ????????????"}, > + {"whose.key.risk", "%s ??? %s ???????"}, > > Thanks > Max > > On 05/11/2017 04:39 PM, Leo Jiang wrote: >> Hi, >> >> Please help to CR resource update of JDK9 msg drop 40. As usual, some >> keys are added/updated, and some values are changed to fix the bugs. >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8180167 >> >> CR: >> http://cr.openjdk.java.net/~ljiang/MsgDrop-8180167/webrev.00/ >> >> http://cr.openjdk.java.net/~ljiang/MsgDrop-8180167/webrev.00/jaxp/ >> http://cr.openjdk.java.net/~ljiang/MsgDrop-8180167/webrev.00/jdk/ >> http://cr.openjdk.java.net/~ljiang/MsgDrop-8180167/webrev.00/langtools/ >> >> Thanks, >> Leo From li.jiang at oracle.com Fri May 12 06:39:24 2017 From: li.jiang at oracle.com (Leo Jiang) Date: Fri, 12 May 2017 14:39:24 +0800 Subject: RFR: JDK-8180167 : JDK9 msg drop 40 l10n resource file update In-Reply-To: <5914F2D2.8020202@oracle.com> References: <574551a9-832b-b64e-297c-41cd8844f542@oracle.com> <5914F2D2.8020202@oracle.com> Message-ID: <33a61e64-d814-5e8f-c8b4-f7ff3fda5bf4@oracle.com> Thank you Robert! I have got feedback from linguist, for the form of 'myformat' (identifier like word), according to translation guideline we don't translate it. Also from my opinion, it would make me confused if it's localized as "????" (my format), actually it's not 'my format'. Thanks, Leo On 05/12/2017 07:25 AM, Robert Field wrote: > To the limited extent that I can tell, the updates to the Japanese and Chinese jshell tool translations look fine. > > As before, the example in help.set.mode uses "myformat" which is just a random "user" mode name, choosing a localized > might make this clearer. > > -Robert > > On 05/11/17 01:39, Leo Jiang wrote: >> Hi, >> >> Please help to CR resource update of JDK9 msg drop 40. As usual, some keys are added/updated, and some values are >> changed to fix the bugs. >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8180167 >> >> CR: >> http://cr.openjdk.java.net/~ljiang/MsgDrop-8180167/webrev.00/ >> >> http://cr.openjdk.java.net/~ljiang/MsgDrop-8180167/webrev.00/jaxp/ >> http://cr.openjdk.java.net/~ljiang/MsgDrop-8180167/webrev.00/jdk/ >> http://cr.openjdk.java.net/~ljiang/MsgDrop-8180167/webrev.00/langtools/ >> >> Thanks, >> Leo > From sadhak001 at gmail.com Fri May 12 11:45:35 2017 From: sadhak001 at gmail.com (Mani Sarkar) Date: Fri, 12 May 2017 11:45:35 +0000 Subject: LJC/vJUG Hackday query: Jigsaw encapsulation effects on frameworks and libraries Message-ID: *How will Jigsaws encapsulation affect frameworks like spring? I heard there was some discussions around this since spring uses reflection and depends on class that I would suspect would be unaccessible in the module?* Mani: Martijn did provide a response to this query but if there is anything the OpenJDK / Java 9 team would like to add to this. *Alan Bateman:* There have been many discussions about this topic on the jigsaw-dev list. There are two main issues here - one is the implementation of the framework breaking into the JDK (to invoke the non-public ClassLoader.defineClass for example). Here is where the frameworks should be looking at the new reflection API java.lang.invoke and using Lookup objects as capabilities. Lookup.defineClass provides an easy way to inject code into the same runtime package as a user class for example. Separately, the module system has evolved to support the ability to open packages for deep reflection. We expect the frameworks will take advantage of that in time once they have support for modules. The jigsaw-dev list is the best place to bring up any further discussion on this topic. @all - lets continue with this conversation here Cheers, Mani -- @theNeomatrix369 * | **Blog ** | *LJC Associate & LJC Advocate (@adoptopenjdk & @adoptajsr programs) *Meet-a-Project - *MutabilityDetector * | **Bitbucket * * | **Github * * | **LinkedIn * *Come to Devoxx UK 2017:* http://www.devoxx.co.uk/ *Don't chase success, rather aim for "Excellence", and success will come chasing after you!* From sadhak001 at gmail.com Fri May 12 11:48:20 2017 From: sadhak001 at gmail.com (Mani Sarkar) Date: Fri, 12 May 2017 11:48:20 +0000 Subject: LJC/vJUG Hackday query: ServiceLoader class Message-ID: Since I don?t have an IDE compatible con Java9 I don?t know if ServiceLoader class has a way to explicitly ask for an implementation on an explicit module *Anonymous: * See new constructors in JavaDoc: http://download.java.net/java/jdk9/docs/api/java/util/ServiceLoader.html Mani: would the OpenJDK / Java 9 team please want to add anything else to the above Alex Buckley: I think you're looking for https://youtu.be/u8Hbdo-u-88?t=9m56s *Al an B at em an :* In a dd it io n to A le x? s re co rd in g, t he s ec ti on o n se le ct io n an d fi lt er in g in t he j av ad oc s ho ul d he lp w it h th is q ue st io n. B ri ng a ny f ol lo w- up q ue st io ns t o ji gs aw -d ev . Cheers, Mani -- @theNeomatrix369 * | **Blog ** | *LJC Associate & LJC Advocate (@adoptopenjdk & @adoptajsr programs) *Meet-a-Project - *MutabilityDetector * | **Bitbucket * * | **Github * * | **LinkedIn * *Come to Devoxx UK 2017:* http://www.devoxx.co.uk/ *Don't chase success, rather aim for "Excellence", and success will come chasing after you!* From sadhak001 at gmail.com Fri May 12 11:51:06 2017 From: sadhak001 at gmail.com (Mani Sarkar) Date: Fri, 12 May 2017 11:51:06 +0000 Subject: LJC/vJUG Hackday query: on the linking process using JLink Message-ID: *I noticed that the executable directory that is generated in session 01 is only 44 Mb. Is the link process limiting the JDK modules that it includes somehow? If so, how? There doesn?t seem to be any info about what JDK modules to include in the module-info.java files in the project.* Mani: If you check the modules created in the executable directory it does only include the java.base module from the jdk modules, and has two of our modules from the exercise. I would think the linker knows the dependencies and limits it. There is an inspect.sh script which shows how to inspect the contents of the modules file to see what modules are included. - does this answer the question Stefan? Does the OpenJDK / Java 9 team wish to expound on this ? *Alan Bateman:* I can?t quite tell what the question is asking. If you `--add-modules myapp` then jlink will link in ?myapp? and all modules that it transitively requires. Maybe the question is about creating a small run-time image for a non-modular application? If so then `jdeps` can be used to do a static analysis and get the list of modules that are required (no guarantee that it?s all of them of course as there may be core reflection usages that can?t be detected by jdeps). Send any follow-ups to jigsaw-dev and we will try to help. Cheers, Mani -- @theNeomatrix369 * | **Blog ** | *LJC Associate & LJC Advocate (@adoptopenjdk & @adoptajsr programs) *Meet-a-Project - *MutabilityDetector * | **Bitbucket * * | **Github * * | **LinkedIn * *Come to Devoxx UK 2017:* http://www.devoxx.co.uk/ *Don't chase success, rather aim for "Excellence", and success will come chasing after you!* From chris.hegarty at oracle.com Fri May 12 14:53:21 2017 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 12 May 2017 15:53:21 +0100 Subject: LJC/vJUG Hackday query: ServiceLoader class In-Reply-To: References: Message-ID: <762823ea-e89e-2751-ccfb-4bdd98a3555c@oracle.com> Mani, On 12/05/17 12:48, Mani Sarkar wrote: > Since I don?t have an IDE compatible con Java9 I don?t know if > ServiceLoader class has a way to explicitly ask for an implementation on an > explicit module > > *Anonymous: * > > See new constructors in JavaDoc: > http://download.java.net/java/jdk9/docs/api/java/util/ServiceLoader.html > > Mani: would the OpenJDK / Java 9 team please want to add anything else to > the above I added the following concrete example to the online doc. --- It is possible to use the new-in-9 ServiceLoader::stream method to return a stream of ServiceLoader.Provider?s. Filtering based on type/module can be done on the stream. For example: // List all ToolProvider service providers in the jdk.jdeps module. ServiceLoader sl = ServiceLoader.load(java.util.spi.ToolProvider.class); sl.stream() .map(p -> p.type()) .filter(t -> t.getModule().getName().equals("jdk.jdeps")) .map(t -> t.getName()) .forEach(System.out::println); -Chris. From li.jiang at oracle.com Mon May 15 01:56:34 2017 From: li.jiang at oracle.com (Leo Jiang) Date: Mon, 15 May 2017 09:56:34 +0800 Subject: RFR: JDK-8180167 : JDK9 msg drop 40 l10n resource file update In-Reply-To: References: <574551a9-832b-b64e-297c-41cd8844f542@oracle.com> <5914F2D2.8020202@oracle.com> <33a61e64-d814-5e8f-c8b4-f7ff3fda5bf4@oracle.com> Message-ID: Hi Shinya, Very appreciated your excellent detailed feedback! Thanks, Leo On 05/13/2017 11:46 AM, ShinyaYoshida wrote: > Hi Leo, > I've noticed some problems in Japanese of jshell translation. > > 1. "?????????" in help.shortcuts is confusing for Japanese > When we see "?????????", we understand it means "1. press , 2. keep pressing and press > ." > But it isn't actually so. > We need to do "1. press , 2. keep pressing and press ", so it should be "?????????" > > 2. "??" in jshell.console.completion.current.signatures should be translated to "?????"(Katakana-form) > Because "?????" is familiar for us in this situation. > "?????" is used for the translation of "Sigunature" in the javadoc of java.lang.reflect.Method, ex > https://docs.oracle.com/javase/jp/8/docs/api/java/lang/reflect/Method.html#getGenericExceptionTypes-- . > > 3. "??" is preferred than "??/??" for the translation of "complete/completion" in this situation > We commonly use "??" for the translation of "complete/completion" in programming. > (Famous IDEs including NetBeans, Eclipse, IntelliJ and VisualStudio do so) > > 150 jshell.console.completion.all.completions.number = ???????????: {0}> > 151 jshell.console.completion.all.completions = > 251 help.shortcuts.summary = ????????????????????????????????\n??????????? > 252 help.shortcuts = ... ????????????????\n\t\t?????????????????????????? > ??? > > Above should be following: > > 150 jshell.console.completion.all.completions.number = ???????????: {0}> > 151 jshell.console.completion.all.completions = > 251 help.shortcuts.summary = ?????????????????????????????????\n??????????? > 252 help.shortcuts = ... ????????????????\n\t\t?????????????????????????? > ??? > > Regards, > Shinya Yoshida(shinyafox) > > 2017-05-12 15:39 GMT+09:00 Leo Jiang >: > > Thank you Robert! > > I have got feedback from linguist, for the form of 'myformat' (identifier like word), according to translation > guideline we don't translate it. > > Also from my opinion, it would make me confused if it's localized as "????" (my format), actually it's not 'my > format'. > > Thanks, > Leo > > > On 05/12/2017 07:25 AM, Robert Field wrote: > > To the limited extent that I can tell, the updates to the Japanese and Chinese jshell tool translations look fine. > > As before, the example in help.set.mode uses "myformat" which is just a random "user" mode name, choosing a > localized > might make this clearer. > > -Robert > > On 05/11/17 01:39, Leo Jiang wrote: > > Hi, > > Please help to CR resource update of JDK9 msg drop 40. As usual, some keys are added/updated, and some > values are > changed to fix the bugs. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8180167 > > CR: > http://cr.openjdk.java.net/~ljiang/MsgDrop-8180167/webrev.00/ > > > http://cr.openjdk.java.net/~ljiang/MsgDrop-8180167/webrev.00/jaxp/ > > http://cr.openjdk.java.net/~ljiang/MsgDrop-8180167/webrev.00/jdk/ > > http://cr.openjdk.java.net/~ljiang/MsgDrop-8180167/webrev.00/langtools/ > > > Thanks, > Leo > > > From peter.levart at gmail.com Mon May 15 14:23:51 2017 From: peter.levart at gmail.com (Peter Levart) Date: Mon, 15 May 2017 16:23:51 +0200 Subject: CFV: New JDK 9 Reviewer: Andrew Dinn In-Reply-To: <31d3afd6-a89d-43c3-f5f8-13c001a576ca@redhat.com> References: <31d3afd6-a89d-43c3-f5f8-13c001a576ca@redhat.com> Message-ID: <5a6a2356-dcde-4c9c-10cd-fb0b19fa1115@gmail.com> Vote: yes On 05/08/2017 12:48 PM, Andrew Haley wrote: > I hereby nominate Andrew Dinn (adinn) to JDK 9 Reviewer. > > Andrew co-wrote the original AArch64 port. He is the author of 15 > patches in the HotSpot sources, but that does not reflect the true > extent of his contribution because he is the author of 341 patches in > the aarch64-port project which I merged into OpenJDK. His > considerable expertise, particularly with the C2 compiler, will be of > great value to the project. > > Votes are due by 22 May, 2017. > > Only current Open|JDK 9 Reviewers [1] are eligible to vote > on this nomination. Votes must be cast in the open by replying > to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Andrew Haley. > > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote From huizhe.wang at oracle.com Tue May 16 17:22:09 2017 From: huizhe.wang at oracle.com (huizhe wang) Date: Tue, 16 May 2017 10:22:09 -0700 Subject: RFR: JDK-8180167 : JDK9 msg drop 40 l10n resource file update In-Reply-To: <574551a9-832b-b64e-297c-41cd8844f542@oracle.com> References: <574551a9-832b-b64e-297c-41cd8844f542@oracle.com> Message-ID: <88e6bb8f-13db-5ad0-0720-c0c88b3f80ef@oracle.com> Hi Leo, For the jaxp portion, I don't know the languages, but for CatalogMessages, it's best not to translate "Catalog" or "catalog" since Catalog is a technical term. Thanks, Joe On 5/11/2017 1:39 AM, Leo Jiang wrote: > Hi, > > Please help to CR resource update of JDK9 msg drop 40. As usual, some > keys are added/updated, and some values are changed to fix the bugs. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8180167 > > CR: > http://cr.openjdk.java.net/~ljiang/MsgDrop-8180167/webrev.00/ > > http://cr.openjdk.java.net/~ljiang/MsgDrop-8180167/webrev.00/jaxp/ > http://cr.openjdk.java.net/~ljiang/MsgDrop-8180167/webrev.00/jdk/ > http://cr.openjdk.java.net/~ljiang/MsgDrop-8180167/webrev.00/langtools/ > > Thanks, > Leo From lana.steuck at oracle.com Wed May 17 19:31:21 2017 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 17 May 2017 19:31:21 GMT Subject: jdk9-b170: dev Message-ID: <201705171931.v4HJVL0V012667@scaaa563.us.oracle.com> http://hg.openjdk.java.net/jdk9/jdk9/rev/4d163ec59d98 http://hg.openjdk.java.net/jdk9/jdk9/nashorn/rev/550bfc15779f http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/18355c879c69 http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/ef9954f6896b http://hg.openjdk.java.net/jdk9/jdk9/jaxws/rev/e75d3abe579a http://hg.openjdk.java.net/jdk9/jdk9/jaxp/rev/6e78f902f477 http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/38a240fd58a2 http://hg.openjdk.java.net/jdk9/jdk9/corba/rev/8a4ab3b0ab9a --- All the fixes will be tested during promotion (no PIT testing at this point): List of all fixes: =================== JDK-7155591 core-libs test/java/net/MulticastSocket/SetOutgoingIf.java fails on macOS JDK-8177153 core-libs LambdaMetafactory has default constructor JDK-8177328 core-libs java/lang/ClassLoader/securityManager/ClassLoaderTest.java times out w JDK-8179021 core-libs Latest bugfixes to WebSocket/HPACK from the sandbox repo JDK-8179515 core-libs Class java.util.concurrent.ThreadLocalRandom fails to Initialize when JDK-8179592 core-libs Update tables in java.base to be HTML 5-friendly. JDK-8179697 core-libs Fix Html5 errors in java.naming, java.logging, jdk.httpserver, jdk.net JDK-8179891 core-libs JavaDoc for for..in is incorrect JDK-8180075 core-libs Javadoc of MethodHandles.Lookup::bind should note the difference from JDK-8180082 core-libs Broken javadoc links JDK-8180085 core-libs (ch) java/nio/channels/SocketChannel/VectorIO.java: add debug instrume JDK-8180128 core-libs small errors in String javadoc JDK-8180137 core-libs fix broken link in java.lang.Iterable JDK-8180176 core-libs Broken javadoc links in java.logging and java.naming JDK-8180256 core-libs Fix HTML 5 issues in java.sql and java.sql.rowset modules JDK-8180303 core-libs Remove technote doc link from ProxySelector/B8035158.java test JDK-8180309 core-libs Minor update to javax.sql.rowset package.html JDK-8180319 core-libs Update Serialization spec to omit obsolete serialver -show and change JDK-8179460 core-svc Fix unnecessary uses of {@docRoot} in serviceability APIs JDK-8179631 core-svc Fix Html5 errors in java.management, jdk.management, jdk.jdi and jdk.a JDK-8179954 hotspot AArch64: C1 and C2 volatile accesses are not sequentially consistent JDK-8180004 hotspot jdk.test.lib.DynamicVMOption should be moved to jdk.test.lib.managemen JDK-8180037 hotspot move jdk.test.lib.InMemoryJavaCompiler to a separate package JDK-8180048 hotspot Interned string and symbol table leak memory during parallel unlinking JDK-8179105 infrastructure A new property to specify import module to be included in unified docs JDK-8179889 infrastructure Fix typographic errors in copyright headers JDK-8180083 infrastructure Adjust Jib and JDL configurations for 9 to support new generation Mach JDK-8180129 infrastructure Bundles.gmk:181: *** unterminated call to function 'filter-out': missi JDK-8180208 infrastructure Provide a new docs bundle page JDK-8180281 infrastructure --with-jtreg is broken for many use cases JDK-8180328 infrastructure Bad links in footer of all javadoc-generated pages JDK-8180420 infrastructure Set PATH for dot and pandoc in JIB JDK-8180041 other-libs Fix HTML 5 issues in java.corba JDK-8178043 tools Support grouping modules in unified javadoc JDK-8178152 tools Handling of incubating modules, the jdk.unsupported module and --add-e JDK-8179479 tools Add new styles to enable HTML 5 tables JDK-8179632 tools Fix the old doclet documentation JDK-8179868 xml Java API Docs of javax.xml.transform.stax contains TODOs From christoph.langer at sap.com Thu May 18 13:40:36 2017 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 18 May 2017 13:40:36 +0000 Subject: New JDK 9 Reviewer: Andrew Dinn In-Reply-To: <31d3afd6-a89d-43c3-f5f8-13c001a576ca@redhat.com> References: <31d3afd6-a89d-43c3-f5f8-13c001a576ca@redhat.com> Message-ID: Vote: Yes > -----Original Message----- > From: jdk9-dev [mailto:jdk9-dev-bounces at openjdk.java.net] On Behalf Of > Andrew Haley > Sent: Montag, 8. Mai 2017 12:48 > To: jdk9-dev at openjdk.java.net > Subject: CFV: New JDK 9 Reviewer: Andrew Dinn > > I hereby nominate Andrew Dinn (adinn) to JDK 9 Reviewer. > > Andrew co-wrote the original AArch64 port. He is the author of 15 > patches in the HotSpot sources, but that does not reflect the true > extent of his contribution because he is the author of 341 patches in > the aarch64-port project which I merged into OpenJDK. His > considerable expertise, particularly with the C2 compiler, will be of > great value to the project. > > Votes are due by 22 May, 2017. > > Only current Open|JDK 9 Reviewers [1] are eligible to vote > on this nomination. Votes must be cast in the open by replying > to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Andrew Haley. > > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote From javalists at cbfiddle.com Thu May 18 19:39:01 2017 From: javalists at cbfiddle.com (Alan Snyder) Date: Thu, 18 May 2017 12:39:01 -0700 Subject: VisualVM CPU sampling not working In-Reply-To: References: <97CDC8E9-A588-4DA7-B5AF-289D8402505D@cbfiddle.com> Message-ID: <4F9BC98B-53C8-4B48-8380-C9BFC7A12C74@cbfiddle.com> As far as I can tell, the latest VisualVM (1.3.9) is unable to do CPU sampling or profiling on the latest EA build (9-ea+169-jigsaw-nightly-h6406-20170517). Is this really the case, or am I missing something? Is someone working on this? I would think that performance analysis would be important during the EA period. Is there some other tool I should be using that works? Alan P.S. No response on serviceability-dev? > On May 2, 2017, at 5:39 PM, Mandy Chung wrote: > > serviceability-dev (cc?ed) is the proper mailing list for this issue > and so bcc jdk9-dev. > > https://bugs.openjdk.java.net/browse/JDK-8167121 has been pushed > to jdk8u-dev. We will need to get this fix in a 8u release. > > Mandy > >> On May 2, 2017, at 2:15 PM, Alan Snyder wrote: >> >> Is this a known problem? It resembles JDK-8165005. Makes it hard to investigate performance problems if the tools don't work. Are there other tools that work? >> >> This is VisualVM 1.39 on an application running under jdk9-ea+166. >> >> It reports: >> >> Cannot access threads in target application. >> >> The log file shows: >> >> java.lang.IllegalArgumentException: Unexpected composite type for ThreadInfo >> at sun.management.ThreadInfoCompositeData.validateCompositeData(ThreadInfoCompositeData.java:372) >> at sun.management.ThreadInfoCompositeData.getInstance(ThreadInfoCompositeData.java:68) >> at java.lang.management.ThreadInfo.(ThreadInfo.java:263) >> at java.lang.management.ThreadInfo.from(ThreadInfo.java:794) >> >> Caused: java.lang.reflect.InvocationTargetException >> 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:498) >> at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:71) >> at sun.reflect.GeneratedMethodAccessor6.invoke(Unknown Source) >> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> at java.lang.reflect.Method.invoke(Method.java:498) >> at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:275) >> at com.sun.jmx.mbeanserver.DefaultMXBeanMappingFactory$CompositeBuilderViaFrom.fromCompositeData(DefaultMXBeanMappingFactory.java:1018) >> >> Caused: java.io.InvalidObjectException: Failed to invoke from(CompositeData) >> at com.sun.jmx.mbeanserver.DefaultMXBeanMappingFactory.invalidObjectException(DefaultMXBeanMappingFactory.java:1457) >> at com.sun.jmx.mbeanserver.DefaultMXBeanMappingFactory$CompositeBuilderViaFrom.fromCompositeData(DefaultMXBeanMappingFactory.java:1021) >> at com.sun.jmx.mbeanserver.DefaultMXBeanMappingFactory$CompositeMapping.fromNonNullOpenValue(DefaultMXBeanMappingFactory.java:919) >> at com.sun.jmx.mbeanserver.DefaultMXBeanMappingFactory$NonNullMXBeanMapping.fromOpenValue(DefaultMXBeanMappingFactory.java:133) >> at com.sun.jmx.mbeanserver.DefaultMXBeanMappingFactory$ArrayMapping.fromNonNullOpenValue(DefaultMXBeanMappingFactory.java:584) >> at com.sun.jmx.mbeanserver.DefaultMXBeanMappingFactory$NonNullMXBeanMapping.fromOpenValue(DefaultMXBeanMappingFactory.java:133) >> at com.sun.jmx.mbeanserver.ConvertingMethod.fromOpenReturnValue(ConvertingMethod.java:131) >> at com.sun.jmx.mbeanserver.MXBeanProxy.invoke(MXBeanProxy.java:168) >> at javax.management.MBeanServerInvocationHandler.invoke(MBeanServerInvocationHandler.java:258) >> >> Caused: java.lang.reflect.UndeclaredThrowableException >> at com.sun.proxy.$Proxy16.dumpAllThreads(Unknown Source) >> at com.sun.tools.visualvm.sampler.cpu.ThreadInfoProvider.dumpAllThreads(ThreadInfoProvider.java:103) >> >> [catch] at com.sun.tools.visualvm.sampler.cpu.ThreadInfoProvider.initialize(ThreadInfoProvider.java:88) >> at com.sun.tools.visualvm.sampler.cpu.ThreadInfoProvider.(ThreadInfoProvider.java:54) >> at com.sun.tools.visualvm.sampler.SamplerImpl$11.run(SamplerImpl.java:485) >> at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:1423) >> at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:2033) >> > From Alan.Bateman at oracle.com Thu May 18 20:29:07 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 18 May 2017 21:29:07 +0100 Subject: VisualVM CPU sampling not working In-Reply-To: <4F9BC98B-53C8-4B48-8380-C9BFC7A12C74@cbfiddle.com> References: <97CDC8E9-A588-4DA7-B5AF-289D8402505D@cbfiddle.com> <4F9BC98B-53C8-4B48-8380-C9BFC7A12C74@cbfiddle.com> Message-ID: On 18/05/2017 20:39, Alan Snyder wrote: > As far as I can tell, the latest VisualVM (1.3.9) is unable to do CPU sampling or profiling on the latest EA build (9-ea+169-jigsaw-nightly-h6406-20170517). > > Is this really the case, or am I missing something? > > Is someone working on this? I took a quite look. As Mandy said in the previous mail, the JMX interop issue between JDK 8 and JDK 9 is JDK-8167121. This is fixed in jdk8u-dev but hasn't got into a released JDK 8 update yet. So as a test, I ran Visual VM 1.3.9 on a JDK 9 build to attach to an application running on the same JDK 9 build. As VisualVM (or maybe the NetBeans framework that it builds on) makes use of a number of JDK internal APIs. It has encapsulation busting command line options configured in etc/visualvm.conf but the module names aren't quite right - specifically, jdk.jvmstat was renamed to jdk.internal.jvmstat a couple of builds ago. I fixed those and it started up okay. I tried the Monitor, Threads, and Sampler tabs and they seem to work okay. -Alan From mandy.chung at oracle.com Thu May 18 20:45:49 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 18 May 2017 13:45:49 -0700 Subject: VisualVM CPU sampling not working In-Reply-To: References: <97CDC8E9-A588-4DA7-B5AF-289D8402505D@cbfiddle.com> <4F9BC98B-53C8-4B48-8380-C9BFC7A12C74@cbfiddle.com> Message-ID: > On May 18, 2017, at 1:29 PM, Alan Bateman wrote: > > On 18/05/2017 20:39, Alan Snyder wrote: > >> As far as I can tell, the latest VisualVM (1.3.9) is unable to do CPU sampling or profiling on the latest EA build (9-ea+169-jigsaw-nightly-h6406-20170517). >> >> Is this really the case, or am I missing something? >> >> Is someone working on this? > I took a quite look. > > As Mandy said in the previous mail, the JMX interop issue between JDK 8 and JDK 9 is JDK-8167121. This is fixed in jdk8u-dev but hasn't got into a released JDK 8 update yet. > > So as a test, I ran Visual VM 1.3.9 on a JDK 9 build to attach to an application running on the same JDK 9 build. As VisualVM (or maybe the NetBeans framework that it builds on) makes use of a number of JDK internal APIs. It has encapsulation busting command line options configured in etc/visualvm.conf but the module names aren't quite right - specifically, jdk.jvmstat was renamed to jdk.internal.jvmstat a couple of builds ago. I fixed those and it started up okay. I tried the Monitor, Threads, and Sampler tabs and they seem to work okay. VisualVM 1.3.9 was released on Oct 2016. It has to be updated to work with the latest JDK 9 release. You may reference the ?-add-opens options used by NetBeans Dev version (under etc/netbeans.conf) Mandy From li.jiang at oracle.com Mon May 22 14:12:16 2017 From: li.jiang at oracle.com (Leo Jiang) Date: Mon, 22 May 2017 22:12:16 +0800 Subject: RFR: JDK-8180167: (2nd webrev) JDK9 msg drop 40 l10n resource file update Message-ID: <138ac02e-57b1-8e52-afe0-67b38cfa964d@oracle.com> Hi, Since the first round of webrev, we got the feedback and suggestion from jdk developers. After fixing the translation bugs, and add three new messages in compiler.properties, now please help to review the updated resources. Open a new clean thread for 2nd webrev. Bug: https://bugs.openjdk.java.net/browse/JDK-8180167 CR: http://cr.openjdk.java.net/~ljiang/MsgDrop-8180167/webrev.01/jaxp/ http://cr.openjdk.java.net/~ljiang/MsgDrop-8180167/webrev.01/jdk/ http://cr.openjdk.java.net/~ljiang/MsgDrop-8180167/webrev.01/langtools/ Updates: - Added three msgs into compiler.properties. - compiler.err.add.exports.with.release - compiler.err.add.reads.with.release - compiler.err.patch.module.with.release - Fixed the missing translation of for French. - Removed the underscore in the option values in launcher_es.properties - Use English term 'catalog' for some localized version. For rest of languages, has the localized term for catalog, don't change. - Improved the translation for SimpChinese and TradChinese according to Max's suggestion. - Improved the translation for Japanese according to Shinya's suggestion. - Fixed the bug of translated keyword in jar_[es, fr].properties Thanks, Leo From daniel.fuchs at oracle.com Mon May 22 15:00:54 2017 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Mon, 22 May 2017 16:00:54 +0100 Subject: RFR: JDK-8180167: (2nd webrev) JDK9 msg drop 40 l10n resource file update In-Reply-To: <138ac02e-57b1-8e52-afe0-67b38cfa964d@oracle.com> References: <138ac02e-57b1-8e52-afe0-67b38cfa964d@oracle.com> Message-ID: Hi Leo, On 22/05/2017 15:12, Leo Jiang wrote: > Hi, > > Since the first round of webrev, we got the feedback and suggestion from > jdk developers. After fixing the translation bugs, and add three new > messages in compiler.properties, now please help to review the updated > resources. > > Open a new clean thread for 2nd webrev. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8180167 > > CR: > http://cr.openjdk.java.net/~ljiang/MsgDrop-8180167/webrev.01/jaxp/ > http://cr.openjdk.java.net/~ljiang/MsgDrop-8180167/webrev.01/jdk/ The changes to share/classes/sun/tools/jar/resources/jar_fr.properties look good to me. That sounds much better, thanks! :-) However I'm still a bit puzzled about the java.launcher.opt.header message in: share/classes/sun/launcher/resources/launcher_*.properties It looks like half of the files have translated , and half of them have not. It's probably a small thing since anyone able to understand the concept of "main class" should certainly be able to figure out what "" means - but is there any logic for translating it in some languages and not translating it in others? Or is that a bug? best regards, -- daniel > http://cr.openjdk.java.net/~ljiang/MsgDrop-8180167/webrev.01/langtools/ > > > Updates: > - Added three msgs into compiler.properties. > - compiler.err.add.exports.with.release > - compiler.err.add.reads.with.release > - compiler.err.patch.module.with.release > - Fixed the missing translation of for French. > - Removed the underscore in the option values in launcher_es.properties > - Use English term 'catalog' for some localized version. For rest of > languages, has the localized term for catalog, don't change. > - Improved the translation for SimpChinese and TradChinese according to > Max's suggestion. > - Improved the translation for Japanese according to Shinya's suggestion. > - Fixed the bug of translated keyword in jar_[es, fr].properties > > Thanks, > Leo > > > From huizhe.wang at oracle.com Mon May 22 16:27:42 2017 From: huizhe.wang at oracle.com (huizhe wang) Date: Mon, 22 May 2017 09:27:42 -0700 Subject: RFR: JDK-8180167: (2nd webrev) JDK9 msg drop 40 l10n resource file update In-Reply-To: <138ac02e-57b1-8e52-afe0-67b38cfa964d@oracle.com> References: <138ac02e-57b1-8e52-afe0-67b38cfa964d@oracle.com> Message-ID: <3a67bcd2-d2ac-c035-0263-0ebb27dea1f8@oracle.com> Hi Leo, On 5/22/2017 7:12 AM, Leo Jiang wrote: > Hi, > > Since the first round of webrev, we got the feedback and suggestion > from jdk developers. After fixing the translation bugs, and add three > new messages in compiler.properties, now please help to review the > updated resources. > > Open a new clean thread for 2nd webrev. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8180167 > > CR: > http://cr.openjdk.java.net/~ljiang/MsgDrop-8180167/webrev.01/jaxp/ > http://cr.openjdk.java.net/~ljiang/MsgDrop-8180167/webrev.01/jdk/ > http://cr.openjdk.java.net/~ljiang/MsgDrop-8180167/webrev.01/langtools/ > > > Updates: > - Added three msgs into compiler.properties. > - compiler.err.add.exports.with.release > - compiler.err.add.reads.with.release > - compiler.err.patch.module.with.release > - Fixed the missing translation of for French. > - Removed the underscore in the option values in launcher_es.properties > - Use English term 'catalog' for some localized version. For rest of > languages, has the localized term for catalog, don't change. I don't know the languages, but there seems to be inconsistencies, for example, in CatalogMessages_sv.properties: 33 InvalidCatalog = JAXP09020001: Dokumentelementet f?r en katalog m?ste vara "catalog". This looks ok. But in some other language files, the document element "catalog" was translated, in CatalogMessages_pt_BR.properties for example: 33 InvalidCatalog = JAXP09020001: O elemento de documento de um cat?logo deve ser o cat?logo. Thanks, Joe > - Improved the translation for SimpChinese and TradChinese according > to Max's suggestion. > - Improved the translation for Japanese according to Shinya's > suggestion. > - Fixed the bug of translated keyword in jar_[es, fr].properties > > Thanks, > Leo > > > From li.jiang at oracle.com Mon May 22 17:06:41 2017 From: li.jiang at oracle.com (Leo Jiang) Date: Tue, 23 May 2017 01:06:41 +0800 Subject: RFR: JDK-8180167: (2nd webrev) JDK9 msg drop 40 l10n resource file update In-Reply-To: References: <138ac02e-57b1-8e52-afe0-67b38cfa964d@oracle.com> Message-ID: <35f0d47d-a090-cf20-6e1c-b11bd9dc02b5@oracle.com> Hi Daniel, According to current translatability guideline, we would not translate mainclass like word. We're working on a guideline for translator to avoid the inconsistent. In the future, we would review resource files for all the cmdline tools to make them consistent. Thanks, Leo On 05/22/2017 11:00 PM, Daniel Fuchs wrote: > Hi Leo, > > On 22/05/2017 15:12, Leo Jiang wrote: >> Hi, >> >> Since the first round of webrev, we got the feedback and suggestion from >> jdk developers. After fixing the translation bugs, and add three new >> messages in compiler.properties, now please help to review the updated >> resources. >> >> Open a new clean thread for 2nd webrev. >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8180167 >> >> CR: >> http://cr.openjdk.java.net/~ljiang/MsgDrop-8180167/webrev.01/jaxp/ >> http://cr.openjdk.java.net/~ljiang/MsgDrop-8180167/webrev.01/jdk/ > > The changes to share/classes/sun/tools/jar/resources/jar_fr.properties > look good to me. That sounds much better, thanks! :-) > > However I'm still a bit puzzled about the java.launcher.opt.header > message in: > share/classes/sun/launcher/resources/launcher_*.properties > It looks like half of the files have translated , and half of > them have not. It's probably a small thing since anyone able to > understand the concept of "main class" should certainly be able > to figure out what "" means - but is there any logic for > translating it in some languages and not translating it in others? > Or is that a bug? > > best regards, > > -- daniel > >> http://cr.openjdk.java.net/~ljiang/MsgDrop-8180167/webrev.01/langtools/ >> >> >> Updates: >> - Added three msgs into compiler.properties. >> - compiler.err.add.exports.with.release >> - compiler.err.add.reads.with.release >> - compiler.err.patch.module.with.release >> - Fixed the missing translation of for French. >> - Removed the underscore in the option values in launcher_es.properties >> - Use English term 'catalog' for some localized version. For rest of >> languages, has the localized term for catalog, don't change. >> - Improved the translation for SimpChinese and TradChinese according to >> Max's suggestion. >> - Improved the translation for Japanese according to Shinya's suggestion. >> - Fixed the bug of translated keyword in jar_[es, fr].properties >> >> Thanks, >> Leo >> >> >> > From li.jiang at oracle.com Mon May 22 17:13:08 2017 From: li.jiang at oracle.com (Leo Jiang) Date: Tue, 23 May 2017 01:13:08 +0800 Subject: RFR: JDK-8180167: (2nd webrev) JDK9 msg drop 40 l10n resource file update In-Reply-To: <3a67bcd2-d2ac-c035-0263-0ebb27dea1f8@oracle.com> References: <138ac02e-57b1-8e52-afe0-67b38cfa964d@oracle.com> <3a67bcd2-d2ac-c035-0263-0ebb27dea1f8@oracle.com> Message-ID: Hi Joe, The linguists believe for some languages the term has its localized version, e.g. German, pt_BR, so not changed. For Chinese, we can tell the translation is inappropriate, so use English term to emphasize/correct the concept. Thanks, Leo On 05/23/2017 12:27 AM, huizhe wang wrote: > Hi Leo, > > On 5/22/2017 7:12 AM, Leo Jiang wrote: >> Hi, >> >> Since the first round of webrev, we got the feedback and suggestion from jdk developers. After fixing the translation >> bugs, and add three new messages in compiler.properties, now please help to review the updated resources. >> >> Open a new clean thread for 2nd webrev. >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8180167 >> >> CR: >> http://cr.openjdk.java.net/~ljiang/MsgDrop-8180167/webrev.01/jaxp/ >> http://cr.openjdk.java.net/~ljiang/MsgDrop-8180167/webrev.01/jdk/ >> http://cr.openjdk.java.net/~ljiang/MsgDrop-8180167/webrev.01/langtools/ >> >> >> Updates: >> - Added three msgs into compiler.properties. >> - compiler.err.add.exports.with.release >> - compiler.err.add.reads.with.release >> - compiler.err.patch.module.with.release >> - Fixed the missing translation of for French. >> - Removed the underscore in the option values in launcher_es.properties >> - Use English term 'catalog' for some localized version. For rest of languages, has the localized term for catalog, >> don't change. > > I don't know the languages, but there seems to be inconsistencies, for example, in CatalogMessages_sv.properties: > 33 InvalidCatalog = JAXP09020001: Dokumentelementet f?r en katalog m?ste vara "catalog". > > This looks ok. But in some other language files, the document element "catalog" was translated, in > CatalogMessages_pt_BR.properties for example: > > 33 InvalidCatalog = JAXP09020001: O elemento de documento de um cat?logo deve ser o cat?logo. > > Thanks, > Joe > >> - Improved the translation for SimpChinese and TradChinese according to Max's suggestion. >> - Improved the translation for Japanese according to Shinya's suggestion. >> - Fixed the bug of translated keyword in jar_[es, fr].properties >> >> Thanks, >> Leo >> >> >> > From huizhe.wang at oracle.com Mon May 22 17:54:42 2017 From: huizhe.wang at oracle.com (huizhe wang) Date: Mon, 22 May 2017 10:54:42 -0700 Subject: RFR: JDK-8180167: (2nd webrev) JDK9 msg drop 40 l10n resource file update In-Reply-To: References: <138ac02e-57b1-8e52-afe0-67b38cfa964d@oracle.com> <3a67bcd2-d2ac-c035-0263-0ebb27dea1f8@oracle.com> Message-ID: <07574d38-2879-a8d0-607d-1fce1794a3a7@oracle.com> It's fine to use its localized version when the "Catalog" means a catalog file, but not so when it represents the name of the document element, that is in a catalog file, in which case or and etc. won't work. -Joe On 5/22/2017 10:13 AM, Leo Jiang wrote: > Hi Joe, > > The linguists believe for some languages the term has its localized > version, e.g. German, pt_BR, so not changed. For Chinese, we can tell > the translation is inappropriate, so use English term to > emphasize/correct the concept. > Thanks, > Leo > > On 05/23/2017 12:27 AM, huizhe wang wrote: >> Hi Leo, >> >> On 5/22/2017 7:12 AM, Leo Jiang wrote: >>> Hi, >>> >>> Since the first round of webrev, we got the feedback and suggestion >>> from jdk developers. After fixing the translation bugs, and add >>> three new messages in compiler.properties, now please help to review >>> the updated resources. >>> >>> Open a new clean thread for 2nd webrev. >>> >>> Bug: >>> https://bugs.openjdk.java.net/browse/JDK-8180167 >>> >>> CR: >>> http://cr.openjdk.java.net/~ljiang/MsgDrop-8180167/webrev.01/jaxp/ >>> http://cr.openjdk.java.net/~ljiang/MsgDrop-8180167/webrev.01/jdk/ >>> http://cr.openjdk.java.net/~ljiang/MsgDrop-8180167/webrev.01/langtools/ >>> >>> >>> Updates: >>> - Added three msgs into compiler.properties. >>> - compiler.err.add.exports.with.release >>> - compiler.err.add.reads.with.release >>> - compiler.err.patch.module.with.release >>> - Fixed the missing translation of for French. >>> - Removed the underscore in the option values in >>> launcher_es.properties >>> - Use English term 'catalog' for some localized version. For rest >>> of languages, has the localized term for catalog, don't change. >> >> I don't know the languages, but there seems to be inconsistencies, >> for example, in CatalogMessages_sv.properties: >> 33 InvalidCatalog = JAXP09020001: Dokumentelementet f?r en katalog >> m?ste vara "catalog". >> >> This looks ok. But in some other language files, the document element >> "catalog" was translated, in CatalogMessages_pt_BR.properties for >> example: >> >> 33 InvalidCatalog = JAXP09020001: O elemento de documento de um >> cat?logo deve ser o cat?logo. >> >> Thanks, >> Joe >> >>> - Improved the translation for SimpChinese and TradChinese >>> according to Max's suggestion. >>> - Improved the translation for Japanese according to Shinya's >>> suggestion. >>> - Fixed the bug of translated keyword in jar_[es, fr].properties >>> >>> Thanks, >>> Leo >>> >>> >>> >> From daniel.fuchs at oracle.com Mon May 22 18:36:53 2017 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Mon, 22 May 2017 19:36:53 +0100 Subject: RFR: JDK-8180167: (2nd webrev) JDK9 msg drop 40 l10n resource file update In-Reply-To: <35f0d47d-a090-cf20-6e1c-b11bd9dc02b5@oracle.com> References: <138ac02e-57b1-8e52-afe0-67b38cfa964d@oracle.com> <35f0d47d-a090-cf20-6e1c-b11bd9dc02b5@oracle.com> Message-ID: <2a1e5ab8-5dc1-92de-e943-553ad29fa6d6@oracle.com> On 22/05/17 18:06, Leo Jiang wrote: > Hi Daniel, > > According to current translatability guideline, we would not translate > mainclass like word. We're working on a guideline for translator to > avoid the inconsistent. In the future, we would review resource files > for all the cmdline tools to make them consistent. Thanks Leo! -- daniel > > Thanks, > Leo > > On 05/22/2017 11:00 PM, Daniel Fuchs wrote: >> Hi Leo, >> >> On 22/05/2017 15:12, Leo Jiang wrote: >>> Hi, >>> >>> Since the first round of webrev, we got the feedback and suggestion from >>> jdk developers. After fixing the translation bugs, and add three new >>> messages in compiler.properties, now please help to review the updated >>> resources. >>> >>> Open a new clean thread for 2nd webrev. >>> >>> Bug: >>> https://bugs.openjdk.java.net/browse/JDK-8180167 >>> >>> CR: >>> http://cr.openjdk.java.net/~ljiang/MsgDrop-8180167/webrev.01/jaxp/ >>> http://cr.openjdk.java.net/~ljiang/MsgDrop-8180167/webrev.01/jdk/ >> >> The changes to share/classes/sun/tools/jar/resources/jar_fr.properties >> look good to me. That sounds much better, thanks! :-) >> >> However I'm still a bit puzzled about the java.launcher.opt.header >> message in: >> share/classes/sun/launcher/resources/launcher_*.properties >> It looks like half of the files have translated , and half of >> them have not. It's probably a small thing since anyone able to >> understand the concept of "main class" should certainly be able >> to figure out what "" means - but is there any logic for >> translating it in some languages and not translating it in others? >> Or is that a bug? >> >> best regards, >> >> -- daniel >> >>> http://cr.openjdk.java.net/~ljiang/MsgDrop-8180167/webrev.01/langtools/ >>> >>> >>> Updates: >>> - Added three msgs into compiler.properties. >>> - compiler.err.add.exports.with.release >>> - compiler.err.add.reads.with.release >>> - compiler.err.patch.module.with.release >>> - Fixed the missing translation of for French. >>> - Removed the underscore in the option values in launcher_es.properties >>> - Use English term 'catalog' for some localized version. For rest of >>> languages, has the localized term for catalog, don't change. >>> - Improved the translation for SimpChinese and TradChinese according to >>> Max's suggestion. >>> - Improved the translation for Japanese according to Shinya's >>> suggestion. >>> - Fixed the bug of translated keyword in jar_[es, fr].properties >>> >>> Thanks, >>> Leo >>> >>> >>> >> From lana.steuck at oracle.com Wed May 24 19:18:14 2017 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 24 May 2017 19:18:14 GMT Subject: jdk9-b171: dev Message-ID: <201705241918.v4OJIEC5019640@scaaa563.us.oracle.com> http://hg.openjdk.java.net/jdk9/jdk9/rev/4c12464a907d http://hg.openjdk.java.net/jdk9/jdk9/nashorn/rev/fc416270a776 http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/aae59039c1f5 http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/29bbedd4cce8 http://hg.openjdk.java.net/jdk9/jdk9/jaxws/rev/139e7c786ee4 http://hg.openjdk.java.net/jdk9/jdk9/jaxp/rev/c27321c889cf http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/d53171650a2c http://hg.openjdk.java.net/jdk9/jdk9/corba/rev/c62e5964cfcf --- All the fixes will be tested during promotion (no PIT testing at this point): List of all fixes: =================== JDK-8180452 client-libs Mark ClipCloseLoss.java as failing intermittently JDK-7086489 core-libs File.lastModified should specify accuracy as well as resolution JDK-8180424 core-libs Another build issue on AIX after 8034174 JDK-8180431 core-libs Remove "intermittent" keyword from some no longer failing NIO tests JDK-8180498 core-libs Remove httpclient internal APIs which supply ByteBuffers to read calls JDK-8180633 core-libs Remove intermittent key from java/lang/ClassLoader/Assert.java JDK-8175845 core-svc Provide javadoc descriptions for jdk.hotspot.agent module JDK-8178800 hotspot compiler/c2/PolynomialRoot.java fails on Xeon Phi linux host with UseA JDK-8180511 hotspot Null pointer dereference in Matcher::ReduceInst() JDK-8180565 hotspot Null pointer dereferences of ConstMethod::method() JDK-8180575 hotspot Null pointer dereference in LoadNode::Identity() JDK-8180576 hotspot Null pointer dereference in Matcher::xform() JDK-8180617 hotspot Null pointer dereference in InitializeNode::complete_stores JDK-8180721 hotspot clean up ProblemList JDK-8180793 hotspot move jdk.test.lib.wrappers.* to jdk.test.lib package JDK-8180318 infrastructure Enable HTML 5 checking at compile time. JDK-8180426 infrastructure Use standard css file for new docs bundle index.html page JDK-8180453 infrastructure [JVMCI] mx eclipseinit doesn't pick up generated sources JDK-8180472 infrastructure Pandoc should generate html5 from markdown JDK-8180480 infrastructure Use "requires transitive" relationship when determining modules for ja JDK-8180540 infrastructure Add pandoc build fix for windows JDK-8180717 infrastructure Upgrade the docs bundle index page JDK-8176745 security-libs Drop SSLContext TLSv1 cipher suite requirements JDK-8180307 security-libs Update JDK 9 Required Cipher Algorithms JDK-8180447 tools Trailing space in JDK_JAVA_OPTIONS causes an application fail to launc JDK-8180486 tools extLink taglet needs escaped "&" JDK-8180385 xml Fix HTML5 issues in the java.xml module From mark.reinhold at oracle.com Tue May 30 19:53:33 2017 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 30 May 2017 12:53:33 -0700 (PDT) Subject: Proposed schedule change for JDK 9 Message-ID: <20170530195333.C452CECC7A@eggemoggin.niobe.net> As you probably know by now, the JCP Executive Committee (EC) recently voted [1] not to approve JSR 376, the Java Platform Module System [2], for the next stage of the process. This vote does not mean that JSR 376 is dead, nor that Jigsaw has been rejected. It only means that the EC raised a number of concerns that it wanted the JSR 376 Expert Group (EG) to address. The JCP rules give the EG thirty days, until 7 June, to submit a revised specification for a second EC vote, which will end no later than 26 June [3]. The JSR 376 EG held a series of conference calls over the past two weeks in order discuss the EC's concerns [4]. The net impact of those meetings on JDK 9 itself was to clarify the specification of the module system's resolution algorithm, work on which had already begun, and to add one five-line method to the module-system API. These changes, together with additional clarifications to the JSR 376 and JSR 379 (Java SE 9) [5] Specifications, will hopefully address the EC's concerns. In order to be ready for all possible outcomes I suggest that here in the JDK 9 Project we continue to work toward the current goal of producing an initial Release Candidate build on 22 June [6], but adjust the GA date in order to accommodate the additional time required to move through the JCP process. To be specific, I propose that we move the GA date out by eight weeks, from 27 July to 21 September. Comments on this proposal from JDK 9 Committers are welcome, as are reasoned objections. If no such objections are raised by 23:00 UTC next Tuesday, 6 June, or if they're raised and satisfactorily answered, then per the JEP 2.0 process proposal [7] this will be the new schedule for JDK 9. - Mark [1] https://jcp.org/en/jsr/results?id=5959 [2] http://openjdk.java.net/projects/jigsaw/spec/ [3] https://www.jcp.org/en/procedures/jcp2#3.4.5 [4] http://openjdk.java.net/projects/jigsaw/spec/#Meeting-minutes [5] http://openjdk.java.net/projects/jdk9/spec/ [6] http://openjdk.java.net/projects/jdk9/ [7] http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html From lana.steuck at oracle.com Wed May 31 20:36:59 2017 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 31 May 2017 20:36:59 GMT Subject: jdk9-b172: dev Message-ID: <201705312036.v4VKaxHH009932@scaaa563.us.oracle.com> http://hg.openjdk.java.net/jdk9/jdk9/rev/2c25fc241032 http://hg.openjdk.java.net/jdk9/jdk9/nashorn/rev/c8d6b740f0f7 http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/03669efa77f5 http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/0ff9ad7d067c http://hg.openjdk.java.net/jdk9/jdk9/jaxws/rev/8c615099f3e3 http://hg.openjdk.java.net/jdk9/jdk9/jaxp/rev/eedb6e54c8bd http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/1ae9e84f68b3 http://hg.openjdk.java.net/jdk9/jdk9/corba/rev/95ed14547ca9 --- All the fixes will be tested during promotion (no PIT testing at this point): List of all fixes: =================== JDK-8066005 client-libs java.awt.event.KeyEvent.originalSource doesn't have "since" tag in Ser JDK-8169897 client-libs [PIT] javax/swing/plaf/basic/BasicGraphicsUtils/8132119/bug8132119.jav JDK-8175915 client-libs NullPointerException from JComboBox and JList when Accessibility enabl JDK-8177393 client-libs Result of RescaleOp for 4BYTE_ABGR images may be 25% black JDK-8177628 client-libs Opensource unit/regression tests for ImageIO JDK-8178383 client-libs Validation of FileIO in the tests for JavaSound should be stricter JDK-8178996 client-libs [macos] JComboBox doesn't display popup in mixed JavaFX Swing Applicat JDK-8179014 client-libs JFileChooser with Windows look and feel crashes on win 10 JDK-8179665 client-libs [Windows] java.awt.IllegalComponentStateException: component must be s JDK-8074977 core-libs Constructor.getAnnotatedParameterTypes returns wrong value JDK-8175131 core-libs sun.rmi.transport.tcp.TCPChannel.createConnection close connection on JDK-8180279 core-libs java/net/httpclient/whitebox/Driver.java failed due to timeout JDK-8180353 core-libs FileOutputStream documentation does not indicate properly whether file JDK-8180428 core-libs Clarify implementation note in Clock.java to match implementation chan JDK-8180728 core-libs DatabaseMetaData.getRowIdLifetime() refers to an int return value rath JDK-8180807 core-libs java.io.Serializable class-level readObject description error JDK-8180885 core-libs Create test to detect if TimeZone.setDefault affects File.setLastModif JDK-8180949 core-libs Correctly handle exception in TCPChannel.createConnection JDK-8179200 deploy "Request authentication" dialog from Java is blank JDK-8180139 deploy [test] Test for JDK-8176059: Better update checking for jdk9 JDK-8180909 deploy [test] Blocked dialog does not show up JDK-8180915 deploy The app can not be blocked. JDK-8180916 deploy At step5.There is no security dialog,but there is a native dialog with JDK-8180920 deploy The app will be blocked once the app is launched JDK-8180926 deploy At step5,the dialog title is not "Application Blocked for Security". JDK-8180167 globalization JDK9 msg drop 40 l10n resource file update JDK-8180813 hotspot Null pointer dereference of CodeCache::find_blob() result JDK-8180855 hotspot Null pointer dereference in OopMapSet::all_do of oopMap.cpp:394 JDK-8175824 infrastructure Adapt javadoc generation to different requirements for JDK and JavaSE JDK-8180574 tools tools/launcher/modules/patch/systemmodules/PatchSystemModules.java fai JDK-8181033 tools Confusing message: A JNI error has occurred, please check your install JDK-8180349 xml Review JAXP Java SE 9 API javadocs