MethodHandles.lookup().findVarHandle alternative not throwing checked exceptions?

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

MethodHandles.lookup().findVarHandle alternative not throwing checked exceptions?

Dávid Karnok
Hello,

I've been implementing a lot of concurrent code with VarHandles lately and there is a repeated inconvenience of using

MethodHandles.lookup().findVarHandle(...)

because I can't use it to initialize static fields directly but have to use a static initialization block and have try-catch around them:

static {
   try {
       UPSTREAM = MethodHandles.lookup().findVarHandle(A.class, "upstream", Flow.Subscription.class);
   } catch (Throwable ex) {
      throw new InternalError(ex);
   }
}

Apart from writing the above by hand all the time, there is a slight annoyance that a well parameterized findVarHandle will never throw thus the throw new InternalError remains uncovered by code-coverage.

Factoring out the lookup part doesn't work if the target class and/or field is non accessible from the point of the common routine, plus I lose the nice IntelliJ feature of validating the findVarHandle parameters in the IDE itself.

Would it be possible to have some versions of findVarHandle and co in Java 10+ that don't throw checked exceptions?

(Tools such as Lombok may (eventually) help with hiding the VarHandle setup via annotation, but the generated catch code would still remain uncovered.)

--
Best regards,
David Karnok

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: MethodHandles.lookup().findVarHandle alternative not throwing checked exceptions?

Nathan and Ila Reynolds
Until findVarHandle() with unchecked exceptions, how about writing a utility class that has a static findVarHandle(Class<?>, String, Class<?>) with the code you have below?  The initialization code would then be...

UPSTREAM = VarHandleUtilities.findVarHandle(A.class, "upstream", Flow.Subscription.class);

-Nathan

On 8/15/2017 8:18 AM, Dávid Karnok wrote:
Hello,

I've been implementing a lot of concurrent code with VarHandles lately and there is a repeated inconvenience of using

MethodHandles.lookup().findVarHandle(...)

because I can't use it to initialize static fields directly but have to use a static initialization block and have try-catch around them:

static {
   try {
       UPSTREAM = MethodHandles.lookup().findVarHandle(A.class, "upstream", Flow.Subscription.class);
   } catch (Throwable ex) {
      throw new InternalError(ex);
   }
}

Apart from writing the above by hand all the time, there is a slight annoyance that a well parameterized findVarHandle will never throw thus the throw new InternalError remains uncovered by code-coverage.

Factoring out the lookup part doesn't work if the target class and/or field is non accessible from the point of the common routine, plus I lose the nice IntelliJ feature of validating the findVarHandle parameters in the IDE itself.

Would it be possible to have some versions of findVarHandle and co in Java 10+ that don't throw checked exceptions?

(Tools such as Lombok may (eventually) help with hiding the VarHandle setup via annotation, but the generated catch code would still remain uncovered.)

--
Best regards,
David Karnok


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest

-- 
-Nathan

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: MethodHandles.lookup().findVarHandle alternative not throwing checked exceptions?

Dávid Karnok
Already mentioned:

Factoring out the lookup part doesn't work if the target class and/or field is non accessible from the point of the common routine

My code is full of package-private classes and fields, so I have to have the helper class in every package or make the classes or fields public. 

In addition, I can't use modules in case the library's users don't use it either (assuming it is still true that in order to use a library that is modularized, one has to be modularized itself).


2017-08-15 16:31 GMT+02:00 Nathan and Ila Reynolds <[hidden email]>:
Until findVarHandle() with unchecked exceptions, how about writing a utility class that has a static findVarHandle(Class<?>, String, Class<?>) with the code you have below?  The initialization code would then be...

UPSTREAM = VarHandleUtilities.findVarHandle(A.class, "upstream", Flow.Subscription.class);

-Nathan


On 8/15/2017 8:18 AM, Dávid Karnok wrote:
Hello,

I've been implementing a lot of concurrent code with VarHandles lately and there is a repeated inconvenience of using

MethodHandles.lookup().findVarHandle(...)

because I can't use it to initialize static fields directly but have to use a static initialization block and have try-catch around them:

