From jai.forums2013 at gmail.com Sat Feb 1 07:38:42 2020 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Sat, 1 Feb 2020 13:08:42 +0530 Subject: RFR: 8211917: (zipfs) Creating or updating a JAR file system should put the MANIFEST.MF at the start Message-ID: Can I please get a review and a sponsor for a patch for https://bugs.openjdk.java.net/browse/JDK-8211917? The webrev containing the patch is available at https://cr.openjdk.java.net/~jpai/webrev/8211917/1/webrev/ The commit in the patch updates the jdk.nio.zipfs.ZipFileSystem to write out the manifest (if any) as the first entry in the LOC. That then allows the java.util.jar.JarInputStream to find the manifest and return it through JarInputStream.getManifest(). In an initial attempt at this patch, I had tried to just reorder the CEN to add the manifest entry first instead of forcing the manifest entry first in the LOC. But that didn't work and the JarInputStream still couldn't find the manifest. So I used this approach to force the manifest as the first entry in the LOC (and the existing code effectively also ensures that it's also the first entry in the CEN). The patch also includes a test case to reproduce this issue and verify the change. In the test case I intentionally used the verbose version of the FileSystem.newFileSystem() API, instead of the newer simpler ones. This is to allow cleaner/easier backporting of this patch to Java version 8 if and when that happens. Functionally, which API variant of the FileSystem.newFileSystem() API is used shouldn't matter in the context of this test case. However, if someone feels that I should switch to the newer available API, then please do let me know and I'll update the patch. -Jaikiran From li.jiang at oracle.com Mon Feb 3 03:46:21 2020 From: li.jiang at oracle.com (li.jiang at oracle.com) Date: Mon, 3 Feb 2020 11:46:21 +0800 Subject: [14] RFR (l10n) 8238377 : JDK 14 L10n resource files update - msg drop 20 Message-ID: <2403ebd8-85d6-6828-05a4-cbd25bd66c23@oracle.com> Hi, Please review the update for L10n resource files in JDK 14 msg drop 20. In this fix, we cover l10n resource files for the MSI installer of jpackage and the latest update from jdeps and jshell. https://bugs.openjdk.java.net/browse/JDK-8238377 http://cr.openjdk.java.net/~ljiang/8238377/webrev/read/ Thanks, Leo From peter.levart at gmail.com Mon Feb 3 09:05:39 2020 From: peter.levart at gmail.com (Peter Levart) Date: Mon, 3 Feb 2020 10:05:39 +0100 Subject: RFR: 8223260: NamingManager should cache InitialContextFactory In-Reply-To: <7da546ba-3e9d-08d9-56e0-b5bfd8e13703@oracle.com> References: <03485410-9a0c-9762-bc9b-7e5fe2253f89@oracle.com> <9efbcc1d-eec7-b8ab-8580-580ebd103fa1@oracle.com> <8a59dccc-c7dc-a254-d832-8f9dca3e31b9@oracle.com> <5d2af667-e978-8459-04ac-7c9314d7fedb@oracle.com> <9d30e61a-8638-8d61-36ce-1259fd697f11@oracle.com> <58ed7f17-90cb-c5f0-9431-b58136f1022d@gmail.com> <6a923a69-c8f1-2d6b-ff64-2ba53ad0d483@oracle.com> <7da546ba-3e9d-08d9-56e0-b5bfd8e13703@oracle.com> Message-ID: <02ca2c08-1c10-1ba2-2048-92258a586b2a@gmail.com> Hi Se?n, On 2/1/20 12:22 AM, Se?n Coffey wrote: >> The following is also possible: >> >> ??????????? // 1st try finding a ServiceLoader.Provider with type() >> of correct name >> ??????????? factory = loader >> ??????????????? .stream() >> ??????????????? .filter(p -> p.type().getName().equals(className)) >> ??????????????? .findFirst() >> ??????????????? .map(ServiceLoader.Provider::get) >> ??????????????? .or( // if that doesn't yield any result, instantiate >> the services >> ???????????????????? // one by one and search for implementation >> class of correct name >> ??????????????????? () -> loader >> ??????????????????????? .stream() >> ??????????????????????? .map(ServiceLoader.Provider::get) >> ??????????????????????? .filter(f -> >> f.getClass().getName().equals(className)) >> ??????????????????????? .findFirst() >> ??????????????? ).orElse(null); >> >> So what do you think? > > ok - possible I guess but I think it's highly unlikely ? It looks like > alot of extra care for a case that shouldn't happen. I'll stick with > your earlier suggestion unless you or others object. For the 3 InitialContextFactory implementations in JDK (DnsContextFactory, RegistryContextFactory, LdapCtxFactory), none uses the provider() static method convention, so for them the Provider.type()s are actually the same as their implementation classes. Should other InitialContextFactory service providers use the provider() static method convention (they may do this only if they are provided as Java modules I think), the InitialContextFactory sub-type name searched for in the NamingManager.getInitialContext() method is the provider type name, and not the implementation class name of the InitialContextFactory. They are usually the same, but in case of provider() static method convention, they may or may not be. This is not a problem for JDK supplied implementations and I don't think for any other current implementation. But anyway, I think this distinction should be spelled out in the specification of the NamingManager.getInitialContext() method and this is an opportunity to add some text for that. For example: Index: src/java.naming/share/classes/javax/naming/spi/NamingManager.java IDEA additional info: Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP <+>UTF-8 =================================================================== --- src/java.naming/share/classes/javax/naming/spi/NamingManager.java (revision 57904:0905868db490c87df463258166762797374e5a96) +++ src/java.naming/share/classes/javax/naming/spi/NamingManager.java (revision 57904+:0905868db490+) @@ -644,7 +660,9 @@ ????? *????