-
Notifications
You must be signed in to change notification settings - Fork 17
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
support inner classes in inline-java #89
Comments
SGTM. |
I do wonder though, is it really such a cost to just assume that dollar signs always refer to inner classes? I know that technically the user is allowed to call his/her classes |
Furthermore, the Java Language Specification says this:
https://docs.oracle.com/javase/specs/jls/se8/html/jls-3.html#jls-3.8 |
We can ask the user to not use We could consider adding some escape syntax instead. So |
That's easy enough to work around (with class aliases), and if we are to take the JLS on face value, entirely a theoretical problem (i.e. only applicable for very old legacy code). And yes, we could introduce an escaping mechanism for legacy names, but I'd wait to see whether someone needs that. At least this way, the default (i.e. when we're not dealing with legacy names) is the unsurprising case, and the user only needs to do something special when dealing with legacy things (that may well mean never in this day age, but I'm not a Java old timer). |
Regarding (2), we can do better than checking A.B.C.class.getName().equals("A.B$C") We write This test can be performed at runtime by inserting it in static blocks in the generated classes, or it can be done at build time in a few ways. The simplest way I found to do it at build time is to call I propose that we start with the simple approach to check it at build time. If 80 ms turns out to be too expensive, we either do it at runtime or consider javac hooks. The main advantage of this approach is that we get better error messages. The user does not have to spend time figuring out the cause of a |
This turned out to complicate the plugin more than what a sparingly-used feature would deserve. We can revisit this if inner classes are used more than we anticipate. The patches that we tried before are here. |
Currently inline-java fails with a runtime error when trying to marshal an object of an inner class.
produces
There are two problems with this behavior.
To fix (1) we can have the user be explicit in that
Thread.State
is an inner class. He could do so by writing instead:using
:
as a separator of the inner class. We can't use$
as a separator because$
is a valid character in Java identifiers.To fix (2), the plugin could call javap on the generated bytecode and check that the signature of the methods
inline__method_i
are as expected. Thus, typing.
instead of:
would be caught at build time.The text was updated successfully, but these errors were encountered: