I'm interested in understanding where Java language support is going for
InvokeDynamic. The context is that I'd like to replace a system that
forward-generates API with a system based on InvokeDynamic. Silly
hypothetical example follows:
// colors.prop
color1: Red
color2: Green
preprocessor < colors.prop > Colors.java
// generated API
class Colors {
Color color1() { return Color.red; }
Color color2() { return Color.green; }
}
You get the benefits of static analysis (type-errors, code-completion, etc),
but you have messy pre-processing / multi-staged compilation to deal with.
One possible example of what I'd like to be able to do:
Dynamic colors = ColorFactory.create("colors.prop");
Color red = colors.color1();
Color green = colors.color2();
With the right tooling support, I think I could provide the same kinds of
static analysis benefits without the messiness of the preprocessor. I don't
know a ton about C#, but I believe that this looks fairly achievable with
the "dynamic" type.
I've already read through the coin
proposal<http://wikis.sun.com/display/mlvm/InterfaceDynamic> and
InterfaceDynamic <http://wikis.sun.com/display/mlvm/InterfaceDynamic>. My
understanding is that there is no language support at all for JDK 7
(correct?), but I've been playing around with the jdk7 compiler which does
support the InvokeDynamic static call syntax. Unlike C#'s dynamic, it seems
like there are a lot of barriers to making the above syntax work with (the
proposed) Java language support. Examples I ran into with a couple of hours
of playing:
1) You have to apply @BootstrapMethod to every class.
2) InvokeDynamic invocations are static.
3) InvokeDynamic calls all throw Throwable.
These are all deal breakers when it comes to users using InvokeDynamic
directly. Essentially, the current picture I'm seeing is that the planned
language support isn't useful at all in API, as compared to implementation
for alternate language runtimes. I realize that's the primary usecase, but
it feels like we're missing out on a lot that invokedynamic could do for us.
Are there any plans to provide anything in that direction?
_______________________________________________
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
