April 2016 - core-libs-dev

RFR 9: 8066750 Remove HTTP proxy implementation and tests from RMI
by Roger Riggs 26 Apr '16

26 Apr '16

The RMI http proxy mechanism was deprecated in Java SE 8. Please review the removal of now dead code for the RMI Http proxy implementation and tests. Webrev: http://cr.openjdk.java.net/~rriggs/webrev-httpproxy-8066750/ Issue: https://bugs.openjdk.java.net/browse/JDK-8066750 Thanks, Roger

2 2

UNIXProcess.toString -- include more useful information
by Steven Schlansker 26 Apr '16

26 Apr '16

Hi core-libs-dev, I recently was diagnosing a problem relating to an external program invoked via the ProcessBuilder API. The returned Process is an instance of java.lang.UNIXProcess, which does not have a toString method. While I understand that the concepts of "pid" etc are not cross-platform, it might be useful to operators to have the toString method dump them as diagnostic information. Imagine if instead of "java.lang.UNIXProcess@<hashCode>" you could see "UNIXProcess[running=true, pid=1234]" "UNIXProcess[running=false, exitCode=127]" This seems like it would be a fairly trivial change that could help some operator down the road. Is this a reasonable request? Thanks, Steven

3 4

Why are manifest files compressed by default?
by Martin Buchholz 26 Apr '16

26 Apr '16

Some of us at Google are having growing doubts about the compression of zip file entries. Compression works best when a lot of data is digested, allowing the compression engine to do "common bit-sequence elimination". But each zip entry is compressed separately, and many zip entries are small. The manifest is special not only because it is likely to be small but because it may be read by many programs that are only interested in zip file metadata (like the java launcher itself!), so its contents are more likely to be read than other entries. I guess the jar command has only one flag -0 to choose compression for all entries, and it would be surprising for the JDK to override the user's choice? Maybe the default behavior should be for the JDK to automatically choose compression only when there's a significant win, e.g. if the entry data is sufficiently large and compressible? Maybe the jar command should grow other compression-related options, and -9 could ask for "maximal overall compression"?

1 0

RFR(XS): 8155156: Remove remaining sun.misc.* imports from the jdk repo
by Volker Simonis 26 Apr '16

26 Apr '16

Hi, can I please have a review for this trivial change: http://cr.openjdk.java.net/~simonis/webrevs/2016/8155156/ https://bugs.openjdk.java.net/browse/JDK-8155156 The fix for "8153737: Unsupported Module" moved sun.misc to the jdk.unsupported module and removed sun.misc.* imports. Unfortunately, it forgot to remove the sun.misc.* imports from: src/java.base/share/classes/sun/nio/ch/AbstractPollSelectorImpl.java src/java.base/unix/classes/sun/nio/ch/PollSelectorImpl.java which are only used on AIX. Because the base module doesn't require jdk.unsupported, this leads to a build error on AIX. The last remaining sun.misc.* import in src/java.desktop/unix/classes/sun/awt/X11/XToolkit.java isn't required any more as well after "8147544: Remove sun.misc.ManagedLocalsThread from java.desktop" has been pushed. It doesn't lead to a build error because the java.desktop module still requires jdk.unsupported, but as the import isn't necessary any more, I think it's better to remove it as well. I build and smoke tested on Linux, Solaris and AIX. Thank you and best regards, Volker

2 1

Re: RFR JDK-8155005: java.lang.reflect.Module.WeakSet is not thread-safe
by Peter Levart 26 Apr '16

26 Apr '16

