April 2020 - core-libs-dev

RFR(S): 8242848: Improve performance of InflaterOutputStream.write()
by Volker Simonis 23 Apr '20

23 Apr '20

Hi, can I please have a review for the following simple performance enhancement: http://cr.openjdk.java.net/~simonis/webrevs/2020/8242848/ https://bugs.openjdk.java.net/browse/JDK-8242864 InflaterOutputStream has an internal buffer which is used for the inflated data. This buffer can be configured to a custom size (the default is 512 bytes) by using the specialized "InflaterOutputStream(OutputStream out, Inflater infl, int bufLen)" constructor. A bigger buffer, results in fewer native calls to "write()" on the associated OutputStream and better overall performance. Unfortunately "InflaterOutputStream.write(byte[] b, int off, int len)" unnecessarily chunks its own byte input buffer "b" into pieces of maximum 512 bytes before feeding them to the underlying Inflater. This unnecessarily increases the number of native calls to Inflater.inflate() and limits the benefit of the configurable internal buffer to a size of ~(512 * compression-ratio) bytes. Instead, we could easily pass the complete input buffer "b" as input to the underlying Inflater. This simplifies the code and results in up to ~25% performance improvements for bigger internal buffers (see the JMH benchmark attached to the bug). Regarding the implementation, I initially wanted to completely remove the "for (;;)" loop after removing the chunking of the input buffer. But I think it is still necessary, because an InflaterOutputStream can be created with a custom Inflater which already has some input data. In that case, the Inflater will first consume its initial input data in the first "for" loop iteration while "write()"s input buffer "b" will only be consumed in the second "for" loop iteration. While doing this change, I've also realized that all the streams in java.util.zip (i.e. DeflaterInputStream, GZIPInputStream, GZIPOutputStream, InflaterInputStream, DeflaterOutputStream) use an internal byte buffer of 512 bytes by default. Looking at the benchmark attached to JDK-8242864, I think that increasing this default to a bigger size (e.g. 4096 bytes) will considerably speed up (up to 50%) read and write operations on these streams when they are created with the default buffer size. I think the value "512" is a legacy of old times when memory was more precious :) so I've opened "JDK-8242864: Increase the default, internal buffer size of the Streams in java.util.zip" to track that as as separate issue. Do you think it makes sense to increase that default value? Thank you and best regards, Volker PS: do you think it makes sense to contribute the benchmark attached to JDK-8242864 to the code-tools/mh-jdk-microbenchmarks [1] project? [1] http://openjdk.java.net/projects/code-tools/jmh-jdk-microbenchmarks/

9 23

Unexpected behaviour with larger Strings
by Adam Retter 23 Apr '20

23 Apr '20

