I am using the new annotation support in the BCEL trunk to write a utility for processing custom annotations. This required extending the Annotations and AnnotationEntry classes, and the subclasses I created needed to access the fields in the superclasses. Unfortunately, this wasn't possible because these fields have private access. They should instead have protected access.
Created attachment 19614 [details] Simple patch that makes the private fields protected
Just as a general note, protected fields should be used with caution as they have significant implications for binary compatibility; once added they become part of the "public api" of the class and cannot be changed without potentially breaking existing code. Where possible, protected accessor methods are better than allowing direct access to protected fields. Note, however, that I haven't reviewed this patch to determine what the best solution is for this particular case.
I think accessor methods might also work in my case, but I would prefer protected members (possibly in addition to accessors) because it offers the most flexibility and control. And yes, field access rights raise compatibility issues, which is why I hope this bug can be resolved before the annotation support in BCEL migrates from the trunk to an official release. In any case, something must be changed, otherwise it will be impossible for users to extend BCEL's annotation support.
Could you elaborate why you have to extend them?
I need to extend them in order to tell BCEL how to process non-standard annotations. Currently BCEL is hard-coded for the existing annotation names: RuntimeInvisibleAnnotations, RuntimeInvisibleAnnotations, RuntimeInvisibleParameterAnnotations, and RuntimeVisibleParameterAnnotations. However, with the JSR-308 proposal, new annotation names are likely on the way: RuntimeInvisibleTypeAnnotations/RuntimeVisibleTypeAnnotations and (possibly) RuntimeInvisibleStatementAnnotations/RuntimeVisibleStatementAnnotations. Now, I'd like to use BCEL to parse and display these new annotation types. In fact, I've already written such a utility here: http://volta.svn.sourceforge.net/viewvc/volta/util/dump-annotations/ However, the utility can't work with the current BCEL trunk because the Annotations and AnnotationEntry classes have private inaccessible fields. This makes extending those classes in any meaningful way impossible. But if I simply modify BCEL so that those fields are exposed to subclasses, then my utility works perfectly.
So, is this patch acceptable for inclusion in the trunk, or does it need more work? Should I rewrite it to use accessor methods instead of protected fields?
Can someone please review this patch? It's a very simple fix. If you like, I can submit another one that uses accessor methods instead of protected fields.
I found another example of why this bug needs to be fixed: http://forum.java.sun.com/thread.jspa?threadID=775449 Note that Mathias has created two entirely new types of annotations (RuntimeVisibleLocalVariableAnnotations and RuntimeInvisibleLocalVariableAnnotations). Naturally, one might want to use BCEL to read these annotations from a class file, but that's currently impossible. Unless this bug is fixed, BCEL is effectively hard-coded for the standard annotation names.
public int getTypeIndex() { return type_index; } public ConstantPool getConstantPool() { return constant_pool; } public boolean isRuntimeVisible() { return isRuntimeVisible; } Expose the variables now. In Annotations they are already available and you can even set the annotation table. Should fix your problems. Please re-open if that's not enough.