Re: svn commit: r153332 -jakarta/bcel/trunk/src/java/org/apache/bcel/verifier/structurals/OperandStack.java

[Dave Brosius <db...@qis.net>]

Thanks for the reminder, and certainly agree with the principle.. It seemed 
to me that size() being a 'const' and 'primal' method is safe to expose, as 
no matter what kind of stack you have, it's going to have a size.
If folks feel different, i'd be glad to revert.

.
----- Original Message ----- 
From: "Simon Kitching" <sk...@apache.org>
To: "BCEL Developers List" <bc...@jakarta.apache.org>
Sent: Thursday, February 10, 2005 10:43 PM
Subject: Re: svn commit: 
r153332 -jakarta/bcel/trunk/src/java/org/apache/bcel/verifier/structurals/OperandStack.java


> On Fri, 2005-02-11 at 03:17 +0000, dbrosius@apache.org wrote:
>> Author: dbrosius
>> Date: Thu Feb 10 19:17:49 2005
>> New Revision: 153332
>>
>> URL: http://svn.apache.org/viewcvs?view=rev&rev=153332
>> Log:
>> Apply Patch 27646 from Stephan Michels to change method 
>> OperandStack.size() to be public
>
> Hi Dave,
>
> I'm sure you're well aware of this, and that this email is not necesary.
> But I have to earn my keep as BCEL list member :-)
>
> Once some method/variable/class/whatever has been made "public" or
> "protected", it then takes a major version change to get rid of it
> again, as it is generally frowned upon to break user code in a minor
> version release.
>
> And having too much stuff public can make it difficult sometimes to
> introduce new optimisations or even to fix bugs.
>
> If it really makes logical sense for the OperandStack to be public, then
> fine. I just wanted to remind you of the "backwards compatibility"
> burden that is associated with promoting something from internal
> (package or private) to external (public or protected) visibility.
>
> Cheers,
>
> Simon
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: bcel-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: bcel-dev-help@jakarta.apache.org
>
> 



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

Re: BCEL release strategies

[Simon Kitching <sk...@apache.org>]

On Tue, 2005-02-15 at 00:23 +0100, Torsten Curdt wrote:
> >>> Yes, I'd like to start committing new Annotation parsing code.
> >>> Problem is,
> >>> of course, is if clients out there were using the Unknown attribute
> >>> to gain
> >>> access to annotations, adding in true Annotation support will cause
> >>> their
> >>> code to fail, as Annotations will no longer be Unknown. Things will
> >>> still
> >>> compile as is, just not run as expected.
> >>>
> >>
> >> Have you considered adding a new method for accessing annotations?
> >>
> >> Code calling the old method would get "Unknown" nodes returned, and new
> >> code would get the real Annotations. And the old method could be marked
> >> as deprecated.
> >>
> >> Regards,
> >>
> >> Simon
> >
> >
> > Yes, we could create Visitor15 interfaces, et. al. But then
> 
> *puke* ;)

How about defining a "marker" interface "Visitor15", ie one that has no
methods on it? 

Code invoking the visitor interface can then have
  if (visitor instanceof Visitor15) {  
    // pass Attribute
  } else {  
    // pass Unknown
  }

Yes, it's a little warty. But it has minimal impact on user code, and
minimal impact on BCEL code.

And if there is a reason to expand the visitor interface later with
additional methods (rather than changing the semantics of the current
API, as this does) then the new interface can define the new API.

The alternative is to move to a BCEL 2.x series. But that means two
branches to maintain, and as is painfully obvious, BCEL doesn't have a
whole lot of developer time available...

BTW, I'm commenting here only from the info in the emails; I haven't yet
had time to actually read the BCEL code + patches. So sorry if I'm not
on the right track here. Anyone know where to get 40 hour days??

Regards,

Simon


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

Re: BCEL release strategies

[Torsten Curdt <tc...@apache.org>]

