August 2018 - core-libs-dev

Makefile Suppress Deprecation Warnings
by mr rupplin 13 Aug '18

13 Aug '18

Where in the Makefile would we add this to silence to deprecated warnings from GCC compiler? -Wno-deprecated Who thought this would be fine? To run this seem falty. ok

2 1

JVMTI lib location
by mr rupplin 13 Aug '18

13 Aug '18

Trying to write a quick agent for the JVM. The jvmti.h file is found quickly but I do not know what to link it with. Can you guys help? Thanks. Max r.

2 2

C files and their Mapping(s)
by mr rupplin 11 Aug '18

11 Aug '18

Hello. Thanks for taking time. We had a quick question about the Java to C mappings in the JDK. For instance the System.java has a corresponding System.c and even a System.o. We find these without too much problem. However many of the "core" packages (corba, nashorn, jaxp, jaxws) do not have a corresponding C source folder. If we were to make changes to System.java we would, for example, also make changes to System.c. It is quickly clear then that we would need a mechanism for altering the remaining java classes. Since these do not have a C file what do we then alter? How would we rewrite a method, add one, etc.? -- -- -- -- Thank you, Max

2 1

Initial JDK 11 RFR of JDK-8202385: Annotation to mark serial-related fields and methods
by joe darcy 10 Aug '18

10 Aug '18

Hello, Please review the webrev (code below) to address JDK-8202385: Annotation to mark serial-related fields and methods http://cr.openjdk.java.net/~darcy/8202385.0/ The proposed java.io.Serial annotation type is intended to be used along with an augmented implementation of javac's "serial" lint check; that work will be done separately as part of JDK-8202056: "Expand serial warning to check for bad overloads of serial-related methods". Currently, javac's serial lint check looks for serialVersionUID fields to be declared in Serializable classes. However, there are various other structural properties of the declaration of serialization-related fields and methods that could be checked at compile-time. The proposed java.io.Serial annotation type (name subject to change [*]) explicitly marks fields and methods that are intended to be called as part of the Serialization machinery. This marking allows using the wrong name for a method or field to be easily caught; the serialization mechanism will generally silently ignore mis-declared serialization-related fields and methods. Since the annotation is intended for compile-time checking, the annotation type has has source retention, like the Override annotation type. Cheers, -Joe [*] Unleash the bikes from the bikeshed! On the name and package of the annotation type, since the other serialization types are in the java.io package and the checks are not proposed to be part of the language, this annotation type more appropriately lives in java.io package rather than java.lang. The name "Serial" is consistent with the "@serial" javadoc tag. Other possible names include "Serialize" and "SerialRelated". Another possibility would be to have the annotation type be a nested type in java.io.Serializable. -=-=-=-=-=-=- // GPLv2 elided. package java.io; import java.lang.annotation.*; /** * Indicates that a field or method is related to the {@linkplain * Serializable serialization mechanism}. This annotation type is * intended to allow compile-time checking of serialization-related * declarations, analogous to the checking enabled by the {@link * java.lang.Override} annotation type to validate method overriding. * * Specifically, annotations of this type are intended to be * applied to serialization-related methods and fields in classes * declared to be {@code Serializable}. The five serialization-related * methods are: * * <ul> * <li>{@code private void writeObject(java.io.ObjectOutputStream stream) throws IOException} * <li>{@code private void readObject(java.io.ObjectInputStream stream) throws IOException, ClassNotFoundException} * <li>{@code private void readObjectNoData() throws ObjectStreamException} * <li>ANY-ACCESS-MODIFIER {@code Object writeReplace() throws ObjectStreamException} * <li>ANY-ACCESS-MODIFIER {@code Object readResolve() throws ObjectStreamException} * </ul> * * The two serialization-related fields are: * * <ul> * <li>{@code private static final ObjectStreamField[] serialPersistentFields} * <li>{@code private static final long serialVersionUID} * </ul> * * A compiler can validate that a method or field marked with a * <code>@Serial</code> annotation is one of the defined serialization-related * methods declared in a meaningful context. * * It is a semantic error to apply this annotation to other fields or methods, including: * <ul> * <li>fields or methods in a class that is not {@code Serializable} * * <li>fields or methods of the proper structural declaration, but in * a type where they are ineffectual. For example, {@code enum} types * are defined to have a {@code serialVersionUID} of {@code 0L} so a * {@code serialVersionUID} field declared in an {@code enum} type is * ignored. The five serialization-related methods identified above * are likewise ignored for an {@code enum} type. * * </ul> */ @Target({ElementType.METHOD, ElementType.FIELD}) @Retention(RetentionPolicy.SOURCE) public @interface Serial { }

