OK, I see. I guess I need to revert all those changes. I had hoped to make as much as possible immutable, and hide all mutable fields, but this looks to be impossible with the current design.
I'm beginning to wonder if we should try to revert to being binary-compatible with the previous version. Although the Clirr report showed some errors, Clirr does not distinguish between binary and source compatibility. As it happens, adding methods to an Interface is binary-compatible [1] Of course it will break source compatibility if the Visitor interface is implemented directly; though not if the EmptyVisitor class is extended instead. The downside of remaining binary compatible is that some useful fixes cannot be implemented. Once I have reverted the setters/non-private mutable fields we can see what breaking changes remain. It will then be a trade-off to see whether it is worth reverting the other fixes to restore compatibilty, or whether we really do need to break the API in places. [1] https://docs.oracle.com/javase/specs/jls/se7/html/jls-13.html#jls-13.5.3-100 On 17 August 2015 at 16:37, Mark Roberts <mar...@cs.washington.edu> wrote: > That's a little tricky to answer. As one example, look at > generic/LocalVariableInstruction. Neither the index or opcode is final. A > user needs to be able to insert new local variables and hence they need to be > able to modify the local variable offset (index). And 'beneath the covers' > BCEL will modify the opcode if the index changes from one side of the single > byte opcode to the other. E.g., it will change an 'aload_<n>' to an 'aload'; > thus changing both the opcode and the length of the instruction. > > As a general rule, you might try to say you can only replace an instruction > rather than modify it. Personally, I think that is too restrictive. > > > -----Original Message----- > From: sebb [mailto:seb...@gmail.com] > Sent: Sunday, August 16, 2015 5:17 AM > To: Commons Developers List > Subject: Re: BCEL design goals? (was RE: [jira] [Commented] (BCEL-233) The > access_flags field in AccessFlags class should be final) > > 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. > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
