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

Dávid Karnok akarnokd at gmail.com
Tue Aug 15 11:40:35 EDT 2017


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>:

> 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 listConcurrency-interest at cs.oswego.eduhttp://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
>
> --
> -Nathan
>
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
>


-- 
Best regards,
David Karnok
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20170815/ea3e1cf5/attachment.html>


More information about the Concurrency-interest mailing list