>>> Yes, I'd like to start committing new Annotation parsing code.
>>> Problem is,
>>> of course, is if clients out there were using the Unknown attribute
>>> to gain
>>> access to annotations, adding in true Annotation support will cause
>>> their
>>> code to fail, as Annotations will no longer be Unknown. Things will
>>> still
>>> compile as is, just not run as expected.
>>>
>>
>> Have you considered adding a new method for accessing annotations?
>>
>> Code calling the old method would get "Unknown" nodes returned, and new
>> code would get the real Annotations. And the old method could be marked
>> as deprecated.
>>
>> Regards,
>>
>> Simon
>
>
> Yes, we could create Visitor15 interfaces, et. al. But then

*puke* ;)

> we live with that mess forever.
> I'm game for whatever folks agree on, though.

Well ...I'd say let's keep a maintenance branch for
a while (which is backwards compatible) but let's not
restrict ourselves on trunk.

WDYT?

cheers
--
Torsten

Re: BCEL release strategies

[Dave Brosius <db...@qis.net>]

> On Sat, 2005-02-12 at 00:33 -0500, Dave Brosius wrote:
>> >>I mean we are on trunk anyway... btw: maybe it would be
>> >>good to talk about release strategies for bcel.
>>
>> >>cheers
>> >>--
>> >>Torsten
>>
>>
>> Yes, I'd like to start committing new Annotation parsing code. Problem 
>> is,
>> of course, is if clients out there were using the Unknown attribute to 
>> gain
>> access to annotations, adding in true Annotation support will cause their
>> code to fail, as Annotations will no longer be Unknown. Things will still
>> compile as is, just not run as expected.
>>
>
> Have you considered adding a new method for accessing annotations?
>
> Code calling the old method would get "Unknown" nodes returned, and new
> code would get the real Annotations. And the old method could be marked
> as deprecated.
>
> Regards,
>
> Simon

Yes, we could create Visitor15 interfaces, et. al. But then we live with 
that mess forever.
I'm game for whatever folks agree on, though.




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

Re: BCEL release strategies

[Simon Kitching <sk...@apache.org>]

On Sat, 2005-02-12 at 00:33 -0500, Dave Brosius wrote:
> >>I mean we are on trunk anyway... btw: maybe it would be
> >>good to talk about release strategies for bcel.
> 
> >>cheers
> >>--
> >>Torsten
> 
> 
> Yes, I'd like to start committing new Annotation parsing code. Problem is, 
> of course, is if clients out there were using the Unknown attribute to gain 
> access to annotations, adding in true Annotation support will cause their 
> code to fail, as Annotations will no longer be Unknown. Things will still 
> compile as is, just not run as expected.
> 

Have you considered adding a new method for accessing annotations?

Code calling the old method would get "Unknown" nodes returned, and new
code would get the real Annotations. And the old method could be marked
as deprecated.

Regards,

Simon


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

BCEL release strategies

[Dave Brosius <db...@qis.net>]

>>I mean we are on trunk anyway... btw: maybe it would be
>>good to talk about release strategies for bcel.

>>cheers
>>--
>>Torsten


Yes, I'd like to start committing new Annotation parsing code. Problem is, 
of course, is if clients out there were using the Unknown attribute to gain 
access to annotations, adding in true Annotation support will cause their 
code to fail, as Annotations will no longer be Unknown. Things will still 
compile as is, just not run as expected.






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

Re: svn commit: r153332 -jakarta/bcel/trunk/src/java/org/apache/bcel/verifier/structurals/OperandStack.java

[Torsten Curdt <tc...@apache.org>]

> Thanks for the reminder, and certainly agree with the principle.. It
> seemed to me that size() being a 'const' and 'primal' method is safe to
> expose, as no matter what kind of stack you have, it's going to have a
> size.
> If folks feel different, i'd be glad to revert.

No, please don't.

The patches from Stephan are the ones that we needed for
javaflow. IIRC he forked some of the code because noone
was actually applying patches to bcel at all :)

Would be good if we could remove that code from javaflow.

...but soon I am going to have a closer look into the
rewrite process from javaflow anyway. Now being able
to tune both ends I might be able to come up with a
different solution ...who knows *shrug*

I mean we are on trunk anyway... btw: maybe it would be
good to talk about release strategies for bcel.

cheers
--
Torsten