Hi there, I am not sure if the following is expected behaviour or possibly indicates one or more bugs? Regardless, the behaviour was surprising to me as it seems to vary between JVM versions and vendors. The Java code is simply: import java.io.UnsupportedEncodingException; import java.nio.charset.Charset; import static java.nio.charset.StandardCharsets.*; public class GetBytesTest { public static void main(final String args[]) throws UnsupportedEncodingException { for (final Charset charset : new Charset[]{ISO_8859_1, US_ASCII, UTF_8}) { System.out.println("Attempting: " + charset.name()); final String str = new String(new char[1073741824]); str.getBytes(charset); System.out.println("OK"); } } } I have run this against multiple JDKs and versions by running: $ javac GetBytesTest.java $ java -Xmx10g -cp . GetBytesTest My results on macOS 10.15.2 are: 1. Azul Zulu 7.34.0.5-CA-macosx build 24.242-b7 Exception in thread "main" java.lang.OutOfMemoryError: Requested array size exceeds VM limit at java.lang.StringCoding.encode(StringCoding.java:350) at java.lang.String.getBytes(String.java:939) at GetBytesTest.main(GetBytesTest.java:15) 2. Oracle JDK 1.8.0_221-b11 Exception in thread "main" java.lang.OutOfMemoryError: Requested array size exceeds VM limit at java.lang.StringCoding.encode(StringCoding.java:350) at java.lang.String.getBytes(String.java:941) at GetBytesTest.main(GetBytesTest.java:15) 3. AdoptOpenJDK 1.8.0_232-b09 with openj9-0.17.0 ALL PASSES :-) 4. AdoptOpenJDK 1.8.0_252-b09 Exception in thread "main" java.lang.OutOfMemoryError: Requested array size exceeds VM limit at java.lang.StringCoding.encode(StringCoding.java:350) at java.lang.String.getBytes(String.java:941) at GetBytesTest.main(GetBytesTest.java:15) 5. Azul Zulu 8.40.0.25-CA-macosx build 1.8.0_222-b10 Exception in thread "main" java.lang.OutOfMemoryError: Requested array size exceeds VM limit at java.lang.StringCoding.encode(StringCoding.java:350) at java.lang.String.getBytes(String.java:941) at GetBytesTest.main(GetBytesTest.java:15) 6. Azul Zulu build 9.0.7.1+1 Exception in thread "main" java.lang.NegativeArraySizeException at java.base/java.lang.StringCoding.encodeUTF8(StringCoding.java:505) at java.base/java.lang.StringCoding.encode(StringCoding.java:593) at java.base/java.lang.String.getBytes(String.java:975) at GetBytesTest.main(GetBytesTest.java:15) 7. Azul Zulu10.3+5 build 10.0.2+13 ALL PASSES :-) 8. AdoptOpenJDK 11.0.7+10 with openj9-0.20.0 FAILS at ISO-8859-1 stage... also for fails for any of the character sets :-( Exception in thread "main" java.lang.OutOfMemoryError: UTF16 String size is 1073741824, should be less than 1073741823 at java.base/java.lang.StringUTF16.newBytesFor(StringUTF16.java:49) at java.base/java.lang.String.<init>(String.java:746) at java.base/java.lang.String.<init>(String.java:695) at GetBytesTest.main(GetBytesTest.java:15) 9. Azul Zulu11.37+17-CA build 11.0.6+10-LTS ALL PASSES :-) 10. Azul Zulu13.28+11-CA build 13.0.1+10-MTS ALL PASSES :-) 11. AdoptOpenJDK 13.0.2+8 with openj9-0.18.0 Exception in thread "main" java.lang.NegativeArraySizeException at java.base/java.lang.String.<init>(String.java:750) at java.base/java.lang.String.<init>(String.java:699) at GetBytesTest.main(GetBytesTest.java:14) Regarding the code and the results - if you are concerned about overall memory you can comment out all the character sets apart from UTF-8 and you still get the same errors! I was surprised that by my findings that: 1. On JDK 7 and 8 with HotSpot - getting the bytes of a UTF-8 string where all chars are '0' wants to allocate an array larger than the VM limit, whereas the same operation on ASCII and ISO-8859-1 do not. If I am not mistaken then the char '0' takes up the same amount of bytes (i.e. 1 byte) in ASCII, ISO-8559-1, andUTF-8. 2. JDK 8 with J9 (NOT HotSpot) - seems to work just fine, whereas HotSpot fails, see (1). 3. JDK 9 with HotSpot seems to report a different error than those versions before it. 4. JDK 11 with J9 (NOT HotSpot) will not let me allocate any String of length 1073741824 for any of the character sets. In this area this seems to be a change from JDK 8 with J9. Could this be considered a regression? 5. This seems to be fixed on JDK 10 through 13 with HotSpot. 6. JDK 13 with J9 (NOT HotSpot) like JDK 11 with J9, will not let me allocate the String. Seems to be a different error though. Likewise is this a regression over JDK8 with J9? 7. Why is the version number for J9 in JDK13 less than that in JDK11? Now obviously I am happy to see that this passes on JDK 10+ with HotSpot :-) But shouldn't it also pass for J9? Also why is there such a variation in the errors, I would have hoped that such simple Java code was "portable". Thanks :-) -- Adam Retter skype: adam.retter tweet: adamretter http://www.adamretter.org.uk

2 1

[15] RFR: 8243138: Enhance BaseLdapServer to support starttls extended request
by Chris Yin 23 Apr '20

23 Apr '20

Hello Please review following change for enhancement to com/sun/jndi/ldap/lib/BaseLdapServer.java, thanks Bug: https://bugs.openjdk.java.net/browse/JDK-8243138 Webrev: http://cr.openjdk.java.net/~xyin/8243138/webrev.00/ There is requirement to test starttls extended op against dummy ldap server, but unfortunately, current BaseLdapSever logic cannot handle it correctly since the starttls request is quite special to use existed socket for tls negotiate. This enhancement will provide the possibility to wrap current socket connection and overwrite in-place processing input/output stream, certainly, that will not affect existed tests which depends on BaseLdapServer. Run existed dependency tests on 4 platforms for total 200 times, all green. Thanks, Chris