Hi Alan, On 04/25/2016 02:58 PM, Alan Bateman wrote: > On 25/04/2016 12:13, Peter Levart wrote: >> Hi Alan, >> >> I created an issue for this: >> >> JDK-8155005: java.lang.reflect.Module.WeakSet is not thread-safe >> >> https://bugs.openjdk.java.net/browse/JDK-8155005 >> >> >> I did what you suggested, renamed type parameters to <K1, K2, V>, >> split long line in Module and modified the test so that it now waits >> for entry to be expunged for up to 5 seconds when it is expected to >> be expunged but returns as soon as it detects that the entry is gone >> (usually in 1st 100 ms). It still waits just 500 ms when the entry is >> expected to remain in the map. False negatives should be eliminated >> this way and the test still doesn't waist plenty of execution time. >> >> Here's latest webrev: >> >> http://cr.openjdk.java.net/~plevart/jdk9-dev/Module.WeakSet.multithreadUnsa… >> > I think using <K1, K2, V> makes it a lot more readable - thanks. > > On gcAndWaitRemoved then I wonder if it would be more robust to have a > variant that polls indefinitely. 5s is a long time but with fastdebug > builds, maybe a looping thread or processes left over from a previous > test runs, virtual machines, then it might be long enough. I increased the timeout to 30 seconds. It is not exactly 30 seconds, but 300 iterations with sleep(100L) + check in each iteration. If the system is really overloaded then this loop should stretch automatically: http://cr.openjdk.java.net/~plevart/jdk9-dev/Module.WeakSet.multithreadUnsa… Are there any other jigsaw-specific tests I should be paying close attention to? I ran the jdk/test/java/lang/reflect/WeakPairMap jdk/test/java/lang/reflect/Module and jdk/test/java/lang/Class tests. Will I need an official blessing to push this to jdk9/dev on the core-libs-dev as we have been discussing this patch only on jigsaw-dev for a while? Regards, Peter > >> >> >> If this is accepted then I would need to know via which repo this >> should be pushed (jdk9/dev or jake). > It should be okay to push this to jdk9/dev and we'll pull the changes > into jake. In general then we will be iterating on the module code for > some time and so will be using the jake sandbox for that. > > -Alan

2 2

RFR 8015594: java.util.Pattern.matcher function throws a NullPointerException
by Sergey Ustimenko 26 Apr '16

26 Apr '16

Hi all! There is a bug described at https://bugs.openjdk.java.net/browse/JDK-8015594 The problem is that if we are using java.util.Pattern.matcher with NULL argument, then the NPE will be thrown. As Stuart Marks has noticed in the comments, that such behavior have not been specified, so it seems more convenient to update method's javadoc, saying that if argument is null, then the NPE will be thrown. I'm looking for review and sponsor. File with patch attached. diff --git a/src/java.base/share/classes/java/util/regex/Pattern.java b/src/java.base/share/classes/java/util/regex/Pattern.java --- a/src/java.base/share/classes/java/util/regex/Pattern.java +++ b/src/java.base/share/classes/java/util/regex/Pattern.java @@ -1097,8 +1097,11 @@ * The character sequence to be matched * * @return A new matcher for this pattern + * @throws NullPointerException if the specified {@code input} + * is {@code null}. */ public Matcher matcher(CharSequence input) { + Objects.requireNonNull(input); if (!compiled) { synchronized(this) { if (!compiled)

2 1

RFR(s): 8154801 deprecate java.util.Observable/Observer
by Stuart Marks 25 Apr '16

25 Apr '16

