Well, first: i disagree "advanced field resolution" to be default for GETFIELD/PUTFIELD or for existing InstructionFactory field access facilities.
The solution you sent is really good, and moderately fast on runtime. But the problem for me is that one must keep most of his classes in consistent state almost all the time - at least enough consistent to enable superclass resolution and field finding. Wich is inaccessible for me.
Fair enough
At the bare minimum, there needs to be a FAQ for some really common mistakes like I made. The difference between static and regular access is important--however the validation and verification tools didn't lead me in the right direction. I had to use a combination of JustIce and javap to get my stuff working--even then I had to piece things together.
FAQ Entries:
Q: Why does the classloader complain about "Invalid getter or setter"?
A: You are probably accessing a field with the wrong access type. There are two bytecodes, one to get a static field and one to get a regular field (GETSTATIC and GETFIELD respectively). Make sure you are using the proper access type.
Q: Why does the classloader complain about a field not being accessible? It's a protected member of a superclass!
A: You are probably trying to resolve against the class you are generating. Make sure you specify the classname that declares the field. For example, if you have a base class named AbstractXMLSource with a protected member named "m_contentHandler", then your generated class must access "m_contentHandler" using "AbstractXMLSource" as the class name.
Q: Why does the classloader complain about not being able to pop
a variable off the stack?A: Don't forget to load the object that you are going to execute a
method on. You must first load the object, then all the parameters,
and then you can call the method.Those were the two biggest problems I had.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