static {
   try {
       UPSTREAM = MethodHandles.lookup().findVarHandle(A.class, "upstream", Flow.Subscription.class);
   } catch (Throwable ex) {
      throw new InternalError(ex);
   }
}

Apart from writing the above by hand all the time, there is a slight annoyance that a well parameterized findVarHandle will never throw thus the throw new InternalError remains uncovered by code-coverage.

Factoring out the lookup part doesn't work if the target class and/or field is non accessible from the point of the common routine, plus I lose the nice IntelliJ feature of validating the findVarHandle parameters in the IDE itself.

Would it be possible to have some versions of findVarHandle and co in Java 10+ that don't throw checked exceptions?

(Tools such as Lombok may (eventually) help with hiding the VarHandle setup via annotation, but the generated catch code would still remain uncovered.)

--
Best regards,
David Karnok


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest

-- 
-Nathan

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest




--
Best regards,
David Karnok

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: MethodHandles.lookup().findVarHandle alternative not throwing checked exceptions?

Aaron Grunthal
You could create a MethodHandles.Lookup in the caller and pass it to the utility class. The creation does not throw an exception.

On 15.08.2017 17:40, Dávid Karnok wrote:

> Already mentioned:
>
> Factoring out the lookup part doesn't work if the target class and/or field is non accessible from the point of the common routine
>
> My code is full of package-private classes and fields, so I have to have the helper class in every package or make the classes or fields public.
>
> In addition, I can't use modules in case the library's users don't use it either (assuming it is still true that in order to use a library that is modularized, one has to be modularized itself).
>
>
> 2017-08-15 16:31 GMT+02:00 Nathan and Ila Reynolds <[hidden email] <mailto:[hidden email]>>:
>
>     Until findVarHandle() with unchecked exceptions, how about writing a utility class that has a static findVarHandle(Class<?>, String, Class<?>) with the code you have below?  The initialization
>     code would then be...
>
>     UPSTREAM = VarHandleUtilities.findVarHandle(A.class, "upstream", Flow.Subscription.class);
>
>     -Nathan
>
>
>     On 8/15/2017 8:18 AM, Dávid Karnok wrote:
>>     Hello,
>>
>>     I've been implementing a lot of concurrent code with VarHandles lately and there is a repeated inconvenience of using
>>
>>     MethodHandles.lookup().findVarHandle(...)
>>
>>     because I can't use it to initialize static fields directly but have to use a static initialization block and have try-catch around them:
>>
>>     static {
>>        try {
>>            UPSTREAM = MethodHandles.lookup().findVarHandle(A.class, "upstream", Flow.Subscription.class);
>>        } catch (Throwable ex) {
>>           throw new InternalError(ex);
>>        }
>>     }
>>
>>     Apart from writing the above by hand all the time, there is a slight annoyance that a well parameterized findVarHandle will never throw thus the throw new InternalError remains uncovered by
>>     code-coverage.
>>
>>     Factoring out the lookup part doesn't work if the target class and/or field is non accessible from the point of the common routine, plus I lose the nice IntelliJ feature of validating the
>>     findVarHandle parameters in the IDE itself.
>>
>>     Would it be possible to have some versions of findVarHandle and co in Java 10+ that don't throw checked exceptions?
>>
>>     (Tools such as Lombok may (eventually) help with hiding the VarHandle setup via annotation, but the generated catch code would still remain uncovered.)
>>
>>     --
>>     Best regards,
>>     David Karnok
>>
>>
>>     _______________________________________________
>>     Concurrency-interest mailing list
>>     [hidden email] <mailto:[hidden email]>
>>     http://cs.oswego.edu/mailman/listinfo/concurrency-interest <http://cs.oswego.edu/mailman/listinfo/concurrency-interest>
>
>     --
>     -Nathan
>
>
>     _______________________________________________
>     Concurrency-interest mailing list
>     [hidden email] <mailto:[hidden email]>
>     http://cs.oswego.edu/mailman/listinfo/concurrency-interest <http://cs.oswego.edu/mailman/listinfo/concurrency-interest>
>
>
>
>
> --
> Best regards,
> David Karnok
>
>
> _______________________________________________
> Concurrency-interest mailing list
> [hidden email]
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: MethodHandles.lookup().findVarHandle alternative not throwing checked exceptions?