4 6

Some Classes with a public void close() don't implement AutoCloseable
by Johannes Kuhn 22 Apr '20

22 Apr '20

After failing to wrap a XMLStreamReader in a try-with-resources after discovering it's close() method, I thought about checking what other classes have a public void close() method in the JDK but don't implement AutoCloseable. So I wrote a small program that enumerates all classes present in in the jrt image with a public void close() method that does not directly or indirectly implement AutoCloseable: https://gist.github.com/DasBrain/8d50e02e35654870e2c2c00bf3f79954 (Output & Code, Code requires JDK 14 with preview features and ASM) As I am not an expert in any of those areas where classes showed up, and I don't know if it was an oversight, or if there is a good reason for not implementing AutoCloseable. Implementing AutoCloseable is a double edged sword, a few IDEs warn about resource leaks based on that interface. And treat an AutoCloseable passed to methods who return an AutoCloseable as the return value wraping the parameter. I did look at a few classes: * javax.xml.stream.XMLStreamReader:Javadoc: "Frees any resources associated with this Reader. This method does not close the underlying input source." Better not implement it? * javax.naming.Context: Javadoc: "This method releases this context's resources immediately, instead of waiting for them to be released automatically by the garbage collector." Implement AutoCloseable? * java.util.logging.Handler: Lifecycle seems to be managed by a LogManager. Better not implement AutoCloseable? * jdk.internal.jrtfs.ExplodedImage: class is package private, overrides close() from SystemImage while increasing visibility to public. I did not restrict my enumeration to public and exported types - it was easier not to do that and I'm lazy. This touches many unrelated areas, but David Holmes suggested that I take it to core-libs-dev. I know, I just did some static code analysis, but it seems that there might be some low hanging fruits. And for public classes I wish to have at least some rationale why a class with a public void close() method doesn't implement AutoCloseable. Thanks, Johannes Classes found: com/sun/jdi/connect/spi/Connection com/sun/jndi/dns/BaseNameClassPairEnumeration com/sun/jndi/dns/DnsClient com/sun/jndi/dns/DnsContext com/sun/jndi/dns/Resolver com/sun/jndi/ldap/AbstractLdapNamingEnumeration com/sun/jndi/ldap/LdapCtx com/sun/jndi/ldap/LdapReferralContext com/sun/jndi/ldap/LdapSchemaCtx com/sun/jndi/ldap/ext/StartTlsResponseImpl com/sun/jndi/rmi/registry/BindingEnumeration com/sun/jndi/rmi/registry/NameClassPairEnumeration com/sun/jndi/rmi/registry/RegistryContext com/sun/jndi/toolkit/dir/ContextEnumerator com/sun/jndi/toolkit/dir/HierMemDirCtx com/sun/jndi/toolkit/dir/HierMemDirCtx$BaseFlatNames com/sun/jndi/toolkit/dir/LazySearchEnumerationImpl com/sun/jndi/toolkit/url/GenericURLContext com/sun/media/sound/AudioFloatFormatConverter$AudioFloatInputStreamChannelMixer com/sun/media/sound/AudioFloatFormatConverter$AudioFloatInputStreamResampler com/sun/media/sound/AudioFloatInputStream com/sun/media/sound/AudioFloatInputStream$BytaArrayAudioFloatInputStream com/sun/media/sound/AudioFloatInputStream$DirectAudioFloatInputStream com/sun/media/sound/ModelAbstractOscillator com/sun/media/sound/ModelDirector com/sun/media/sound/ModelOscillatorStream com/sun/media/sound/ModelStandardDirector com/sun/media/sound/ModelStandardIndexedDirector com/sun/media/sound/RIFFWriter$RandomAccessByteWriter com/sun/media/sound/RIFFWriter$RandomAccessFileWriter com/sun/media/sound/RIFFWriter$RandomAccessWriter com/sun/media/sound/SoftAbstractResampler$ModelAbstractResamplerStream com/sun/media/sound/SoftMainMixer com/sun/media/sound/SoftMixingDataLine$AudioFloatInputStreamResampler com/sun/media/sound/SoftMixingMainMixer com/sun/media/sound/SoftMixingSourceDataLine$NonBlockingFloatInputStream com/sun/naming/internal/VersionHelper$InputStreamEnumeration com/sun/org/apache/xerces/internal/impl/XMLStreamFilterImpl com/sun/org/apache/xerces/internal/impl/XMLStreamReaderImpl com/sun/org/apache/xerces/internal/xinclude/XIncludeTextReader com/sun/org/apache/xml/internal/serializer/EmptySerializer com/sun/org/apache/xml/internal/serializer/SerializationHandler com/sun/org/apache/xml/internal/serializer/SerializerBase com/sun/org/apache/xml/internal/serializer/ToHTMLSAXHandler com/sun/org/apache/xml/internal/serializer/ToUnknownStream com/sun/org/apache/xml/internal/serializer/WriterChain com/sun/tools/javac/api/JavacTaskPool$ReusableContext$ReusableJavaCompiler com/sun/tools/javac/file/JavacFileManager$1 com/sun/tools/javac/file/JavacFileManager$ArchiveContainer com/sun/tools/javac/file/JavacFileManager$Container com/sun/tools/javac/file/JavacFileManager$DirectoryContainer com/sun/tools/javac/file/JavacFileManager$JRTImageContainer com/sun/tools/javac/file/Locations com/sun/tools/javac/main/JavaCompiler com/sun/tools/javac/processing/JavacProcessingEnvironment$DiscoveredProcessors com/sun/tools/javac/processing/JavacProcessingEnvironment$ServiceIterator com/sun/tools/jdi/SharedMemoryConnection com/sun/tools/jdi/SocketConnection com/sun/tools/sjavac/PubApiExtractor com/sun/xml/internal/stream/Entity$ScannedEntity com/sun/xml/internal/stream/XMLEventReaderImpl com/sun/xml/internal/stream/writers/XMLDOMWriterImpl com/sun/xml/internal/stream/writers/XMLEventWriterImpl com/sun/xml/internal/stream/writers/XMLStreamWriterImpl java/awt/SplashScreen java/util/logging/ConsoleHandler java/util/logging/FileHandler java/util/logging/Handler java/util/logging/MemoryHandler java/util/logging/SocketHandler java/util/logging/StreamHandler javax/naming/Context javax/naming/InitialContext javax/naming/NamingEnumeration javax/naming/directory/BasicAttribute$ValuesEnumImpl javax/naming/directory/BasicAttributes$AttrEnumImpl javax/naming/directory/BasicAttributes$IDEnumImpl javax/naming/ldap/StartTlsResponse javax/naming/spi/ContinuationContext javax/smartcardio/CardChannel javax/sql/PooledConnection javax/swing/ProgressMonitor javax/swing/text/rtf/RTFReader$AttributeTrackingDestination javax/swing/text/rtf/RTFReader$ColortblDestination javax/swing/text/rtf/RTFReader$Destination javax/swing/text/rtf/RTFReader$DiscardingDestination javax/swing/text/rtf/RTFReader$FonttblDestination javax/swing/text/rtf/RTFReader$StylesheetDestination javax/swing/text/rtf/RTFReader$StylesheetDestination$StyleDefiningDestination javax/swing/text/rtf/RTFReader$TextHandlingDestination javax/xml/stream/XMLEventReader javax/xml/stream/XMLEventWriter javax/xml/stream/XMLStreamReader javax/xml/stream/XMLStreamWriter javax/xml/stream/util/EventReaderDelegate javax/xml/stream/util/StreamReaderDelegate jdk/internal/jrtfs/ExplodedImage jdk/internal/util/xml/XMLStreamWriter jdk/internal/util/xml/impl/XMLStreamWriterImpl jdk/jfr/internal/consumer/ChunkParser jdk/jshell/SourceCodeAnalysisImpl jdk/tools/jlink/internal/Archive jdk/tools/jlink/internal/DirArchive jdk/tools/jlink/internal/JarArchive jdk/tools/jlink/internal/JmodArchive org/graalvm/compiler/code/CompilationResult org/graalvm/compiler/code/DataSection org/graalvm/compiler/debug/DiagnosticsOutputDirectory org/w3c/dom/html/HTMLDocument sun/awt/image/ImageDecoder sun/jvm/hotspot/debugger/DataSource sun/jvm/hotspot/debugger/InputLexer sun/jvm/hotspot/debugger/MappedByteBufferDataSource sun/jvm/hotspot/debugger/RandomAccessFileDataSource sun/jvm/hotspot/debugger/posix/AddressDataSource sun/jvm/hotspot/debugger/posix/elf/ELFFile sun/jvm/hotspot/debugger/posix/elf/ELFFileParser$ELFFileImpl sun/jvm/hotspot/debugger/win32/coff/COFFFile sun/jvm/hotspot/debugger/win32/coff/COFFFileParser$COFFFileImpl sun/jvm/hotspot/debugger/windbg/AddressDataSource sun/jvm/hotspot/debugger/windbg/DLL sun/net/ProgressSource sun/net/httpserver/ExchangeImpl sun/net/www/URLConnection sun/rmi/log/ReliableLog sun/rmi/runtime/Log$InternalStreamHandler sun/rmi/transport/Connection sun/rmi/transport/tcp/TCPConnection sun/security/smartcardio/ChannelImpl sun/tools/java/ClassPath

