An experimental assertion library based on code-reflections project

[Paul Sandoz]

Thanks, this is good feedback, I agree with Maurizio’s responses.

We shall investigate further, but also you are more than welcome if you want to contribute directly with PRs. 

Paul.

> On Jul 22, 2024, at 2:15 AM, Maurizio Cimadamore <maurizio.cimadamore at oracle.com> wrote:
> 
> 
> 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
> 
>