September 2018 - core-libs-dev

[12] RFR of JDK-8209832: Refactor jdk/internal/reflect/Reflection/GetCallerClassTest.sh to plain java test
by Amy Lu 04 Sep '18

04 Sep '18

test/jdk/jdk/internal/reflect/Reflection/GetCallerClassTest.sh Please review this patch to refactor above shell script test to java. bug: https://bugs.openjdk.java.net/browse/JDK-8209832 webrev: http://cr.openjdk.java.net/~amlu/8209832/webrev.00/ Thanks, Amy

3 4

StackWalker::getCallerClass throws UnsupportedOperationException
by Michael Rasmussen 04 Sep '18

04 Sep '18

Hi StackWalker::getCallerClass can throw "UnsupportedOperationException: StackWalker::getCallerClass called from @CallerSensitive", depending on how the underlying fetchNextBatch/fill_in_frames splits the stacktrace. This seems to be a result of what was introduced in JDK-8157464. The following code example produces the exception (Tested on the jdk.java.net releases of OpenJDK 10 and 11-ea build 28): // ----- snip ---- package com.test; import java.lang.reflect.Method; public class Main { public static void main(String[] args) throws Exception { Method method = Main.class.getDeclaredMethod("bar"); Method m = Method.class.getMethod("invoke", Object.class, Object[].class); // get 'm' past compilation threshold for (int i = 0; i < 15; i++) { m.invoke(Main.class.getDeclaredMethod("dummy"), null, null); } m.invoke(m, m, new Object[] {method, new Object[] {null, null}}); } static void dummy() { } static void bar() { System.out.println(StackWalker.getInstance(StackWalker.Option.RETAIN_CLASS_REFERENCE).getCallerClass()); } } // ----- snip ---- The above code is constructed so Method::invoke ends up as the frame for which index==start_index in fill_in_frames, thus causing the exception. For example output, including stackwalk debug output, see below. // ----- snip ---- $ java -Xlog:stackwalk=debug com.test.Main [0.154s][debug][stackwalk] Start walking: mode 6 skip 0 frames batch size 6 [0.155s][debug][stackwalk] skip java.lang.StackStreamFactory$AbstractStackWalker::callStackWalk [0.156s][debug][stackwalk] skip java.lang.StackStreamFactory$AbstractStackWalker::beginStackWalk [0.157s][debug][stackwalk] skip java.lang.StackStreamFactory$AbstractStackWalker::walk [0.158s][debug][stackwalk] skip java.lang.StackStreamFactory$CallerClassFinder::findCaller [0.159s][debug][stackwalk] skip java.lang.StackWalker::getCallerClass [0.160s][debug][stackwalk] fill_in_frames limit=6 start=2 frames length=8 [0.161s][debug][stackwalk] 2: frame method: com.test.Main::bar bci=9 [0.162s][debug][stackwalk] 3: frame method: jdk.internal.reflect.NativeMethodAccessorImpl::invoke0 bci=0 [0.162s][debug][stackwalk] 4: frame method: jdk.internal.reflect.NativeMethodAccessorImpl::invoke bci=100 [0.163s][debug][stackwalk] 5: frame method: jdk.internal.reflect.DelegatingMethodAccessorImpl::invoke bci=6 [0.163s][debug][stackwalk] 6: frame method: java.lang.reflect.Method::invoke bci=59 [0.168s][debug][stackwalk] 7: frame method: jdk.internal.reflect.GeneratedMethodAccessor1::invoke bci=48 [0.169s][debug][stackwalk] StackWalk::fetchNextBatch frame_count 8 existing_stream 0x000000a5b8ffb5f0 start 2 frames 10 [0.170s][debug][stackwalk] fill_in_frames limit=8 start=2 frames length=10 [0.171s][debug][stackwalk] 2: frame method: jdk.internal.reflect.DelegatingMethodAccessorImpl::invoke bci=6 [0.171s][debug][stackwalk] 3: frame method: java.lang.reflect.Method::invoke bci=59 [0.172s][debug][stackwalk] 4: frame method: jdk.internal.reflect.GeneratedMethodAccessor1::invoke bci=48 [0.173s][debug][stackwalk] 5: frame method: jdk.internal.reflect.DelegatingMethodAccessorImpl::invoke bci=6 [0.174s][debug][stackwalk] 6: frame method: java.lang.reflect.Method::invoke bci=59 [0.175s][debug][stackwalk] 7: frame method: jdk.internal.reflect.NativeMethodAccessorImpl::invoke0 bci=0 [0.175s][debug][stackwalk] 8: frame method: jdk.internal.reflect.NativeMethodAccessorImpl::invoke bci=100 [0.179s][debug][stackwalk] 9: frame method: jdk.internal.reflect.DelegatingMethodAccessorImpl::invoke bci=6 [0.180s][debug][stackwalk] StackWalk::fetchNextBatch frame_count 8 existing_stream 0x000000a5b8ffb5f0 start 2 frames 10 [0.181s][debug][stackwalk] fill_in_frames limit=8 start=2 frames length=10 [0.181s][debug][stackwalk] 2: frame method: java.lang.reflect.Method::invoke bci=59 Exception in thread "main" java.lang.reflect.InvocationTargetException at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:566) at com.test.Main.main(Main.java:15) Caused by: java.lang.reflect.InvocationTargetException at java.base/jdk.internal.reflect.GeneratedMethodAccessor1.invoke(Unknown Source) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:566) ... 5 more Caused by: java.lang.reflect.InvocationTargetException at java.base/jdk.internal.reflect.GeneratedMethodAccessor1.invoke(Unknown Source) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:566) ... 8 more Caused by: java.lang.reflect.InvocationTargetException at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:566) ... 11 more Caused by: java.lang.UnsupportedOperationException: StackWalker::getCallerClass called from @CallerSensitive java.lang.reflect.Method.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object; method at java.base/java.lang.StackStreamFactory$AbstractStackWalker.fetchStackFrames(Native Method) at java.base/java.lang.StackStreamFactory$AbstractStackWalker.fetchStackFrames(StackStreamFactory.java:386) at java.base/java.lang.StackStreamFactory$AbstractStackWalker.getNextBatch(StackStreamFactory.java:322) at java.base/java.lang.StackStreamFactory$AbstractStackWalker.peekFrame(StackStreamFactory.java:263) at java.base/java.lang.StackStreamFactory$AbstractStackWalker.hasNext(StackStreamFactory.java:351) at java.base/java.lang.StackStreamFactory$AbstractStackWalker.nextFrame(StackStreamFactory.java:336) at java.base/java.lang.StackStreamFactory$CallerClassFinder.consumeFrames(StackStreamFactory.java:683) at java.base/java.lang.StackStreamFactory$CallerClassFinder.consumeFrames(StackStreamFactory.java:612) at java.base/java.lang.StackStreamFactory$AbstractStackWalker.doStackWalk(StackStreamFactory.java:306) at java.base/java.lang.StackStreamFactory$AbstractStackWalker.callStackWalk(Native Method) at java.base/java.lang.StackStreamFactory$AbstractStackWalker.beginStackWalk(StackStreamFactory.java:370) at java.base/java.lang.StackStreamFactory$AbstractStackWalker.walk(StackStreamFactory.java:243) at java.base/java.lang.StackStreamFactory$CallerClassFinder.findCaller(StackStreamFactory.java:670) at java.base/java.lang.StackWalker.getCallerClass(StackWalker.java:600) at com.test.Main.bar(Main.java:21) ... 15 more // ----- snip ---- Kind regards /Michael