Hi all, Here's a small proposal to deprecate the java.util.Observable and Observer. This deprecation will not be for removal. See https://bugs.openjdk.java.net/browse/JDK-8154801 for some background. Essentially, these classes are a very thin implementation of the Observer pattern. These classes provide little beyond maintaining a list of callbacks plus the ability calling them upon request. A 1999 comment from Josh Bloch in a related bug report said that they are no longer under active development and have been superseded by the 1.1 Beans/AWT event model. Their only use in the JDK is in the Hotspot Serviceability Agent, which doesn't even use Observable, and which uses Observer as a callback interface. SA's use of Observer could easily be replaced with lambdas and Consumer<TypeDataBase>. There is some use of these classes "in the wild" but only for conventional callback purposes. Deprecation will generate warnings if that code is recompiled with deprecation warnings enabled. Diffs follow. Thanks, s'marks diff -r 92280897299f -r e16d8d56da15 src/java.base/share/classes/java/util/Observable.java --- a/src/java.base/share/classes/java/util/Observable.java Mon Apr 18 14:10:14 2016 -0700 +++ b/src/java.base/share/classes/java/util/Observable.java Thu Apr 21 15:48:23 2016 -0700 @@ -58,7 +58,19 @@ * @see java.util.Observer * @see java.util.Observer#update(java.util.Observable, java.lang.Object) * @since 1.0 + * + * @deprecated + * This class and the {@link Observer} interface have been deprecated. + * The event model supported by {@code Observer} and {@code Observable} + * is quite limited, the order of notifications delivered by + * {@code Observable} is unspecified, and state changes are not in + * one-for-one correspondence with notifications. + * For a richer event model, consider using the + * {@link java.beans} package. For reliable and ordered + * messaging among threads, consider using one of the concurrent data + * structures in the {@link java.util.concurrent} package. */ +@Deprecated(since="9") public class Observable { private boolean changed = false; private Vector<Observer> obs; diff -r 92280897299f -r e16d8d56da15 src/java.base/share/classes/java/util/Observer.java --- a/src/java.base/share/classes/java/util/Observer.java Mon Apr 18 14:10:14 2016 -0700 +++ b/src/java.base/share/classes/java/util/Observer.java Thu Apr 21 15:48:23 2016 -0700 @@ -31,7 +31,12 @@ * @author Chris Warth * @see java.util.Observable * @since 1.0 + * + * @deprecated + * This interface has been deprecated. See the {@link Observable} + * class for further information. */ +@Deprecated(since="9") public interface Observer { /** * This method is called whenever the observed object is changed. An

3 3

Annotation with array of Annotation
by Jochen Theodorou 23 Apr '16

23 Apr '16

Hi all, I know the following does not compile and does right so by the JLS: public @interface SomeCollector { Annotation[] value(); } I know also that it would be easy to support with the existing infrastructure. What I am looking for, is the reasoning as of why this is not allowed besides what is directly in the JLS. I am trying to understand the background a bit more. Has someone a pointer? bye Jochen

2 1

JDK 9 RFR of JDK-8154277: JavaDoc warnings in VirtualMachineManager.java and Pool.java
by Amy Lu 22 Apr '16

22 Apr '16

Please review this tiny fix for typos in the the documentation of: jdk/src/jdk.jlink/share/classes/jdk/tools/jlink/plugin/Pool.java jdk/src/jdk.jdi/share/classes/com/sun/jdi/VirtualMachineManager.java bug: https://bugs.openjdk.java.net/browse/JDK-8154277 webrev: http://cr.openjdk.java.net/~amlu/8154277/webrev.00/ Thanks, Amy --- old/src/jdk.jdi/share/classes/com/sun/jdi/VirtualMachineManager.java 2016-04-22 15:53:09.000000000 +0800 +++ new/src/jdk.jdi/share/classes/com/sun/jdi/VirtualMachineManager.java 2016-04-22 15:53:09.000000000 +0800 @@ -257,11 +257,11 @@ * delegate to the {@link com.sun.jdi.connect.spi.TransportService#description() * description()} method of the underlying transport service. Both * the AttachingConnector and the ListeningConnector will have two - * Connector {@link com.sun.jdi.connect.Connector$Argument Arguments}. - * A {@link com.sun.jdi.connect.Connector$StringArgument StringArgument} + * Connector {@link com.sun.jdi.connect.Connector.Argument Arguments}. + * A {@link com.sun.jdi.connect.Connector.StringArgument StringArgument} * named {@code address} is the connector argument to specify the * address to attach too, or to listen on. A - * {@link com.sun.jdi.connect.Connector$IntegerArgument IntegerArgument} + * {@link com.sun.jdi.connect.Connector.IntegerArgument IntegerArgument} * named {@code timeout} is the connector argument to specify the * timeout when attaching, or accepting. The timeout connector may be * ignored depending on if the transport service supports an attach --- old/src/jdk.jlink/share/classes/jdk/tools/jlink/plugin/Pool.java 2016-04-22 15:53:10.000000000 +0800 +++ new/src/jdk.jlink/share/classes/jdk/tools/jlink/plugin/Pool.java 2016-04-22 15:53:10.000000000 +0800 @@ -226,7 +226,7 @@ * <li>For jimage content: /{module name}/{package1}/.../{packageN}/{file * name}</li> * <li>For other files (shared lib, launchers, config, ...):/{module name}/ - * {@literal bin|conf|native}/{dir1}>/.../{dirN}/{file name}</li> + * {@literal bin|conf|native}/{dir1}/.../{dirN}/{file name}</li> * </ul> */ public static class ModuleData {

