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. > 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. > >> >> Chris > > 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