2 1

RFR - 8210366: Typo in MethodHandles.Lookup: must be either be
by Daniel Fuchs 04 Sep '18

04 Sep '18

Hi, This is a simple doc-only fix for a typo in MethodHandles.Lookup: 8210366: Typo in MethodHandles.Lookup: must be either be https://bugs.openjdk.java.net/browse/JDK-8210366 patch: ---------------------------------------------------------------------------- diff --git a/src/java.base/share/classes/java/lang/invoke/MethodHandles.java b/src/java.base/share/classes/java/lang/invoke/MethodHandles.java --- a/src/java.base/share/classes/java/lang/invoke/MethodHandles.java +++ b/src/java.base/share/classes/java/lang/invoke/MethodHandles.java @@ -450,7 +450,7 @@ * independently of any {@code Lookup} object. * <p> * If the desired member is {@code protected}, the usual JVM rules apply, - * including the requirement that the lookup class must be either be in the + * including the requirement that the lookup class must either be in the * same package as the desired member, or must inherit that member. * (See the Java Virtual Machine Specification, sections 4.9.2, 5.4.3.5, and 6.4.) * In addition, if the desired member is a non-static field or method ---------------------------------------------------------------------------- best regards, -- daniel

2 1

RFR: 8209937: Enhance java.io.Console - provide methods to query console width and height
by Langer, Christoph 04 Sep '18

