[concurrency-interest] MethodHandles.lookup().findVarHandle alternative not throwing checked exceptions?

Aaron Grunthal aaron.grunthal at infinite-source.de
Tue Aug 15 12:25:56 EDT 2017


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 <nathanila at gmail.com <mailto:nathanila at gmail.com>>:
> 
>     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
>>     Concurrency-interest at cs.oswego.edu <mailto:Concurrency-interest at cs.oswego.edu>
>>     http://cs.oswego.edu/mailman/listinfo/concurrency-interest <http://cs.oswego.edu/mailman/listinfo/concurrency-interest>
> 
>     -- 
>     -Nathan
> 
> 
>     _______________________________________________
>     Concurrency-interest mailing list
>     Concurrency-interest at cs.oswego.edu <mailto:Concurrency-interest at cs.oswego.edu>
>     http://cs.oswego.edu/mailman/listinfo/concurrency-interest <http://cs.oswego.edu/mailman/listinfo/concurrency-interest>
> 
> 
> 
> 
> -- 
> Best regards,
> David Karnok
> 
> 
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
> 



More information about the Concurrency-interest mailing list