6 10

RFR: 8239365: ProcessBuilder/Basic.java test modifications for AIX execution
by Adam Farley8 22 Apr '20

22 Apr '20

Hi All, Reviews and sponsor requested for a small test change. Short version: When an AIX machine has the file set "bos.msg.en_US.rte", the error messages are not in a form that the test expects, causing failure. The simplest option appears to be adding the second potential form of the message into the regex (see webrev). http://cr.openjdk.java.net/~afarley/8239365.1/webrev/ Bug: https://bugs.openjdk.java.net/browse/JDK-8239365 Best Regards Adam Farley IBM Runtimes 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

3 7

RFR: 8243254: Examine ZipFile slash optimization for non-ASCII compatible charsets
by Claes Redestad 22 Apr '20

22 Apr '20

Hi, ZipFile.getEntry does optimizations to check for directory entries by adding a '/' to the encoded byte array. JDK-8242959 improved on this optimization, but a question was raised Jason Zaugg on whether the optimization is always valid[1]. Turns out it isn't, but only for non-ASCII compatible charsets. While JarFiles are always assumed to be UTF-8-encoded or compatible, ZipFiles allow arbitrary encoding. E.g., UTF-16 would encode '/' (2F) as either 2F 00 or 00 2F, which means the hash code would differ and a directory "foo/" potentially not be found when looking up "foo". Further complications arise when/if the directory name ends with a code point that might be encoded so that the final byte is 2F, e.g. \u012F. This patch only enables this low-level optimization when the charset encoding used is known to be ASCII compatible in the sense that 2F will be encoded as single-byte 2F. UTF-8 is compatible in this sense - and since this is the charset exclusively used by JarFile these changes have little to no effect on startup performance in the cases we've been looking at. Webrev: http://cr.openjdk.java.net/~redestad/8243254/open.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8243254 I've partially repurposed ZipFile/TestZipFile to test some such corner cases. Mainly expanded it to test ZipFiles created with various non- standard encodings, but also slimmed it down so that it can actually run quickly and reliably - as well as enabled it in regular testing. The updated test fails both before and after JDK-8242959, but passes with the proposed changes. Testing: tier1+2 Thanks! /Claes [1] https://twitter.com/retronym/status/1252134723431747584?s=20