04 Sep '18

Hi, please review and give feedback for this augmentation of java.io.Console. We have users that have the need to query for Width and Height of the console device in Java. In our own JVM implementation we had given them this hook as a custom extension already quite some time ago. We think, however, that it is a worthwhile augmentation of java.io.Console. Bug: https://bugs.openjdk.java.net/browse/JDK-8209937 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8209937.0/ I'll also open a CSR for this, but I'll wait for some feedback on our proposal first. Thanks & Best regards Christoph

5 7

RFR: JDK-8197398, (zipfs) Files.walkFileTree walk indefinitelly while processing JAR file with "/" as a directory inside.
by Xueming Shen 03 Sep '18

03 Sep '18

Hi, Please help review the proposed change for JDK-8197398. issue: https://bugs.openjdk.java.net/browse/JDK-8197398 webrev: http://cr.openjdk.java.net/~sherman/8197398/webrev A little background: The existing zipfs has an assumption that the "normal/healthy/secured" zip/jar file should not include any entry that has an absolute path, root "/" included. Various jar/zip tools have been fixed/patched in the past years to avoid create such a jar/zip file for security reason. But there are zip/jar files in the wild that do include absolute paths and do include a "/" root sometime, the offending jar file included in the bug report is just one of those. With this "wrong" assumption, the existing zipfs implementation always add a pseudo root directory before building the internal inode tree and unfortunately attaches the "real" root entry (exists in the jar/zip file) to be its child, in which trigger a circle when iteration. The proposed change is to solve this problem by only adding the pseudo root when there is no real root in the zip/jar file. Further the proposed change will try to "normalize" the zip/jar file when it has any update needs to sync/write the update to the underlying zip/jar file when closing, by removing any absolute path for all the entries, root "/" included, with the assumption that the zipfis implementation should never create/generate an unsecured zip/jar file. Thanks, Sherman

2 3

Are TimeZone instances guaranteed to be thread-safe
by Bernd Eckenfels 01 Sep '18

01 Sep '18

Hello, I am not sure I missed it, but it looks like there is no definition in the JCL JavaDoc about instances of j.u.TimeZone (specifically SimpleTimeZone as well as instances obtained with getDefault or by Id) beeing reentrant/thread Safe or not. (There are for examplequite a few non-final fields in SimpleTimeZone as well), Since TimeZone is used together with Calendar it might be natural for developers to know. Is there a helper/factory which would allow access to some standard timezones (at least GMT/UTC). This might be especially useful if we cannot define TimeZone instances generally as thread safe, because then we can at least declare it for this „fast“ implementation. [ Background of my question is BTW the rs.getTimestamp(idx, Calendar) method in the JDBC API where the need for constructing a Calendar object is painful and it would help if I could at least use new Calendar(SimpleTimeZone.UTC). (And having an alternative like getTimestamp(Int, ZoneId) would be even better ] I can imagine naming it GMT vs. UTC might also be a nice bike shed. Gruss Bernd -- http://bernd.eckenfels.net

1 1