not be ideal though.
/Kasper
/Kasper
On Sat, 18 Nov 2023 at 15:00, Rob Spoor wrote:
>
> On 18/11/2023 06:46, Kasper Nielsen wrote:
> > Hi Rob,
> >
> > Delegating caller sensitive methods can be tricky.
> >
> > Besides the obvious solutions with StackWalker and/
Hi Rob,
Delegating caller sensitive methods can be tricky.
Besides the obvious solutions with StackWalker and/or Lookup objects I've
sometimes used an abstract class that must be extended by users of my library.
This may be more trouble in your case than the other solutions though.
In your
What would an alternative method signature look like for a method called
closeUnchecked?
On Sat, 8 Jul 2023 at 15.49, Glavo wrote:
>
> Can it be a static method instead of a default method? `Closeable` is a
> widely used class, so adding new default methods risks conflicting with
> existing
> In contrast the foreign memory API is very stable already since Java 19 and
> the changes were minimal in 21.
If you take a look at differences from Java 20 to Java 21 on Java
Almanac [1] for java.lang.foreign.
I wouldn't really call it minimal. Lots of classes and methods were
added and
On Sun, 26 Mar 2023 at 10:38, Jens Lideström wrote:
>
> I think Map#of and friends would be more useful and less error prone if they
> where to return collections that have a fixed iteration order, where the
> order is defined by the insertion order when the map is created.
The problem is that
> >>
> >> I don't (yet) want to be prescriptive in any potential solution. And I
> >> know that this has been discussed before. I mostly just want to start a
> >> conversation and see how much traction it gets.
> >>
> > Would
> > java.util.SequencedMap.of(...)
> >
>
> I don't (yet) want to be prescriptive in any potential solution. And I
> know that this has been discussed before. I mostly just want to start a
> conversation and see how much traction it gets.
>
Would
java.util.SequencedMap.of(...)
java.util.SequencedMap.copyOf(SequencedMap map)
I've been in situations as well where a bit more context would have been very
useful for some collection NPEs.
While lambdas are overkill. I do think there are some more low-level solutions.
requireNonNull(k0) can be replaced with with requireNonNull(k0, "key is null");
For the indexed versions
On Wed, 22 Feb 2023 21:29:12 GMT, Rémi Forax wrote:
>> In all the places I've seen LambdaMetaFactory used, it is because of
>> performance over reflection/non-static method handles. See, for example,
>> https://www.optaplanner.org/blog/2018/01/09/JavaReflectionButMuchFaster.html.
>> I believe
On Thu, 9 Feb 2023 18:11:18 GMT, Volker Simonis wrote:
>> Prior to
>> [JDK-8239384](https://bugs.openjdk.org/browse/JDK-8239384)/[JDK-8238358](https://bugs.openjdk.org/browse/JDK-8238358)
>> LambdaMetaFactory has created VM-anonymous classes which could easily be
>> unloaded once they were
On Tue, 31 Jan 2023 at 21:21, wrote:
>
> There is no conflict with JLS 7.2.2 as I can see.
Thanks for getting back to me.
Maybe there isn't a direct conflict. But I still think this is not very
intuitive.
If I have an application with two packages:
com.acme.foreveryone
com.acme.secret
Hi,
I just saw the pull request for 8217920 (Lookup.defineClass injects a class
that can access private members of any class in its own module.)
The PR details how you can generate a class in a package that has been opened
to you via a module declaration. This generated class can then create a
On Mon, 30 Jan 2023 at 09:11, Glavo wrote:
> Now that we have the interface default method, can we add a new method to the
> Collection to obtain the support status of the feature, like this:
>
> public record CollectionFeature(String name) {
> public enum Status {
> SUPPORTED,
>
> and ClassDesc.packageName is as well.
>
> Class.getPackage has been doing what it been doing since about JDK 1.2 so due
> to behavioral compatibility, there would have to be a much stronger case for
> altering its behavior at this point.
>
> -Joe
>
> On
Hi,
I was playing around with java.lang.constant and found an inconsistency between
ClassDesc::packageName and Class::getPackageName as outlined in the table below.
Specifically dealing with primitive and array types.
Class ClassDesc::packageName Class::getPackage Class::getPackageName
On Thu, 28 Jul 2022 at 22:11, Holo The Sage Wolf wrote:
> I have a question about the proposal, why not allow try-with-resources
> with this API?
>
Hi,
For Loom related questions, loom-...@openjdk.org is probably a better fit.
The main problem with TWR is that it cannot guard against
16 matches
Mail list logo