KSL: Reflection's orthogonality improvement
Maurizio Cimadamore
maurizio.cimadamore at oracle.com
Mon Oct 12 12:45:21 UTC 2015
Hi,
Note that in general it is not possible to implement reflection checks
statically, simply because the compile time and the runtime views of the
world might be different: so, if all access checking was done at
compile-time, (and the code would be replaced with the member name), you
could have cases where at runtime no access error occurs - in cases
where the member is no longer accessible (i.e. because of separate
compilation).
A different approach would be e.g. to say that we have some syntactic
sugar to create reflective elements. In such a setting lookup,
accessibility check would still occur dynamically - the compiler will
only help you removing the boilerplate. But I'm not sure such a feature
would help much in the BD-like example you posted.
Maurizio
On 12/10/15 11:58, bsrbnd wrote:
> Hi,
>
> Just an idea for the "Kitchen Sink Language".
> I hope this subject hasn't already been discussed and that I haven't missed
> anything in the quite big and complex JLS.
> It's said not to think too much if this is a good or bad idea before
> submitting it for the KSL, but I hope I've thought enough...;-)
> Any comments, ideas or suggestions are welcomed.
> No implementation draft has been done until now, but it could be explored
> if comments are encouraging...
>
> Thanks in advance,
> bsrbnd
>
> Abstract
> --------
> Reflection is designed to access a class member given its name as a String.
> For example:
> MyClass.class.getDeclaredField("field") reflects MyClass.field or
> MyClass.class.getDeclaredMethod("method") reflects MyClass.method()
> But the reciprocal is false, we can't get the "String name" of a class member
> given its identifier.
> This implies a runtime check of the "String name" and an eventual exception
> if the name doesn't match a declared member...
> For this reason, we can say that reflection isn't totally orthogonal.
>
> Reciprocity with qualified strings (to be added to JLS 6.5.6.2,15.8,..?)
> ------------------------------------------------------------------------
> To avoid occasional exceptions (but not runtime checks) and improve reflection's
> orthogonality, I suggest to add the concept of "qualified strings".
> For example:
> MyClass."field" checks at compile-time that "field" is declared on
> MyClass and respects accessibility and visibility rules in a compatible way
> defined by reflection's API. This means that all declared member's names
> (private, protected, public, static or not) but neither inherited nor synthetic
> should be accessible as they are accepted by getDeclaredField() or
> getDeclaredMethod().
> If all compile-checks pass, this expression gives back the name of the
> member as a String.
>
> Grammar update (JLS 15.8)
> -------------------------
> I suggest to add the following line in "PrimaryNoNewArray" rule of the grammar:
>
> PrimaryNoNewArray:
> TypeName . " Identifier "
>
> A simple databases example using "qualified strings"
> ----------------------------------------------------
> In the following example, "qualified strings" ensure that valid member's names
> are used in SQL requests to be correctly used by reflection to store back
> the result of the request:
>
> class MyTable {
> public static final String name=MyTable.class.getSimpleName().toLowerCase();
> public Integer id;
> public Integer value;
> }
> MyTable line = new MyTable();
>
> String request =
> "SELECT " + MyTable."value" + " FROM " + MyTable.name +
> " WHERE " + MyTable."id" + "=" + line.id
>
> String valueColumn = resultset.getMetaData().getColumnName(1);
> Field f = MyTable.class.getDeclaredField(valueColumn.toLowerCase());
> f.set(line, resultSet.getInt(valueColumn));
>
> Conclusion
> ----------
> The usefulness of "qualified strings" isn't limited to this simple
> database example.
> It extends to every context where it is necessary to get informations
> from external parties and store back results dynamically in objects
> through reflection.
More information about the compiler-dev
mailing list