Re: [patch] FieldOrMethod.java, added two convenience methods

Hello Neeme,

> Ok, sorry for that, I managed to miss that for some reason.
> So, following your proposal, the new methods would be:
> Method.java:
> * Type getReturnType()
> * Type[] getArgumentTypes()
> Field.java:
> * Type getType()
>
> (patches attached)

Yes, that looks way better.

> > Look at the "FieldOrMethod" in the "generic" package;
> > there's all of the above, done in the way I'd suppose.
>
> Well, I had a look there, but as far as I have understood, generic
> package purpose is for generating classes, not for inspecting them.
> And, I didn't really find the thing you mention... there is:
> FieldOrMethod.java
> FieldInstruction.java
> MethodGen.java
> MethodObserver.java

The generic.FieldOrMethod class has FieldInstruction, InvokeInstruction as
subclasses which have that getXXXType[s]() methods mentioned above.
FieldOrMethod is quite a misnomer here, FieldOrInvokeInstruction would
describe the purpose of that class better.

> All of those are geared towards generating classes, not for inspecting
> them, no?

Well, yes. But on the other hand, if you'd like to inspect CODE you'd also
need the generic package. Also, you *can* use the generic package to
inspect classes-- it however may not be the most performant choice.

> What I need is an API that fulfils the same need as java reflection API
> but has the same types as BCEL uses. This would make it easier to
> inspect a class and then generate a new class based on the inspected
> class...

So adding Type info to the classfile is not really a bad idea. Maybe in
the long run, one should merge the packages anyway since "only"
performance reasons could be used to hold that artificial border.

Regards,
Enver