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 Mon, 17 Aug 2015 18:21:55 GMT
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 <markro@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:sebbaz@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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message