Security-dev, If we can live with "engine=keystore" happily, why not just make the whole string lowercase and search for "permission=java.io.filepermission"? I don't think there are permission types or URL names that are only different in cases. Although file names are case-sensitive in Unix, I doubt if any customer will complain if we show him info on /ETC even if what he sets is "codebase=/etc".
We can add new methods like hasCodebase(URL) and hasPermission(Class<? extends Permission>) to hide the search details inside Debug. Thanks Max > On May 10, 2016, at 1:36 PM, Xueming Shen <xueming.s...@oracle.com> wrote: > > Hi, > > While testing for the attached regex changes, a fatal vm init error was > triggered for test > case with -Djava.security.debug=xyz turned on, as showed in following > stacktrace. > > It appears sun.security.util.Debug is being initialized even before the > lambda is ready > for use, and unfortunately it uses j.u.regex (for its args parsing), which is > being migrated > to use lambda function in the proposed regex change. > > Since Debug is the only class now triggers j.u.regex -> lambda during > initialization, it > is suggested to update/rewrite the related method in Debug to NOT use > j.u.regex to > solve/workaround this specific initialization issue. > > The webrev below has been updated to include such a change. > > http://cr.openjdk.java.net/~sherman/regexBackTrack.Lamnda.CanonEQ/webrev/ > > The sun.security.util.Debug related change is at > > http://cr.openjdk.java.net/~sherman/regexBackTrack.Lamnda.CanonEQ/webrev/src/java.base/share/classes/sun/security/util/Debug.java.sdiff.html > > Can security-dev guys help take a look if this is an acceptable/reasonable > approach. > > Thanks, > Sherman > > ----------------------------------------------------------------------------- > Caused by: java.lang.ExceptionInInitializerError > > > at > jdk.internal.loader.BootLoader.loadClassOrNull(java.base/BootLoader.java:110) > at > java.lang.invoke.BoundMethodHandle$Factory$1.apply(java.base/BoundMethodHandle.java:497) > at > java.lang.invoke.BoundMethodHandle$Factory$1.apply(java.base/BoundMethodHandle.java:492) > ... > at > java.lang.invoke.MethodHandleNatives.linkCallSite(java.base/MethodHandleNatives.java:240) > at java.util.regex.Pattern.<clinit>(java.base/Pattern.java:5682) > at sun.security.util.Debug.marshal(java.base/Debug.java:247) > at sun.security.util.Debug.<clinit>(java.base/Debug.java:59) > at > java.security.ProtectionDomain.<clinit>(java.base/ProtectionDomain.java:142) > at > jdk.internal.misc.InnocuousThread.<clinit>(java.base/InnocuousThread.java:129) > at > jdk.internal.ref.CleanerFactory$1$1.run(java.base/CleanerFactory.java:48) > at > jdk.internal.ref.CleanerFactory$1$1.run(java.base/CleanerFactory.java:45) > at java.security.AccessController.doPrivileged(java.base/Native Method) > at > jdk.internal.ref.CleanerFactory$1.newThread(java.base/CleanerFactory.java:45) > at jdk.internal.ref.CleanerImpl.start(java.base/CleanerImpl.java:116) > at java.lang.ref.Cleaner.create(java.base/Cleaner.java:203) > at > jdk.internal.ref.CleanerFactory.<clinit>(java.base/CleanerFactory.java:42) > at sun.nio.fs.NativeBuffer.<init>(java.base/NativeBuffer.java:60) > at > sun.nio.fs.NativeBuffers.allocNativeBuffer(java.base/NativeBuffers.java:49) > at > sun.nio.fs.UnixNativeDispatcher.copyToNativeBuffer(java.base/UnixNativeDispatcher.java:44) > at > sun.nio.fs.UnixNativeDispatcher.stat(java.base/UnixNativeDispatcher.java:306) > at > sun.nio.fs.UnixFileSystemProvider.isRegularFile(java.base/UnixFileSystemProvider.java:514) > at java.nio.file.Files.isRegularFile(java.base/Files.java:2244) > at > java.lang.module.ModuleFinder.ofSystem(java.base/ModuleFinder.java:165) > at > jdk.internal.module.ModuleBootstrap.boot(java.base/ModuleBootstrap.java:105) > at java.lang.System.initPhase2(java.base/System.java:1924) > > --------------------------------------------------------------------------------- > > > On 3/18/16 1:05 PM, Xueming Shen wrote: >> Hi, >> >> There are couple regex related changes waiting for review. I have pull them >> together here (with the notes) to make it easy to review. >> >> http://cr.openjdk.java.net/~sherman/regexBackTrack.Lamnda.CanonEQ/webrev/ >> >> (1) Exponential backtracking >> >> Note: >> http://cr.openjdk.java.net/~sherman/regexBackTrack.Lamnda.CanonEQ/backtracking >> >> https://bugs.openjdk.java.net/browse/JDK-6328855 >> https://bugs.openjdk.java.net/browse/JDK-6192895 >> https://bugs.openjdk.java.net/browse/JDK-6345469 >> https://bugs.openjdk.java.net/browse/JDK-6988218 >> https://bugs.openjdk.java.net/browse/JDK-6693451 >> https://bugs.openjdk.java.net/browse/JDK-7006761 >> https://bugs.openjdk.java.net/browse/JDK-8140212 >> >> (2) Anonymous class to lambda function cleanup >> >> Note: >> http://cr.openjdk.java.net/~sherman/regexBackTrack.Lamnda.CanonEQ/lambdafunction >> >> https://bugs.openjdk.java.net/browse/JDK-8151481 >> https://bugs.openjdk.java.net/browse/JDK-6609854 >> >> (3) Canonical Equivalents >> >> Note: >> http://cr.openjdk.java.net/~sherman/regexBackTrack.Lamnda.CanonEQ/canonEQ >> >> https://bugs.openjdk.java.net/browse/JDK-4916384 >> https://bugs.openjdk.java.net/browse/JDK-4867170 >> https://bugs.openjdk.java.net/browse/JDK-6995635 >> https://bugs.openjdk.java.net/browse/JDK-6728861 >> https://bugs.openjdk.java.net/browse/JDK-6736245 >> https://bugs.openjdk.java.net/browse/JDK-7080302 >> >> Thanks >> Sherman >
