An experimental assertion library based on code-reflections project

[Maurizio Cimadamore]

On 20/07/2024 11:36, Tagir Valeev wrote:
> Hello, Paul!
>
> Thank you for your response!
>
> So far, I have had a few problems with API, though probably I'm just 
> missing something.
> 1. NewOp does not provide a direct way to resolve a constructor. For 
> InvokeOp, one can use op.invokeDescriptor().resolveToHandle(lookup), 
> but creating an instance having a NewOp in hands is more tricky. I do 
> it like this
>
>           Class<?>[] argTypes = 
> newOp.constructorType().parameterTypes().stream()
>                   .map(this::toClass).toArray(Class[]::new);
>           Class<?> objType = toClass(newOp.type());
>           Object result = 
> objType.getConstructor(argTypes).newInstance(arguments.toArray());
>
> (where toClass is a helper method to get a class from the type). I 
> feel that there should be a simple method to resolve to a Constructor 
> or a MethodHandle.
In javac, an instance creation expression tree has both a symbolic 
reference to the constructor being used and an instantiated type. 
`NewOp` only has the latter, which is, I think, what you are rubbing up 
against. I agree that this should be fixed.
>
> 2. The initialized array creation like `int[] data = {1,2,3,4,5}` is 
> somewhat tricky to decompile. It has a block operand, which contains 
> an imperative sequence of constant loads and array stores. Probably 
> some kind of extended op should be provided for this, which is closer 
> to Java source and can be lowered?
Good idea.
>
> 3. I've noticed that the code model for new int['a'] does not add a 
> ConvOp and directly passes the char value 'a' as the argument to 
> NewOp. I feel that it's unexpected: NewOp should always take int as an 
> array dimension, so there should be a char-to-int conversion step. Am 
> I wrong?
Yes, there should be a conversion - probably some missing call to 
`toValue` in ReflectMethods... we'll check.
>
> 4. It's probably expected but I cannot call private methods and access 
> private fields at the Quotable lambda callsite. For this, I need a 
> callsite Lookup object. It would be inconvenient to pass a lookup 
> object every time together with lambda. Would it be possible to have 
> some kind of BlessedQuotable extends Quotable, which aside from 
> quoted(), also provides a callsite lookup? I think if we call a method 
> that accepts a quotable lambda, we already trust that method quite 
> much. It looks not very useful if that method can detect that we refer 
> to a private field from the lambda, but it cannot read that private 
> field. Sorry if I'm missing something.

That's a good point - for "regular" lambdas, the indy machinery will 
pass up a lookup from the caller, which can then be used by the BSM. But 
if the lambda is quotable, such lookup is lost after the quotable 
instance is created, even though client code might still need it (e.g. 
to resolve members inside the quotable lambda body).

Maurizio