4 8

[15] RFR: 8242614: cleanup duplicated test ldap server in some com/sun/jndi/ldap/ tests
by Chris Yin 22 Apr '20

22 Apr '20

Hello Please review following changes to cleanup duplicated test ldap server in some com/sun/jndi/ldap/ tests, thanks Bug: https://bugs.openjdk.java.net/browse/JDK-8242614 Webrev: http://cr.openjdk.java.net/~xyin/8242614/webrev.00/ This is the first part to cleanup straightforward duplicated test ldap server which was embedded in test itself. In the past, ldap tests may copy or implemented a dummy server in test itself to support specific test logic, so we have many duplicated dummy server logic across tests. Now there is already a common test ldap server skeleton available, it’s time to cleanup those duplicated logic to reduce possible future maintenance works. Run modified tests on 4 platforms for total 200 times, all green. Thanks, Chris

4 4

RFR: JDK-8241627: Updating ASM to 8.0 for JDK 15
by Vicente Romero 22 Apr '20

22 Apr '20

Hi all, Please review this patch that updates the ASM version to appear in JDK15 (from 7.0 to 8.0). Version 8.0 is compatible with JDK14 plus it has several experimental APIs to cover records and sealed types. We have also updated a number of tests (mostly record oriented tests) to use the updated APIs. Thanks to Igor Ignatyev for his help in particular for finding the source and fixing an issue that was provoking a failure at test: open/test/jdk/jdk/jfr/jvm/TestLogOutput.java This is the only substantial change that makes our copy of ASM different from the original, apart from several @SuppressWarnings that were added for the build to pass. The patch from Igor is this: diff -r b2ca6a37c16b src/java.base/share/classes/jdk/internal/org/objectweb/asm/Constants.java --- a/src/java.base/share/classes/jdk/internal/org/objectweb/asm/Constants.java Fri Apr 10 07:04:27 2020 -0700 +++ b/src/java.base/share/classes/jdk/internal/org/objectweb/asm/Constants.java Fri Apr 10 17:14:59 2020 -0700 @@ -222,15 +222,15 @@ } static boolean isWhitelisted(final String internalName) { - if (!internalName.startsWith("org/objectweb/asm/")) { + if (!internalName.startsWith("jdk/internal/org/objectweb/asm/")) { return false; } String member = "(Annotation|Class|Field|Method|Module|RecordComponent|Signature)"; return internalName.contains("Test$") || Pattern.matches( - "org/objectweb/asm/util/Trace" + member + "Visitor(\\$.*)?", internalName) + "jdk/internal/org/objectweb/asm/util/Trace" + member + "Visitor(\\$.*)?", internalName) || Pattern.matches( - "org/objectweb/asm/util/Check" + member + "Adapter(\\$.*)?", internalName); + "jdk/internal/org/objectweb/asm/util/Check" + member + "Adapter(\\$.*)?", internalName); } static void checkIsPreview(final InputStream classInputStream) { And it is basically adapting our copy to the different package prefix we use compared to the original ASM code. I have prepared two webrevs one at [1] which has the full change and one at [2] for which I have removed a lot of javadoc from the full webrev for reviewers that prefer less javadoc. Thanks, Vicente PS, thanks to Remi for fixing in a very short time a bug I found in ASM related to the parsing of Record attributes [1] http://cr.openjdk.java.net/~vromero/8241627/full/webrev.01/ [2] http://cr.openjdk.java.net/~vromero/8241627/no_javadoc/webrev.01/

3 8

RFR: 8239365: ProcessBuilder/Basic.java test modifications for AIX execution
by Adam Farley8 21 Apr '20

21 Apr '20

Bump :) Hi All, Review requested. @Tom - I don't mind if we use my version or yours, so long as the test passes when it should pass, and fails only when it should fail. The full messages would be nice for clarity and accuracy, though it doesn't seem to matter that much either way. Thanks for your feedback. :) Best Regards Adam Farley IBM Runtimes "Thomas Stüfe" <thomas.stuefe(a)gmail.com> wrote on 03/03/2020 10:52:10: > From: "Thomas Stüfe" <thomas.stuefe(a)gmail.com> > To: Adam Farley8 <adam.farley(a)uk.ibm.com> > Cc: core-libs-dev <core-libs-dev(a)openjdk.java.net> > Date: 03/03/2020 10:52 > Subject: [EXTERNAL] Re: RFR: 8239365: ProcessBuilder/Basic.java test > modifications for AIX execution > > This is why I always was against handing up the result of strerror > to the user :) The same problem we would have when running with > different locales. We should have a platform agnostic string table > in the java lib for that purpose... > > As for the test, looks good, but I personally would shorten the AIX > patterns a bit or maybe try to find a short form fitting all > platforms (e.g. "[Pp]ermission"). > > But thats just idle bikeshedding, lets see what others think. > > Cheers Thomas > > On Tue, Mar 3, 2020 at 11:43 AM Adam Farley8 <adam.farley(a)uk.ibm.com> wrote: > Hi All, > > Reviews and sponsor requested for a small test change. > > Short version: When an AIX machine has the file set "bos.msg.en_US.rte", > the error messages are not in a form that the test expects, causing > failure. > > The simplest option appears to be adding the second potential form of the > message into the regex (see webrev). > > http://cr.openjdk.java.net/~afarley/8239365.1/webrev/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8239365 > > Best Regards > > Adam Farley > IBM Runtimes > 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

2 1

RFR (T): 8243117: Cleanups in Java code of module jdk.jlink
by Langer, Christoph 21 Apr '20

21 Apr '20

Hi, please help review this cleanup patch for the Java code in module jdk.jlink. It's mostly automatic IDE cleanups of unused imports plus a few removals for unused private methods, fields and annotations. I've also added some @Override annotations where such were missing. Bug: https://bugs.openjdk.java.net/browse/JDK-8243117 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8243117.0/ Thanks Christoph

3 6