Marcel Hlopko <marcel.hlopko@gmail.com> [Sun, 13 Oct 2013 14:54:32 +0200] rev 2827
move resolveForVersion moved to JavaClassRef2
Marcel Hlopko <marcel.hlopko@gmail.com> [Sun, 13 Oct 2013 12:31:42 +0200] rev 2826
jv please revide, I probably broke something and this only fixes a symptom.
I did small tweaking in jinterpret.c. After the changes, this error
appeared (contents was ST string, not Java string).
Marcel Hlopko <marcel.hlopko@gmail.com> [Sun, 13 Oct 2013 12:04:03 +0200] rev 2825
experimenting with fieldRef resolving for particular class version
Marcel Hlopko <marcel.hlopko@gmail.com> [Sat, 12 Oct 2013 21:52:51 +0200] rev 2824
rename reresolveForVersion to resolveForVersion
Marcel Hlopko <marcel.hlopko@gmail.com> [Sat, 12 Oct 2013 21:03:21 +0200] rev 2823
temporarily ignore type inconsistencies on return values
no exception is thrown when reloaded method returns
something type-incompatible
Marcel Hlopko <marcel.hlopko@gmail.com> [Sat, 12 Oct 2013 21:01:01 +0200] rev 2822
do not migrate instances when type of the field is generalized
e.g. changing field type from String to Object is OK, all existing
instances are still valid.
Marcel Hlopko <marcel.hlopko@gmail.com> [Sat, 12 Oct 2013 18:13:33 +0200] rev 2821
fix stupid test and voila - hierarchy tests passing :)
I changed field type from int to Integer. With int, compiler
generated INVOKESTATIC Integer.valueOf instr, which caused
the method to return 0 instead of "foo" (because Integer.valueOf("foo")
is 0) With Integer, everything works as expected.
Marcel Hlopko <marcel.hlopko@gmail.com> [Sat, 12 Oct 2013 18:10:18 +0200] rev 2820
small cleanup
Marcel Hlopko <marcel.hlopko@gmail.com> [Sat, 12 Oct 2013 15:53:06 +0200] rev 2819
add JavaFieldRef>>reresolveForVersion: javaClass
which is called by the VM when there are multiple
class versions and we must ensure we use correct
version for field resolving
Marcel Hlopko <marcel.hlopko@gmail.com> [Thu, 10 Oct 2013 16:53:51 +0200] rev 2818
add blank requestRecompile & requestReload methods