On 16 August 2015 at 13:00, sebb <seb...@gmail.com> wrote: > 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
Ignore that - Branches refer to Instruction Handles not relative offsets as I had assumed. > Maybe the solution to this is to make the classfile.* classes fully > mutable, but make the generic.* classes immutable? I think it's still an error to change certain aspects of an Instruction class. For example, the opcode and length are fixed for a particular instruction type. >> 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