3 2

Re: error reporting path fix in java.util.prefs.FileSytemPreferences.lockFile0()
by Roger Riggs 22 Apr '16

22 Apr '16

Hi Harry, Great to see a new contributor. If you haven't read up on the OpenJDK processes, there are a few things you can read about how to contribute [1] and the developers guide [2] Typically, changes are applied to the current developers release (JDK 9) and then backported as needed. Please provide a description of the problem we can see if there is already a bugid for it or create one. Send the email to core-libs-dev(a)openjdk.java.net If the patch is not too big you can include it in an email to core-libs-dev(a)openjdk.java.net and folks will review it and someone will volunteer to sponsor it for you. Changes typically require a test case so it can be shown that the test fails without the change and works with the change. Regards, Roger [1] http://openjdk.java.net/contribute/ [2] http://openjdk.java.net/guide/ On 4/22/2016 12:53 PM, harry muttart wrote: > Greetings, > > I would like to submit a jdk runtime fix on behalf of my employer, > Azul Systems. > > The issue is a long-standing error reporting corner case in the > openjdk source > base. The same error exists in jdk6, jdk7, jdk8, and jdk9 sources. > The same > change easily applies to all of these source bases. A recent check of > the latest > openjdk source base shows this as still an issue. > > As I am a complete openjdk process newbie. Can someone please recommend > the simplest way to make this happen? > > Thanks to all for your patience. > > Harry Muttart > Azul Systems > > > > The issue... > ============ > > From the runtime code below, you can see there is a path through > java.util.prefs.FileSytemPreferences.lockFile0() which can result in an > error return with an unset errno field. On the path where the incoming > argument, shared, is JNI_TRUE, any errno set by an open failure is not > saved (in result[1]). Then, when the return code from the open is > checked, > the code zeroes result[0] but the errno slot remains unset. Because > return[] is stack allocated, return[1] may contain ANY value, and the > reported errno returned is completely unhelpful. > > There is an easy fix. Capture the errno value after ALL fopen() calls. > > An Azul customer tripped this issue. > > > The source file containing the "fix opportunity" is... > jdk6, jdk7, jdk8) > jdk/src/solaris/native/java/util/FileSystemPreferences.c > jdk9) jdk/src/java.prefs/unix/native/libprefs/FileSystemPreferences.c > > > The problem code (from openjdk6 source base) is: > > Java_java_util_prefs_FileSystemPreferences_lockFile0(JNIEnv *env, > jclass thisclass, jstring java_fname, jint permission, > jboolean shared) { > const char *fname = JNU_GetStringPlatformChars(env, > java_fname, JNI_FALSE); > int fd, rc; > int result[2]; > jintArray javaResult; > int old_umask; > FLOCK fl; > > fl.l_whence = SEEK_SET; > fl.l_len = 0; > fl.l_start = 0; > if (shared == JNI_TRUE) { > fl.l_type = F_RDLCK; > } else { > fl.l_type = F_WRLCK; > } > > if (shared == JNI_TRUE) { > fd = open(fname, O_RDONLY, 0); > // NEED FIX HERE: "result[1] = errno;" > } else { > old_umask = umask(0); > fd = open(fname, O_WRONLY|O_CREAT, permission); > result[1] = errno; > umask(old_umask); > } > > if (fd < 0) { > result[0] = 0; > } else { > rc = fcntl(fd, F_SETLK64, &fl); > result[1] = errno; > if (rc < 0) { > result[0]= 0; > close(fd); > } else { > result[0] = fd; > } > } > JNU_ReleaseStringPlatformChars(env, java_fname, fname); > javaResult = (*env)->NewIntArray(env,2); > (*env)->SetIntArrayRegion(env, javaResult, 0, 2, result); > return javaResult; > } >

1 0