Dávid Karnok
Thanks for all the feedback. Indeed, one has to hand MethodHandles.lookup()'s result as well into the utility method because the Lookup gets all the rights to access the package private fields.

public static VarHandle find(MethodHandles.Lookup lookup, Class<?> parent, String field, Class<?> type) {
try {
return lookup.findVarHandle(parent, field, type);
} catch (Throwable ex) {
throw new InternalError(ex);
}
}


2017-08-15 18:25 GMT+02:00 Aaron Grunthal <[hidden email]>:
You could create a MethodHandles.Lookup in the caller and pass it to the utility class. The creation does not throw an exception.

On 15.08.2017 17:40, Dávid Karnok wrote:
> Already mentioned:
>
> Factoring out the lookup part doesn't work if the target class and/or field is non accessible from the point of the common routine
>
> My code is full of package-private classes and fields, so I have to have the helper class in every package or make the classes or fields public.
>
> In addition, I can't use modules in case the library's users don't use it either (assuming it is still true that in order to use a library that is modularized, one has to be modularized itself).
>
>
> 2017-08-15 16:31 GMT+02:00 Nathan and Ila Reynolds <[hidden email] <mailto:[hidden email]>>:
>
>     Until findVarHandle() with unchecked exceptions, how about writing a utility class that has a static findVarHandle(Class<?>, String, Class<?>) with the code you have below?  The initialization
>     code would then be...
>
>     UPSTREAM = VarHandleUtilities.findVarHandle(A.class, "upstream", Flow.Subscription.class);
>
>     -Nathan
>
>
>     On 8/15/2017 8:18 AM, Dávid Karnok wrote:
>>     Hello,
>>
>>     I've been implementing a lot of concurrent code with VarHandles lately and there is a repeated inconvenience of using
>>
>>     MethodHandles.lookup().findVarHandle(...)
>>
>>     because I can't use it to initialize static fields directly but have to use a static initialization block and have try-catch around them:
>>
>>     static {
>>        try {
>>            UPSTREAM = MethodHandles.lookup().findVarHandle(A.class, "upstream", Flow.Subscription.class);
>>        } catch (Throwable ex) {
>>           throw new InternalError(ex);
>>        }
>>     }
>>
>>     Apart from writing the above by hand all the time, there is a slight annoyance that a well parameterized findVarHandle will never throw thus the throw new InternalError remains uncovered by
>>     code-coverage.
>>
>>     Factoring out the lookup part doesn't work if the target class and/or field is non accessible from the point of the common routine, plus I lose the nice IntelliJ feature of validating the
>>     findVarHandle parameters in the IDE itself.
>>
>>     Would it be possible to have some versions of findVarHandle and co in Java 10+ that don't throw checked exceptions?
>>
>>     (Tools such as Lombok may (eventually) help with hiding the VarHandle setup via annotation, but the generated catch code would still remain uncovered.)
>>
>>     --
>>     Best regards,
>>     David Karnok
>>
>>
>>     _______________________________________________
>>     Concurrency-interest mailing list
>>     [hidden email] <mailto:[hidden email]>
>>     http://cs.oswego.edu/mailman/listinfo/concurrency-interest <http://cs.oswego.edu/mailman/listinfo/concurrency-interest>
>
>     --
>     -Nathan
>
>
>     _______________________________________________
>     Concurrency-interest mailing list
>     [hidden email] <mailto:[hidden email]>
>     http://cs.oswego.edu/mailman/listinfo/concurrency-interest <http://cs.oswego.edu/mailman/listinfo/concurrency-interest>
>
>
>
>
> --
> Best regards,
> David Karnok
>
>
> _______________________________________________
> Concurrency-interest mailing list
> [hidden email]
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest



--
Best regards,
David Karnok

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: MethodHandles.lookup().findVarHandle alternative not throwing checked exceptions?

Gregg Wonderly-3
In reply to this post by Aaron Grunthal
It seems that the specific detail is that he is using static VarHandle values and in having to declare them in static {} blocks, is stuck with catching exceptions because there is not a path out of static initializers for checked Exception handling.  Thus, one has to catch them, and then rethrow an unchecked exception to cause the exception to be transferable to the caller.  Thus, the use of an unchecked exception makes more sense in this weird case.  Even using the suggested method, only pastes over the details.  Security/Access exceptions have never been checked exceptions before, and making them checked now, for this one case, seems irregular doesn’t it?  I am not against checked exceptions, but this seems like an odd man out API design that will, in the end, cause a lot of mindless catch->throw logic to be plastered all over code to deal with it.

