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) va
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 t
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/
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
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
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
>> using Optional.get outs
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 r
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 04/25/
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
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 framewor
On 4/22/16 3:03 AM, Mark Thomas wrote:
Excellent. Thank you very much for that. It does indeed work.
Glad to hear it!
It's probably necessary to unexport and maybe also unbind everything
from this registry as well, as Roger had suggested previously.
For the record, if the module/applicati
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 recently was diagnosing a pr
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,
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/
--
Than
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 it, assumes that it provide
15 matches
Mail list logo
