Re: Improve `finally` block exception handling

Thanks a lot for your feedback! My original message was a bit vague in parts, sorry for that. The proposal consists of the following: 1. Forbidding usage of `break`, `continue`, `yield` and `return` in `finally` blocks 2. Adding exceptions as suppressed exceptions: If exception E1 led to

Improve `finally` block exception handling

Hello, are there any plans to improve exception handling in combination with `finally` blocks? Currently, when a `finally` block does not complete normally, the original exception is silently discarded (as described in the JLS). This behavior is error-prone, not obvious at all, and has been

Re: RFR: 6594730: UUID.getVersion() is only meaningful for Leach-Salz variant

> 1. Replace ` ` with a normal space, that should work as well and is easier > to read Looks like my e-mail client was so kind and replaced the HTML character reference. It should have said: "Replace `& nbsp ;` with a normal space, ..." Additionally, if you want to search for projects using

Re: RFR: 6594730: UUID.getVersion() is only meaningful for Leach-Salz variant

The following probably does not matter much because I am not an OpenJDK contributor, but personally I think throwing an UnsupportedOperationException is reasonable: 1. It is consistent with the other methods which also only work for one specific variant 2. Code which calls UUID.version() on

Re: Is SharedSecrets thread-safe?

Hello Peter, feel free to consider these issues one at a time, or not at all, if you don't think that it is worth it. However, please note that I will unsubscribe from this mailing list in the next days again due to the high degree of activity. (Related:

Re: Is SharedSecrets thread-safe?

Hello Peter, the changes look good, however there might be more to consider: - `jdk.internal.access.SharedSecrets.getJavaLangRefAccess()` Might be good to add a comment there or for `java.lang.ref.Reference` that it is (hopefully?) initialized during JVM start-up. Similar to the comment for

Re: Is SharedSecrets thread-safe?

That would also be my understanding of the current situation, though this contradicts what Claes wrote. Maybe the JVM behaves in a way which does not allow reordering, but the JLS definitely seems to allow it. Section § 12.2.4 [0] only mentions that for the class to be initialized there has to

Is SharedSecrets thread-safe?

Hello, the class `jdk.internal.access.SharedSecrets` provides getter methods which all look similar to this: ``` if (static_field == null) { initialize(); } return static_field; ``` However, neither the static fields are `volatile` nor are the getter methods synchronized. So if my

Re: Feature suggestion: Allow generic wildcard in class literal expression

What do you think about this idea? I hope the fact that I did not get any responses yet does not mean that you are not interested or that I annoyed you. > JDK-6184881 describes that Object.getClass() should ideally not return > classes of raw types anymore but instead use wildcards. The problem

Re: Feature suggestion: Provide efficient way for nullable value lookup in Map

Would this method then be useful enough if the default implementation is that inefficient (in case you only want to get a nullable value)? > Brian Goetz hat am 8. Januar 2019 um 16:57 > geschrieben: > > > Here's a default implementation that returns the actual key: > >    default Optional>

Re: Feature suggestion: Provide efficient way for nullable value lookup in Map

Yes it is now possible to implement the methods `getKey(Object key)` and `getEntry(Object key)` requested by JDK-6552529 as default methods, however both would have to include that "The default implementation returns the provided key. Overriding implementations may return the actual key used

Re: Feature suggestion: Add static equals methods to Float and Double

My main goal was to provide a way where NaN is equal to NaN and I went with the behavior of the respective wrapper classes, Float and Double, which consider -0.0 and +0.0 as not equal. The static method could be called "exactlyEquals" if that is better. It might also depend on the usecase

Re: Feature suggestion: Add static equals methods to Float and Double

If the developer implemented the Comparable interface correctly, the method you proposed would be equivalent to java.util.Objects.equals(Object, Object). Additionally both variants would require boxing for primitive types which I initially wanted to prevent. > Zheka Kozlov hat am 6. Januar

Re: Feature suggestion: Add static equals methods to Float and Double

Hello Remi, You are right, the proposed method names would prevent backwards compatibility, I forgot to think about that. Sorry for the trouble. Maybe a different, currently not used name, such as `areEqual`, `primitiveEquals` or similar would be better. What do You think about the addition of

Feature suggestion: Provide efficient way for nullable value lookup in Map

The methods currently provided by the Map interface (https://docs.oracle.com/javase/8/docs/api/java/util/Map.html) do not provide an efficient way to look up nullable values. This problem would be solved if JDK-6552529 was implemented, but that will likely not be happening since the interface

Feature suggestion: Add static equals methods to Float and Double

To test whether primitive float or double values are equal according to `Float.equals` and `Double.equals` you either have to create wrapper instances for them (possible performance decrease), use the respective static `compareTo` (verbose) or have to use the appropriate methods

Feature suggestion: Allow generic wildcard in class literal expression

JDK-6184881 describes that Object.getClass() should ideally not return classes of raw types anymore but instead use wildcards. The problem is that, as noted in the comments, this breaks compability with previously written code and therefore this change is not very likely (at the moment?).