Am 05.01.2013 21:03, schrieb Remi Forax: > On 01/05/2013 07:53 PM, Noctarius wrote: >> Am 05.01.2013 19:41, schrieb Remi Forax: >>> On 01/05/2013 07:37 PM, Noctarius wrote: >>>> Am 05.01.2013 19:15, schrieb BGB: >>>>> On 1/5/2013 10:17 AM, Noctarius wrote: >>>>>> Ok I took some time to make a deeper introduction in >>>>>> what I imagine to do: >>>>>> https://www.sourceprojects.org/default/2013/01/05/1357395720000.html >>>>>> >>>>>> >>>>>> >>>> >>>>>> As mentioned before it would be great if someone is interested in >>>>>> the topic and wants to help. >>>>> well, I guess this forum is more for JVM level stuff, >>>>> whereas all this is more a Java compiler level feature, >>>>> but oh well... >>>>> >>>> But this feature would need JVM level support to make old >>>> code working. That's the most important feature from my >>>> point of view - you can just make the old public field a >>>> property and old external code does not needs to be >>>> recompiled. One idea would be to relocate the xload >>>> bytecode to the property accessor (maybe there would be a >>>> better way). >>> There is a better way, the load should be an invokedynamic >>> so it can be wired to a getter or a field access depending >>> on the implementation. >> By "relocate the xload bytecode" i meant to exchange it with >> an invokedynamic call just on loadtime of a class. The idea >> would be to flag the members of type property and exchange >> them. I want to prevent recompile of depending code. > > You can do that with 'invokedynamic' and not at load time but > the first time the instruction is called, note the name is > invokedynamic and not invokevirtual.
But that needs to be backed in the bytecode. See the other answer below. >> >>> Now, the real question is what problem do you want to solve >>> exactly ? >> As I've written in the blog article is to unify the access >> to members. As an addition you'll get some kind of syntactic >> sugar which prevents you from writing all that getter / >> setter stuff (yeah I know Eclipse / IntelliJ / ... can >> generate them for you) but the main reason is to have a >> possibility to "update" and strongen old codebasis without >> breaking compatibility - quite similar to the idea of the >> virtual extension methods. > > I think I prefer a more general mechanism that ask javac to > replace all access to fields (or methods) for a given class, > insert an invokedynamic instead and let you specifies the > bootstrap method in Java code. > > With that, you have properties, proxy, interceptor, AOP, and > with a little effort method_not_found. Yeah I totally agree but I'm not sure if you should break the backward compatibility that extremely. Your the guys with more experience in bringing new features to Java so I would rely on your opinion in case of this. > Rémi > > _______________________________________________ mlvm-dev > mailing list mlvm-dev@openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
