From sundararajan.athijegannathan at oracle.com Mon Aug 1 03:29:20 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Mon, 1 Aug 2016 08:59:20 +0530 Subject: RFR 8162782: jlink ResourcePool.releaseProperties should be removed In-Reply-To: References: <7a816ec0-b76f-f161-304a-301f2b9166a5@oracle.com> <441873e0-4db0-6eae-f967-97ec378a0625@oracle.com> Message-ID: <96f9ffe2-392d-d360-a502-19c5a8141027@oracle.com> Hi, I'll handle that issue in another fix. Thanks, -Sundar On 7/29/2016 8:42 PM, Alan Bateman wrote: > > > On 29/07/2016 15:52, Sundararajan Athijegannathan wrote: >> I just checked release file in custom image generated by jlink. It has >> OS_NAME, OS_ARCH (may be after current cleanup). JAVA_HOME is missing. >> I'll add that. >> >> PS. Should I do that separate fix or part of the current fix? >> > Up to you, I only mentioned it as it's same place in the code. > > -Alan From felix.yang at oracle.com Mon Aug 1 06:48:28 2016 From: felix.yang at oracle.com (Felix Yang) Date: Mon, 1 Aug 2016 14:48:28 +0800 Subject: RFR 8157135, Fix module dependencies javax/* EE tests Message-ID: Hi all, please review the patch for some tests, which explicitly declare module dependencies to EE modules. Bug: https://bugs.openjdk.java.net/browse/JDK-8157135 Webrev: http://cr.openjdk.java.net/~xiaofeya/8157135/webrev.00/ This is a partial fix left by https://bugs.openjdk.java.net/browse/JDK-8155088. The fix had been hold off for a moment, to wait for new jtreg with resolved https://bugs.openjdk.java.net/browse/CODETOOLS-7901671. Otherwise those tests will be ignored silently. Thanks, Felix From dalibor.topic at oracle.com Mon Aug 1 10:40:39 2016 From: dalibor.topic at oracle.com (dalibor topic) Date: Mon, 1 Aug 2016 12:40:39 +0200 Subject: Exporting - the wrong default? In-Reply-To: <80d34193-5846-e792-bc64-8b12ea118fb4@redhat.com> References: <03d2c64f-4d24-f303-112f-2e6baa0514c2@oracle.com> <4f49aa3a-4f87-0ca7-4f5e-6048bfbd1b04@oracle.com> <80d34193-5846-e792-bc64-8b12ea118fb4@redhat.com> Message-ID: On 29.07.2016 16:55, David M. Lloyd wrote: > On 07/29/2016 09:20 AM, dalibor topic wrote: >> >> Is it safe to assume that all potentially headache inducing Guns and >> Bullets are always kept under lock in non-public classes? > > Of course, that's why we had non-public classes in the first place. OK, let's assume that's correct for the deliberate headache instrument hiding decisions made by all Java developers for the sake of the argument. To balance that assumption out, please grant me an assumption as well: Let's assume for the sake of the argument that not all Java developers are experts all the time, and therefore some of them might sometimes produce classes that could be abused as headache inducing Slings and Stones. Is it safe to assume that all such involuntarily headache inducing Slings and Stones are also kept under lock in non-public classes? cheers, dalibor topic -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From adinn at redhat.com Mon Aug 1 11:36:34 2016 From: adinn at redhat.com (Andrew Dinn) Date: Mon, 1 Aug 2016 12:36:34 +0100 Subject: Exporting - the wrong default? In-Reply-To: <579BB8FD.9070401@oracle.com> References: <45d10b60-a0ab-9019-87fd-6491ae148fb7@oracle.com> <5799C6B6.5060104@redhat.com> <579A81C0.1040901@oracle.com> <579B3CFC.4040202@redhat.com> <579BB8FD.9070401@oracle.com> Message-ID: <579F3442.80908@redhat.com> On 29/07/16 21:13, Alex Buckley wrote: > Mark already discussed with Jason how a container can rewrite > descriptors as modules are being spun up [1] so I'm struggling to see > the problem unless there is some burning desire to rewrite the > descriptor by hand prior to run time. I can understand that if Sanne > takes third party JARs containing no descriptors, and manually creates > descriptors by spying on the POMs, then sure it's nice to keep the > descriptors external and the JARs unchanged ... but a Jigsaw modular JAR > already contains a descriptor that we assume is authoritative unless a > container is rewriting at run time. Yes, I had already read that discussion and I am hoping it can continue to a point where it reaches a more definitive and actionable conclusion. Firstly, I'll note that it was merely that -- a discussion. It was not a conclusive investigation (let alone resolution) of the all the problems that might be involved in providing the functionality required to manage exports in the way Mark suggested. So, the suggestion that Jigsaw provides all the functionality that is needed would not (yet) seem to me to be warranted. Secondly, the ability to rewrite import export relations at runtime when constructing module Layers does not of itself remove any of the complexity resulting from baking module descriptors into deployments. It merely removes the stopper from the fly bottle -- the fly still needs to work out how to locate and attain the exit. Now, if the fly was never led into the fly-bottle in the first place ... Thirdly, I think there are still outstanding issues on the table which may invalidate this proposed solution (#CyclicDependences, #MutableConfigurations). Indeed, Jason's response to Mark referred to the latter issue (albeit not by name) and I don't think the response really took into account the potential for problems in this area. In particular, in a runtime where stopping and restarting of services along with all their dependents may happen repeatedly and regularly issue #MutableConfigurations may well transmute into issue #LazyConfigurationAndInstantiation. Jigsaw really is not built to support the removal and reinstallation of modules. Whether or not its Layer concept is adequate to the needs of containers for which this is a critical capability appears to me still to be an open question. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From adinn at redhat.com Mon Aug 1 11:51:46 2016 From: adinn at redhat.com (Andrew Dinn) Date: Mon, 1 Aug 2016 12:51:46 +0100 Subject: Flag missing with "requires java.base"? In-Reply-To: <579BA1BD.5030105@oracle.com> References: <579A4C2E.9020206@oracle.com> <579B0A5A.2020104@redhat.com> <579BA1BD.5030105@oracle.com> Message-ID: <579F37D2.8000808@redhat.com> On 29/07/16 19:34, Alex Buckley wrote: > On 7/29/2016 12:48 AM, Andrew Dinn wrote: >> It might be worth pointing out at this stage in the discussion that >> ACC_SYNTHETIC was never given a hard and fast meaning whose logic >> transcends the vagaries of what javac decided to use it for -- citation, >> Neal Gafter in a thread I was involved in many years ago on the meaning >> of this term: >> >> Said definition: >> >> http://mail.openjdk.java.net/pipermail/compiler-dev/2010-August/002257.html >> >> >> and explanation: >> >> http://mail.openjdk.java.net/pipermail/compiler-dev/2010-August/002258.html >> > > On the contrary, Neal and I agree on the hard and fast meaning of > ACC_SYNTHETIC. The second link says: ... Well, it's rather a moot point as to whether it is you and Neal or, as I phrased it, "the vagaries of what javac decided to use [SYNTHETIC] for" that constitutes the determining factor since obviously javac didn't really 'decide' anything except by way of proxy for those who informed it's construction as a piece of code. My point was not that ACC_SYNTHETIC did not have a determinate meaning (which is what you seem to take me as saying) rather that the decision as to what it means was made within the scope of what javac wanted to do with this property and that said meaning is not up for grabs for some external program to freight with its own semantic content. That is precisely (yes, I do mean precisely) what my exchange with Neal established. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From Alan.Bateman at oracle.com Mon Aug 1 12:00:05 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 1 Aug 2016 05:00:05 -0700 Subject: RFR 8157135, Fix module dependencies javax/* EE tests In-Reply-To: References: Message-ID: <25b5a7ba-8818-e1e7-d563-120644b33813@oracle.com> On 31/07/2016 23:48, Felix Yang wrote: > Hi all, > > please review the patch for some tests, which explicitly declare > module dependencies to EE modules. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8157135 > > Webrev: http://cr.openjdk.java.net/~xiaofeya/8157135/webrev.00/ > > This is a partial fix left by > https://bugs.openjdk.java.net/browse/JDK-8155088. The fix had been > hold off for a moment, to wait for new jtreg with resolved > https://bugs.openjdk.java.net/browse/CODETOOLS-7901671. Otherwise > those tests will be ignored silently. This looks okay. One thing to mention is that with the changes in jtreg then we should be able to drop -addmods from several of these tests. That is for a separate issue of course, also tied to the CLI changes as all these -addmods usages have been switched to --add-modules. -Alan From Alan.Bateman at oracle.com Mon Aug 1 12:22:14 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 1 Aug 2016 05:22:14 -0700 Subject: RFR 8162782: jlink ResourcePool.releaseProperties should be removed In-Reply-To: <96f9ffe2-392d-d360-a502-19c5a8141027@oracle.com> References: <7a816ec0-b76f-f161-304a-301f2b9166a5@oracle.com> <441873e0-4db0-6eae-f967-97ec378a0625@oracle.com> <96f9ffe2-392d-d360-a502-19c5a8141027@oracle.com> Message-ID: <00b90222-1a24-fd66-92d6-8abbdf4cb2c6@oracle.com> On 31/07/2016 20:29, Sundararajan Athijegannathan wrote: > Hi, > > I'll handle that issue in another fix. > > Okay. One thing with the current patch is that the try/catch in releaseProperties isn't clear. Also in ResourcePoolEntry, where it defines TOP, it says "jdk image directory" then I assume it should say "run-time image" as it's not specific to JDK images. The rest looks okay to me. -Alan From david.lloyd at redhat.com Mon Aug 1 14:04:03 2016 From: david.lloyd at redhat.com (David M. Lloyd) Date: Mon, 1 Aug 2016 09:04:03 -0500 Subject: Exporting - the wrong default? In-Reply-To: References: <03d2c64f-4d24-f303-112f-2e6baa0514c2@oracle.com> <4f49aa3a-4f87-0ca7-4f5e-6048bfbd1b04@oracle.com> <80d34193-5846-e792-bc64-8b12ea118fb4@redhat.com> Message-ID: <3354e329-2fa4-a66e-3b3b-ab77501d1237@redhat.com> On 08/01/2016 05:40 AM, dalibor topic wrote: > > > On 29.07.2016 16:55, David M. Lloyd wrote: >> On 07/29/2016 09:20 AM, dalibor topic wrote: >>> >>> Is it safe to assume that all potentially headache inducing Guns and >>> Bullets are always kept under lock in non-public classes? >> >> Of course, that's why we had non-public classes in the first place. > > OK, let's assume that's correct for the deliberate headache instrument > hiding decisions made by all Java developers for the sake of the argument. > > To balance that assumption out, please grant me an assumption as well: > Let's assume for the sake of the argument that not all Java developers > are experts all the time, and therefore some of them might sometimes > produce classes that could be abused as headache inducing Slings and > Stones. > > Is it safe to assume that all such involuntarily headache inducing > Slings and Stones are also kept under lock in non-public classes? Of course not, no more than it is safe to assume that such will be kept hidden in non-exported packages under the existing regime. At some point the user has to make the decision to make something public or not public; nothing can change that. But what we can do is to make it easy for users: a public class is public, otherwise it is secret and has to be explicitly shared. Contrast with the current system, where whole packages must have their definition of "public" defined to mean either selectively shared or fully public, which is less intuitive and more confusing. The more confused the user is, the more likely they are to make a mistake about security. With my proposal, if there are any doubts about a class, you make it non-public (regardless of what package it is in), which is a very simple criterion. In addition, you make the public/non-public choice on a per-class basis, not a per-package basis, which is also useful as well as intuitive. -- - DML From peter.levart at gmail.com Mon Aug 1 14:10:26 2016 From: peter.levart at gmail.com (Peter Levart) Date: Mon, 1 Aug 2016 16:10:26 +0200 Subject: RFR: 8161203: ResourceBundle.getBundle performance regression In-Reply-To: <2b8eb9f2-7b81-512b-6dde-0631d2c01c39@oracle.com> References: <7fc61181-7c3c-ea1c-d07a-90a2e712844c@oracle.com> <5991183a-8d2a-967d-74ec-c99e7d1636f3@oracle.com> <884a78a8-ebfb-a15d-a036-37b9fd377401@gmail.com> <2b8eb9f2-7b81-512b-6dde-0631d2c01c39@oracle.com> Message-ID: <4826d920-0ec2-5f97-5266-c53458ff779b@gmail.com> Hi Masayosh, Alan, Thanks for looking at the change. I suppose application containers are already accustomed to invoke ResourceBundle.clearCache(ClassLoader) when undeploying an application so that the corresponding ClassLoader can get GCed right away. But there's a change in the semantics of this method that Jigsaw introduced... Before Jigsaw, this method was specified to: * Removes all resource bundles from the cache that have been loaded * using the given class loader. After Jigsaw, this method is specified to: * Removes all resource bundles from the cache that have been loaded * by the caller's module using the given class loader. Now suppose that the "caller's module" that loads the bundle is the application's module and the module that clears the cache is the container's module. The app's cache won't get cleared. I understand that the change in semantics was an attempt to "isolate" modules among themselves so that one module could not clear the cache of another module if they happen to map to the same class loader, but this also means that an application container can't easily clear the cache of the application it wishes to undeploy unless it uses the new ResourceBundle.clearCache(Module) method on each application's module before undeploying it. I also wonder if the change of the semantics of this method is backwards compatible. Suppose that some container is using this method to clear the cache of the application loaded by say "classloaderA" before undeploying it. It calls ResourceBundle.clearCache(classloaderA). Now suppose the container code is loaded by some other class loader (say "classloaderC") which is usually the case in today's containers. Both container and application classes are part of the unnamed modules of their corresponding class loaders. With the change in the semantics of this method introduced by jigsaw, the container will not clear the cache of the application any more since the container module is not the same as the application module (they are distinct unnamed modules). Anyway, I noticed an inconsistency in my webrev.04 immediately after posting it a week ago. I was off for a week then, so now that I'm back, here's the corrected webrev of my proposed change: http://cr.openjdk.java.net/~plevart/jdk9-dev/ResourceBundle.cleanup/webrev.05/ The only real change of logic compared to webrev.04 is that I moved the "format" field from the LoadSession (previous CacheKey) to ResourceBundle itself. This field is needed to hold the bundle's format for invoking the Control.needsReload() method. It is not semantically correct to use the value from the LoadSession as done in webrev.04. This has to be the value that the bundle was created with, so it belongs to the bundle itself. In original code it was taken from the cloned CacheKey that was attached to the bundle. All other changes from webrev.04 are limited to ResourceBundle.java file and include some comments and nits that don't change the overall logic. All ResourceBundle tests still pass. The diff from webrev.04 is the following: *** ResourceBundle.webrev.04.java 2016-08-01 15:33:49.408565452 +0200 --- ResourceBundle.java 2016-08-01 14:43:59.875401697 +0200 *************** *** 40,55 **** package java.util; - import jdk.internal.misc.JavaUtilResourceBundleAccess; - import jdk.internal.misc.SharedSecrets; - import jdk.internal.reflect.CallerSensitive; - import jdk.internal.reflect.Reflection; - import jdk.internal.util.concurrent.AbstractClassLoaderValue; - import jdk.internal.util.concurrent.ClassLoaderValue; - import sun.util.locale.BaseLocale; - import sun.util.locale.LocaleObjectCache; - import sun.util.locale.provider.ResourceBundleProviderSupport; - import java.io.IOException; import java.io.InputStream; import java.lang.ref.ReferenceQueue; --- 40,45 ---- *************** *** 69,74 **** --- 59,73 ---- import java.util.spi.ResourceBundleControlProvider; import java.util.spi.ResourceBundleProvider; + import jdk.internal.misc.JavaUtilResourceBundleAccess; + import jdk.internal.misc.SharedSecrets; + import jdk.internal.reflect.CallerSensitive; + import jdk.internal.reflect.Reflection; + import jdk.internal.util.concurrent.AbstractClassLoaderValue; + import jdk.internal.util.concurrent.ClassLoaderValue; + import sun.util.locale.BaseLocale; + import sun.util.locale.LocaleObjectCache; + import sun.util.locale.provider.ResourceBundleProviderSupport; import static sun.security.util.SecurityConstants.GET_CLASSLOADER_PERMISSION; *************** *** 346,354 **** */ public abstract class ResourceBundle { - /** initial size of the bundle cache */ - private static final int INITIAL_CACHE_SIZE = 32; - static { SharedSecrets.setJavaUtilResourceBundleAccess( new JavaUtilResourceBundleAccess() { --- 345,350 ---- *************** *** 386,392 **** /** ! * The cache of BundleReference(s) per class loader, bundle base name and locale. */ private static final ClassLoaderValue cache = new ClassLoaderValue<>(); --- 382,389 ---- /** ! * The cache of BundleReference(s) per class loader, module, bundle base name ! * and locale. */ private static final ClassLoaderValue cache = new ClassLoaderValue<>(); *************** *** 419,430 **** * The parent bundle is searched by {@link #getObject getObject} * when this bundle does not contain a particular resource. */ ! protected ResourceBundle parent = null; /** * The locale for this bundle. */ ! private Locale locale = null; /** * The base bundle name for this bundle. --- 416,427 ---- * The parent bundle is searched by {@link #getObject getObject} * when this bundle does not contain a particular resource. */ ! protected ResourceBundle parent; /** * The locale for this bundle. */ ! private Locale locale; /** * The base bundle name for this bundle. *************** *** 432,437 **** --- 429,440 ---- private String name; /** + * Bundle format which is necessary for calling + * Control.needsReload(). + */ + private String format; + + /** * The flag indicating this bundle has expired in the cache. */ private volatile boolean expired; *************** *** 622,629 **** /** * A session object used during the {@link #getBundle} call. ! * The loader may be null, but the base name, the locale and ! * module must have a non-null value. */ private static class LoadSession { // These four are the actual keys for lookup in cache. --- 625,633 ---- /** * A session object used during the {@link #getBundle} call. ! * The loader may be null (in which case it is considered to be the ! * bootstrap class loader), but the module, base name, and locale must have ! * a non-null value. */ private static class LoadSession { // These four are the actual keys for lookup in cache. *************** *** 642,651 **** return key().get(loader); } - // bundle format which is necessary for calling - // Control.needsReload(). - private String format; - // Placeholder for an error report by a Throwable private Throwable cause; --- 646,651 ---- *************** *** 699,712 **** return callerHasProvider == Boolean.TRUE; } - String getFormat() { - return format; - } - - void setFormat(String format) { - this.format = format; - } - private void setCause(Throwable cause) { if (this.cause == null) { this.cause = cause; --- 699,704 ---- *************** *** 734,740 **** } } return "LookupSession[" + name + ", lc=" + l + ", ldr=" + getLoader() ! + "(format=" + format + ")]"; } } --- 726,732 ---- } } return "LookupSession[" + name + ", lc=" + l + ", ldr=" + getLoader() ! + "]"; } } *************** *** 1666,1672 **** bundle = loadBundleFromProviders(baseName, targetLocale, providers, loadSession); if (bundle != null) { ! loadSession.setFormat(UNKNOWN_FORMAT); } } // If none of providers returned a bundle and the caller has no provider, --- 1658,1664 ---- bundle = loadBundleFromProviders(baseName, targetLocale, providers, loadSession); if (bundle != null) { ! bundle.format = UNKNOWN_FORMAT; } } // If none of providers returned a bundle and the caller has no provider, *************** *** 1690,1696 **** } if (bundle != null) { ! loadSession.setFormat(format); break; } } catch (Exception e) { --- 1682,1688 ---- } if (bundle != null) { ! bundle.format = format; break; } } catch (Exception e) { *************** *** 1764,1770 **** Iterable providers, LoadSession loadSession) { ! // assert cacheKey != null && providers != null; return AccessController.doPrivileged( new PrivilegedAction<>() { public ResourceBundle run() { --- 1756,1762 ---- Iterable providers, LoadSession loadSession) { ! // assert loadSession != null && providers != null; return AccessController.doPrivileged( new PrivilegedAction<>() { public ResourceBundle run() { *************** *** 1819,1825 **** if (bundle != null) { // Set the format in the cache key so that it can be // used when calling needsReload later. ! loadSession.setFormat(format); bundle.name = loadSession.getName(); bundle.locale = targetLocale; // Bundle provider might reuse instances. So we should make --- 1811,1817 ---- if (bundle != null) { // Set the format in the cache key so that it can be // used when calling needsReload later. ! bundle.format = format; bundle.name = loadSession.getName(); bundle.locale = targetLocale; // Bundle provider might reuse instances. So we should make *************** *** 1877,1883 **** * Finds a bundle in the cache. Any expired bundles are marked as * `expired' and removed from the cache upon return. * ! * @param loadSession the key to look up the cache * @param control the Control to be used for the expiration control * @return the cached bundle, or null if the bundle is not found in the * cache or its parent has expired. bundle.expire is true --- 1869,1875 ---- * Finds a bundle in the cache. Any expired bundles are marked as * `expired' and removed from the cache upon return. * ! * @param loadSession the load session used look up the cache * @param control the Control to be used for the expiration control * @return the cached bundle, or null if the bundle is not found in the * cache or its parent has expired. bundle.expire is true *************** *** 1946,1954 **** if (!bundle.expired && expirationTime >= 0 && expirationTime <= System.currentTimeMillis()) { try { ! bundle.expired = control.needsReload(loadSession.getName(), ! loadSession.getLocale(), ! loadSession.getFormat(), loadSession.getLoader(), bundle, bundle.loadTime); --- 1938,1946 ---- if (!bundle.expired && expirationTime >= 0 && expirationTime <= System.currentTimeMillis()) { try { ! bundle.expired = control.needsReload(bundle.getBaseBundleName(), ! bundle.getLocale(), ! bundle.format, loadSession.getLoader(), bundle, bundle.loadTime); In my opinion, the change of the semantics of ResourceBundle.clearCache(ClassLoader) could be tolerated if the invocation of that method was not a requirement for application containers to be able to unload the app's class loader. With my proposed change to caching it is not a requirement any more. Regards, Peter On 07/25/2016 08:08 AM, Masayoshi Okutsu wrote: > Hi Peter, > > The change (ResourceBundle part) looks very good to me. There's a > simple workaround for the problem -- call > ResourceBundle.clearCache(ClassLoader). So I don't know how serious > the problem is, though. I still like this change. > > Yes, the comment in ReferenceTest should be removed. > > Thanks, > Masayoshi > > On 7/22/2016 10:13 PM, Peter Levart wrote: >> On 07/22/2016 10:46 AM, Peter Levart wrote: >>> Hi Masayoshi, >> >> Here's a preview of work to migrate ResourceBundle caching to using >> ClassLoaderValue utility: >> >> http://cr.openjdk.java.net/~plevart/jdk9-dev/ResourceBundle.cleanup/webrev.04/ >> >> >> The changes are very straightforward. They preserve the general >> structure of the logic. I renamed the CacheKey nested class to >> LoadSession as it now only functions as a mutable object passed >> around the methods while executing the getBundle() process. >> LoadSession is now a factory for ClassLoaderValue cache key. I moved >> the loadTime and expirationTime fields from LoadSession (old >> CacheKey) to ResourceBundle. As each cached entry must maintain it's >> own loadTime/expirationTime, I changed the NONEXISTENT_BUNDLE >> constant into a private subclass of ResourceBundle. The back-link >> from ResourceBundle to CacheKey is not needed any more. There is a >> backlink from BundleReference to ClassLoaderValue key and the >> associated ClassLoader to enable expunging. >> >> All 41 java/util/ResourceBundle tests pass with this change applied. >> Including the ReferenceTest which I had to modify a little to remove >> a dependency on ResourceBundle.cacheList field which is only used in >> test to report the size of the Map. It is not possible to obtain the >> size of the Map any more with this change applied, since the entries >> are distributed to multiple Map(s) - one Map per ClassLoader >> instance. The following comment in ReferenceTest could now be removed: >> >> * This test relies on the current behavior of the garbage collector >> and is >> * therefore no clear indicator of whether the fix for 4405807 works. >> * If the test fails, it might indicate a regression, or it might >> just mean >> * that a less aggressive garbage collector is used. >> >> ...as the ClassLoader(s) unloading does not depend on eagerness of >> SoftReference(s) clearing or any other activity any more. >> >> What do you think? >> >> Regards, Peter >> >>> >>> Thinking of how the ResourceBundle caching is implemented, I think >>> it has a serious flaw. The cache is currently the following: >>> >>> private static final ConcurrentMap cacheList >>> >>> ...where the CacheKey is an object which contains WeakReference(s) >>> to the caller's ClassLoader and Module. This is OK. >>> >>> BundleReference, OTOH, is a SoftReference. The >>> problem is ResourceBundle(s) can be arbitrary user subclasses, which >>> means that they may have an implicit reference to the ClassLoader >>> that appears in the CacheKey. The consequence is that such cache can >>> prevent GC-ing of the ClassLoader for arbitrary amount of time >>> (SoftReferences are cleared on memory pressure). >>> >>> Luckily there might be a solution. If the ResourceBundle subclasses >>> are always resolvable from the ClassLoader that appears in the >>> CacheKey, then there is a utility class that I created recently: >>> java.lang.reflect.ClassLoaderValue. This a package-private class as >>> it is currently used only in java.lang.reflect.Proxy for caching of >>> dynamic Proxy classes, but could be made public and moved to some >>> jdk.internal... package. >>> >>> Basing ResourceBundle caching on this utility class could also >>> simplify the implementation as you wouldn't have to deal with >>> WeakReference(s) to ClassLoader and Module objects. You could still >>> have a BundleReference extending SoftReference to >>> release the bundles on memory pressure but since such >>> SoftReference(s) would be anchored in the particular ClassLoader >>> instance that can resolve the ResourceBundle subclasses, it would >>> not prevent such ClassLoader from being GCed immediately. >>> >>> I can prototype such caching if you like. >>> >>> Regards, Peter >>> >>> On 07/22/2016 06:07 AM, Masayoshi Okutsu wrote: >>>> Hi Peter, >>>> >>>> Thank you for your suggestion. Actually CacheKey is used for >>>> storing information required to load resource bundles during a >>>> ResourceBundle.getBundle call. The current CacheKey usage may be >>>> too tricky and cause some maintenance problems. I will file a >>>> separate issue on that problem. I wanted to work on some clean up >>>> of the CacheKey usage, but I haven't had a chance. >>>> >>>> Thanks, >>>> Masayoshi >>>> >>>> >>>> On 7/21/2016 10:13 PM, Peter Levart wrote: >>>>> Hi Masayoshi, >>>>> >>>>> Previously the CacheKey::clone() method cleared a reference to >>>>> 'providers' in the clone making the provides unreachable from the >>>>> clone and making the clone unable to obtain providers. Now you >>>>> also reset the 'providersChecked' flag which makes the clone be >>>>> able to re-obtain the providers. This is dangerous as the clone is >>>>> used as a key in the cache and is strongly reachable from the >>>>> cache. A slight future modification of code could unintentionally >>>>> produce a class loader leak. To prevent that, I would somehow mark >>>>> the clone so that any attempt to invoke getProviders() on the >>>>> clone would throw IllegalStateException. >>>>> >>>>> Regards, Peter >>>>> >>>>> On 07/21/2016 06:14 AM, Masayoshi Okutsu wrote: >>>>>> Hi, >>>>>> >>>>>> Please review the fix for JDK-8161203. The fix is to lazily load >>>>>> ResourceBundleProviders. It's not necessary to load providers >>>>>> before cache look-up. >>>>>> >>>>>> Issue: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8161203 >>>>>> >>>>>> Webrev: >>>>>> http://cr.openjdk.java.net/~okutsu/9/8161203/webrev.01 >>>>>> >>>>>> Thanks, >>>>>> Masayoshi >>>>>> >>>>> >>>> >>> >> > From peter.levart at gmail.com Mon Aug 1 14:37:45 2016 From: peter.levart at gmail.com (Peter Levart) Date: Mon, 1 Aug 2016 16:37:45 +0200 Subject: Exporting - the wrong default? In-Reply-To: References: Message-ID: <37163b76-cf0d-4066-5ed3-5df356b69ac8@gmail.com> Hi, On 07/26/2016 06:42 PM, Stephen Colebourne wrote: > If the default does not change, then I assume the tools will > effectively work around it. ie. that Maven will have an option to > export all packages not explicitly hidden. Anything else would be far > too annoying for development. > > Stephen > PS, I would accept a design where developers could choose to use > exports or restricts (but not both) in module-info.java. What about adding support for automatic modules to javac ? Currently if there is a directory in the -modulesourcepath that contains sources but no module-info.java file, it is not treated as a module. If it was treated as an automatic module (meaning that it would export all packages and require all other modules), the development process could be more easily bootstrapped. At some point in time when clear API of the module is formed, the developer would just add the module-info.java to it to describe the module in full... Regards, Peter From pbenedict at apache.org Mon Aug 1 15:29:11 2016 From: pbenedict at apache.org (Paul Benedict) Date: Mon, 1 Aug 2016 10:29:11 -0500 Subject: SPI for customizing modules? Message-ID: Jigsaw Experts, It seems the only way to customize modules is not to use --module-path. It seems if I want to customize, I have to load myself. Right or wrong? I am looking for an SPI where I can customize any non-JDK module. I believe this would be easier than the current path I am on. I'd rather just provide a service the JDK can call for anything it finds in --module-path so I can customize each module loaded. Please advise. Cheers, Paul From charbel_yazbeck at hotmail.com Mon Aug 1 15:37:34 2016 From: charbel_yazbeck at hotmail.com (charbel yazbeck) Date: Mon, 1 Aug 2016 15:37:34 +0000 Subject: Issue with an automatic module Message-ID: Hi i was trying to play around latest jigsaw version in order to adapt an open source projet that i developed and i found the following issue. When using a jar containing a class with no package, the modulefinder is failing to create its module descriptor. It guesses that it is an automatic module (unamed), but fails with the following stack trace : Exception in thread "main" java.lang.module.FindException: Unable to derive module descriptor for: D:\.m2\com\github\maven-nar\nar-maven-plugin\3.0.0\nar-maven-plugin-3.0.0.jar at java.lang.module.ModulePath.readJar(java.base at 9-ea/ModulePath.java:538) at java.lang.module.ModulePath.readModule(java.base at 9-ea/ModulePath.java:273) at java.lang.module.ModulePath.scan(java.base at 9-ea/ModulePath.java:192) at java.lang.module.ModulePath.scanNextEntry(java.base at 9-ea/ModulePath.java:144) at java.lang.module.ModulePath.findAll(java.base at 9-ea/ModulePath.java:120) at test.Test.main(Test.java:46) Caused by: java.lang.IllegalArgumentException: Empty package name at jdk.internal.module.Checks.requireJavaIdentifier(java.base at 9-ea/Checks.java:70) at jdk.internal.module.Checks.requirePackageName(java.base at 9-ea/Checks.java:93) at java.lang.module.ModuleDescriptor$Exports.(java.base at 9-ea/ModuleDescriptor.java:269) at java.lang.module.ModuleDescriptor$Exports.(java.base at 9-ea/ModuleDescriptor.java:266) at java.lang.module.ModuleDescriptor$Exports.(java.base at 9-ea/ModuleDescriptor.java:239) at java.lang.module.ModuleDescriptor$Builder.exports(java.base at 9-ea/ModuleDescriptor.java:1347) at java.util.stream.ForEachOps$ForEachOp$OfRef.accept(java.base at 9-ea/ForEachOps.java:184) at java.util.stream.DistinctOps$1$2.accept(java.base at 9-ea/DistinctOps.java:175) at java.util.stream.ReferencePipeline$3$1.accept(java.base at 9-ea/ReferencePipeline.java:195) at java.util.HashMap$KeySpliterator.forEachRemaining(java.base at 9-ea/HashMap.java:1600) at java.util.stream.AbstractPipeline.copyInto(java.base at 9-ea/AbstractPipeline.java:484) at java.util.stream.AbstractPipeline.wrapAndCopyInto(java.base at 9-ea/AbstractPipeline.java:474) at java.util.stream.ForEachOps$ForEachOp.evaluateSequential(java.base at 9-ea/ForEachOps.java:151) at java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(java.base at 9-ea/ForEachOps.java:174) at java.util.stream.AbstractPipeline.evaluate(java.base at 9-ea/AbstractPipeline.java:234) at java.util.stream.ReferencePipeline.forEach(java.base at 9-ea/ReferencePipeline.java:430) at java.lang.module.ModulePath.deriveModuleDescriptor(java.base at 9-ea/ModulePath.java:435) at java.lang.module.ModulePath.readJar(java.base at 9-ea/ModulePath.java:534) ... 5 more when looking in the class ModulePath, in the method deriveModuleDescriptor, the problem seems to come from the following code // all packages are exported classFiles.stream() .map(c -> toPackageName(c)) .distinct() .forEach(builder::exports); when the class has no package, toPackageName returns "", and builder::exports throws an exception. Easy fix could be to assert in the forEach before calling builder::exports Thank you From pbenedict at apache.org Mon Aug 1 15:38:53 2016 From: pbenedict at apache.org (Paul Benedict) Date: Mon, 1 Aug 2016 10:38:53 -0500 Subject: Exporting - the wrong default? In-Reply-To: <3354e329-2fa4-a66e-3b3b-ab77501d1237@redhat.com> References: <03d2c64f-4d24-f303-112f-2e6baa0514c2@oracle.com> <4f49aa3a-4f87-0ca7-4f5e-6048bfbd1b04@oracle.com> <80d34193-5846-e792-bc64-8b12ea118fb4@redhat.com> <3354e329-2fa4-a66e-3b3b-ab77501d1237@redhat.com> Message-ID: To echo David, there is a complaint by me in these archives how I still find it difficult to remember that "public" is no longer being public. I feel the same way today still. The word "public" means "for everyone" so it's always jarring to have it no longer mean what it should mean in normal English. Also, I find it less than appealing to do double-duty to make my classes public. I now have to remind myself to export my package but it's still something I forget. I find this step to be a nuisance. That's my real world feedback. Cheers, Paul On Mon, Aug 1, 2016 at 9:04 AM, David M. Lloyd wrote: > On 08/01/2016 05:40 AM, dalibor topic wrote: > >> >> >> On 29.07.2016 16:55, David M. Lloyd wrote: >> >>> On 07/29/2016 09:20 AM, dalibor topic wrote: >>> >>>> >>>> Is it safe to assume that all potentially headache inducing Guns and >>>> Bullets are always kept under lock in non-public classes? >>>> >>> >>> Of course, that's why we had non-public classes in the first place. >>> >> >> OK, let's assume that's correct for the deliberate headache instrument >> hiding decisions made by all Java developers for the sake of the argument. >> >> To balance that assumption out, please grant me an assumption as well: >> Let's assume for the sake of the argument that not all Java developers >> are experts all the time, and therefore some of them might sometimes >> produce classes that could be abused as headache inducing Slings and >> Stones. >> >> Is it safe to assume that all such involuntarily headache inducing >> Slings and Stones are also kept under lock in non-public classes? >> > > Of course not, no more than it is safe to assume that such will be kept > hidden in non-exported packages under the existing regime. At some point > the user has to make the decision to make something public or not public; > nothing can change that. But what we can do is to make it easy for users: > a public class is public, otherwise it is secret and has to be explicitly > shared. Contrast with the current system, where whole packages must have > their definition of "public" defined to mean either selectively shared or > fully public, which is less intuitive and more confusing. The more > confused the user is, the more likely they are to make a mistake about > security. With my proposal, if there are any doubts about a class, you > make it non-public (regardless of what package it is in), which is a very > simple criterion. In addition, you make the public/non-public choice on a > per-class basis, not a per-package basis, which is also useful as well as > intuitive. > > -- > - DML > From stef at epardaud.fr Mon Aug 1 15:58:48 2016 From: stef at epardaud.fr (Stephane Epardaud) Date: Mon, 1 Aug 2016 17:58:48 +0200 Subject: Exporting - the wrong default? In-Reply-To: References: <03d2c64f-4d24-f303-112f-2e6baa0514c2@oracle.com> <4f49aa3a-4f87-0ca7-4f5e-6048bfbd1b04@oracle.com> <80d34193-5846-e792-bc64-8b12ea118fb4@redhat.com> <3354e329-2fa4-a66e-3b3b-ab77501d1237@redhat.com> Message-ID: <579F71B8.6000308@epardaud.fr> I don't think public ever meant "public to the world". In Java 1->8 it means "visible to those who can see the containing scope". If you declare a public inner class in a private (or package-private) class, then those who cannot access the outer type also cannot access the public inner class. So no, "public" never meant "visible to everyone", it was always about scope. On the other hand, for toplevel types, the scope had always been the package, and packages were public by default. Now that default changes to private, but notice that even here, a package is only private outside its scope (the module). Other packages in the same scope (module) will be able to access it. So for me it's always been about exporting from the current scope. On 01/08/16 17:38, Paul Benedict wrote: > To echo David, there is a complaint by me in these archives how I still > find it difficult to remember that "public" is no longer being public. I > feel the same way today still. The word "public" means "for everyone" so > it's always jarring to have it no longer mean what it should mean in normal > English. Also, I find it less than appealing to do double-duty to make my > classes public. I now have to remind myself to export my package but it's > still something I forget. I find this step to be a nuisance. That's my real > world feedback. > From pbenedict at apache.org Mon Aug 1 16:04:13 2016 From: pbenedict at apache.org (Paul Benedict) Date: Mon, 1 Aug 2016 11:04:13 -0500 Subject: Exporting - the wrong default? In-Reply-To: <579F71B8.6000308@epardaud.fr> References: <03d2c64f-4d24-f303-112f-2e6baa0514c2@oracle.com> <4f49aa3a-4f87-0ca7-4f5e-6048bfbd1b04@oracle.com> <80d34193-5846-e792-bc64-8b12ea118fb4@redhat.com> <3354e329-2fa4-a66e-3b3b-ab77501d1237@redhat.com> <579F71B8.6000308@epardaud.fr> Message-ID: Stephane, please take my words within context. I wasn't being too technical; just merely using "public to the world" with regards to exporting packages. However, I appreciate your technical eye to get the details right. Thanks for the broader explanation. Cheers, Paul On Mon, Aug 1, 2016 at 10:58 AM, Stephane Epardaud wrote: > I don't think public ever meant "public to the world". In Java 1->8 it > means "visible to those who can see the containing scope". If you declare a > public inner class in a private (or package-private) class, then those who > cannot access the outer type also cannot access the public inner class. > > So no, "public" never meant "visible to everyone", it was always about > scope. > > On the other hand, for toplevel types, the scope had always been the > package, and packages were public by default. Now that default changes to > private, but notice that even here, a package is only private outside its > scope (the module). Other packages in the same scope (module) will be able > to access it. > > So for me it's always been about exporting from the current scope. > > > On 01/08/16 17:38, Paul Benedict wrote: > >> To echo David, there is a complaint by me in these archives how I still >> find it difficult to remember that "public" is no longer being public. I >> feel the same way today still. The word "public" means "for everyone" so >> it's always jarring to have it no longer mean what it should mean in >> normal >> English. Also, I find it less than appealing to do double-duty to make my >> classes public. I now have to remind myself to export my package but it's >> still something I forget. I find this step to be a nuisance. That's my >> real >> world feedback. >> >> > From sundararajan.athijegannathan at oracle.com Mon Aug 1 16:31:25 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Mon, 1 Aug 2016 22:01:25 +0530 Subject: RFR 8162782: jlink ResourcePool.releaseProperties should be removed In-Reply-To: <00b90222-1a24-fd66-92d6-8abbdf4cb2c6@oracle.com> References: <7a816ec0-b76f-f161-304a-301f2b9166a5@oracle.com> <441873e0-4db0-6eae-f967-97ec378a0625@oracle.com> <96f9ffe2-392d-d360-a502-19c5a8141027@oracle.com> <00b90222-1a24-fd66-92d6-8abbdf4cb2c6@oracle.com> Message-ID: I had moved that try..catch code to read module descriptor from elsewhere. When I removed that try..catch, I got test failures. Found another lurking issue on reading descriptor from compressed resources! Fixed that [ImagePluginStack.LastPoolManager] and removed try..catch. All tests pass now. Also fixed the comment for ResourcePoolEntry.Type.TOP Please review updated webrev @ http://cr.openjdk.java.net/~sundar/8162782/webrev.01/index.html Thanks, -Sundar On 8/1/2016 5:52 PM, Alan Bateman wrote: > > > On 31/07/2016 20:29, Sundararajan Athijegannathan wrote: >> Hi, >> >> I'll handle that issue in another fix. >> >> > Okay. One thing with the current patch is that the try/catch in > releaseProperties isn't clear. Also in ResourcePoolEntry, where it > defines TOP, it says "jdk image directory" then I assume it should say > "run-time image" as it's not specific to JDK images. The rest looks > okay to me. > > -Alan From Alan.Bateman at oracle.com Mon Aug 1 16:32:23 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 1 Aug 2016 09:32:23 -0700 Subject: Issue with an automatic module In-Reply-To: References: Message-ID: On 01/08/2016 08:37, charbel yazbeck wrote: > Hi > > > i was trying to play around latest jigsaw version in order to adapt an open source projet that i developed and i found the following issue. > > When using a jar containing a class with no package, the modulefinder is failing to create its module descriptor. > > A named module (this includes automatic modules) can't have types in the unnamed package. So the FindException is correct, this seems to be JAR file that can't be automatic module. Do you know this plugin? It is completely in the unnamed package? -Alan From charbel_yazbeck at hotmail.com Mon Aug 1 19:01:50 2016 From: charbel_yazbeck at hotmail.com (charbel yazbeck) Date: Mon, 1 Aug 2016 19:01:50 +0000 Subject: Issue with an automatic module In-Reply-To: References: , Message-ID: hi I was just trying the following sample: ModuleFinder finder = ModuleFinder.of(path); //path points to the location of a jar with an unnamed module finder.findAll().forEach(System.out::println); Layer parent = Layer.boot(); Configuration cf = parent.configuration().resolveRequires(finder, ModuleFinder.of(), Set.of()); ClassLoader scl = ClassLoader.getSystemClassLoader(); Layer newLayer=parent.defineModulesWithManyLoaders(cf, scl); newLayer.modules().stream().forEach(System.out::println); Thank u for ur help ________________________________ De : Alan Bateman Envoy? : lundi 1 ao?t 2016 16:32 ? : charbel yazbeck; jigsaw-dev at openjdk.java.net Objet : Re: Issue with an automatic module On 01/08/2016 08:37, charbel yazbeck wrote: > Hi > > > i was trying to play around latest jigsaw version in order to adapt an open source projet that i developed and i found the following issue. > > When using a jar containing a class with no package, the modulefinder is failing to create its module descriptor. > > A named module (this includes automatic modules) can't have types in the unnamed package. So the FindException is correct, this seems to be JAR file that can't be automatic module. Do you know this plugin? It is completely in the unnamed package? -Alan From Alan.Bateman at oracle.com Mon Aug 1 22:00:07 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 1 Aug 2016 15:00:07 -0700 Subject: Issue with an automatic module In-Reply-To: References: Message-ID: <40663b81-01a0-d349-b75a-c88bcb5cfc30@oracle.com> On 01/08/2016 12:01, charbel yazbeck wrote: > hi > > > I was just trying the following sample: > > > ModuleFinder finder = ModuleFinder.of(path); //path points to > the location of a jar with an unnamed module > finder.findAll().forEach(System.out::println); I see nar-maven-plugin-3.0.0.jar has a class HelpMojo.class, do you know if this is supposed to be in this JAR file? In any case, it is as I said, named modules can not contain types in the unnamed package so this is why ModuleFinder fails. In this javadoc where it describes automatic it has the following "If a .class file that corresponds to a class in an unnamed package is encountered then FindException is thrown." -Alan From Alan.Bateman at oracle.com Mon Aug 1 22:51:42 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 1 Aug 2016 15:51:42 -0700 Subject: SPI for customizing modules? In-Reply-To: References: Message-ID: <924aab4c-efa1-13eb-7a89-c386c8261746@oracle.com> On 01/08/2016 08:29, Paul Benedict wrote: > Jigsaw Experts, > > It seems the only way to customize modules is not to use --module-path. It > seems if I want to customize, I have to load myself. Right or wrong? > > I am looking for an SPI where I can customize any non-JDK module. I believe > this would be easier than the current path I am on. I'd rather just provide > a service the JDK can call for anything it finds in --module-path so I can > customize each module loaded. > > Please advise. > You should be able to do this with a simple launcher, essentially the code fragment in the recent mail with Jochen [1] but replacing it with your ModuleFinder. This is preferable to creating two layers at startup, and it avoids chicken 'n egg issues that would arise if your finder module needed to be resolved in order to find the modules for the boot layer. -Alan [1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-July/008919.html From Alan.Bateman at oracle.com Mon Aug 1 22:54:45 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 1 Aug 2016 15:54:45 -0700 Subject: RFR 8162782: jlink ResourcePool.releaseProperties should be removed In-Reply-To: References: <7a816ec0-b76f-f161-304a-301f2b9166a5@oracle.com> <441873e0-4db0-6eae-f967-97ec378a0625@oracle.com> <96f9ffe2-392d-d360-a502-19c5a8141027@oracle.com> <00b90222-1a24-fd66-92d6-8abbdf4cb2c6@oracle.com> Message-ID: On 01/08/2016 09:31, Sundararajan Athijegannathan wrote: > I had moved that try..catch code to read module descriptor from > elsewhere. When I removed that try..catch, I got test failures. Found > another lurking issue on reading descriptor from compressed resources! > Fixed that [ImagePluginStack.LastPoolManager] and removed try..catch. > All tests pass now. Also fixed the comment for ResourcePoolEntry.Type.TOP > > Please review updated webrev @ > http://cr.openjdk.java.net/~sundar/8162782/webrev.01/index.html > Thanks for the updates, this versions looks okay to me. -Alan From lois.foltan at oracle.com Tue Aug 2 00:40:48 2016 From: lois.foltan at oracle.com (Lois Foltan) Date: Mon, 01 Aug 2016 20:40:48 -0400 Subject: RFR(L) 8136930: Simplify use of module-system options by custom launchers In-Reply-To: <4de6f3b7-d5ed-8569-aab9-798f39a1f134@oracle.com> References: <4de6f3b7-d5ed-8569-aab9-798f39a1f134@oracle.com> Message-ID: <579FEC0F.1010407@oracle.com> On 7/17/2016 7:05 PM, harold seigel wrote: > Hi, > > Please review these Hotspot VM only changes to process the seven > module-specific options that have been renamed to have gnu-like > names. JDK changes for this bug will be reviewed separately. > > Descriptions of these options are here > . For these six options, > --module-path, --upgrade-module-path, --add-modules, --limit-modules, > --add-reads, and --add-exports, the JVM just sets a system property. > For the --patch-module option, the JVM sets a system property and then > processes the option in the same way as when it was named -Xpatch. > > Additionally, the JVM now checks properties specified on the command > line. If a property matches one of the properties used by one of the > above options then the JVM ignores the property. This forces users to > use the explicit option when wanting to do things like add a module or > a package export. > > The RFR contains two new tests. Also, many existing tests were > changed to use the new option names. > > JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8136930 > > Webrev: http://cr.openjdk.java.net/~hseigel/bug_8136930.hs/ Hi Harold, Overall looks good. A couple of comments: src/share/vm/prims/jvmtiEnv.cpp - line #3428 - The if statement is incorrect. There are internal properties, like jdk.boot.class.path.append, whose value if non-null should be returned. src/share/vm/runtime/arguments.cpp - Arguments::append_to_addmods_property was added before the VM starting to process --add-modules. So with this fix, it seems like it could be simply changed to: bool Arguments::append_to_addmods_property(const char* module_name) { PropertyList_unique_add(&_system_properties, Arguments::get_property("jdk.module.addmods"), module_name, AppendProperty, UnwriteableProperty, InternalProperty); } Please consider making this change since currently it contains a lot of duplicated code that is now unnecessary. - line #3171, should the comment be "--add-modules=java.sql" instead of "--add-modules java.sql"? Thanks, Lois > > The changes were tested with the JCK lang and VM tests, the JTreg > hotspot tests, and the RBT hotspot nightlies. > > Thanks, Harold From david.holmes at oracle.com Tue Aug 2 01:26:09 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 2 Aug 2016 11:26:09 +1000 Subject: Exporting - the wrong default? In-Reply-To: <579F71B8.6000308@epardaud.fr> References: <03d2c64f-4d24-f303-112f-2e6baa0514c2@oracle.com> <4f49aa3a-4f87-0ca7-4f5e-6048bfbd1b04@oracle.com> <80d34193-5846-e792-bc64-8b12ea118fb4@redhat.com> <3354e329-2fa4-a66e-3b3b-ab77501d1237@redhat.com> <579F71B8.6000308@epardaud.fr> Message-ID: On 2/08/2016 1:58 AM, Stephane Epardaud wrote: > I don't think public ever meant "public to the world". In Java 1->8 it > means "visible to those who can see the containing scope". If you > declare a public inner class in a private (or package-private) class, > then those who cannot access the outer type also cannot access the > public inner class. > > So no, "public" never meant "visible to everyone", it was always about > scope. > > On the other hand, for toplevel types, the scope had always been the > package, and packages were public by default. Now that default changes > to private, but notice that even here, a package is only private outside > its scope (the module). Other packages in the same scope (module) will > be able to access it. > > So for me it's always been about exporting from the current scope. That is my take on this exactly. Modules introduce a new scoping layer. If you want packages to now appear to users of a module, you have to export them. David H. > On 01/08/16 17:38, Paul Benedict wrote: >> To echo David, there is a complaint by me in these archives how I still >> find it difficult to remember that "public" is no longer being public. I >> feel the same way today still. The word "public" means "for everyone" so >> it's always jarring to have it no longer mean what it should mean in >> normal >> English. Also, I find it less than appealing to do double-duty to make my >> classes public. I now have to remind myself to export my package but it's >> still something I forget. I find this step to be a nuisance. That's my >> real >> world feedback. >> > From charbel_yazbeck at hotmail.com Tue Aug 2 07:21:18 2016 From: charbel_yazbeck at hotmail.com (charbel yazbeck) Date: Tue, 2 Aug 2016 07:21:18 +0000 Subject: Issue with an automatic module In-Reply-To: <40663b81-01a0-d349-b75a-c88bcb5cfc30@oracle.com> References: , <40663b81-01a0-d349-b75a-c88bcb5cfc30@oracle.com> Message-ID: hi, most of the open sources jars have classes with unnamed package, like nar-maven-plugin. Any idea how can i solve this? Do i have to implement my own version of ModuleFinder? Some examples: D:\.m2\jdom\jdom\1.0\jdom-1.0.jar, D:\.m2\net\java\dev\javacc\javacc\5.0\javacc-5.0.jar, D:\.m2\hsqldb\hsqldb\1.8.0.7\hsqldb-1.8.0.7.jar thank you ________________________________ De : Alan Bateman Envoy? : lundi 1 ao?t 2016 22:00 ? : charbel yazbeck; jigsaw-dev at openjdk.java.net Objet : Re: Issue with an automatic module On 01/08/2016 12:01, charbel yazbeck wrote: hi I was just trying the following sample: ModuleFinder finder = ModuleFinder.of(path); //path points to the location of a jar with an unnamed module finder.findAll().forEach(System.out::println); I see nar-maven-plugin-3.0.0.jar has a class HelpMojo.class, do you know if this is supposed to be in this JAR file? In any case, it is as I said, named modules can not contain types in the unnamed package so this is why ModuleFinder fails. In this javadoc where it describes automatic it has the following "If a .class file that corresponds to a class in an unnamed package is encountered then FindException is thrown." -Alan From pbenedict at apache.org Tue Aug 2 07:53:53 2016 From: pbenedict at apache.org (Paul Benedict) Date: Tue, 2 Aug 2016 02:53:53 -0500 Subject: Issue with an automatic module In-Reply-To: References: <40663b81-01a0-d349-b75a-c88bcb5cfc30@oracle.com> Message-ID: Charbel, have you looked into the Maven Shade Plugin? I wonder if you could shade what's in the unnamed package so as to put it in some other named package? Cheers, Paul On Tue, Aug 2, 2016 at 2:21 AM, charbel yazbeck wrote: > hi, > > > most of the open sources jars have classes with unnamed package, like > nar-maven-plugin. > > Any idea how can i solve this? Do i have to implement my own version of > ModuleFinder? > > Some examples: D:\.m2\jdom\jdom\1.0\jdom-1.0.jar, > D:\.m2\net\java\dev\javacc\javacc\5.0\javacc-5.0.jar, > D:\.m2\hsqldb\hsqldb\1.8.0.7\hsqldb-1.8.0.7.jar > > > thank you > > > > > ________________________________ > De : Alan Bateman > Envoy? : lundi 1 ao?t 2016 22:00 > ? : charbel yazbeck; jigsaw-dev at openjdk.java.net > Objet : Re: Issue with an automatic module > > > On 01/08/2016 12:01, charbel yazbeck wrote: > > hi > > > I was just trying the following sample: > > > ModuleFinder finder = ModuleFinder.of(path); //path points to > the location of a jar with an unnamed module > finder.findAll().forEach(System.out::println); > > I see nar-maven-plugin-3.0.0.jar has a class HelpMojo.class, do you know > if this is supposed to be in this JAR file? > > In any case, it is as I said, named modules can not contain types in the > unnamed package so this is why ModuleFinder fails. In this javadoc where it > describes automatic it has the following "If a .class file that corresponds > to a class in an unnamed package is encountered then FindException is > thrown." > > -Alan > From dalibor.topic at oracle.com Tue Aug 2 09:48:06 2016 From: dalibor.topic at oracle.com (dalibor topic) Date: Tue, 2 Aug 2016 11:48:06 +0200 Subject: Exporting - the wrong default? In-Reply-To: <3354e329-2fa4-a66e-3b3b-ab77501d1237@redhat.com> References: <03d2c64f-4d24-f303-112f-2e6baa0514c2@oracle.com> <4f49aa3a-4f87-0ca7-4f5e-6048bfbd1b04@oracle.com> <80d34193-5846-e792-bc64-8b12ea118fb4@redhat.com> <3354e329-2fa4-a66e-3b3b-ab77501d1237@redhat.com> Message-ID: On 01.08.2016 16:04, David M. Lloyd wrote: > With my proposal, if there are any > doubts about a class, you make it non-public (regardless of what package > it is in), which is a very simple criterion. In addition, you make the > public/non-public choice on a per-class basis, not a per-package basis, > which is also useful as well as intuitive. How do I make a single class non-public in a third party component? cheers, dalibor topic -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From adinn at redhat.com Tue Aug 2 10:59:48 2016 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 2 Aug 2016 11:59:48 +0100 Subject: Issue with an automatic module In-Reply-To: References: <40663b81-01a0-d349-b75a-c88bcb5cfc30@oracle.com> Message-ID: <57A07D24.50304@redhat.com> On 02/08/16 08:21, charbel yazbeck wrote: > most of the open sources jars have classes with unnamed package, like nar-maven-plugin. Hmm, citation needed for that I think. In my experience it is extremely rare for production code to place classes in the unnamed module. It is extremely bad practice to do so because it invites name space clashes. I'm astonished that someone thought it was ok to do this in a maven plugin. But then again ... > Any idea how can i solve this? Do i have to implement my own version of ModuleFinder? Getting the owner of the jar to release a new jar with the class in a sensible package is a far better solution. If you really have to use such a jar then I guess you can always use the maven shade plugin to generate a variant that has contains the offending class(es) in a suitably named module. But that's probably not going to be a great solution when you are trying to use the maven plugin from maven (chicken and egg issues?) -- I guess you will need to deploy your own fixed variant in a suitable repo before consuming it in your project. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From sundararajan.athijegannathan at oracle.com Tue Aug 2 11:39:04 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Tue, 2 Aug 2016 17:09:04 +0530 Subject: RFR 8159487: Add JAVA_VERSION, OS_NAME, OS_ARCH properties in release file Message-ID: <7b5d4cfe-6bc3-1ef7-9834-1e9f5808f37a@oracle.com> Please review http://cr.openjdk.java.net/~sundar/8159487/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8159487 OS_NAME, OS_ARCH, OS_VERSION properties are already added due to another fix. Just adding "JAVA_VERSION" and a test change to check these properties exist in release file. Thanks -Sundar From dalibor.topic at oracle.com Tue Aug 2 11:49:01 2016 From: dalibor.topic at oracle.com (dalibor topic) Date: Tue, 2 Aug 2016 13:49:01 +0200 Subject: Exporting - the wrong default? In-Reply-To: <3354e329-2fa4-a66e-3b3b-ab77501d1237@redhat.com> References: <03d2c64f-4d24-f303-112f-2e6baa0514c2@oracle.com> <4f49aa3a-4f87-0ca7-4f5e-6048bfbd1b04@oracle.com> <80d34193-5846-e792-bc64-8b12ea118fb4@redhat.com> <3354e329-2fa4-a66e-3b3b-ab77501d1237@redhat.com> Message-ID: <5bcb93f9-d6f1-0690-f42c-ad290c76d971@oracle.com> On 01.08.2016 16:04, David M. Lloyd wrote: > On 08/01/2016 05:40 AM, dalibor topic wrote: >> Is it safe to assume that all such involuntarily headache inducing >> Slings and Stones are also kept under lock in non-public classes? > > Of course not, no more than it is safe to assume that such will be kept > hidden in non-exported packages under the existing regime. Great - I think we can agree that some inadvertently headache inducing classes might be public and some might be not. Let's now consider two different scenarios, in which Sling and Stone are either public, or not, and denote the variants with a P or N prefix - PSling is a public Sling, while NStone is a non-public Stone, for example. Let's also consider two defaults: permissive (i.e. all packages are exported) and fail safe (i.e. no packages are exported). Permissive: PSling + PStone can induce a headache, while the other three cases fortunately can not. So a mere 25% opportunity for a headache. Fail safe: none of the four cases induce a headache. Let's now add reflection & setAccessible to the mix. To make the example more plastic, let's hypothetically assume that the Sling is some kind of a universal reflector utility class, which has a method that kindly performs a reflective operation upon polite request, using setAccessible if necessary to access otherwise inaccessible members, while violating SEC05-J [0]. Let's also assume that the Stone has some other potentially headache inducing problem. Again, no headache occurs in the Failsafe case, because no packages are exported, while at the same time in the Permissive case, both the PSling+PStone and PSling+NStone cases now can induce a headache. Fortunately, the other two cases still do not, so that's a mere 50% opportunity for headache. A coin toss, in other words. Now let's consider the Fail safe default with developers optionally exporting packages containing Sling and Stone. Let's mark classes contained in an exported package with an X prefix, while those that aren't get an O. The headache inducing cases are XPSling+XPStone and XPSling+XNStone while the other 14 cases are not. While headaches can no longer be excluded, that's quite a bit better than a coin toss, or even just the initial permissive scenario without use of reflection & setAccessible in the Sling. Of course, you can get to the same cases starting with a Permissive default and then restricting exports of the packages in question. Yet, there is an interesting difference between the two scenarios: a) in the fail safe default case you start at no risk of headache inducing combinations of Slings and Stones, and then can increase your risk of a headache occurring to a certain level by adding exports, while in the permissive case you start at a coin toss level of headache risk and have to remove exports to decrease it to the same level, and b) regardless of how many Slings and Stones there are in the mix, you always start at no risk of headache inducing combinations of Stones and Slings in the fail safe default case, while adding further Slings and Stones to the mix makes your initial headache risk significantly greater than a coin toss in the permissive case. cheers, dalibor topic [0] https://www.securecoding.cert.org/confluence/display/java/SEC05-J.+Do+not+use+reflection+to+increase+accessibility+of+classes,+methods,+or+fields -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From james.laskey at oracle.com Tue Aug 2 11:53:10 2016 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Tue, 2 Aug 2016 08:53:10 -0300 Subject: RFR 8159487: Add JAVA_VERSION, OS_NAME, OS_ARCH properties in release file In-Reply-To: <7b5d4cfe-6bc3-1ef7-9834-1e9f5808f37a@oracle.com> References: <7b5d4cfe-6bc3-1ef7-9834-1e9f5808f37a@oracle.com> Message-ID: <0D87F1D2-99CE-4059-9854-2E34FB84F71A@oracle.com> +1 > On Aug 2, 2016, at 8:39 AM, Sundararajan Athijegannathan wrote: > > Please review http://cr.openjdk.java.net/~sundar/8159487/webrev.00/ for > https://bugs.openjdk.java.net/browse/JDK-8159487 > > OS_NAME, OS_ARCH, OS_VERSION properties are already added due to another > fix. Just adding "JAVA_VERSION" and a test change to check these > properties exist in release file. > > Thanks > > -Sundar > From Alan.Bateman at oracle.com Tue Aug 2 12:01:36 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 2 Aug 2016 05:01:36 -0700 Subject: Issue with an automatic module In-Reply-To: References: <40663b81-01a0-d349-b75a-c88bcb5cfc30@oracle.com> Message-ID: <5f1edb4a-8ade-6e65-a547-8f6019d1380e@oracle.com> On 02/08/2016 00:21, charbel yazbeck wrote: > hi, > > > most of the open sources jars have classes with unnamed package, like > nar-maven-plugin. > > Any idea how can i solve this? Do i have to implement my own version > of ModuleFinder? > > Some examples: D:\.m2\jdom\jdom\1.0\jdom-1.0.jar, > D:\.m2\net\java\dev\javacc\javacc\5.0\javacc-5.0.jar, > D:\.m2\hsqldb\hsqldb\1.8.0.7\hsqldb-1.8.0.7.jar > > > thank you > > HelpMojo seems to be something to do with Maven Plugin Plugin. It doesn't seem to be present in nar-maven-plugin 3.3.0 or 3.5.0 $ java --module-path nar-maven-plugin-3.5.0.jar --list-modules nar.maven.plugin nar.maven.plugin at 3.5.0 (file:///d/nar-maven-plugin-3.5.0.jar) requires mandated java.base exports com.github.maven_nar exports com.github.maven_nar.cpptasks exports com.github.maven_nar.cpptasks.apple exports com.github.maven_nar.cpptasks.arm : We have tried out hundreds of libraries as automatic modules (to test the derivation comes up with sensible module names etc.) and haven't seen too many issues. I did come across javacc, not the others you mention. The summary is that if you have libraries with types in the unnamed package then they will need to remain on the class path. This means that nobody will be able to use `requires` to name them as a dependence in their module declaration. -Alan. From Alan.Bateman at oracle.com Tue Aug 2 12:12:26 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 2 Aug 2016 05:12:26 -0700 Subject: RFR 8159487: Add JAVA_VERSION, OS_NAME, OS_ARCH properties in release file In-Reply-To: <7b5d4cfe-6bc3-1ef7-9834-1e9f5808f37a@oracle.com> References: <7b5d4cfe-6bc3-1ef7-9834-1e9f5808f37a@oracle.com> Message-ID: On 02/08/2016 04:39, Sundararajan Athijegannathan wrote: > Please review http://cr.openjdk.java.net/~sundar/8159487/webrev.00/ for > https://bugs.openjdk.java.net/browse/JDK-8159487 > > OS_NAME, OS_ARCH, OS_VERSION properties are already added due to another > fix. Just adding "JAVA_VERSION" and a test change to check these > properties exist in release file. > This seems to put the value of the "java.version" property into the release file, I don't think you want that. Consider the cross targeting case where jlink is running on 9 but the modules for the target image are 9.1. So it needs to come from the java.base module for the target run-time image. -Alan From scolebourne at joda.org Tue Aug 2 12:47:34 2016 From: scolebourne at joda.org (Stephen Colebourne) Date: Tue, 2 Aug 2016 13:47:34 +0100 Subject: Exporting - the wrong default? In-Reply-To: <5bcb93f9-d6f1-0690-f42c-ad290c76d971@oracle.com> References: <03d2c64f-4d24-f303-112f-2e6baa0514c2@oracle.com> <4f49aa3a-4f87-0ca7-4f5e-6048bfbd1b04@oracle.com> <80d34193-5846-e792-bc64-8b12ea118fb4@redhat.com> <3354e329-2fa4-a66e-3b3b-ab77501d1237@redhat.com> <5bcb93f9-d6f1-0690-f42c-ad290c76d971@oracle.com> Message-ID: On 2 August 2016 at 12:49, dalibor topic wrote: > Let's now consider two different scenarios, in which Sling and Stone are > either public, or not, and denote the variants with a P or N prefix - PSling > is a public Sling, while NStone is a non-public Stone, for example. > > Let's also consider two defaults: permissive (i.e. all packages are > exported) and fail safe (i.e. no packages are exported). > > Permissive: > PSling + PStone can induce a headache, while the other three cases > fortunately can not. So a mere 25% opportunity for a headache. > > Fail safe: > none of the four cases induce a headache. Er, now no-one can use the library. The purpose of a library is to provide public types for applications to use. That these have bugs and/or security issues is a fact of life in software. Developers are not going to suddenly stop using external OSS libraries. > Let's now add reflection & setAccessible to the mix. > ... > Again, no headache occurs in the Failsafe case, because no packages are > exported, Er, now no-one can use the library because it can't operate without reflection+setAccessible. I again draw attention to the fact that many many OSS libraries use reflection+setAccessible, and that the ecosystem relies on it pretty much everywhere [1], at least in part because beans+properties has never been addressed. > Of course, you can get to the same cases starting with a Permissive default > and then restricting exports of the packages in question. > > Yet, there is an interesting difference between the two scenarios: > > a) in the fail safe default case you start at no risk of headache inducing > combinations of Slings and Stones, and then can increase your risk of a > headache occurring to a certain level by adding exports, while in the > permissive case you start at a coin toss level of headache risk and have to > remove exports to decrease it to the same level, and > > b) regardless of how many Slings and Stones there are in the mix, you always > start at no risk of headache inducing combinations of Stones and Slings in > the fail safe default case, while adding further Slings and Stones to the > mix makes your initial headache risk significantly greater than a coin toss > in the permissive case. Er, but this is such a straw man. There is no "initial headache risk". The packages have to be exported to actually use the library, and are today. The vast majority of libraries porting to Java 9 will have to export all packages because nothing else will work. In virtually no cases, is the end-user developer going to be changing the exported packages of the libraries they depend on. To get any benefit from the new modular scope, existing OSS projects will require significant backward-incompatible reworking - to take existing public classes and methods and move them to different packages. This is major work, and far less likely than just exporting everything (how many years has it taken to do this in the JDK?). What I want from jigsaw is a *new* ability, not alteration of the status quo. ie. to allow developers to *opt-in* to selectively hide things at the module level *going forward*. Ideally I also want to hide individual classes, methods and fields, because packages are far too coarse grained for this. IMO, we need to get existing OSS libraries migrated to modules ASAP to maintain the ecosystem, which requires the migration to be really simple. Get this wrong, and we'll all just carry on using the classpath, and the last 5+ years of effort in the JDK will have little value. Stephen [1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-July/008855.html From alan.bateman at oracle.com Tue Aug 2 12:57:03 2016 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Tue, 02 Aug 2016 12:57:03 +0000 Subject: hg: jigsaw/jake/jdk: javax/smartcardio/TerminalFactorySpiTest.java failing Message-ID: <201608021257.u72Cv3TH022539@aojmv0008.oracle.com> Changeset: 8e042568422f Author: alanb Date: 2016-08-02 05:56 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/8e042568422f javax/smartcardio/TerminalFactorySpiTest.java failing ! test/javax/smartcardio/TerminalFactorySpiTest.java From adinn at redhat.com Tue Aug 2 12:59:19 2016 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 2 Aug 2016 13:59:19 +0100 Subject: Issue with an automatic module In-Reply-To: <5f1edb4a-8ade-6e65-a547-8f6019d1380e@oracle.com> References: <40663b81-01a0-d349-b75a-c88bcb5cfc30@oracle.com> <5f1edb4a-8ade-6e65-a547-8f6019d1380e@oracle.com> Message-ID: <57A09927.7010209@redhat.com> On 02/08/16 13:01, Alan Bateman wrote: > HelpMojo seems to be something to do with Maven Plugin Plugin. It > doesn't seem to be present in nar-maven-plugin 3.3.0 or 3.5.0 HelpMojo is indeed something to do with the Maven Plugin Plugin. The latter will generate a class called HelpMojo on demand to provide automatic help output to guide configuration and use of a Maven plugin built using the Plugin Plugin. However, a generated HelpMojo definition is not normally generated in the empty package since it is usually generated in the same package as the XXXMojo that implements the XXX plugin behaviour. Of course it can also be implemented by hand. Looking at the 3.0.0 source jar file com/github/maven_nar/HelpMojo.java contains a definition for class HelpMojo which appears to have been hand-code and does not have a package declaration. The package declaration appears to have been added in 3.2.0. In 3.3.0 the file appears to have been removed -- I assume the class been auto-generated by this stage. So, the solution here is to use the fixed version of the plugin. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From peter.levart at gmail.com Tue Aug 2 13:19:45 2016 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 2 Aug 2016 15:19:45 +0200 Subject: Issue with an automatic module In-Reply-To: <57A09927.7010209@redhat.com> References: <40663b81-01a0-d349-b75a-c88bcb5cfc30@oracle.com> <5f1edb4a-8ade-6e65-a547-8f6019d1380e@oracle.com> <57A09927.7010209@redhat.com> Message-ID: <5477d77d-de73-cd52-267b-803b27e0e469@gmail.com> Hi, Top-package (unnamed package) classes can not be referenced from classes in named packages anyway, so they usually represent just reflective entry points (such as Main class with main() method). If a jar is used as an automatic module, it would probably be safe to just ignore any classes that appear in the jar at the top-level. Maybe this way there would be less grief in trying to use such jars as automatic modules than by rejecting them. Regards, Peter On 08/02/2016 02:59 PM, Andrew Dinn wrote: > On 02/08/16 13:01, Alan Bateman wrote: >> HelpMojo seems to be something to do with Maven Plugin Plugin. It >> doesn't seem to be present in nar-maven-plugin 3.3.0 or 3.5.0 > HelpMojo is indeed something to do with the Maven Plugin Plugin. The > latter will generate a class called HelpMojo on demand to provide > automatic help output to guide configuration and use of a Maven plugin > built using the Plugin Plugin. > > However, a generated HelpMojo definition is not normally generated in > the empty package since it is usually generated in the same package as > the XXXMojo that implements the XXX plugin behaviour. Of course it can > also be implemented by hand. Looking at the 3.0.0 source jar file > > com/github/maven_nar/HelpMojo.java > > contains a definition for class HelpMojo which appears to have been > hand-code and does not have a package declaration. The package > declaration appears to have been added in 3.2.0. In 3.3.0 the file > appears to have been removed -- I assume the class been auto-generated > by this stage. > > So, the solution here is to use the fixed version of the plugin. > > regards, > > > Andrew Dinn > ----------- > Senior Principal Software Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From harold.seigel at oracle.com Tue Aug 2 13:25:01 2016 From: harold.seigel at oracle.com (harold seigel) Date: Tue, 2 Aug 2016 09:25:01 -0400 Subject: RFR(L) 8136930: Simplify use of module-system options by custom launchers In-Reply-To: <579FEC0F.1010407@oracle.com> References: <4de6f3b7-d5ed-8569-aab9-798f39a1f134@oracle.com> <579FEC0F.1010407@oracle.com> Message-ID: Hi Lois, Thanks for the review. Please see comments in-line. Harold On 8/1/2016 8:40 PM, Lois Foltan wrote: > > On 7/17/2016 7:05 PM, harold seigel wrote: >> Hi, >> >> Please review these Hotspot VM only changes to process the seven >> module-specific options that have been renamed to have gnu-like >> names. JDK changes for this bug will be reviewed separately. >> >> Descriptions of these options are here >> . For these six options, >> --module-path, --upgrade-module-path, --add-modules, --limit-modules, >> --add-reads, and --add-exports, the JVM just sets a system property. >> For the --patch-module option, the JVM sets a system property and >> then processes the option in the same way as when it was named -Xpatch. >> >> Additionally, the JVM now checks properties specified on the command >> line. If a property matches one of the properties used by one of the >> above options then the JVM ignores the property. This forces users to >> use the explicit option when wanting to do things like add a module >> or a package export. >> >> The RFR contains two new tests. Also, many existing tests were >> changed to use the new option names. >> >> JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8136930 >> >> Webrev: http://cr.openjdk.java.net/~hseigel/bug_8136930.hs/ > > Hi Harold, > > Overall looks good. A couple of comments: > > src/share/vm/prims/jvmtiEnv.cpp > - line #3428 - The if statement is incorrect. There are internal > properties, like jdk.boot.class.path.append, whose value if non-null > should be returned. This code will be reworked in the next version of these changes because of multiple issues. > > src/share/vm/runtime/arguments.cpp > - Arguments::append_to_addmods_property was added before the VM > starting to process --add-modules. So with this fix, it seems like it > could be simply changed to: > > bool Arguments::append_to_addmods_property(const char* module_name) { > PropertyList_unique_add(&_system_properties, > Arguments::get_property("jdk.module.addmods"), > module_name, > AppendProperty, UnwriteableProperty, InternalProperty); > } > > Please consider making this change since currently it contains a lot > of duplicated code that is now unnecessary. The one difference is that append_to_addmods_property() returns a status but PropertyList_unique_add() does not. I'll look into this a bit further. > > - line #3171, should the comment be "--add-modules=java.sql" instead > of "--add-modules java.sql"? yes. The changes suggested by you, Coleen, and Dan will be in the next version of this webrev. Thanks, Harold > > Thanks, > Lois > > > > > > > > > > > > > >> >> The changes were tested with the JCK lang and VM tests, the JTreg >> hotspot tests, and the RBT hotspot nightlies. >> >> Thanks, Harold > From charbel_yazbeck at hotmail.com Tue Aug 2 13:41:08 2016 From: charbel_yazbeck at hotmail.com (charbel yazbeck) Date: Tue, 2 Aug 2016 13:41:08 +0000 Subject: Issue with an automatic module In-Reply-To: <5477d77d-de73-cd52-267b-803b27e0e469@gmail.com> References: <40663b81-01a0-d349-b75a-c88bcb5cfc30@oracle.com> <5f1edb4a-8ade-6e65-a547-8f6019d1380e@oracle.com> <57A09927.7010209@redhat.com>, <5477d77d-de73-cd52-267b-803b27e0e469@gmail.com> Message-ID: hi, i would vote for that... thank u ________________________________ De : Peter Levart Envoy? : mardi 2 ao?t 2016 13:19 ? : Andrew Dinn; Alan Bateman; charbel yazbeck; jigsaw-dev at openjdk.java.net Objet : Re: Issue with an automatic module Hi, Top-package (unnamed package) classes can not be referenced from classes in named packages anyway, so they usually represent just reflective entry points (such as Main class with main() method). If a jar is used as an automatic module, it would probably be safe to just ignore any classes that appear in the jar at the top-level. Maybe this way there would be less grief in trying to use such jars as automatic modules than by rejecting them. Regards, Peter On 08/02/2016 02:59 PM, Andrew Dinn wrote: > On 02/08/16 13:01, Alan Bateman wrote: >> HelpMojo seems to be something to do with Maven Plugin Plugin. It >> doesn't seem to be present in nar-maven-plugin 3.3.0 or 3.5.0 > HelpMojo is indeed something to do with the Maven Plugin Plugin. The > latter will generate a class called HelpMojo on demand to provide > automatic help output to guide configuration and use of a Maven plugin > built using the Plugin Plugin. > > However, a generated HelpMojo definition is not normally generated in > the empty package since it is usually generated in the same package as > the XXXMojo that implements the XXX plugin behaviour. Of course it can > also be implemented by hand. Looking at the 3.0.0 source jar file > > com/github/maven_nar/HelpMojo.java > > contains a definition for class HelpMojo which appears to have been > hand-code and does not have a package declaration. The package > declaration appears to have been added in 3.2.0. In 3.3.0 the file > appears to have been removed -- I assume the class been auto-generated > by this stage. > > So, the solution here is to use the fixed version of the plugin. > > regards, > > > Andrew Dinn > ----------- > Senior Principal Software Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From Alan.Bateman at oracle.com Tue Aug 2 14:10:46 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 2 Aug 2016 07:10:46 -0700 Subject: Issue with an automatic module In-Reply-To: <5477d77d-de73-cd52-267b-803b27e0e469@gmail.com> References: <40663b81-01a0-d349-b75a-c88bcb5cfc30@oracle.com> <5f1edb4a-8ade-6e65-a547-8f6019d1380e@oracle.com> <57A09927.7010209@redhat.com> <5477d77d-de73-cd52-267b-803b27e0e469@gmail.com> Message-ID: <06adc3c1-db01-abcb-7566-ba321d48f866@oracle.com> On 02/08/2016 06:19, Peter Levart wrote: > Hi, > > Top-package (unnamed package) classes can not be referenced from > classes in named packages anyway, so they usually represent just > reflective entry points (such as Main class with main() method). If a > jar is used as an automatic module, it would probably be safe to just > ignore any classes that appear in the jar at the top-level. Maybe this > way there would be less grief in trying to use such jars as automatic > modules than by rejecting them. The concern is that it gives the impression that a module can have a type in the unnamed package. If it is the main class then `java -m nar.maven.plugin/HelpMojo` will fail for example. I concede of course that at some cases will be just mistakes where someone has included some classes in the top-level directory by accident. (Note that the main class scenario has an another issue where it's possible for a JAR file to have a Main-Class attribute that named a class in the unnamed package as the main class. Known problem that will resolve itself once the builder API is overhauled). -Alan From forax at univ-mlv.fr Tue Aug 2 14:10:53 2016 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 02 Aug 2016 07:10:53 -0700 Subject: Issue with an automatic module In-Reply-To: <5477d77d-de73-cd52-267b-803b27e0e469@gmail.com> References: <40663b81-01a0-d349-b75a-c88bcb5cfc30@oracle.com> <5f1edb4a-8ade-6e65-a547-8f6019d1380e@oracle.com> <57A09927.7010209@redhat.com> <5477d77d-de73-cd52-267b-803b27e0e469@gmail.com> Message-ID: <7155B34C-C3E8-46D0-A2EF-61E57E0FFE25@univ-mlv.fr> Seems to be a reasonable idea :) Rem On August 2, 2016 6:19:45 AM PDT, Peter Levart wrote: >Hi, > >Top-package (unnamed package) classes can not be referenced from >classes >in named packages anyway, so they usually represent just reflective >entry points (such as Main class with main() method). If a jar is used >as an automatic module, it would probably be safe to just ignore any >classes that appear in the jar at the top-level. Maybe this way there >would be less grief in trying to use such jars as automatic modules >than >by rejecting them. > >Regards, Peter > > >On 08/02/2016 02:59 PM, Andrew Dinn wrote: >> On 02/08/16 13:01, Alan Bateman wrote: >>> HelpMojo seems to be something to do with Maven Plugin Plugin. It >>> doesn't seem to be present in nar-maven-plugin 3.3.0 or 3.5.0 >> HelpMojo is indeed something to do with the Maven Plugin Plugin. The >> latter will generate a class called HelpMojo on demand to provide >> automatic help output to guide configuration and use of a Maven >plugin >> built using the Plugin Plugin. >> >> However, a generated HelpMojo definition is not normally generated in >> the empty package since it is usually generated in the same package >as >> the XXXMojo that implements the XXX plugin behaviour. Of course it >can >> also be implemented by hand. Looking at the 3.0.0 source jar file >> >> com/github/maven_nar/HelpMojo.java >> >> contains a definition for class HelpMojo which appears to have been >> hand-code and does not have a package declaration. The package >> declaration appears to have been added in 3.2.0. In 3.3.0 the file >> appears to have been removed -- I assume the class been >auto-generated >> by this stage. >> >> So, the solution here is to use the fixed version of the plugin. >> >> regards, >> >> >> Andrew Dinn >> ----------- >> Senior Principal Software Engineer >> Red Hat UK Ltd >> Registered in England and Wales under Company Registration No. >03798903 >> Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander -- Sent from my Android device with K-9 Mail. Please excuse my brevity. From masayoshi.okutsu at oracle.com Tue Aug 2 15:30:42 2016 From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu) Date: Wed, 3 Aug 2016 00:30:42 +0900 Subject: RFR: 8161203: ResourceBundle.getBundle performance regression In-Reply-To: <4826d920-0ec2-5f97-5266-c53458ff779b@gmail.com> References: <7fc61181-7c3c-ea1c-d07a-90a2e712844c@oracle.com> <5991183a-8d2a-967d-74ec-c99e7d1636f3@oracle.com> <884a78a8-ebfb-a15d-a036-37b9fd377401@gmail.com> <2b8eb9f2-7b81-512b-6dde-0631d2c01c39@oracle.com> <4826d920-0ec2-5f97-5266-c53458ff779b@gmail.com> Message-ID: <0e19e8ab-570e-f9d6-4602-dee90adf213e@oracle.com> Hi Peter, Thanks for bringing up the semantics issue of clearCache. You are right. There's some semantics change in clearCache(ClassLoader). Let me look into it. The format field-related changes look good to me. Thanks, Masayoshi On 8/1/2016 11:10 PM, Peter Levart wrote: > Hi Masayosh, Alan, > > Thanks for looking at the change. > > I suppose application containers are already accustomed to invoke > ResourceBundle.clearCache(ClassLoader) when undeploying an application > so that the corresponding ClassLoader can get GCed right away. But > there's a change in the semantics of this method that Jigsaw > introduced... > > Before Jigsaw, this method was specified to: > > * Removes all resource bundles from the cache that have been loaded > * using the given class loader. > > After Jigsaw, this method is specified to: > > * Removes all resource bundles from the cache that have been loaded > * by the caller's module using the given class loader. > > > Now suppose that the "caller's module" that loads the bundle is the > application's module and the module that clears the cache is the > container's module. The app's cache won't get cleared. I understand > that the change in semantics was an attempt to "isolate" modules among > themselves so that one module could not clear the cache of another > module if they happen to map to the same class loader, but this also > means that an application container can't easily clear the cache of > the application it wishes to undeploy unless it uses the new > ResourceBundle.clearCache(Module) method on each application's module > before undeploying it. > > I also wonder if the change of the semantics of this method is > backwards compatible. Suppose that some container is using this method > to clear the cache of the application loaded by say "classloaderA" > before undeploying it. It calls > ResourceBundle.clearCache(classloaderA). Now suppose the container > code is loaded by some other class loader (say "classloaderC") which > is usually the case in today's containers. Both container and > application classes are part of the unnamed modules of their > corresponding class loaders. With the change in the semantics of this > method introduced by jigsaw, the container will not clear the cache of > the application any more since the container module is not the same as > the application module (they are distinct unnamed modules). > > Anyway, I noticed an inconsistency in my webrev.04 immediately after > posting it a week ago. I was off for a week then, so now that I'm > back, here's the corrected webrev of my proposed change: > > http://cr.openjdk.java.net/~plevart/jdk9-dev/ResourceBundle.cleanup/webrev.05/ > > > The only real change of logic compared to webrev.04 is that I moved > the "format" field from the LoadSession (previous CacheKey) to > ResourceBundle itself. This field is needed to hold the bundle's > format for invoking the Control.needsReload() method. It is not > semantically correct to use the value from the LoadSession as done in > webrev.04. This has to be the value that the bundle was created with, > so it belongs to the bundle itself. In original code it was taken from > the cloned CacheKey that was attached to the bundle. > > All other changes from webrev.04 are limited to ResourceBundle.java > file and include some comments and nits that don't change the overall > logic. All ResourceBundle tests still pass. > > The diff from webrev.04 is the following: > > *** ResourceBundle.webrev.04.java 2016-08-01 15:33:49.408565452 > +0200 > --- ResourceBundle.java 2016-08-01 14:43:59.875401697 +0200 > *************** > *** 40,55 **** > > package java.util; > > - import jdk.internal.misc.JavaUtilResourceBundleAccess; > - import jdk.internal.misc.SharedSecrets; > - import jdk.internal.reflect.CallerSensitive; > - import jdk.internal.reflect.Reflection; > - import jdk.internal.util.concurrent.AbstractClassLoaderValue; > - import jdk.internal.util.concurrent.ClassLoaderValue; > - import sun.util.locale.BaseLocale; > - import sun.util.locale.LocaleObjectCache; > - import sun.util.locale.provider.ResourceBundleProviderSupport; > - > import java.io.IOException; > import java.io.InputStream; > import java.lang.ref.ReferenceQueue; > --- 40,45 ---- > *************** > *** 69,74 **** > --- 59,73 ---- > import java.util.spi.ResourceBundleControlProvider; > import java.util.spi.ResourceBundleProvider; > > + import jdk.internal.misc.JavaUtilResourceBundleAccess; > + import jdk.internal.misc.SharedSecrets; > + import jdk.internal.reflect.CallerSensitive; > + import jdk.internal.reflect.Reflection; > + import jdk.internal.util.concurrent.AbstractClassLoaderValue; > + import jdk.internal.util.concurrent.ClassLoaderValue; > + import sun.util.locale.BaseLocale; > + import sun.util.locale.LocaleObjectCache; > + import sun.util.locale.provider.ResourceBundleProviderSupport; > import static > sun.security.util.SecurityConstants.GET_CLASSLOADER_PERMISSION; > > > *************** > *** 346,354 **** > */ > public abstract class ResourceBundle { > > - /** initial size of the bundle cache */ > - private static final int INITIAL_CACHE_SIZE = 32; > - > static { > SharedSecrets.setJavaUtilResourceBundleAccess( > new JavaUtilResourceBundleAccess() { > --- 345,350 ---- > *************** > *** 386,392 **** > > > /** > ! * The cache of BundleReference(s) per class loader, bundle base > name and locale. > */ > private static final ClassLoaderValue cache > = new ClassLoaderValue<>(); > --- 382,389 ---- > > > /** > ! * The cache of BundleReference(s) per class loader, module, > bundle base name > ! * and locale. > */ > private static final ClassLoaderValue cache > = new ClassLoaderValue<>(); > *************** > *** 419,430 **** > * The parent bundle is searched by {@link #getObject getObject} > * when this bundle does not contain a particular resource. > */ > ! protected ResourceBundle parent = null; > > /** > * The locale for this bundle. > */ > ! private Locale locale = null; > > /** > * The base bundle name for this bundle. > --- 416,427 ---- > * The parent bundle is searched by {@link #getObject getObject} > * when this bundle does not contain a particular resource. > */ > ! protected ResourceBundle parent; > > /** > * The locale for this bundle. > */ > ! private Locale locale; > > /** > * The base bundle name for this bundle. > *************** > *** 432,437 **** > --- 429,440 ---- > private String name; > > /** > + * Bundle format which is necessary for calling > + * Control.needsReload(). > + */ > + private String format; > + > + /** > * The flag indicating this bundle has expired in the cache. > */ > private volatile boolean expired; > *************** > *** 622,629 **** > > /** > * A session object used during the {@link #getBundle} call. > ! * The loader may be null, but the base name, the locale and > ! * module must have a non-null value. > */ > private static class LoadSession { > // These four are the actual keys for lookup in cache. > --- 625,633 ---- > > /** > * A session object used during the {@link #getBundle} call. > ! * The loader may be null (in which case it is considered to be the > ! * bootstrap class loader), but the module, base name, and > locale must have > ! * a non-null value. > */ > private static class LoadSession { > // These four are the actual keys for lookup in cache. > *************** > *** 642,651 **** > return key().get(loader); > } > > - // bundle format which is necessary for calling > - // Control.needsReload(). > - private String format; > - > // Placeholder for an error report by a Throwable > private Throwable cause; > > --- 646,651 ---- > *************** > *** 699,712 **** > return callerHasProvider == Boolean.TRUE; > } > > - String getFormat() { > - return format; > - } > - > - void setFormat(String format) { > - this.format = format; > - } > - > private void setCause(Throwable cause) { > if (this.cause == null) { > this.cause = cause; > --- 699,704 ---- > *************** > *** 734,740 **** > } > } > return "LookupSession[" + name + ", lc=" + l + ", ldr=" > + getLoader() > ! + "(format=" + format + ")]"; > } > } > > --- 726,732 ---- > } > } > return "LookupSession[" + name + ", lc=" + l + ", ldr=" > + getLoader() > ! + "]"; > } > } > > *************** > *** 1666,1672 **** > bundle = loadBundleFromProviders(baseName, targetLocale, > providers, loadSession); > if (bundle != null) { > ! loadSession.setFormat(UNKNOWN_FORMAT); > } > } > // If none of providers returned a bundle and the caller has > no provider, > --- 1658,1664 ---- > bundle = loadBundleFromProviders(baseName, targetLocale, > providers, loadSession); > if (bundle != null) { > ! bundle.format = UNKNOWN_FORMAT; > } > } > // If none of providers returned a bundle and the caller has > no provider, > *************** > *** 1690,1696 **** > } > > if (bundle != null) { > ! loadSession.setFormat(format); > break; > } > } catch (Exception e) { > --- 1682,1688 ---- > } > > if (bundle != null) { > ! bundle.format = format; > break; > } > } catch (Exception e) { > *************** > *** 1764,1770 **** > Iterable providers, > LoadSession loadSession) > { > ! // assert cacheKey != null && providers != null; > return AccessController.doPrivileged( > new PrivilegedAction<>() { > public ResourceBundle run() { > --- 1756,1762 ---- > Iterable providers, > LoadSession loadSession) > { > ! // assert loadSession != null && providers != null; > return AccessController.doPrivileged( > new PrivilegedAction<>() { > public ResourceBundle run() { > *************** > *** 1819,1825 **** > if (bundle != null) { > // Set the format in the cache key so that it can be > // used when calling needsReload later. > ! loadSession.setFormat(format); > bundle.name = loadSession.getName(); > bundle.locale = targetLocale; > // Bundle provider might reuse instances. So we > should make > --- 1811,1817 ---- > if (bundle != null) { > // Set the format in the cache key so that it can be > // used when calling needsReload later. > ! bundle.format = format; > bundle.name = loadSession.getName(); > bundle.locale = targetLocale; > // Bundle provider might reuse instances. So we > should make > *************** > *** 1877,1883 **** > * Finds a bundle in the cache. Any expired bundles are marked as > * `expired' and removed from the cache upon return. > * > ! * @param loadSession the key to look up the cache > * @param control the Control to be used for the expiration control > * @return the cached bundle, or null if the bundle is not found > in the > * cache or its parent has expired. bundle.expire > is true > --- 1869,1875 ---- > * Finds a bundle in the cache. Any expired bundles are marked as > * `expired' and removed from the cache upon return. > * > ! * @param loadSession the load session used look up the cache > * @param control the Control to be used for the expiration control > * @return the cached bundle, or null if the bundle is not found > in the > * cache or its parent has expired. bundle.expire > is true > *************** > *** 1946,1954 **** > if (!bundle.expired && expirationTime >= 0 && > expirationTime <= > System.currentTimeMillis()) { > try { > ! bundle.expired = > control.needsReload(loadSession.getName(), > ! loadSession.getLocale(), > ! loadSession.getFormat(), > loadSession.getLoader(), > bundle, > bundle.loadTime); > --- 1938,1946 ---- > if (!bundle.expired && expirationTime >= 0 && > expirationTime <= > System.currentTimeMillis()) { > try { > ! bundle.expired = > control.needsReload(bundle.getBaseBundleName(), > ! bundle.getLocale(), > ! bundle.format, > loadSession.getLoader(), > bundle, > bundle.loadTime); > > > > In my opinion, the change of the semantics of > ResourceBundle.clearCache(ClassLoader) could be tolerated if the > invocation of that method was not a requirement for application > containers to be able to unload the app's class loader. With my > proposed change to caching it is not a requirement any more. > > Regards, Peter > > > On 07/25/2016 08:08 AM, Masayoshi Okutsu wrote: >> Hi Peter, >> >> The change (ResourceBundle part) looks very good to me. There's a >> simple workaround for the problem -- call >> ResourceBundle.clearCache(ClassLoader). So I don't know how serious >> the problem is, though. I still like this change. >> >> Yes, the comment in ReferenceTest should be removed. >> >> Thanks, >> Masayoshi >> >> On 7/22/2016 10:13 PM, Peter Levart wrote: >>> On 07/22/2016 10:46 AM, Peter Levart wrote: >>>> Hi Masayoshi, >>> >>> Here's a preview of work to migrate ResourceBundle caching to using >>> ClassLoaderValue utility: >>> >>> http://cr.openjdk.java.net/~plevart/jdk9-dev/ResourceBundle.cleanup/webrev.04/ >>> >>> >>> The changes are very straightforward. They preserve the general >>> structure of the logic. I renamed the CacheKey nested class to >>> LoadSession as it now only functions as a mutable object passed >>> around the methods while executing the getBundle() process. >>> LoadSession is now a factory for ClassLoaderValue cache key. I moved >>> the loadTime and expirationTime fields from LoadSession (old >>> CacheKey) to ResourceBundle. As each cached entry must maintain it's >>> own loadTime/expirationTime, I changed the NONEXISTENT_BUNDLE >>> constant into a private subclass of ResourceBundle. The back-link >>> from ResourceBundle to CacheKey is not needed any more. There is a >>> backlink from BundleReference to ClassLoaderValue key and the >>> associated ClassLoader to enable expunging. >>> >>> All 41 java/util/ResourceBundle tests pass with this change applied. >>> Including the ReferenceTest which I had to modify a little to remove >>> a dependency on ResourceBundle.cacheList field which is only used in >>> test to report the size of the Map. It is not possible to obtain the >>> size of the Map any more with this change applied, since the entries >>> are distributed to multiple Map(s) - one Map per ClassLoader >>> instance. The following comment in ReferenceTest could now be removed: >>> >>> * This test relies on the current behavior of the garbage collector >>> and is >>> * therefore no clear indicator of whether the fix for 4405807 works. >>> * If the test fails, it might indicate a regression, or it might >>> just mean >>> * that a less aggressive garbage collector is used. >>> >>> ...as the ClassLoader(s) unloading does not depend on eagerness of >>> SoftReference(s) clearing or any other activity any more. >>> >>> What do you think? >>> >>> Regards, Peter >>> >>>> >>>> Thinking of how the ResourceBundle caching is implemented, I think >>>> it has a serious flaw. The cache is currently the following: >>>> >>>> private static final ConcurrentMap >>>> cacheList >>>> >>>> ...where the CacheKey is an object which contains WeakReference(s) >>>> to the caller's ClassLoader and Module. This is OK. >>>> >>>> BundleReference, OTOH, is a SoftReference. The >>>> problem is ResourceBundle(s) can be arbitrary user subclasses, >>>> which means that they may have an implicit reference to the >>>> ClassLoader that appears in the CacheKey. The consequence is that >>>> such cache can prevent GC-ing of the ClassLoader for arbitrary >>>> amount of time (SoftReferences are cleared on memory pressure). >>>> >>>> Luckily there might be a solution. If the ResourceBundle subclasses >>>> are always resolvable from the ClassLoader that appears in the >>>> CacheKey, then there is a utility class that I created recently: >>>> java.lang.reflect.ClassLoaderValue. This a package-private class as >>>> it is currently used only in java.lang.reflect.Proxy for caching of >>>> dynamic Proxy classes, but could be made public and moved to some >>>> jdk.internal... package. >>>> >>>> Basing ResourceBundle caching on this utility class could also >>>> simplify the implementation as you wouldn't have to deal with >>>> WeakReference(s) to ClassLoader and Module objects. You could still >>>> have a BundleReference extending SoftReference to >>>> release the bundles on memory pressure but since such >>>> SoftReference(s) would be anchored in the particular ClassLoader >>>> instance that can resolve the ResourceBundle subclasses, it would >>>> not prevent such ClassLoader from being GCed immediately. >>>> >>>> I can prototype such caching if you like. >>>> >>>> Regards, Peter >>>> >>>> On 07/22/2016 06:07 AM, Masayoshi Okutsu wrote: >>>>> Hi Peter, >>>>> >>>>> Thank you for your suggestion. Actually CacheKey is used for >>>>> storing information required to load resource bundles during a >>>>> ResourceBundle.getBundle call. The current CacheKey usage may be >>>>> too tricky and cause some maintenance problems. I will file a >>>>> separate issue on that problem. I wanted to work on some clean up >>>>> of the CacheKey usage, but I haven't had a chance. >>>>> >>>>> Thanks, >>>>> Masayoshi >>>>> >>>>> >>>>> On 7/21/2016 10:13 PM, Peter Levart wrote: >>>>>> Hi Masayoshi, >>>>>> >>>>>> Previously the CacheKey::clone() method cleared a reference to >>>>>> 'providers' in the clone making the provides unreachable from the >>>>>> clone and making the clone unable to obtain providers. Now you >>>>>> also reset the 'providersChecked' flag which makes the clone be >>>>>> able to re-obtain the providers. This is dangerous as the clone >>>>>> is used as a key in the cache and is strongly reachable from the >>>>>> cache. A slight future modification of code could unintentionally >>>>>> produce a class loader leak. To prevent that, I would somehow >>>>>> mark the clone so that any attempt to invoke getProviders() on >>>>>> the clone would throw IllegalStateException. >>>>>> >>>>>> Regards, Peter >>>>>> >>>>>> On 07/21/2016 06:14 AM, Masayoshi Okutsu wrote: >>>>>>> Hi, >>>>>>> >>>>>>> Please review the fix for JDK-8161203. The fix is to lazily load >>>>>>> ResourceBundleProviders. It's not necessary to load providers >>>>>>> before cache look-up. >>>>>>> >>>>>>> Issue: >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8161203 >>>>>>> >>>>>>> Webrev: >>>>>>> http://cr.openjdk.java.net/~okutsu/9/8161203/webrev.01 >>>>>>> >>>>>>> Thanks, >>>>>>> Masayoshi >>>>>>> >>>>>> >>>>> >>>> >>> >> > From blackdrag at gmx.org Tue Aug 2 16:51:20 2016 From: blackdrag at gmx.org (Jochen Theodorou) Date: Tue, 2 Aug 2016 18:51:20 +0200 Subject: Issue with an automatic module In-Reply-To: <5477d77d-de73-cd52-267b-803b27e0e469@gmail.com> References: <40663b81-01a0-d349-b75a-c88bcb5cfc30@oracle.com> <5f1edb4a-8ade-6e65-a547-8f6019d1380e@oracle.com> <57A09927.7010209@redhat.com> <5477d77d-de73-cd52-267b-803b27e0e469@gmail.com> Message-ID: <57A0CF88.4090002@gmx.org> On 02.08.2016 15:19, Peter Levart wrote: > Hi, > > Top-package (unnamed package) classes can not be referenced from classes > in named packages anyway, so they usually represent just reflective > entry points (such as Main class with main() method). In Java that is you mean. The JVM does not care about the package as long as the class can be found, nor does a class loader. It is a java compiler restriction, an intended one, but only for those wanting to be a java compiler. bye Jochen From pbenedict at apache.org Tue Aug 2 17:12:46 2016 From: pbenedict at apache.org (Paul Benedict) Date: Tue, 2 Aug 2016 12:12:46 -0500 Subject: Flag missing with "requires java.base"? In-Reply-To: <579F37D2.8000808@redhat.com> References: <579A4C2E.9020206@oracle.com> <579B0A5A.2020104@redhat.com> <579BA1BD.5030105@oracle.com> <579F37D2.8000808@redhat.com> Message-ID: Correct me if wrong, but it seems there is no universal way to flag something as compiler/tool generated. My take away from Alex's comments is that ACC_SYNTHETIC is very much concerned with implicitness/explicitness... but why? I still don't understand why it *must* be concerned anything like that. I'd just like to state that definition sounds overloaded to me. Furthermore, I think the definition of ACC_MANDATED is overloaded too. If the JLS mandates a construct, it must be in the class file -- yet why does the means matter? I prose the flag should mean no more than a mandate. It's mandated so it must exist -- how it got there is irrelevant to me with regard to this flag. So doesn't anyone (Alex? Andrew?) find value in universally specifying something was generated? That's what I thought ACC_SYNTHETIC could be used for. If there is pushback on this idea, is there a universal way that I have neglected to see? Cheers, Paul On Mon, Aug 1, 2016 at 6:51 AM, Andrew Dinn wrote: > > > On 29/07/16 19:34, Alex Buckley wrote: > > On 7/29/2016 12:48 AM, Andrew Dinn wrote: > >> It might be worth pointing out at this stage in the discussion that > >> ACC_SYNTHETIC was never given a hard and fast meaning whose logic > >> transcends the vagaries of what javac decided to use it for -- citation, > >> Neal Gafter in a thread I was involved in many years ago on the meaning > >> of this term: > >> > >> Said definition: > >> > >> > http://mail.openjdk.java.net/pipermail/compiler-dev/2010-August/002257.html > >> > >> > >> and explanation: > >> > >> > http://mail.openjdk.java.net/pipermail/compiler-dev/2010-August/002258.html > >> > > > > On the contrary, Neal and I agree on the hard and fast meaning of > > ACC_SYNTHETIC. The second link says: > > ... > > Well, it's rather a moot point as to whether it is you and Neal or, as I > phrased it, "the vagaries of what javac decided to use [SYNTHETIC] for" > that constitutes the determining factor since obviously javac didn't > really 'decide' anything except by way of proxy for those who informed > it's construction as a piece of code. > > My point was not that ACC_SYNTHETIC did not have a determinate meaning > (which is what you seem to take me as saying) rather that the decision > as to what it means was made within the scope of what javac wanted to do > with this property and that said meaning is not up for grabs for some > external program to freight with its own semantic content. That is > precisely (yes, I do mean precisely) what my exchange with Neal > established. > > regards, > > > Andrew Dinn > ----------- > Senior Principal Software Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander > From eric at tibco.com Tue Aug 2 17:43:45 2016 From: eric at tibco.com (Eric Johnson) Date: Tue, 2 Aug 2016 10:43:45 -0700 Subject: Exporting - the wrong default? In-Reply-To: References: <03d2c64f-4d24-f303-112f-2e6baa0514c2@oracle.com> <4f49aa3a-4f87-0ca7-4f5e-6048bfbd1b04@oracle.com> <80d34193-5846-e792-bc64-8b12ea118fb4@redhat.com> <3354e329-2fa4-a66e-3b3b-ab77501d1237@redhat.com> <5bcb93f9-d6f1-0690-f42c-ad290c76d971@oracle.com> Message-ID: <741302ca-6d23-a4ba-90c3-fd0549882cb9@tibco.com> There's so much to tackle on this thread... On 8/2/16 5:47 AM, Stephen Colebourne wrote: > IMO, we need to get existing OSS libraries migrated to modules ASAP to > maintain the ecosystem, which requires the migration to be really > simple. Get this wrong, and we'll all just carry on using the > classpath, and the last 5+ years of effort in the JDK will have little > value. Indeed. Commercial vendors will have the same problem. And to the extent that we use open source libraries, we may need to fork said libraries. In working with OSGi, my company has had enormous issues with getting the metadata right for libraries - nothing obviously wrong with the code, but the metadata is a royal pain. It doesn't appear to transfer between platforms seamlessly. Potentially a huge cost with JDK 9 modularization. At the same time, I work on security issues. I want security by default. So I want both sides of this question to get the answer they want. Nasty conundrum we've found ourselves in. One part of the split is simple - modules are a (presumably) useful compile time constraint. Giving Java the ability to hide public classes simply because the author didn't really want to expose them, but the language constraints didn't give them a choice, that seems like an improvement. This is not a security problem, just a language problem. Bring module enforcement into the runtime, and it is now a security problem. All security problems are trade-offs. For one step, (as I've mentioned before) I'd really like someone to point at some security analysis document that goes through the threat model analysis (or its equivalent), so we can have a deeper discussion than "default to secure" as the only answer. Off the top of my head, I cannot think of any threats to something like Eclipse, which has already embraced the OSGi form of modularization. How will Jigsaw modularization enforcement at runtime can actually make Eclipse safer? I don't think it will. On the server side - much different question. On the server side, without deep analysis, I suspect the default to enforce module boundaries makes sense. However, we also know, up front, that such a step will break things. To fix that breakage, will mean lots of changes to code, made by a lot of people, not all with lots of experience, across a lot of libraries. In other words, an opportunity to accidentally introduce new security bugs while trying to work within a new security framework. Again, wanting a threat model analysis, because helping those developers cross the chasm should be part of the threat equation that we're trying to solve. So we really want a place where people can start using modules at compile time, and choose to opt into module boundary enforcement at runtime. I suspect it is probably an OK starting position if the JRE itself always benefits from boundary enforcement. But everything else - not sure that's a good idea, as it will blow-up the Java ecosystem. Two possibilities - either a flag for the Java runtime to enforce module boundaries (default off?), or let individual modules choose whether they opt-in. Actually, both might be useful. With the opt-in on a module basis, the open source project that needs to produce a module can produce one quickly, and opt-out of boundary enforcement. No source code changes besides module declarations, so minimal risk. That way, those developers can avoid all the hacking on code and changes that might be necessary by flipping to strict enforcement immediately. Over time, downstream users of those open source projects will be able to test those libraries by flipping a switch, and enforcing module boundaries for a given module, then testing to see if that caused problems. They can then go back to the open source project with definitive information, gleaned from actual use, about what is necessary to opt-in to full enforcement. As for flags on the runtime, it might be good to have a flag which defaults to off. Other settings would be "warn", and "strict". SELinux, which seems closely analogous to this problem, has a similar model of "warn" vs. "enforce". So perhaps a good pattern to follow? Eric From adinn at redhat.com Wed Aug 3 09:03:33 2016 From: adinn at redhat.com (Andrew Dinn) Date: Wed, 3 Aug 2016 10:03:33 +0100 Subject: Flag missing with "requires java.base"? In-Reply-To: References: <579A4C2E.9020206@oracle.com> <579B0A5A.2020104@redhat.com> <579BA1BD.5030105@oracle.com> <579F37D2.8000808@redhat.com> Message-ID: <57A1B365.3080803@redhat.com> On 02/08/16 18:12, Paul Benedict wrote: > Correct me if wrong, but it seems there is no universal way to flag > something as compiler/tool generated. My take away from Alex's comments > is that ACC_SYNTHETIC is very much concerned with > implicitness/explicitness... but why? I still don't understand why it > *must* be concerned anything like that. I'd just like to state that > definition sounds overloaded to me. There is indeed no way to flag something as compiler/tool generated. The thread I cited was about exactly that. AOP (you may or not remember what that that tool did but it doesn't really matter) was flagging generated methods as synthetic and the explanation I received when this led to subsequent errors was that this was invalid; such flagging is the prerogative of the compiler for its own narrowly defined (and, as Alex was so keen to point out, quite well-defined) purposes. You may want that flag to mean something else but it doesn't. You may argue that it ought mean something else but that is not going to happen unless i) you can arrive at a consensus that this meaning is better than the current one and, crucially, ii) you can guarantee that changing javac and other tools to adopt your new meaning is not going to cause legacy problems. > Furthermore, I think the definition of ACC_MANDATED is overloaded too. > If the JLS mandates a construct, it must be in the class file -- yet why > does the means matter? I prose the flag should mean no more than a > mandate. It's mandated so it must exist -- how it got there is > irrelevant to me with regard to this flag. As above? > So doesn't anyone (Alex? Andrew?) find value in universally specifying > something was generated? That's what I thought ACC_SYNTHETIC could be > used for. If there is pushback on this idea, is there a universal way > that I have neglected to see? I am sure it /might/ be useful to be able to specify this but I have not actually found a need for it myself. Rather than hijacking SYNTHETIC I suggest it would be much better to introduce a new GENERATED class/method attribute indicating that the relevant object was generated by a bytecode transformer tool (possibly with associated data identifying the tool and, perhaps, its version). In the case of a method it would also be useful if the attribute could be used to record modification of bytecode (or at least injection) by detailing specific bytecode segments introduced by a tool. Of course, this would require bytecode transformer tools to update such indices (underlying libraries like ASM or Javassist might be able to help with that). regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From dalibor.topic at oracle.com Wed Aug 3 12:52:22 2016 From: dalibor.topic at oracle.com (dalibor topic) Date: Wed, 3 Aug 2016 14:52:22 +0200 Subject: Exporting - the wrong default? In-Reply-To: References: <03d2c64f-4d24-f303-112f-2e6baa0514c2@oracle.com> <4f49aa3a-4f87-0ca7-4f5e-6048bfbd1b04@oracle.com> <80d34193-5846-e792-bc64-8b12ea118fb4@redhat.com> <3354e329-2fa4-a66e-3b3b-ab77501d1237@redhat.com> <5bcb93f9-d6f1-0690-f42c-ad290c76d971@oracle.com> Message-ID: <8d567a2c-74fe-8db9-518a-029e72f520c8@oracle.com> On 02.08.2016 14:47, Stephen Colebourne wrote: > today. The vast majority of libraries porting to Java 9 will have to > export all packages because nothing else will work. In virtually no > cases, is the end-user developer going to be changing the exported > packages of the libraries they depend on. OK, let's adjust the "reflection under failsafe defaults" example to take the "vast majority" effect into account. Let's say that a component author is n times more likely to export the packages containing Sling and Stone than not, for example by just exporting all packages. In that case, the headache inducing XPSling+XPStone and XPSling+XNStone cases give us 2*(n*n) combinations that might cause a headache (i.e. 2n^2). They are balanced out by XNSling+XPStone and XNSling+XNStone cases, which give us another 2n^2 combinations that can't cause a headache. In addition, there are 8n + 4 other combinations that can't cause a headache, such as XNSling+OPStone, etc. From this example, I think two things are quite obvious: a) Regardless of how high n is, the ratio of headache inducing combinations vs. the total is always going to be less than a half - i.e. the fail safe default always provides less risk than the coin toss of the permissive default, regardless of how widespread a practice of just exporting all packages to everyone would be. c) Looking at https://www.wolframalpha.com/input/?i=(2n%5E2)%2F(4n%5E2%2B8n%2B4) , even assuming that n is as extreme as 15, you get a roughly 44% ratio of headache inducing cases - which would still be quite an improvement over the coin toss of the permissive case. If we look at your survey in http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-July/008823.html, you found about 20 components that export all packages to everyone vs. about 5 that don't. That suggests n may be closer to 4 for some types of components. In that case the ratio of headache inducing combinations ends up being a mere 32% compared to the coin toss probability of the permissive default. I think that's quite a substantial difference. > To get any benefit from the new modular scope, existing OSS projects > will require significant backward-incompatible reworking - to take > existing public classes and methods and move them to different > packages. This is major work, and far less likely than just exporting > everything (how many years has it taken to do this in the JDK?). I'm not sure that the JDK with its millions of lines of code developed over decades in hundreds of packages is a perfect example to guide expectations of effort necessary to benefit from modules for most components in the Java ecosystem. For example, assuming for the sake of argument that the effort to determine and untangle dependencies and exports between packages is roughly quadratic in the number of packages, a multi-year effort for the JDK would translate to much smaller efforts for components with a much smaller number of packages to consider. As a real world example, in your survey above around half of the components have 5 packages or less. > IMO, we need to get existing OSS libraries migrated to modules ASAP to > maintain the ecosystem, which requires the migration to be really > simple. Yes, a general migratory movement would be great! Of course, many component developers may want to continue to support JDK 8, so for example http://openjdk.java.net/jeps/238 is important in this context, as well. Outside of individual organizations, it might be quite hard for everyone everywhere to migrate at the same time though, so ways for modularized and non-modularized components to safely coexist are important in order to allow such migrations to take place at the pace their users and developers are comfortable with. For some of the ways the proposed module system design works hard behind the scenes to support that approach, please see http://openjdk.java.net/projects/jigsaw/spec/sotms/#compatibility--migration . cheers, dalibor topic -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From pbenedict at apache.org Wed Aug 3 15:49:11 2016 From: pbenedict at apache.org (Paul Benedict) Date: Wed, 3 Aug 2016 10:49:11 -0500 Subject: Issue with an automatic module In-Reply-To: <57A0CF88.4090002@gmx.org> References: <40663b81-01a0-d349-b75a-c88bcb5cfc30@oracle.com> <5f1edb4a-8ade-6e65-a547-8f6019d1380e@oracle.com> <57A09927.7010209@redhat.com> <5477d77d-de73-cd52-267b-803b27e0e469@gmail.com> <57A0CF88.4090002@gmx.org> Message-ID: Given that "automatic modules" are meant to be a migration path, I think refusing any legacy jar adds an unfortunate surprise to migrating. I understand the intent to throw FindException with regard to real modules (has module-info.class), but why apply the same restriction to *automatic* modules? I would like to know the design intent here. Is there a downside in carving out an exception (no pun) for automatic modules? Cheers, Paul On Tue, Aug 2, 2016 at 11:51 AM, Jochen Theodorou wrote: > On 02.08.2016 15:19, Peter Levart wrote: > >> Hi, >> >> Top-package (unnamed package) classes can not be referenced from classes >> in named packages anyway, so they usually represent just reflective >> entry points (such as Main class with main() method). >> > > In Java that is you mean. The JVM does not care about the package as long > as the class can be found, nor does a class loader. It is a java compiler > restriction, an intended one, but only for those wanting to be a java > compiler. > > bye Jochen > From Alan.Bateman at oracle.com Wed Aug 3 18:43:42 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 3 Aug 2016 11:43:42 -0700 Subject: Issue with an automatic module In-Reply-To: References: <40663b81-01a0-d349-b75a-c88bcb5cfc30@oracle.com> <5f1edb4a-8ade-6e65-a547-8f6019d1380e@oracle.com> <57A09927.7010209@redhat.com> <5477d77d-de73-cd52-267b-803b27e0e469@gmail.com> <57A0CF88.4090002@gmx.org> Message-ID: On 03/08/2016 08:49, Paul Benedict wrote: > Given that "automatic modules" are meant to be a migration path, I > think refusing any legacy jar adds an unfortunate surprise to > migrating. I understand the intent to throw FindException with regard > to real modules (has module-info.class), but why apply the same > restriction to *automatic* modules? Named modules cannot contain types in the unnamed package. As per the discussion, then such types could be ignored but there is no guarantee that there aren't references to those types. There are several other reasons why a JAR file might be "rejected", the most obvious is where a module name cannot be derived from the name of the JAR file ("_.jar" for example). In general then there should no shame whatsoever in leaving some JAR files on the class path during migration. Automatic modules are the bridge for doing exactly that. -Alan From sundararajan.athijegannathan at oracle.com Thu Aug 4 09:10:22 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Thu, 4 Aug 2016 14:40:22 +0530 Subject: RFR 8146721: FileCopierPlugin should not create fake module Message-ID: Please review http://cr.openjdk.java.net/~sundar/8146721/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8146721 Thanks, -Sundar From peter.levart at gmail.com Thu Aug 4 09:21:31 2016 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 4 Aug 2016 11:21:31 +0200 Subject: ResourceBundleProvider(s) design Message-ID: Hi, I would like to ask about why java.util.spi.ResourceBundleProvider is designed they way it is. I'm questioning the design of the following part of specification: "The provider service type is determined by {@code basename+"Provider"}." Why is that necessary? It requires that provider service types are specialized per bundle base name. Each bundle base name requires a specific ResourceBundleProvider service subtype. This seems superfluous with the API point that ResourceBundleProvider declares: public interface ResourceBundleProvider { /** * Returns a {@code ResourceBundle} for the given bundle name and locale. * This method returns {@code null} if there is no {@code ResourceBundle} * found for the given parameters. * * * @param baseName * the base bundle name of the resource bundle, a fully * qualified class name * @param locale * the locale for which the resource bundle should be loaded * @return the ResourceBundle created for the given parameters, or null if no * {@code ResourceBundle} for the given parameters is found */ public ResourceBundle getBundle(String baseName, Locale locale); } .., the getBundle method takes a 'baseName' parameter. Why does it need such parameter when the service type already implies the bundle base name? What is the rationale behind such design? Who in this design (which module) is meant to define the service type for a particular bundle base name? The consuming module or the providing module? In case it is the consuming module, then the providing module will have an explicit dependency on the consuming module, which goes against the aim of service providers that provide services to multiple modules. If the providing module declares the service type, then the consuming module will have an explicit dependency on the providing module, which also defeats the purpose of service provider's implicit coupling. So the only thing left is to define the service types for each particular bundle base name in a special module that consumers and providers depend on. But this just goes against the aim of encapsulation. The bundle name should be a private contract between an unknown consumer and unknown provider - no other module(s) should be involved. A better design would be to not require that service type name be derived from bundle base name and have a constant service type regardless of bundle base name: java.util.spi.ResourceBundleProvider. So all providers would be polled for a particular bundle name and only the ones responsible for the particular name would respond with a non-null ResourceBundle instance. But this would present a problem in resolving of the transitive closure of dependent observable modules as it would pull-in all modules that provide bundles and not only those that provide bundles for required names. So without some additional resolution constraints this would present a problem. So I wonder whether the addition of ResourceBundleProvider service provider interface to ResourceBundle resolution process is a good idea at all. Now that resources are not encapsulated any more, " java.properties" format of bundles is resolvable among modules and "java.class" format of bundles too, when appropriate packages are exported. It feels that providing resource bundles via service provider infrastructure is too much fuss so no-one will use this mechanism if existing mechanism is more than adequate. Comments? Regards, Peter From peter.levart at gmail.com Thu Aug 4 10:26:05 2016 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 4 Aug 2016 12:26:05 +0200 Subject: ResourceBundleProvider(s) design In-Reply-To: References: Message-ID: <5ad8e43c-bdc7-d6f2-6e9b-e6c4ed3bef70@gmail.com> On 08/04/2016 11:21 AM, Peter Levart wrote: > If the providing module declares the service type, then the consuming > module will have an explicit dependency on the providing module, which > also defeats the purpose of service provider's implicit coupling. I take this back. The service type is resolved at runtime by the ResourceBundle code using the consumer module's class loader and then ResourceBundleProvider interface is used to invoke its method. But I still think that the "baseName" parameter to this method is superfluous. I also see now that using resource bundle service providers is necessary if one wants to provide different modules for different languages covering a set of bundles - each language in its own module. Normally, for "java.class" format bundles, this would require per-language classes to be split among multiple modules and this is not possible as split packages are prohibited. With ResourceBundleProvider approach one can defined a ResourceBundleProvider service type in say "main language" module together with a default implementation and then various language implementations each in its own module with own package(s). For example: module consumer { uses my.BundleProvider; } // containing: package consumer; public class Main { public static void main(String ... args) { ResourceBundle.getBundle("my.Bundle", Locale.getDefault()); } } module my.bundle { exports my; provides my.BundleProvider with my.bundle.Bundle.Provider; } // containing: package my; public interface BundleProvider extends java.util.spi.ResourceBundleProvider {} module my.bundle.en { requires my.bundle; provides my.BundleProvider with my.bundle.en.Bundle.Provider; } module my.bundle.de { requires my.bundle; provides my.BundleProvider with my.bundle.de.Bundle.Provider; } etc... Regards, Peter From james.laskey at oracle.com Thu Aug 4 10:52:10 2016 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Thu, 4 Aug 2016 07:52:10 -0300 Subject: RFR 8146721: FileCopierPlugin should not create fake module In-Reply-To: References: Message-ID: <0E7D46A1-25CD-4CE9-B64E-150A85770E7E@oracle.com> Fix grammar on FileCopierPluginTest.java: "We didn't add any .class resources of java.base module!? +1 > On Aug 4, 2016, at 6:10 AM, Sundararajan Athijegannathan wrote: > > Please review http://cr.openjdk.java.net/~sundar/8146721/webrev.00/ for > https://bugs.openjdk.java.net/browse/JDK-8146721 > > Thanks, > > -Sundar > From sundararajan.athijegannathan at oracle.com Thu Aug 4 11:47:25 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Thu, 4 Aug 2016 17:17:25 +0530 Subject: RFR 8146721: FileCopierPlugin should not create fake module In-Reply-To: <0E7D46A1-25CD-4CE9-B64E-150A85770E7E@oracle.com> References: <0E7D46A1-25CD-4CE9-B64E-150A85770E7E@oracle.com> Message-ID: Fixed: http://cr.openjdk.java.net/~sundar/8146721/webrev.01/ Thanks, -Sundar On 8/4/2016 4:22 PM, Jim Laskey (Oracle) wrote: > Fix grammar on FileCopierPluginTest.java: "We didn't add any .class resources of java.base module!? > > +1 > > > >> On Aug 4, 2016, at 6:10 AM, Sundararajan Athijegannathan wrote: >> >> Please review http://cr.openjdk.java.net/~sundar/8146721/webrev.00/ for >> https://bugs.openjdk.java.net/browse/JDK-8146721 >> >> Thanks, >> >> -Sundar >> From harold.seigel at oracle.com Thu Aug 4 12:46:21 2016 From: harold.seigel at oracle.com (harold seigel) Date: Thu, 4 Aug 2016 08:46:21 -0400 Subject: RFR(L) 8136930: Simplify use of module-system options by custom launchers In-Reply-To: References: <4de6f3b7-d5ed-8569-aab9-798f39a1f134@oracle.com> <579FEC0F.1010407@oracle.com> Message-ID: <9eb4e7de-cfba-772c-c67a-4da1d8074646@oracle.com> Hi, Please review this update for this fix. This webrev only shows the changes since the last webrev. These changes include: 1. Fix forJDK-8162415 - the JVM now prints the following message when ignoring a property and PrintWarnings is enabled: warning: Ignoring system property options whose names start with '-Djdk.module'. They are reserved for internal use. 2. Fix for JDK-8162412 3. Fixes a problem where JVMTI was failing two JCK vm/jvmti tests 4. Incorporates review comments from Alan, Coleen, Dan, and Lois 5. Fixes JTReg tests that failed due to the new option syntax. Revised webrev: http://cr.openjdk.java.net/~hseigel/bug_8136930.hs2/ Thanks, Harold On 8/2/2016 9:25 AM, harold seigel wrote: > > Hi Lois, > > Thanks for the review. Please see comments in-line. > > Harold > > > On 8/1/2016 8:40 PM, Lois Foltan wrote: >> >> On 7/17/2016 7:05 PM, harold seigel wrote: >>> Hi, >>> >>> Please review these Hotspot VM only changes to process the seven >>> module-specific options that have been renamed to have gnu-like >>> names. JDK changes for this bug will be reviewed separately. >>> >>> Descriptions of these options are here >>> . For these six options, >>> --module-path, --upgrade-module-path, --add-modules, >>> --limit-modules, --add-reads, and --add-exports, the JVM just sets a >>> system property. For the --patch-module option, the JVM sets a >>> system property and then processes the option in the same way as >>> when it was named -Xpatch. >>> >>> Additionally, the JVM now checks properties specified on the command >>> line. If a property matches one of the properties used by one of >>> the above options then the JVM ignores the property. This forces >>> users to use the explicit option when wanting to do things like add >>> a module or a package export. >>> >>> The RFR contains two new tests. Also, many existing tests were >>> changed to use the new option names. >>> >>> JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8136930 >>> >>> Webrev: http://cr.openjdk.java.net/~hseigel/bug_8136930.hs/ >> >> Hi Harold, >> >> Overall looks good. A couple of comments: >> >> src/share/vm/prims/jvmtiEnv.cpp >> - line #3428 - The if statement is incorrect. There are internal >> properties, like jdk.boot.class.path.append, whose value if non-null >> should be returned. > This code will be reworked in the next version of these changes > because of multiple issues. >> >> src/share/vm/runtime/arguments.cpp >> - Arguments::append_to_addmods_property was added before the VM >> starting to process --add-modules. So with this fix, it seems like >> it could be simply changed to: >> >> bool Arguments::append_to_addmods_property(const char* module_name) { >> PropertyList_unique_add(&_system_properties, >> Arguments::get_property("jdk.module.addmods"), >> module_name, >> AppendProperty, UnwriteableProperty, InternalProperty); >> } >> >> Please consider making this change since currently it contains a lot >> of duplicated code that is now unnecessary. > The one difference is that append_to_addmods_property() returns a > status but PropertyList_unique_add() does not. I'll look into this a > bit further. >> >> - line #3171, should the comment be "--add-modules=java.sql" instead >> of "--add-modules java.sql"? > yes. > > The changes suggested by you, Coleen, and Dan will be in the next > version of this webrev. > > Thanks, Harold >> >> Thanks, >> Lois >> >> >> >> >> >> >> >> >> >> >> >> >> >>> >>> The changes were tested with the JCK lang and VM tests, the JTreg >>> hotspot tests, and the RBT hotspot nightlies. >>> >>> Thanks, Harold >> > From dalibor.topic at oracle.com Thu Aug 4 13:05:44 2016 From: dalibor.topic at oracle.com (dalibor topic) Date: Thu, 4 Aug 2016 15:05:44 +0200 Subject: Exporting - the wrong default? In-Reply-To: <741302ca-6d23-a4ba-90c3-fd0549882cb9@tibco.com> References: <03d2c64f-4d24-f303-112f-2e6baa0514c2@oracle.com> <4f49aa3a-4f87-0ca7-4f5e-6048bfbd1b04@oracle.com> <80d34193-5846-e792-bc64-8b12ea118fb4@redhat.com> <3354e329-2fa4-a66e-3b3b-ab77501d1237@redhat.com> <5bcb93f9-d6f1-0690-f42c-ad290c76d971@oracle.com> <741302ca-6d23-a4ba-90c3-fd0549882cb9@tibco.com> Message-ID: <5086720e-aece-5403-1d75-9b3baf23ebfa@oracle.com> On 02.08.2016 19:43, Eric Johnson wrote: > So we really want a place where people can start using modules at > compile time, and choose to opt into module boundary enforcement at > runtime. I think that Alex goes a bit into all that in the unnamed and automatic module sections in his JVM Language Summit talk: https://www.youtube.com/watch?v=QnMDsI2GbOc . For some interesting usage of layers to generate dynamic modules, for example, please see the Nashorn talk from the same event: https://www.youtube.com/watch?v=Zk6a6jNZAt0 . A more detailed exploration of different migration approaches to fully modular applications is available in the Advanced Modular Development talk at https://www.youtube.com/watch?v=SU1WFX8yeKM . > But everything else - > not sure that's a good idea, as it will blow-up the Java ecosystem. As exciting [2] as predictions of impending doomsday often seem, they don't turn out to be very likely in practice. [0] [1] cheers, dalibor topic [0] "Comet May Kill All Earth Life Says Scientist," The San Francisco Call (San Francisco, CA), February 8, 1910, Page 1, Image 1, col. 2. http://chroniclingamerica.loc.gov/lccn/sn85066387/1910-02-08/ed-1/seq-1/#words=Halley's+Cyanogen+cyanogen+Flammarion+Yerkes+comet [1] http://sunsite.uakom.sk/sunworldonline/swol-08-1998/swol-08-torvalds.html [2] http://tvtropes.org/pmwiki/pmwiki.php/Main/TheEndOfTheWorldAsWeKnowIt -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From Alan.Bateman at oracle.com Thu Aug 4 13:58:17 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 4 Aug 2016 06:58:17 -0700 Subject: RFR 8146721: FileCopierPlugin should not create fake module In-Reply-To: References: <0E7D46A1-25CD-4CE9-B64E-150A85770E7E@oracle.com> Message-ID: <4afff632-c7ca-9a3b-b757-a166ff316b38@oracle.com> On 04/08/2016 04:47, Sundararajan Athijegannathan wrote: > Fixed: http://cr.openjdk.java.net/~sundar/8146721/webrev.01/ > This looks okay, for now at least, but I assume having the resource in /java.base/other will need to be examined once other issues (like per module man pages, the top section in the JMOD, ...) are sorted out. -Alan From peter.levart at gmail.com Thu Aug 4 16:47:22 2016 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 4 Aug 2016 18:47:22 +0200 Subject: RFR: 8161203: ResourceBundle.getBundle performance regression In-Reply-To: <0e19e8ab-570e-f9d6-4602-dee90adf213e@oracle.com> References: <7fc61181-7c3c-ea1c-d07a-90a2e712844c@oracle.com> <5991183a-8d2a-967d-74ec-c99e7d1636f3@oracle.com> <884a78a8-ebfb-a15d-a036-37b9fd377401@gmail.com> <2b8eb9f2-7b81-512b-6dde-0631d2c01c39@oracle.com> <4826d920-0ec2-5f97-5266-c53458ff779b@gmail.com> <0e19e8ab-570e-f9d6-4602-dee90adf213e@oracle.com> Message-ID: <1dc3c7f5-638f-339c-a935-178c6267d562@gmail.com> Hi Masayoshi, Just a thought. What if RB.clearCache(classLoader) was specified as equivalent to RB.clearCache(classLoader.getUnnamedModule()) ? I think that would be backwards compatible... Regards, Peter On 08/02/2016 05:30 PM, Masayoshi Okutsu wrote: > Hi Peter, > > Thanks for bringing up the semantics issue of clearCache. You are > right. There's some semantics change in clearCache(ClassLoader). Let > me look into it. > > The format field-related changes look good to me. > > Thanks, > Masayoshi > > On 8/1/2016 11:10 PM, Peter Levart wrote: >> Hi Masayosh, Alan, >> >> Thanks for looking at the change. >> >> I suppose application containers are already accustomed to invoke >> ResourceBundle.clearCache(ClassLoader) when undeploying an >> application so that the corresponding ClassLoader can get GCed right >> away. But there's a change in the semantics of this method that >> Jigsaw introduced... >> >> Before Jigsaw, this method was specified to: >> >> * Removes all resource bundles from the cache that have been loaded >> * using the given class loader. >> >> After Jigsaw, this method is specified to: >> >> * Removes all resource bundles from the cache that have been loaded >> * by the caller's module using the given class loader. >> >> >> Now suppose that the "caller's module" that loads the bundle is the >> application's module and the module that clears the cache is the >> container's module. The app's cache won't get cleared. I understand >> that the change in semantics was an attempt to "isolate" modules >> among themselves so that one module could not clear the cache of >> another module if they happen to map to the same class loader, but >> this also means that an application container can't easily clear the >> cache of the application it wishes to undeploy unless it uses the new >> ResourceBundle.clearCache(Module) method on each application's module >> before undeploying it. >> >> I also wonder if the change of the semantics of this method is >> backwards compatible. Suppose that some container is using this >> method to clear the cache of the application loaded by say >> "classloaderA" before undeploying it. It calls >> ResourceBundle.clearCache(classloaderA). Now suppose the container >> code is loaded by some other class loader (say "classloaderC") which >> is usually the case in today's containers. Both container and >> application classes are part of the unnamed modules of their >> corresponding class loaders. With the change in the semantics of this >> method introduced by jigsaw, the container will not clear the cache >> of the application any more since the container module is not the >> same as the application module (they are distinct unnamed modules). >> >> Anyway, I noticed an inconsistency in my webrev.04 immediately after >> posting it a week ago. I was off for a week then, so now that I'm >> back, here's the corrected webrev of my proposed change: >> >> http://cr.openjdk.java.net/~plevart/jdk9-dev/ResourceBundle.cleanup/webrev.05/ >> >> >> The only real change of logic compared to webrev.04 is that I moved >> the "format" field from the LoadSession (previous CacheKey) to >> ResourceBundle itself. This field is needed to hold the bundle's >> format for invoking the Control.needsReload() method. It is not >> semantically correct to use the value from the LoadSession as done in >> webrev.04. This has to be the value that the bundle was created with, >> so it belongs to the bundle itself. In original code it was taken >> from the cloned CacheKey that was attached to the bundle. >> >> All other changes from webrev.04 are limited to ResourceBundle.java >> file and include some comments and nits that don't change the overall >> logic. All ResourceBundle tests still pass. >> >> The diff from webrev.04 is the following: >> >> *** ResourceBundle.webrev.04.java 2016-08-01 15:33:49.408565452 >> +0200 >> --- ResourceBundle.java 2016-08-01 14:43:59.875401697 +0200 >> *************** >> *** 40,55 **** >> >> package java.util; >> >> - import jdk.internal.misc.JavaUtilResourceBundleAccess; >> - import jdk.internal.misc.SharedSecrets; >> - import jdk.internal.reflect.CallerSensitive; >> - import jdk.internal.reflect.Reflection; >> - import jdk.internal.util.concurrent.AbstractClassLoaderValue; >> - import jdk.internal.util.concurrent.ClassLoaderValue; >> - import sun.util.locale.BaseLocale; >> - import sun.util.locale.LocaleObjectCache; >> - import sun.util.locale.provider.ResourceBundleProviderSupport; >> - >> import java.io.IOException; >> import java.io.InputStream; >> import java.lang.ref.ReferenceQueue; >> --- 40,45 ---- >> *************** >> *** 69,74 **** >> --- 59,73 ---- >> import java.util.spi.ResourceBundleControlProvider; >> import java.util.spi.ResourceBundleProvider; >> >> + import jdk.internal.misc.JavaUtilResourceBundleAccess; >> + import jdk.internal.misc.SharedSecrets; >> + import jdk.internal.reflect.CallerSensitive; >> + import jdk.internal.reflect.Reflection; >> + import jdk.internal.util.concurrent.AbstractClassLoaderValue; >> + import jdk.internal.util.concurrent.ClassLoaderValue; >> + import sun.util.locale.BaseLocale; >> + import sun.util.locale.LocaleObjectCache; >> + import sun.util.locale.provider.ResourceBundleProviderSupport; >> import static >> sun.security.util.SecurityConstants.GET_CLASSLOADER_PERMISSION; >> >> >> *************** >> *** 346,354 **** >> */ >> public abstract class ResourceBundle { >> >> - /** initial size of the bundle cache */ >> - private static final int INITIAL_CACHE_SIZE = 32; >> - >> static { >> SharedSecrets.setJavaUtilResourceBundleAccess( >> new JavaUtilResourceBundleAccess() { >> --- 345,350 ---- >> *************** >> *** 386,392 **** >> >> >> /** >> ! * The cache of BundleReference(s) per class loader, bundle >> base name and locale. >> */ >> private static final ClassLoaderValue cache >> = new ClassLoaderValue<>(); >> --- 382,389 ---- >> >> >> /** >> ! * The cache of BundleReference(s) per class loader, module, >> bundle base name >> ! * and locale. >> */ >> private static final ClassLoaderValue cache >> = new ClassLoaderValue<>(); >> *************** >> *** 419,430 **** >> * The parent bundle is searched by {@link #getObject getObject} >> * when this bundle does not contain a particular resource. >> */ >> ! protected ResourceBundle parent = null; >> >> /** >> * The locale for this bundle. >> */ >> ! private Locale locale = null; >> >> /** >> * The base bundle name for this bundle. >> --- 416,427 ---- >> * The parent bundle is searched by {@link #getObject getObject} >> * when this bundle does not contain a particular resource. >> */ >> ! protected ResourceBundle parent; >> >> /** >> * The locale for this bundle. >> */ >> ! private Locale locale; >> >> /** >> * The base bundle name for this bundle. >> *************** >> *** 432,437 **** >> --- 429,440 ---- >> private String name; >> >> /** >> + * Bundle format which is necessary for calling >> + * Control.needsReload(). >> + */ >> + private String format; >> + >> + /** >> * The flag indicating this bundle has expired in the cache. >> */ >> private volatile boolean expired; >> *************** >> *** 622,629 **** >> >> /** >> * A session object used during the {@link #getBundle} call. >> ! * The loader may be null, but the base name, the locale and >> ! * module must have a non-null value. >> */ >> private static class LoadSession { >> // These four are the actual keys for lookup in cache. >> --- 625,633 ---- >> >> /** >> * A session object used during the {@link #getBundle} call. >> ! * The loader may be null (in which case it is considered to be >> the >> ! * bootstrap class loader), but the module, base name, and >> locale must have >> ! * a non-null value. >> */ >> private static class LoadSession { >> // These four are the actual keys for lookup in cache. >> *************** >> *** 642,651 **** >> return key().get(loader); >> } >> >> - // bundle format which is necessary for calling >> - // Control.needsReload(). >> - private String format; >> - >> // Placeholder for an error report by a Throwable >> private Throwable cause; >> >> --- 646,651 ---- >> *************** >> *** 699,712 **** >> return callerHasProvider == Boolean.TRUE; >> } >> >> - String getFormat() { >> - return format; >> - } >> - >> - void setFormat(String format) { >> - this.format = format; >> - } >> - >> private void setCause(Throwable cause) { >> if (this.cause == null) { >> this.cause = cause; >> --- 699,704 ---- >> *************** >> *** 734,740 **** >> } >> } >> return "LookupSession[" + name + ", lc=" + l + ", ldr=" >> + getLoader() >> ! + "(format=" + format + ")]"; >> } >> } >> >> --- 726,732 ---- >> } >> } >> return "LookupSession[" + name + ", lc=" + l + ", ldr=" >> + getLoader() >> ! + "]"; >> } >> } >> >> *************** >> *** 1666,1672 **** >> bundle = loadBundleFromProviders(baseName, targetLocale, >> providers, loadSession); >> if (bundle != null) { >> ! loadSession.setFormat(UNKNOWN_FORMAT); >> } >> } >> // If none of providers returned a bundle and the caller >> has no provider, >> --- 1658,1664 ---- >> bundle = loadBundleFromProviders(baseName, targetLocale, >> providers, loadSession); >> if (bundle != null) { >> ! bundle.format = UNKNOWN_FORMAT; >> } >> } >> // If none of providers returned a bundle and the caller >> has no provider, >> *************** >> *** 1690,1696 **** >> } >> >> if (bundle != null) { >> ! loadSession.setFormat(format); >> break; >> } >> } catch (Exception e) { >> --- 1682,1688 ---- >> } >> >> if (bundle != null) { >> ! bundle.format = format; >> break; >> } >> } catch (Exception e) { >> *************** >> *** 1764,1770 **** >> Iterable providers, >> LoadSession loadSession) >> { >> ! // assert cacheKey != null && providers != null; >> return AccessController.doPrivileged( >> new PrivilegedAction<>() { >> public ResourceBundle run() { >> --- 1756,1762 ---- >> Iterable providers, >> LoadSession loadSession) >> { >> ! // assert loadSession != null && providers != null; >> return AccessController.doPrivileged( >> new PrivilegedAction<>() { >> public ResourceBundle run() { >> *************** >> *** 1819,1825 **** >> if (bundle != null) { >> // Set the format in the cache key so that it can be >> // used when calling needsReload later. >> ! loadSession.setFormat(format); >> bundle.name = loadSession.getName(); >> bundle.locale = targetLocale; >> // Bundle provider might reuse instances. So we >> should make >> --- 1811,1817 ---- >> if (bundle != null) { >> // Set the format in the cache key so that it can be >> // used when calling needsReload later. >> ! bundle.format = format; >> bundle.name = loadSession.getName(); >> bundle.locale = targetLocale; >> // Bundle provider might reuse instances. So we >> should make >> *************** >> *** 1877,1883 **** >> * Finds a bundle in the cache. Any expired bundles are marked as >> * `expired' and removed from the cache upon return. >> * >> ! * @param loadSession the key to look up the cache >> * @param control the Control to be used for the expiration >> control >> * @return the cached bundle, or null if the bundle is not >> found in the >> * cache or its parent has expired. bundle.expire >> is true >> --- 1869,1875 ---- >> * Finds a bundle in the cache. Any expired bundles are marked as >> * `expired' and removed from the cache upon return. >> * >> ! * @param loadSession the load session used look up the cache >> * @param control the Control to be used for the expiration >> control >> * @return the cached bundle, or null if the bundle is not >> found in the >> * cache or its parent has expired. bundle.expire >> is true >> *************** >> *** 1946,1954 **** >> if (!bundle.expired && expirationTime >= 0 && >> expirationTime <= >> System.currentTimeMillis()) { >> try { >> ! bundle.expired = >> control.needsReload(loadSession.getName(), >> ! loadSession.getLocale(), >> ! loadSession.getFormat(), >> loadSession.getLoader(), >> bundle, >> bundle.loadTime); >> --- 1938,1946 ---- >> if (!bundle.expired && expirationTime >= 0 && >> expirationTime <= >> System.currentTimeMillis()) { >> try { >> ! bundle.expired = >> control.needsReload(bundle.getBaseBundleName(), >> ! bundle.getLocale(), >> ! bundle.format, >> loadSession.getLoader(), >> bundle, >> bundle.loadTime); >> >> >> >> In my opinion, the change of the semantics of >> ResourceBundle.clearCache(ClassLoader) could be tolerated if the >> invocation of that method was not a requirement for application >> containers to be able to unload the app's class loader. With my >> proposed change to caching it is not a requirement any more. >> >> Regards, Peter >> >> >> On 07/25/2016 08:08 AM, Masayoshi Okutsu wrote: >>> Hi Peter, >>> >>> The change (ResourceBundle part) looks very good to me. There's a >>> simple workaround for the problem -- call >>> ResourceBundle.clearCache(ClassLoader). So I don't know how serious >>> the problem is, though. I still like this change. >>> >>> Yes, the comment in ReferenceTest should be removed. >>> >>> Thanks, >>> Masayoshi >>> >>> On 7/22/2016 10:13 PM, Peter Levart wrote: >>>> On 07/22/2016 10:46 AM, Peter Levart wrote: >>>>> Hi Masayoshi, >>>> >>>> Here's a preview of work to migrate ResourceBundle caching to using >>>> ClassLoaderValue utility: >>>> >>>> http://cr.openjdk.java.net/~plevart/jdk9-dev/ResourceBundle.cleanup/webrev.04/ >>>> >>>> >>>> The changes are very straightforward. They preserve the general >>>> structure of the logic. I renamed the CacheKey nested class to >>>> LoadSession as it now only functions as a mutable object passed >>>> around the methods while executing the getBundle() process. >>>> LoadSession is now a factory for ClassLoaderValue cache key. I >>>> moved the loadTime and expirationTime fields from LoadSession (old >>>> CacheKey) to ResourceBundle. As each cached entry must maintain >>>> it's own loadTime/expirationTime, I changed the NONEXISTENT_BUNDLE >>>> constant into a private subclass of ResourceBundle. The back-link >>>> from ResourceBundle to CacheKey is not needed any more. There is a >>>> backlink from BundleReference to ClassLoaderValue key and the >>>> associated ClassLoader to enable expunging. >>>> >>>> All 41 java/util/ResourceBundle tests pass with this change >>>> applied. Including the ReferenceTest which I had to modify a little >>>> to remove a dependency on ResourceBundle.cacheList field which is >>>> only used in test to report the size of the Map. It is not possible >>>> to obtain the size of the Map any more with this change applied, >>>> since the entries are distributed to multiple Map(s) - one Map per >>>> ClassLoader instance. The following comment in ReferenceTest could >>>> now be removed: >>>> >>>> * This test relies on the current behavior of the garbage >>>> collector and is >>>> * therefore no clear indicator of whether the fix for 4405807 works. >>>> * If the test fails, it might indicate a regression, or it might >>>> just mean >>>> * that a less aggressive garbage collector is used. >>>> >>>> ...as the ClassLoader(s) unloading does not depend on eagerness of >>>> SoftReference(s) clearing or any other activity any more. >>>> >>>> What do you think? >>>> >>>> Regards, Peter >>>> >>>>> >>>>> Thinking of how the ResourceBundle caching is implemented, I think >>>>> it has a serious flaw. The cache is currently the following: >>>>> >>>>> private static final ConcurrentMap >>>>> cacheList >>>>> >>>>> ...where the CacheKey is an object which contains WeakReference(s) >>>>> to the caller's ClassLoader and Module. This is OK. >>>>> >>>>> BundleReference, OTOH, is a SoftReference. The >>>>> problem is ResourceBundle(s) can be arbitrary user subclasses, >>>>> which means that they may have an implicit reference to the >>>>> ClassLoader that appears in the CacheKey. The consequence is that >>>>> such cache can prevent GC-ing of the ClassLoader for arbitrary >>>>> amount of time (SoftReferences are cleared on memory pressure). >>>>> >>>>> Luckily there might be a solution. If the ResourceBundle >>>>> subclasses are always resolvable from the ClassLoader that appears >>>>> in the CacheKey, then there is a utility class that I created >>>>> recently: java.lang.reflect.ClassLoaderValue. This a >>>>> package-private class as it is currently used only in >>>>> java.lang.reflect.Proxy for caching of dynamic Proxy classes, but >>>>> could be made public and moved to some jdk.internal... package. >>>>> >>>>> Basing ResourceBundle caching on this utility class could also >>>>> simplify the implementation as you wouldn't have to deal with >>>>> WeakReference(s) to ClassLoader and Module objects. You could >>>>> still have a BundleReference extending >>>>> SoftReference to release the bundles on memory >>>>> pressure but since such SoftReference(s) would be anchored in the >>>>> particular ClassLoader instance that can resolve the >>>>> ResourceBundle subclasses, it would not prevent such ClassLoader >>>>> from being GCed immediately. >>>>> >>>>> I can prototype such caching if you like. >>>>> >>>>> Regards, Peter >>>>> >>>>> On 07/22/2016 06:07 AM, Masayoshi Okutsu wrote: >>>>>> Hi Peter, >>>>>> >>>>>> Thank you for your suggestion. Actually CacheKey is used for >>>>>> storing information required to load resource bundles during a >>>>>> ResourceBundle.getBundle call. The current CacheKey usage may be >>>>>> too tricky and cause some maintenance problems. I will file a >>>>>> separate issue on that problem. I wanted to work on some clean up >>>>>> of the CacheKey usage, but I haven't had a chance. >>>>>> >>>>>> Thanks, >>>>>> Masayoshi >>>>>> >>>>>> >>>>>> On 7/21/2016 10:13 PM, Peter Levart wrote: >>>>>>> Hi Masayoshi, >>>>>>> >>>>>>> Previously the CacheKey::clone() method cleared a reference to >>>>>>> 'providers' in the clone making the provides unreachable from >>>>>>> the clone and making the clone unable to obtain providers. Now >>>>>>> you also reset the 'providersChecked' flag which makes the clone >>>>>>> be able to re-obtain the providers. This is dangerous as the >>>>>>> clone is used as a key in the cache and is strongly reachable >>>>>>> from the cache. A slight future modification of code could >>>>>>> unintentionally produce a class loader leak. To prevent that, I >>>>>>> would somehow mark the clone so that any attempt to invoke >>>>>>> getProviders() on the clone would throw IllegalStateException. >>>>>>> >>>>>>> Regards, Peter >>>>>>> >>>>>>> On 07/21/2016 06:14 AM, Masayoshi Okutsu wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> Please review the fix for JDK-8161203. The fix is to lazily >>>>>>>> load ResourceBundleProviders. It's not necessary to load >>>>>>>> providers before cache look-up. >>>>>>>> >>>>>>>> Issue: >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8161203 >>>>>>>> >>>>>>>> Webrev: >>>>>>>> http://cr.openjdk.java.net/~okutsu/9/8161203/webrev.01 >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Masayoshi >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From patrick at reini.net Thu Aug 4 17:33:38 2016 From: patrick at reini.net (Patrick Reinhart) Date: Thu, 4 Aug 2016 19:33:38 +0200 Subject: RFR: JDK-8161230 - Create java.util.stream.Stream from Iterator / Enumeration In-Reply-To: References: <96449a94df44b8a26d9c1abb800baef5@reini.net> <2239A562-0696-47D3-B63C-CD6ECB06EAF5@oracle.com> <7519b84f-6259-701e-4c36-3bd4e4118bff@reini.net> <5ddfd52d9b9b5ac20e52f3ebd85f70b5@reini.net> <57854411.3030602@reini.net> <9A267516-581F-4D2F-BB20-DDECA64BE722@oracle.com> Message-ID: <099B7E7B-86DB-4801-8436-B7938D03D546@reini.net> Hi Paul, I was quit busy lately and this comes a bit late, I guess you do not have less work ;-) On 15.07.2016 17:10, Paul Sandoz wrote: >> When I understand you correctly here we should concentrate on the public >> methods naming firstly? I initially was not sure, what a proper naming >> for the steams method was. It seem to me reasonable the way Stuart pointed >> them out on his first comment to name them something like this: >> >> Stream resources(String name) >> Stream systemResources(String name) >> >> >> Yes. I have a first proposal for the new methods and their documentation to start with the discussion about the actual API without the implementation jet: /** * Finds all the resources with the given name. A resource is some data * (images, audio, text, etc) that can be accessed by class code in a way * that is independent of the location of the code. * * Resources in a named module are private to that module. This method does * not find resources in named modules. * *

The name of a resource is a /-separated path name that * identifies the resource. * *

The search order is described in the documentation for {@link * #getResource(String)}.

* * @apiNote When overriding this method it is recommended that an * implementation ensures that any delegation is consistent with the {@link * #getResource(java.lang.String) getResource(String)} method. This should * ensure that the first element returned by the stream is the same * resource that the {@code getResource(String)} method would return. * * @param name * The resource name * * @return An stream of {@link java.net.URL URL} objects for * the resource. If no resources could be found, the stream * will be empty. Resources that the class loader doesn't have * access to will not be in the stream. * * @throws IOException * If I/O errors occur * * @see #findResources(String) * * @since 1.9 */ public Stream resources(String name) throws IOException { // to be implemented later } /** * Finds all resources of the specified name from the search path used to * load classes. The resources thus found are returned as an * {@link java.util.stream.Stream Stream} of {@link * java.net.URL URL} objects. * * Resources in a named module are private to that module. This method does * not find resources in named modules. * *

The search order is described in the documentation for {@link * #getSystemResource(String)}.

* * @param name * The resource name * * @return An stream of resource {@link java.net.URL URL} * objects * * @throws IOException * If I/O errors occur * @since 1.9 */ public static Stream systemResources(String name) throws IOException { // to be implemented later } >> Has anyone a better naming suggestion? For me those names would fit so >> far. If we look into the stream characteristics I would suggest that it >> has a unknown size and is immutable in both cases. Maybe the entries are >> also distinct, but there I'm not sure. >> > I would expect the URLs to be distinct, but that might not be consistent with URL.equals i.e. i don?t trust URL handlers :-) therefore i would be wary of including the DISTINCT characteristic. > > Paul. So, I was right to no be completely sure about the DISTINCT :-) - then I would go for NONNULL and IMMUTABLE characteristics to start with... From sundararajan.athijegannathan at oracle.com Fri Aug 5 01:36:56 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Fri, 5 Aug 2016 07:06:56 +0530 Subject: RFR 8163116: jlink exclude VM plugin does not fully support cross platform image creation Message-ID: Please review http://cr.openjdk.java.net/~sundar/8163116/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8163116 No cross platform test added. Existing test fixed to use java.base/module-info.class. Also, piggybacking to fix FileCopierPluginTest to avoid catching PluginException. -Sundar From claes.redestad at oracle.com Fri Aug 5 01:44:00 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 4 Aug 2016 18:44:00 -0700 Subject: RFR 8163116: jlink exclude VM plugin does not fully support cross platform image creation In-Reply-To: References: Message-ID: <57A3EF60.2080603@oracle.com> +1 /Claes On 08/04/2016 06:36 PM, Sundararajan Athijegannathan wrote: > Please review http://cr.openjdk.java.net/~sundar/8163116/webrev.00/ for > https://bugs.openjdk.java.net/browse/JDK-8163116 > > No cross platform test added. Existing test fixed to use > java.base/module-info.class. Also, piggybacking to fix > FileCopierPluginTest to avoid catching PluginException. > > -Sundar > From Alan.Bateman at oracle.com Fri Aug 5 03:59:30 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 4 Aug 2016 20:59:30 -0700 Subject: RFR 8163116: jlink exclude VM plugin does not fully support cross platform image creation In-Reply-To: References: Message-ID: <9476c778-3055-1737-1cd5-d63cc8b3c2a8@oracle.com> On 04/08/2016 18:36, Sundararajan Athijegannathan wrote: > Please review http://cr.openjdk.java.net/~sundar/8163116/webrev.00/ for > https://bugs.openjdk.java.net/browse/JDK-8163116 > > No cross platform test added. Existing test fixed to use > java.base/module-info.class. Also, piggybacking to fix > FileCopierPluginTest to avoid catching PluginException. > The changes looks right. (At some point then I think we need to trim down some of the excessive lines in ExcludeVMPluginTest.java to make future side-by-side diffs a bit easier to look at). -Alan From mandy.chung at oracle.com Fri Aug 5 04:08:30 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 4 Aug 2016 21:08:30 -0700 Subject: RFR 8163116: jlink exclude VM plugin does not fully support cross platform image creation In-Reply-To: References: Message-ID: > On Aug 4, 2016, at 6:36 PM, Sundararajan Athijegannathan wrote: > > Please review http://cr.openjdk.java.net/~sundar/8163116/webrev.00/ for > https://bugs.openjdk.java.net/browse/JDK-8163116 Looks fine and it?s right to use the os.name from java.base module descriptor to determine the target platform. Mandy From Alan.Bateman at oracle.com Fri Aug 5 04:18:39 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 4 Aug 2016 21:18:39 -0700 Subject: RFR: JDK-8161230 - Create java.util.stream.Stream from Iterator / Enumeration In-Reply-To: <099B7E7B-86DB-4801-8436-B7938D03D546@reini.net> References: <96449a94df44b8a26d9c1abb800baef5@reini.net> <2239A562-0696-47D3-B63C-CD6ECB06EAF5@oracle.com> <7519b84f-6259-701e-4c36-3bd4e4118bff@reini.net> <5ddfd52d9b9b5ac20e52f3ebd85f70b5@reini.net> <57854411.3030602@reini.net> <9A267516-581F-4D2F-BB20-DDECA64BE722@oracle.com> <099B7E7B-86DB-4801-8436-B7938D03D546@reini.net> Message-ID: <9d888f94-6c5e-8f39-2df0-ddadd90909b8@oracle.com> On 04/08/2016 10:33, Patrick Reinhart wrote: > Hi Paul, > > I was quit busy lately and this comes a bit late, I guess you do not have less work ;-) > > On 15.07.2016 17:10, Paul Sandoz wrote: >>> When I understand you correctly here we should concentrate on the public >>> methods naming firstly? I initially was not sure, what a proper naming >>> for the steams method was. It seem to me reasonable the way Stuart pointed >>> them out on his first comment to name them something like this: >>> >>> Stream resources(String name) >>> Stream systemResources(String name) >>> >>> >>> Yes. > I have a first proposal for the new methods and their documentation to start with the discussion about the actual API without the implementation jet: The method names look right but I don't think `throws IOException` is needed. If overridden then the implementations could be truely lazy and the method will need to specify how stream operations will wrap the errors in UncheckedIOExceptions. For the initial sentence then it might be better to say that it "Returns a stream that loads the resources ...". As I was mentioned previously, we will be replacing the javadoc for the existing methods and this will impact the wording for the new methods. It's okay to align the wording for the new methods with the old and we'll adjust once there is agreement on the proposal in JSR 376 and we bring the changes to JDK 9. -Alan From greggwon at cox.net Fri Aug 5 05:05:51 2016 From: greggwon at cox.net (Gregg Wonderly) Date: Fri, 5 Aug 2016 00:05:51 -0500 Subject: RFR: JDK-8161230 - Create java.util.stream.Stream from Iterator / Enumeration In-Reply-To: References: <96449a94df44b8a26d9c1abb800baef5@reini.net> <2239A562-0696-47D3-B63C-CD6ECB06EAF5@oracle.com> <7519b84f-6259-701e-4c36-3bd4e4118bff@reini.net> <5ddfd52d9b9b5ac20e52f3ebd85f70b5@reini.net> <57854411.3030602@reini.net> <9A267516-581F-4D2F-BB20-DDECA64BE722@oracle.com> <099B7E7B-86DB-4801-8436-B7938D03D546@reini.net> Message-ID: <4A036D1B-B6FA-48D3-B245-AE985D6F9D24@cox.net> Sent from my iPad > On Aug 4, 2016, at 11:18 PM, Alan Bateman wrote: > >> On 04/08/2016 10:33, Patrick Reinhart wrote: >> >> Hi Paul, >> >> I was quit busy lately and this comes a bit late, I guess you do not have less work ;-) >> >> On 15.07.2016 17:10, Paul Sandoz wrote: >>>> When I understand you correctly here we should concentrate on the public >>>> methods naming firstly? I initially was not sure, what a proper naming >>>> for the steams method was. It seem to me reasonable the way Stuart pointed >>>> them out on his first comment to name them something like this: >>>> >>>> Stream resources(String name) >>>> Stream systemResources(String name) >>>> >>>> >>>> Yes. >> I have a first proposal for the new methods and their documentation to start with the discussion about the actual API without the implementation jet: > The method names look right but I don't think `throws IOException` is needed. If overridden then the implementations could be truely lazy and the method will need to specify how stream operations will wrap the errors in UncheckedIOExceptions. > > For the initial sentence then it might be better to say that it "Returns a stream that loads the resources ...". I think that the use of the Stream should throw checked exceptions and these method invocations should only throw RuntimeException instances to make it clear that lazy implementations are expected. Gregg From sundararajan.athijegannathan at oracle.com Fri Aug 5 08:52:57 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Fri, 5 Aug 2016 14:22:57 +0530 Subject: RFR 8163256: jlink/plugins/ExcludeVMPluginTest.java failed with Selected VM server doesn't exist Message-ID: <228d2171-1aa4-6563-a8ea-45256c765f30@oracle.com> Please review http://cr.openjdk.java.net/~sundar/8163256/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8163256 This is a Mac specific issue. ModuleDescriptor read from jrt:/java.base/module-info.class resource returns osName() to be "Darwin" - but, System.getProperty("os.name") still returns "Mac OS X". For now, I'm fixing ExcludeVMPlugin.java to accept both. With this change, all jlink jtreg tests pass on Mac. Thanks, -Sundar From james.laskey at oracle.com Fri Aug 5 11:32:49 2016 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Fri, 5 Aug 2016 08:32:49 -0300 Subject: RFR 8163116: jlink exclude VM plugin does not fully support cross platform image creation In-Reply-To: References: Message-ID: +1 > On Aug 4, 2016, at 10:36 PM, Sundararajan Athijegannathan wrote: > > Please review http://cr.openjdk.java.net/~sundar/8163116/webrev.00/ for > https://bugs.openjdk.java.net/browse/JDK-8163116 > > No cross platform test added. Existing test fixed to use > java.base/module-info.class. Also, piggybacking to fix > FileCopierPluginTest to avoid catching PluginException. > > -Sundar > From Alan.Bateman at oracle.com Fri Aug 5 12:36:21 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 5 Aug 2016 05:36:21 -0700 Subject: RFR 8163256: jlink/plugins/ExcludeVMPluginTest.java failed with Selected VM server doesn't exist In-Reply-To: <228d2171-1aa4-6563-a8ea-45256c765f30@oracle.com> References: <228d2171-1aa4-6563-a8ea-45256c765f30@oracle.com> Message-ID: <34b3ee68-4f97-cb31-505c-914a161597a6@oracle.com> On 05/08/2016 01:52, Sundararajan Athijegannathan wrote: > Please review http://cr.openjdk.java.net/~sundar/8163256/webrev.00/ for > https://bugs.openjdk.java.net/browse/JDK-8163256 > > This is a Mac specific issue. ModuleDescriptor read from > jrt:/java.base/module-info.class resource returns osName() to be > "Darwin" - but, System.getProperty("os.name") still returns "Mac OS X". > > For now, I'm fixing ExcludeVMPlugin.java to accept both. With this > change, all jlink jtreg tests pass on Mac. > > This looks okay for now but I expect we'll need to come back to this and get the names aligned. -Alan. From mandy.chung at oracle.com Fri Aug 5 20:11:28 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 5 Aug 2016 13:11:28 -0700 Subject: Review request 8136930: Simplify use of module-system options by custom launchers Message-ID: This patch renames the module-system options to GNU-style as specified in JEP 293 [1] (see below for the new proposed option names). This addresses the problems discussed in [2] that the launcher will pass the module-system options down to the VM in the form of