4 11

Deprecate java.io.File or at least some methods
by Remi Forax 10 Aug '18

10 Aug '18

Hi all, restarting discussion about JDK-8181098, java.io.File has several severe issues so we should alert users to migrate to use java.nio.file.[Path|Files] ASAP using the deprecation mechanism (obviously not for removal). The usual gotchas - File used string name which may do not map correctly with the underlying file system charset. - methods that are developer hostile - methods that performs an action on the file system file returns a false if there is an issue instead of an IOException - methods that list files return null instead of an IOException if there is an issue. - reading/writing into a file (using File[InputStream|OutputStream|Reader|Writer]) doesn't default to UTF8. I see two ways of deprecation, one is to deprecate the whole class, it has the advantage of making the things clear, the other is to deprecate the constructors and all methods that acts on the file of the file system. The later option allows library to still have methods that takes a java.io.File as parameter if their implementation use toPath() to perform the operations. regards, Rémi

4 3

Re: RFR Bug-pending: Enable Hotspot to Track Native Memory Usage for Direct Byte Buffers
by Adam Farley8 10 Aug '18

10 Aug '18

-- Bump -- Hi Folks, > Zhengyu Gu <zgu(a)redhat.com> wrote on 06/06/2018 01:58:18: > From: Zhengyu Gu <zgu(a)redhat.com> > To: "Thomas Stüfe" <thomas.stuefe(a)gmail.com>, Adam Farley8 > <adam.farley(a)uk.ibm.com> > Cc: "hotspot-dev(a)openjdk.java.net developers" <hotspot- > dev(a)openjdk.java.net>, core-libs-dev <core-libs-dev(a)openjdk.java.net> > Date: 06/06/2018 01:58 > Subject: Re: RFR Bug-pending: Enable Hotspot to Track Native Memory > Usage for Direct Byte Buffers > > On 06/05/2018 12:10 PM, Thomas Stüfe wrote:> On Tue, Jun 5, 2018 at 3:46 > PM, Adam Farley8 <adam.farley(a)uk.ibm.com> wrote: > >> Hi All, > >> > >> Native memory allocation for DBBs is tracked in java.nio.Bits, but that > >> only includes what the user thinks they are allocating. > >> > > > > Which is exactly what I would expect as a user... A debugger poring over the values in the file may prefer total accuracy in at least one of the variables, so they can find out where all their memory went in the event of a leak. Even if this variable is not accessible via a getter method, and is only readable via a system core. > > > > I agree with Thomas, there is no point for a user to aware of tracking > overhead, and the overhead only incurs when native memory tracking is > on. As a matter of fact, it can really confuse user that values can be > varied, depending on whether native memory tracking is on. > > Thanks, > > -Zhengyu I agree that the casual user shouldn't have to worry. This accuracy would be for analysis after the fact, via system cores. The standard variables can stay as they are. I suggest the addition of a single AtomicLong that shows an accurate value for the sole purpose of aiding debugging. > > > >> When the VM adds extra memory to the allocation amount this extra bit is > >> not represented in the Bits total. A cursory glance > >> shows, minimum, that we round the requested memory quantity up to the heap > >> word size in the Unsafe.allocateMemory code > > > > which I do not understand either - why do we do this? After all, > > normal allocations from inside hotspot do not get aligned up in size, > > and the java doc to Unsafe allocateMemory does not state anything > > about the size being aligned. > > > > In addition to questioning the align up of the user requested size, I > > would be in favor of adding a new NMT tag for these, maybe "mtUnsafe"? > > That would be an easy fix. > > > >> , and > >> something to do with nmt_header_size in os:malloc() (os.cpp) too. > > > > That is mighty unspecific and also wrong. The align-up mentioned above > > goes into the size reported by Bits; the nmt header size does not. > > I believe we agree here too. My point is that, for the sake of accuracy, we *should* have this information in Bits. This is part of the debugger-aid change that I am suggesting. > >> > >> On its own, and in small quantities, align_up(sz, HeapWordSize) isn't that > >> big of an issue. But when you allocate a lot of DBBs, > >> and coupled with the nmt_header_size business, it makes the Bits values > >> wrong. The more DBB allocations, the more inaccurate those > >> numbers will be. > > > > To be annoyingly precise, it will never be more wrong than 1:7 on > > 64bit machines :) - if all memory requested via Unsafe.allocateMemory > > would be of size 1 byte. Sounds like the sort of thing I'd do. Once a stress tester, always a stress tester. :) > > > >> > >> To get the "+X", it seems to me that the best option would be to introduce > >> an native method in Bits that fetches "X" directly > >> from Hotspot, using the same code that Hotspot uses (so we'd have to > >> abstract-out the Hotspot logic that adds X to the memory > >> quantity). This way, anyone modifying the Hotspot logic won't risk > >> rendering the Bits logic wrong again. > > > > I don't follow that. I was trying to describe one method to enable the VM to tell Bits how much memory will actually be reserved for a given amount of DBB. E.g. Bits says it has a DBB 7 bytes in size, and it tells the VM. The VM replies with "OK, if you came to me and asked for 7 bytes, I'd reserve 8.", and then Bits can update that debugging variable I mentioned. If we abstract out the logic, then Bits and the VM would be using the exact same code when telling Bits how much memory will *hypothetically* be added, as we do when the VM is determining how much overhead it needs when actually reserving the memory. Is that clearer? > > > >> > >> That's only one way to fix the accuracy problem here though. Suggestions > >> welcome. > > > > You are throwing two effects together: > > > > - As mentioned above, I consider the align-up of the user requested > > size to be at least questionable. It shows up as user size in NMT > > which should not be. I also fail to see a compelling reason for it, > > but maybe someone else can enlighten me. Well, if we got rid of it then that's one way to make the Bits variables accurate. :) > > > > - But anything else - NMT headers, overwriter guards, etc added by the > > VM I consider in the same class as any other overhead incurred e.g. by > > the CRT or the OS when calling malloc (e.g. malloc allocator bucket > > size). Basically, rss will go up by more than size requested by > > malloc. Something maybe worth noting, but IMHO not as part of the > > numbers returned by java.nio.Bits. We agree again. No need to confuse things by altering the return values. Simply store the accurate information internally as a debugging aid. > > > > Just my 2 cents. And they are appreciated. Apologies for the delay in my response. - Adam > > > > Best Regards, Thomas > > > >> > >> Best Regards > >> > >> Adam Farley > >> Unless stated otherwise above: > >> IBM United Kingdom Limited - Registered in England and Wales with number > >> 741598. > >> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

