2014-09-14 17:42 GMT+04:00 sebb <seb...@gmail.com>: > It seems that Tomcat's version of BCEL is diverging significantly from > Commons BCEL. > > Is there any mileage in trying to re-organise Commons BCEL so it is > more easily usable by Tomcat? > > For example, I gather that Tomcat only uses a small portion of Commons BCEL. > Maybe the Commons code could be divided in some way to reflect this need? > There are probably other projects that just need the read-only parts of BCEL. >
Tomcat needs only * super class name * interfaces class names * class-level annotations (RuntimeVisibleAnnotations attibute) All the rest are not needed and have been removed. (See how methods in ClassParser skip over sections of class file). In theory, other libraries may want the same and I think it boils down to an alternate ClassParser that has the same skip-over behaviour. (In theory, there might be other intermediate states between such short and full scanning. If one were to selectively configure a ClassParser, I think that there is a) whether (field+method) information is needed b) what class Attributes to parse. There are a lot of those (23 in Java 8) and most are of no interest. In that case, what would be a use case? If class is already loaded by classloader it would be better to just ask JVM via reflection. There is no need to parse the class file in that case). Possible simple optimizations at this step: a) Stop reading class attributes once "RuntimeVisibleAnnotations" has been read. It can occur at most once. (As most classes do not have such attribute, I do not expect much gain here). b) Do not look for attributes at all (i.e. we may stop reading early) is class file version is old and does not support annotations. (I do not expect any gain here, as I think majority of libraries are compiled with up-to-date java). The next hurdle is reading and maintaining ConstantPool. Only minority of those constants are referenced in those structures that we read. So a) Maybe there is some further way to optimize constant pool parsing. Mark has already removed many constant types that we do not need. One constant type that remains is ConstantUtf8. I wonder whether there will be some gain in delaying byte[] -> String conversion for UTF-8 data, and what methods there are for that. (The methods that I know about are DataInputStream.readUTF8() and static method DataInputStream.readUTF8(DataInput)). b) JavaClass and other structure classes have a reference to ConstantPool. As most information in the pool is not needed, it would be better to not keep it in memory for too long. I think we are already OK here, as JavaClass object and its data structures are not cached by Tomcat but released after scanning. As constant pool indexes are not the information that the caller needs here, I modified JavaClass in http://svn.apache.org/viewvc?view=revision&revision=r1624636 http://svn.apache.org/viewvc?view=revision&revision=r1624642 There might be the same change for internal structures of AnnotationEntry class, but there is really no point, as Tomcat does not cache them. Best regards, Konstantin Kolinko --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
