Re: RFR: JDK-8152690: main thread does not have native thread name

On 26/04/2016 1:11 PM, Yasumasa Suenaga wrote: Hi David, Kumar, I think that we should evacuate original exception before DestroyJavaVM thread name is set. http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.07/hotspot/ http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.07/jdk/

Re: RFR: JDK-8152690: main thread does not have native thread name

Hi David, Kumar, I think that we should evacuate original exception before DestroyJavaVM thread name is set. http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.07/hotspot/ http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.07/jdk/ I added it to LEAVE macro in new webrev. I tested

Re: RFR: JDK-8152690: main thread does not have native thread name

Hi Yasumasa, Kumar, Turns out this change breaks the behaviour of the launcher in the case that main() completes by throwing an exception. What we have in the launcher is: (*env)->CallStaticVoidMethod(env, mainClass, mainID, mainArgs); ret = (*env)->ExceptionOccurred(env) == NULL ? 0

Re: RFR(m): 8140281 deprecate Optional.get()

On Monday, April 25, 2016, Stuart Marks wrote: > > > On 4/25/16 4:35 PM, Jonathan Gibbons wrote: > >> Since the justification for this change appears to be that the IDEs might >> help >> write people write bad code, why not look to the IDEs to generate a >> warning when

Re: Fwd: RFR(m): 8140281 deprecate Optional.get()

On 4/25/16 4:35 PM, Jonathan Gibbons wrote: Since the justification for this change appears to be that the IDEs might help write people write bad code, why not look to the IDEs to generate a warning when using Optional.get outside of the context of Optional.isPresent? In other words, is this

Re: Fwd: RFR(m): 8140281 deprecate Optional.get()

Since the justification for this change appears to be that the IDEs might help write people write bad code, why not look to the IDEs to generate a warning when using Optional.get outside of the context of Optional.isPresent? In other words, is this really such a good change? -- Jon On

RFR(m): 8140281 deprecate Optional.get()

Hi all, Please review these webrevs that deprecate Optional.get() and to replace it with Optional.getWhenPresent(). The corresponding changes are also applied to OptionalDouble.getAsDouble(), OptionalInt.getAsInt(), and OptionalLong.getAsLong(). Unlike most deprecations, this isn't about the

Re: RFR(s): 8154801 deprecate java.util.Observable/Observer

On 4/24/16 6:13 AM, Doug Lea wrote: These days, anyone encountering these is probably hitting them by mistake while using RxJava or other reactive-stream frameworks. In which case, users will normally want to instead use the jdk9 java.util.concurrent.Flow APIs that all reactive-streams

Re: UNIXProcess.toString -- include more useful information

This is a reasonable request. But if you put platform-specific information into the String, then people will start treating that as an API (parsing the string), which is undesirable. On Mon, Apr 25, 2016 at 12:33 PM, Steven Schlansker wrote: > Hi core-libs-dev, > > I

UNIXProcess.toString -- include more useful information

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

RFR:JDK-8148949:DateTimeFormatter pattern letters 'A','n','N'

HI all, Please review a fix for Bug ID - https://bugs.openjdk.java.net/browse/JDK-8148949 Issue - Pattern letters 'A' does not match the intent of LDML/CLDR Solution - Changed the definition of pattern letters 'A','n','N' Webrev - http://cr.openjdk.java.net/~ntv/8148949/webrev.00/ --

Re: PING: RFR: JDK-4347142: Need method to set Password protection to Zip entries

2016-04-20 7:57 GMT+09:00 : > I have to agree. I don't think it makes sense to add a known-vulnerable > encryption algorithm to the JDK. It might work perfectly well for one > use case but it will eventually be used by someone who doesn't take the > time to understand