On 15 August 2015 at 03:53, Gary Gregory <garydgreg...@gmail.com> wrote: > On Fri, Aug 14, 2015 at 3:55 PM, Mark Roberts <mar...@cs.washington.edu> > wrote: > >> I hope this doesn't come across as too strident, but working towards a >> resolution of this particular issue has got me thinking about how I use >> BCEL - and this seems like a good time/place to clarify my understanding of >> BCEL's purpose. >> Simply stated, it is my belief that a client should be able to read and/or >> write any member, field, flag, or what have you in a .class file. >> > > Sounds reasonable. You should be able to fiddle with anything in a .class > file. Perhaps even shooting yourself in the foot ;-)
Sorry, I overlooked this important use case. I had assumed that the BCEL classes would be used to represent an existing class file or be used to create a new classfile. In such cases they could be made immutable. However, that does not allow for easily modifying existing classes. [It would still be possible, but would require creating new instances] Now I think there are still some classes which should not be mutable once created. For example, Instruction is the super-class for IADD; it does not make sense to modify an IADD once created. I'm not sure about other Instruction classes either - although BRANCH instructions make have multiple distinct instances, should they be mutable? If so, then I suspect the InstructionList should not be allowed to share any mutable Instructions. Otherwise updating one GOTO may accidentally update other unrelated GOTOs that happen to have the same offset Maybe the solution to this is to make the classfile.* classes fully mutable, but make the generic.* classes immutable? > Gary > >> >> Is that assuming too much? Are there any intentional restrictions? >> >> Thanks, >> Mark >> >> >> -----Original Message----- >> From: Sebb (JIRA) [mailto:j...@apache.org] >> Sent: Friday, August 14, 2015 3:30 PM >> To: mar...@cs.washington.edu >> Subject: [jira] [Commented] (BCEL-233) The access_flags field in >> AccessFlags class should be final >> >> >> [ >> https://issues.apache.org/jira/browse/BCEL-233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14697872#comment-14697872 >> ] >> >> Sebb commented on BCEL-233: >> --------------------------- >> >> OK, have you got any sample code that could be used as test cases? >> >> > The access_flags field in AccessFlags class should be final >> > ----------------------------------------------------------- >> > >> > Key: BCEL-233 >> > URL: https://issues.apache.org/jira/browse/BCEL-233 >> > Project: Commons BCEL >> > Issue Type: Improvement >> > Reporter: Sebb >> > Fix For: 6.0 >> > >> > >> > The access_flags field in the AccessFlags class should be final. >> > It is currently not set by any other classes outside their constructors. >> > The public setters - e.g. isPrivate(boolean) - are not used and should >> be deleted. [Apart from that, their names are really confusing.] >> >> >> >> -- >> This message was sent by Atlassian JIRA >> (v6.3.4#6332) >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> > > > -- > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org > Java Persistence with Hibernate, Second Edition > <http://www.manning.com/bauer3/> > JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> > Spring Batch in Action <http://www.manning.com/templier/> > Blog: http://garygregory.wordpress.com > Home: http://garygregory.com/ > Tweet! http://twitter.com/GaryGregory --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
