Constructing records through reflection and module restrictions

[Florian Weimer]

* Brian Goetz:

> There is a better approach than passing around the Lookup (which 
> requires everyone to coordinate around the Lookup capability): use open 
> modules.  THe concept of "open module" was designed for exactly this 
> purpose: to allow packages to be "exported for reflection" so that 
> frameworks can reflect over them more liberally than bytecode linkage 
> would permit.  If you put your domain objects in a package that is 
> opened (either to the framework, or to everyone), no need to play games 
> with Lookup.

Open modules still require non-local types, increasing syntactic
overhead considerably.  My example

> On 12/8/2024 11:52 AM, Florian Weimer wrote:
>> * Remi Forax:
>>
>>>> Syntax-wise, it is very tempting to use this with very localized
>>>> record types for various kinds of custom deserialization scenarios.
>>>> For example, to read a CSV file with two colums, something like this
>>>> could be used:
>>>>
>>>>             record Row(String name, int index) {}
>>>>             var csv = CSVReader.newReader(r, Row.class);
>>>>             while (true) {
>>>>                 var row = csv.readRow();
>>>>                 if (row == null)
>>>>                     break;
>>>>                 // Use the row variable.
>>>>                 ...
>>>>             }

was not exactly intended as shorthand notation (in the way in-line
import directives are sometimes used in examples).  I meant it quite
literally, with actual local types.  The record type syntax is so
lightweight that it makes such code reasonable to write, I think.

By the way, I find it confusing that MethodHandles.publicLookup()
produces a method handle that can access open modules, while
MethodHandles.lookup() does not.  But maybe that's a bug in the way I
configure the launcher.