commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: BCEL design goals? (was RE: [jira] [Commented] (BCEL-233) The access_flags field in AccessFlags class should be final)
Date Sun, 16 Aug 2015 12:00:46 GMT
On 15 August 2015 at 03:53, Gary Gregory <garydgregory@gmail.com> wrote:
> On Fri, Aug 14, 2015 at 3:55 PM, Mark Roberts <markro@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:jira@apache.org]
>> Sent: Friday, August 14, 2015 3:30 PM
>> To: markro@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-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message