1 0

File Attributes from DirectoryStream (WindowsPathWithAttributes)?
by Bernd Eckenfels 10 Aug '18

10 Aug '18

Hello, in sun.nio.fs.WindowsDirectoryStream I see that the code which iterates the Directory goes to some length to retain the file attributes returned from that function (by attaching them to a WindowsPathWithAttributes (aka BasicFileAttributesHolder). And indeed I can see that class in my DirectroyStream Iterator or Filter. However I do not see that the normal WindowsFilesystemProvider (or actually WindowsFileAttributes#get() check for instances of that. This way None of the Files.getAttributeView seem to Benefit from that. So I wonder is this missing or is there some other way you are supposed to work with this cached Attributes? For 8 I can work with instanceof, but that might no longer be an Option with JPMS. Gruss Bernd -- http://bernd.eckenfels.net

1 0

[12] RFR 8208483: Add 5 JNDI tests to com/sun/jndi/dns/FactoryTests/
by Chris Yin 10 Aug '18

10 Aug '18

Please review the changes to add 5 JNDI tests to com/sun/jndi/dns/FactoryTests/ in OpenJDK, thanks bug: https://bugs.openjdk.java.net/browse/JDK-8208483 <https://bugs.openjdk.java.net/browse/JDK-8208483> webrev: http://cr.openjdk.java.net/~xyin/8208483/webrev.00/ <http://cr.openjdk.java.net/~xyin/8208483/webrev.00/> Regards, Chris

3 13

[11] RFR(S) : 8205687 : TimeoutHandler generates huge core files
by Igor Ignatyev 09 Aug '18

09 Aug '18

http://cr.openjdk.java.net/~iignatyev//8205687/webrev.00/index.html > 18 lines changed: 3 ins; 5 del; 10 mod; Hi all, could you please review this small fix for TimeoutHandler? gcore dumps non committed memory, which is a problem when JVM is run w/ ZGC or in other configurations where memory is reserved but not committed. the fix replaces invocation of gcore w/ 'kill -ABRT'. as kill has to be the last command run by TimeoutHandler, I've changed jdk.test.failurehandler.ToolKit to run action after we get a list of the process's children and also changed GathererFactory to run "common" part before os-specific part. NB 'kill' will generate core file only if a host has appropriate core file limit and core file handling settings, therefore you might observe that core files aren't generated if your hosts aren't set up correspondingly. JBS: https://bugs.openjdk.java.net/browse/JDK-8205687 webrev: http://cr.openjdk.java.net/~iignatyev//8205687/webrev.00/index.html Thanks, -- Igor

2 2

JDK 12 RFR of JDK-8209024: Use SuppressWarnings on serialVersionUID fields in interfaces
by joe darcy 09 Aug '18

09 Aug '18

Hello, Various interfaces in the JDK extend Serializable and declare serialVersionUID fields. Such fields are ineffectual and @SuppressWarnings("serial") should be applied to such fields to suppress future planned serial lint checks (JDK-8202056). Most of the affected files are in the security-libs area with a handful in RMI and JNDI: http://cr.openjdk.java.net/~darcy/8209024.0/ Patch below. I'll fix-up the copyright years before any push. Thanks, -Joe --- old/src/java.base/share/classes/java/security/Key.java 2018-08-06 12:04:46.666000999 -0700 +++ new/src/java.base/share/classes/java/security/Key.java 2018-08-06 12:04:46.510000999 -0700 @@ -109,6 +109,7 @@ * serialization compatibility with a previous * version of the class. */ + @SuppressWarnings("serial") // serialVersionUID in an interface is ineffectual static final long serialVersionUID = 6603384152749567654L; /** --- old/src/java.base/share/classes/java/security/PrivateKey.java 2018-08-06 12:04:47.062000999 -0700 +++ new/src/java.base/share/classes/java/security/PrivateKey.java 2018-08-06 12:04:46.914000999 -0700 @@ -64,5 +64,6 @@ * The class fingerprint that is set to indicate serialization * compatibility with a previous version of the class. */ + @SuppressWarnings("serial") // serialVersionUID in an interface is ineffectual static final long serialVersionUID = 6034044314589513430L; } --- old/src/java.base/share/classes/java/security/PublicKey.java 2018-08-06 12:04:47.454000999 -0700 +++ new/src/java.base/share/classes/java/security/PublicKey.java 2018-08-06 12:04:47.306000999 -0700 @@ -50,5 +50,6 @@ * The class fingerprint that is set to indicate serialization * compatibility with a previous version of the class. */ + @SuppressWarnings("serial") // serialVersionUID in an interface is ineffectual static final long serialVersionUID = 7187392471159151072L; } --- old/src/java.base/share/classes/java/security/interfaces/DSAPrivateKey.java 2018-08-06 12:04:47.858000999 -0700 +++ new/src/java.base/share/classes/java/security/interfaces/DSAPrivateKey.java 2018-08-06 12:04:47.706000999 -0700 @@ -48,6 +48,7 @@ * serialization compatibility with a previous * version of the class. */ + @SuppressWarnings("serial") // serialVersionUID in an interface is ineffectual static final long serialVersionUID = 7776497482533790279L; /** --- old/src/java.base/share/classes/java/security/interfaces/DSAPublicKey.java 2018-08-06 12:04:48.270000999 -0700 +++ new/src/java.base/share/classes/java/security/interfaces/DSAPublicKey.java 2018-08-06 12:04:48.114000999 -0700 @@ -48,6 +48,7 @@ * serialization compatibility with a previous * version of the class. */ + @SuppressWarnings("serial") // serialVersionUID in an interface is ineffectual static final long serialVersionUID = 1234526332779022332L; /** --- old/src/java.base/share/classes/java/security/interfaces/ECPrivateKey.java 2018-08-06 12:04:48.674000999 -0700 +++ new/src/java.base/share/classes/java/security/interfaces/ECPrivateKey.java 2018-08-06 12:04:48.522000999 -0700 @@ -43,6 +43,7 @@ * The class fingerprint that is set to indicate * serialization compatibility. */ + @SuppressWarnings("serial") // serialVersionUID in an interface is ineffectual static final long serialVersionUID = -7896394956925609184L; /** --- old/src/java.base/share/classes/java/security/interfaces/ECPublicKey.java 2018-08-06 12:04:49.078000999 -0700 +++ new/src/java.base/share/classes/java/security/interfaces/ECPublicKey.java 2018-08-06 12:04:48.926000999 -0700 @@ -45,6 +45,7 @@ * The class fingerprint that is set to indicate * serialization compatibility. */ + @SuppressWarnings("serial") // serialVersionUID in an interface is ineffectual static final long serialVersionUID = -3314988629879632826L; /** --- old/src/java.base/share/classes/java/security/interfaces/RSAMultiPrimePrivateCrtKey.java 2018-08-06 12:04:49.470000999 -0700 +++ new/src/java.base/share/classes/java/security/interfaces/RSAMultiPrimePrivateCrtKey.java 2018-08-06 12:04:49.318000999 -0700 @@ -51,6 +51,7 @@ * serialization compatibility with a previous * version of the type. */ + @SuppressWarnings("serial") // serialVersionUID in an interface is ineffectual static final long serialVersionUID = 618058533534628008L; /** --- old/src/java.base/share/classes/java/security/interfaces/RSAPrivateCrtKey.java 2018-08-06 12:04:49.890000999 -0700 +++ new/src/java.base/share/classes/java/security/interfaces/RSAPrivateCrtKey.java 2018-08-06 12:04:49.726000999 -0700 @@ -46,6 +46,7 @@ * serialization compatibility with a previous * version of the type. */ + @SuppressWarnings("serial") // serialVersionUID in an interface is ineffectual static final long serialVersionUID = -5682214253527700368L; /** --- old/src/java.base/share/classes/java/security/interfaces/RSAPrivateKey.java 2018-08-06 12:04:50.290000999 -0700 +++ new/src/java.base/share/classes/java/security/interfaces/RSAPrivateKey.java 2018-08-06 12:04:50.146000999 -0700 @@ -45,6 +45,7 @@ * serialization compatibility with a previous * version of the type. */ + @SuppressWarnings("serial") // serialVersionUID in an interface is ineffectual static final long serialVersionUID = 5187144804936595022L; /** --- old/src/java.base/share/classes/java/security/interfaces/RSAPublicKey.java 2018-08-06 12:04:50.706000999 -0700 +++ new/src/java.base/share/classes/java/security/interfaces/RSAPublicKey.java 2018-08-06 12:04:50.554000999 -0700 @@ -42,6 +42,7 @@ * serialization compatibility with a previous * version of the type. */ + @SuppressWarnings("serial") // serialVersionUID in an interface is ineffectual static final long serialVersionUID = -8727434096241101194L; /** --- old/src/java.base/share/classes/javax/crypto/SecretKey.java 2018-08-06 12:04:51.142000999 -0700 +++ new/src/java.base/share/classes/javax/crypto/SecretKey.java 2018-08-06 12:04:50.986000999 -0700 @@ -64,5 +64,6 @@ * The class fingerprint that is set to indicate serialization * compatibility since J2SE 1.4. */ + @SuppressWarnings("serial") // serialVersionUID in an interface is ineffectual static final long serialVersionUID = -4795878709595146952L; } --- old/src/java.base/share/classes/javax/crypto/interfaces/DHPrivateKey.java 2018-08-06 12:04:51.550000999 -0700 +++ new/src/java.base/share/classes/javax/crypto/interfaces/DHPrivateKey.java 2018-08-06 12:04:51.398000999 -0700 @@ -42,6 +42,7 @@ * The class fingerprint that is set to indicate serialization * compatibility since J2SE 1.4. */ + @SuppressWarnings("serial") // serialVersionUID in an interface is ineffectual static final long serialVersionUID = 2211791113380396553L; /** --- old/src/java.base/share/classes/javax/crypto/interfaces/DHPublicKey.java 2018-08-06 12:04:51.966000999 -0700 +++ new/src/java.base/share/classes/javax/crypto/interfaces/DHPublicKey.java 2018-08-06 12:04:51.810000999 -0700 @@ -42,6 +42,7 @@ * The class fingerprint that is set to indicate serialization * compatibility since J2SE 1.4. */ + @SuppressWarnings("serial") // serialVersionUID in an interface is ineffectual static final long serialVersionUID = -6628103563352519193L; /** --- old/src/java.base/share/classes/javax/crypto/interfaces/PBEKey.java 2018-08-06 12:04:52.390000999 -0700 +++ new/src/java.base/share/classes/javax/crypto/interfaces/PBEKey.java 2018-08-06 12:04:52.238000999 -0700 @@ -42,6 +42,7 @@ * The class fingerprint that is set to indicate serialization * compatibility since J2SE 1.4. */ + @SuppressWarnings("serial") // serialVersionUID in an interface is ineffectual static final long serialVersionUID = -1430015993304333921L; /** --- old/src/java.base/share/classes/sun/security/internal/interfaces/TlsMasterSecret.java 2018-08-06 12:04:52.814000999 -0700 +++ new/src/java.base/share/classes/sun/security/internal/interfaces/TlsMasterSecret.java 2018-08-06 12:04:52.658000999 -0700 @@ -44,6 +44,7 @@ @Deprecated public interface TlsMasterSecret extends SecretKey { + @SuppressWarnings("serial") // serialVersionUID in an interface is ineffectual public static final long serialVersionUID = -461748105810469773L; /** --- old/src/java.naming/share/classes/javax/naming/Name.java 2018-08-06 12:04:53.294000999 -0700 +++ new/src/java.naming/share/classes/javax/naming/Name.java 2018-08-06 12:04:53.126000999 -0700 @@ -64,6 +64,7 @@ * serialization compatibility with a previous * version of the class. */ + @SuppressWarnings("serial") // serialVersionUID in an interface is ineffectual static final long serialVersionUID = -3617482732056931635L; /** --- old/src/java.naming/share/classes/javax/naming/directory/Attribute.java 2018-08-06 12:04:53.702000999 -0700 +++ new/src/java.naming/share/classes/javax/naming/directory/Attribute.java 2018-08-06 12:04:53.550000999 -0700 @@ -336,5 +336,6 @@ /** * Use serialVersionUID from JNDI 1.1.1 for interoperability. */ + @SuppressWarnings("serial") // serialVersionUID in an interface is ineffectual static final long serialVersionUID = 8707690322213556804L; } --- old/src/java.rmi/share/classes/java/rmi/server/RemoteRef.java 2018-08-06 12:04:54.098000999 -0700 +++ new/src/java.rmi/share/classes/java/rmi/server/RemoteRef.java 2018-08-06 12:04:53.942000999 -0700 @@ -39,6 +39,7 @@ public interface RemoteRef extends java.io.Externalizable { /** indicate compatibility with JDK 1.1.x version of class. */ + @SuppressWarnings("serial") // serialVersionUID in an interface is ineffectual static final long serialVersionUID = 3632638527362204081L; /** --- old/src/java.rmi/share/classes/java/rmi/server/ServerRef.java 2018-08-06 12:04:54.494000999 -0700 +++ new/src/java.rmi/share/classes/java/rmi/server/ServerRef.java 2018-08-06 12:04:54.338000999 -0700 @@ -39,6 +39,7 @@ public interface ServerRef extends RemoteRef { /** indicate compatibility with JDK 1.1.x version of class. */ + @SuppressWarnings("serial") // serialVersionUID in an interface is ineffectual static final long serialVersionUID = -4557750989390278438L; /**

7 9