Gregg


On Aug 17, 2017, at 3:00 PM, Dávid Karnok <[hidden email]> wrote:

Thanks for all the feedback. Indeed, one has to hand MethodHandles.lookup()'s result as well into the utility method because the Lookup gets all the rights to access the package private fields.

public static VarHandle find(MethodHandles.Lookup lookup, Class<?> parent, String field, Class<?> type) {
try {
return lookup.findVarHandle(parent, field, type);
} catch (Throwable ex) {
throw new InternalError(ex);
}
}


2017-08-15 18:25 GMT+02:00 Aaron Grunthal <[hidden email]>:
You could create a MethodHandles.Lookup in the caller and pass it to the utility class. The creation does not throw an exception.

On 15.08.2017 17:40, Dávid Karnok wrote:
> Already mentioned:
>
> Factoring out the lookup part doesn't work if the target class and/or field is non accessible from the point of the common routine
>
> My code is full of package-private classes and fields, so I have to have the helper class in every package or make the classes or fields public.
>
> In addition, I can't use modules in case the library's users don't use it either (assuming it is still true that in order to use a library that is modularized, one has to be modularized itself).
>
>
> 2017-08-15 16:31 GMT+02:00 Nathan and Ila Reynolds <[hidden email] <mailto:[hidden email]>>:
>
>     Until findVarHandle() with unchecked exceptions, how about writing a utility class that has a static findVarHandle(Class<?>, String, Class<?>) with the code you have below?  The initialization
>     code would then be...
>
>     UPSTREAM = VarHandleUtilities.findVarHandle(A.class, "upstream", Flow.Subscription.class);
>
>     -Nathan
>
>
>     On 8/15/2017 8:18 AM, Dávid Karnok wrote:
>>     Hello,
>>
>>     I've been implementing a lot of concurrent code with VarHandles lately and there is a repeated inconvenience of using
>>
>>     MethodHandles.lookup().findVarHandle(...)
>>
>>     because I can't use it to initialize static fields directly but have to use a static initialization block and have try-catch around them:
>>
>>     static {
>>        try {
>>            UPSTREAM = MethodHandles.lookup().findVarHandle(A.class, "upstream", Flow.Subscription.class);
>>        } catch (Throwable ex) {
>>           throw new InternalError(ex);
>>        }
>>     }
>>
>>     Apart from writing the above by hand all the time, there is a slight annoyance that a well parameterized findVarHandle will never throw thus the throw new InternalError remains uncovered by
>>     code-coverage.
>>
>>     Factoring out the lookup part doesn't work if the target class and/or field is non accessible from the point of the common routine, plus I lose the nice IntelliJ feature of validating the
>>     findVarHandle parameters in the IDE itself.
>>
>>     Would it be possible to have some versions of findVarHandle and co in Java 10+ that don't throw checked exceptions?
>>
>>     (Tools such as Lombok may (eventually) help with hiding the VarHandle setup via annotation, but the generated catch code would still remain uncovered.)
>>
>>     --
>>     Best regards,
>>     David Karnok
>>
>>
>>     _______________________________________________
>>     Concurrency-interest mailing list
>>     [hidden email] <mailto:[hidden email]>
>>     http://cs.oswego.edu/mailman/listinfo/concurrency-interest <http://cs.oswego.edu/mailman/listinfo/concurrency-interest>
>
>     --
>     -Nathan
>
>
>     _______________________________________________
>     Concurrency-interest mailing list
>     [hidden email] <mailto:[hidden email]>
>     http://cs.oswego.edu/mailman/listinfo/concurrency-interest <http://cs.oswego.edu/mailman/listinfo/concurrency-interest>
>
>
>
>
> --
> Best regards,
> David Karnok
>
>
> _______________________________________________
> Concurrency-interest mailing list
> [hidden email]
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest



--
Best regards,
David Karnok
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest