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

On 4/26/16 3:43 AM, Stephen Colebourne wrote: In OpenGamma Strata we have 546 uses of Optional.get(). Renaming this would be painful and add no value. Hi Stephen, I just sent a reply [1] to Kevin B, wherein I clarified "rename." Briefly, it strictly isn't a rename. The old method would be

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

On 4/26/16 9:20 PM, Kevin Bourrillion wrote: Guava owner here, and yes, I've never heard such a complaint about our Optional.get() method. This class has about a quarter of a million usages inside Google alone (I'm not kidding), and people seem quite happy with it. Hi Kevin, thanks for your

Re: RFR 8154733, Fix module dependencies missed in java.rmi tests

On 4/27/16 1:00 AM, Alan Bateman wrote: On 26/04/2016 13:50, Felix Yang wrote: Hi Amy, thanks for pointing this out. Updated webrev: http://cr.openjdk.java.net/~xiaofeya/8154733/webrev.01/ This looks okay to me. -Alan Thank you Alan! Felix, I'll sponsor this change for you.

Re: RFR 9: 8066750 broke jdk9 builds; backup the changeset

Yes, just the result of hg backout. Do I need to run a jprt build job or can I push and let Mach5 proof it? Thanks, Roger On 4/26/16 9:16 PM, Joseph D. Darcy wrote: +1 if it is just applying an anti-delta to the earlier change. Thanks, -Joe On 4/26/2016 6:14 PM, Roger Riggs wrote: Please

Re: RFR 9: 8066750 broke jdk9 builds; backup the changeset

+1… > On Apr 26, 2016, at 9:16 PM, Joseph D. Darcy wrote: > > +1 if it is just applying an anti-delta to the earlier change. > > Thanks, > > -Joe > > On 4/26/2016 6:14 PM, Roger Riggs wrote: >> Please review the backout of the change for 8806750 which broke some builds

Re: RFR 9: 8066750 broke jdk9 builds; backup the changeset

+1 if it is just applying an anti-delta to the earlier change. Thanks, -Joe On 4/26/2016 6:14 PM, Roger Riggs wrote: Please review the backout of the change for 8806750 which broke some builds that have not yet removed a dependency. Webrev:

RFR 9: 8066750 broke jdk9 builds; backup the changeset

Please review the backout of the change for 8806750 which broke some builds that have not yet removed a dependency. Webrev: http://cr.openjdk.java.net/~rriggs/webrev-backout-8155182/ After the dependencies are cleared, I'll send a new review for the original removal. Sorry for the hassle,

Re: RFR 8154447: Exempt classes under java.util.concurrent from MH.Lookup restrictions

> On 26 Apr 2016, at 15:14, Martin Buchholz wrote: > > Looks good to me. I'd add a TODO comment. > Thanks. I have changed the comment to: // For caller-sensitive MethodHandles.lookup() disallow lookup from // restricted packages. This a fragile and blunt approach. //

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

I'm really grasping at straws here and asking for something quantitative to substantiate this deprecation plan. As it stands, there is hearsay and some stackoverflow links - surely going through with this (and inflicting some level of pain on folks who don't care for this) deserves something a

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

Are you asking Brian to set up another survey monkey for the masses? I expect a happy silent majority and a raucous minority just based on past results. :-) On Apr 26, 2016 6:38 PM, "Vitaly Davidovich" wrote: I've yet to hear one supporter on this thread besides yourself

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

I've yet to hear one supporter on this thread besides yourself and Stuart. Is there some usability survey or something that actually indicates a significant sample of people don't like the name? Guava Optional behaves and is named the same way, and I've not heard anyone complain about that (I and

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

On 27/04/2016 12:38 AM, Yasumasa Suenaga wrote: Hi Kumar, David, simply to set a name which seems to be useful only for folks trying to debug the VM ??? besides ps and few other OS related utils it has no visibility of value to the JRE or the JDK APIs. I want to check CPU time through ps

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

So, pop quiz, one question: How many folk use the javac options -Xlint -Werror, and would thus see changes like this as a breaking change in the API? -- Jon On 04/26/2016 02:13 AM, Rémi Forax wrote: I agree with Jon, Vitaly and Ali, get is good candidate to @Bikeshed not for @Deprecated.

Re: String.equalsIgnoreCase(...) optimization

I create simple benchmark (attached). Optimized version more faster: # JMH 1.12 (released 26 days ago) # VM version: JDK 1.8.0_91, VM 25.91-b14 ... # Run complete. Total time: 00:04:02 BenchmarkMode Cnt ScoreError Units StringBenchmark.constConst

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

On 4/26/16 2:55 PM, Brian Goetz wrote: Stepping back a bit ... one of the most frequent complaints we get is "mistakes never get fixed". So, we've decided to be more serious about deprecation -- Dr. Deprecator is suiting up! But that means, for any given item, some people are going to

Re: RFR 8154447: Exempt classes under java.util.concurrent from MH.Lookup restrictions

> On Apr 26, 2016, at 3:01 PM, Paul Sandoz wrote: > > Hi, > > Please review: > > > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8154447-mh-lookup-restricted-pkgs/webrev/ > > >

Re: RFR 8154447: Exempt classes under java.util.concurrent from MH.Lookup restrictions

Looks good to me. I'd add a TODO comment. On Tue, Apr 26, 2016 at 3:01 PM, Paul Sandoz wrote: > Hi, > > Please review: > > > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8154447-mh-lookup-restricted-pkgs/webrev/ > >

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

As the person who chose the original (terrible) name, let me weigh in... I think calling this method "get()" was our biggest API mistake in Java 8. Now, one could argue that, if this is the biggest mistake we made, then we did pretty darn good. Which may be true, but ... make no mistake, it

Re: RFR 9: 8066750 Remove HTTP proxy implementation and tests from RMI

Hi Stuart, Good catch, I didn't look in the ProblemList; webrev updated in place. Thanks, Roger On 4/26/2016 4:41 PM, Stuart Marks wrote: Hi Roger, Wow, look at all that red! Red is my favorite color. Changes look good. One small item:

Re: RFR 9: 8066750 Remove HTTP proxy implementation and tests from RMI

Hi Roger, Wow, look at all that red! Red is my favorite color. Changes look good. One small item: test/sun/rmi/transport/proxy/EagerHttpFallback.java is one of the tests being removed. Its entry can also be removed from test/ProblemList.txt. Its corresponding bug JDK-7195095 can probably

RFR 9: 8066750 Remove HTTP proxy implementation and tests from RMI

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

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

>From my experience, devs in general only read the doc when an exception is >thrown so i agree with you. And in the wake of deprecating Optional.get(), I propose to rename RuntimeException to RTFMException :) Remi Le 26 avril 2016 20:05:22 CEST, Peter Levart a écrit

JDK-8155102: Process.toString could include pid, isAlive, exitStatus

Hi, I would like to familiarise myself with contributing process. Can I take this bug to fix? -- Thanks, Andrey

Why are manifest files compressed by default?

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.

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

Hi, If Optional.get() is the method that gets most attention from beginners and learners, then perhaps its javadoc is the place that could be improved by making it a honey pot for advice about Optional use. The assumption that the average programmer starts reading documentation of some new

Re: RFR(XS): 8155156: Remove remaining sun.misc.* imports from the jdk repo

On 26 Apr 2016, at 18:33, Volker Simonis wrote: > 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 Thank you Volker. Reviewed. -Chris. >

RFR(XS): 8155156: Remove remaining sun.misc.* imports from the jdk repo

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.

Re: RFR JDK-8155005: java.lang.reflect.Module.WeakSet is not thread-safe

On 04/26/2016 04:56 PM, Alan Bateman wrote: On 26/04/2016 15:42, Peter Levart wrote: 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

Re: RFR 8154733, Fix module dependencies missed in java.rmi tests

On 26/04/2016 13:50, Felix Yang wrote: Hi Amy, thanks for pointing this out. Updated webrev: http://cr.openjdk.java.net/~xiaofeya/8154733/webrev.01/ This looks okay to me. -Alan

Re: String.equalsIgnoreCase(...) optimization

On 04/26/2016 03:25 PM, Andrey wrote: > May be can create optimized regionMatches(...) for use in > equalsIgnoreCase(...)? When the HotSpot JVM's just-in-time compiler optimizes this code it inlines all of these tests, realizes that they are constant values, and generates no code for them. All

Re: JDK 9 pre-review of JDK-6850612: Deprecate Class.newInstance since it violates the checked exception language contract

The changes to the security-libs portions look fine to me. --Sean On 04/21/2016 12:25 PM, joe darcy wrote: Hello, After a generally positive reception, please review the webrev to implement the deprecation of Class.newInstance and the suppression of the resulting warnings:

Re: RFR JDK-8155005: java.lang.reflect.Module.WeakSet is not thread-safe

On 26/04/2016 15:42, Peter Levart wrote: 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:

Re: RFR JDK-8155005: java.lang.reflect.Module.WeakSet is not thread-safe

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

Re: UNIXProcess.toString -- include more useful information

Created https://bugs.openjdk.java.net/browse/JDK-8155102 to track the request. On 4/26/2016 10:30 AM, Roger Riggs wrote: Hi, The pid (though os specific) is available from the Process API and so adding it to toString does not expose any additional implementation specific information.

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

Hi Kumar, David, simply to set a name which seems to be useful only for folks trying to debug the VM ??? besides ps and few other OS related utils it has no visibility of value to the JRE or the JDK APIs. I want to check CPU time through ps command on Linux. Usually, I get "ps -eLf" and nid

Re: UNIXProcess.toString -- include more useful information

Hi, The pid (though os specific) is available from the Process API and so adding it to toString does not expose any additional implementation specific information. Getting accurate values for exitcode and running status would require a native call on windows but might be ok only for

String.equalsIgnoreCase(...) optimization

Hello!  I read source code equalsIgnoreCase(...) in String class and saw that it is not  optimal. This method check length and call regionMatches(...)  with 'constant' values http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/687fd7c7986d/src/share/classes/java/lang/String.java#l1095   ...    &&

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

On 4/26/2016 6:08 AM, David Holmes wrote: On 26/04/2016 10:54 PM, Yasumasa Suenaga wrote: Hi David, For this issue, I think we can approach as following: 1. Export new JVM function to set native thread name It can avoid JNI call and can handle char* value. However this

Re: RFR 8154733, Fix module dependencies missed in java.rmi tests

On 4/26/16 8:50 PM, Felix Yang wrote: Hi Amy, thanks for pointing this out. Updated webrev: http://cr.openjdk.java.net/~xiaofeya/8154733/webrev.01/ Thank you Felix for the updated webrev. This looks clear and good :-) Just one question, does this fix for all tests for jdk_rmi test

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

On 26/04/2016 10:54 PM, Yasumasa Suenaga wrote: Hi David, For this issue, I think we can approach as following: 1. Export new JVM function to set native thread name It can avoid JNI call and can handle char* value. However this plan has been rejected. 2. Call uncaught

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

Hi David, For this issue, I think we can approach as following: 1. Export new JVM function to set native thread name It can avoid JNI call and can handle char* value. However this plan has been rejected. 2. Call uncaught exception handler from Launcher We have to

Re: RFR 8154733, Fix module dependencies missed in java.rmi tests

Hi Amy, thanks for pointing this out. Updated webrev: http://cr.openjdk.java.net/~xiaofeya/8154733/webrev.01/ Felix On 2016/4/26 17:21, Amy Lu wrote: Hi, Felix With modules declares in TEST.propertiesshould avoid have to modify test file one by one... Maybe I missed things please

Re: RFR 8015594: java.util.Pattern.matcher function throws a NullPointerException

On 26/04/2016 12:49, Sergey Ustimenko wrote: 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

Re: RFR:JDK-8079628:java.time: DateTimeFormatter containing "DD" fails on 3-digit day-of-year value

This change introduces inconsistencies and problems. For example, it will parse up to 19 digits for "D" but only up to 2 digits for "d". The following would be better: *D 1 appendValue(ChronoField.DAY_OF_YEAR) *DD 2 appendValue(ChronoField.DAY_OF_YEAR, 2, 3,

RFR 8015594: java.util.Pattern.matcher function throws a NullPointerException

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

RFR:JDK-8079628:java.time: DateTimeFormatter containing "DD" fails on 3-digit day-of-year value

Hi all, Please review a fix for Bug ID - https://bugs.openjdk.java.net/browse/JDK-8079628 Issue - Pattern 'D' is not implemented as intended by CLDR Solution - Changed the definition of 'D' to D..D 1..3 appendValue(ChronoField.DAY_OF_YEAR, n, 19, SignStyle.NORMAL) Webrev -

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

On Tuesday, April 26, 2016, Stuart Marks wrote: > > > On 4/25/16 5:46 PM, Vitaly Davidovich wrote: > >> We've introduced Optional to avoid this. The problem is that the >> obvious >> thing to do is to get() the value out of the Optional, but this buys >> us >>

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

Hello! While I'm not a reviewer, I agree with Stephen. While I understand the rationale, such renaming would cause even more confusion and pain. Also I think this is not the worst part of Java API, so if we start to rename things, where should we stop then? With best regards, Tagir Valeev.

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

In OpenGamma Strata we have 546 uses of Optional.get(). Renaming this would be painful and add no value. While I understand the pain from some developers not understanding the feature, this is hardly unique in the world of Java. Developers learn the right way of doing something soon enough. And

Re: RFR 8154733, Fix module dependencies missed in java.rmi tests

On 26/04/2016 10:21, Amy Lu wrote: Hi, Felix With modules declares in TEST.propertiesshould avoid have to modify test file one by one... Maybe I missed things please correct me. Example: $ cat jdk/test/java/rmi/TEST.properties modules = java.rmi Yes, this avoid needing to add @modules to

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

On 26/04/2016 7:22 PM, Yasumasa Suenaga wrote: Hi David, I thought about being able to save/restore the original pending exception but could not see a simple way to restore it - ie just by poking it back into the thread's pending exception field. The problem with using env->Throw is that it

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

Hi David, I thought about being able to save/restore the original pending exception but could not see a simple way to restore it - ie just by poking it back into the thread's pending exception field. The problem with using env->Throw is that it acts like the initial throwing of the exception

Re: RFR 8154733, Fix module dependencies missed in java.rmi tests

Hi, Felix With modules declares in TEST.propertiesshould avoid have to modify test file one by one... Maybe I missed things please correct me. Example: $ cat jdk/test/java/rmi/TEST.properties modules = java.rmi Thanks, Amy On 4/26/16 4:53 PM, Felix Yang wrote: Hi all, please review

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

I agree with Jon, Vitaly and Ali, get is good candidate to @Bikeshed not for @Deprecated. Rémi Le 26 avril 2016 08:26:43 CEST, Ali Ebrahimi a écrit : >Hi, >I agree with Jon, Vitaly, >I think the name Optional completely describe its intents and semantics >so >I

RFR 8154733, Fix module dependencies missed in java.rmi tests

Hi all, please review the fix to explicitly declare module dependencies for rmi tests. Bug: https://bugs.openjdk.java.net/browse/JDK-8154733 Webrev: http://cr.openjdk.java.net/~xiaofeya/8154733/webrev.00/ Thanks, Felix

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

Hi, I agree with Jon, Vitaly, I think the name Optional completely describe its intents and semantics so I don't think we need more descriptive method name here. Optional === may be have value So Optional.get === may be return value Therefore, I think this all effort doesn't add any (or enough)

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

On 4/25/16 5:46 PM, Vitaly Davidovich wrote: We've introduced Optional to avoid this. The problem is that the obvious thing to do is to get() the value out of the Optional, but this buys us right back into the what-if-the-value-is-missing case that we had with nulls. Why is this