[bcel] Deprecated InstructionConstants

[Gary Gregory <ga...@gmail.com>]

The interface org.apache.commons.bcel6.generic.InstructionConstants is
deprecated in favor of a class. It seems OK to delete it since bcel6 is a
major new release.

Check?

Gary

-- 
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

Re: [bcel] Deprecated InstructionConstants

[Gary Gregory <ga...@gmail.com>]

On Thu, Jun 2, 2016 at 1:22 PM, Benedikt Ritter <br...@apache.org> wrote:

> Okay, so were are we now?
>
> - people are waiting for a new release
> - package coords have changed - BC is broken
> - sebb has put effort into making all changes compatible
> - two interface changes remain
>
> Is that correct? Then let's just get over with this two interfaces mach
> make the API redesign afterwards. Let's create two extension interfaces
> release this stuff with the old package and maven coord and we're done.
>

Check. Do you want to RM? Or Sebb?

Gary


>
> sebb <se...@gmail.com> schrieb am Do., 2. Juni 2016 um 14:19 Uhr:
>
> > On 2 June 2016 at 12:35, Jörg Schaible <jo...@bpm-inspire.com>
> > wrote:
> > > Hi,
> > >
> > > sebb wrote:
> > >
> > >> Hang on please.
> > >>
> > >> There were plans to produce a new incompatible release with new Maven
> > >> coords and new package names.
> > >> However as I recall there was some pushback from users who wished to
> > >> have a drop-in release.
> > >> That is not possible unless the release is binary compatible.
> > >
> > > The question is, why does one want to have a BC release? If Oliver uses
> > it
> > > as drop-in replacement, he will not use any new stuff, i.e. he might be
> > > interested to get simply a version working with Java 8 runtime.
> > >
> > >> So I spent quite a bit of effort reworking the changes so as to
> > >> facilitate a binary compatible release.
> > >> As far as I can recall, that effort was successful apart from changes
> > >> to an interface (or two).
> > >>
> > >> There were some ideas as to how to resolve the interface
> > >> incompatibilty, but no agreement was reached.
> > >> I think the options were:
> > >> - introduce new interface(s) extending the old one(s)
> > >> - keep the interface(s) and handle any runtime errors
> > >> - use the Java 8 (?) facility which allows an interface to contain a
> > >> method implementation.
> > >>
> > >> Note that the code does not yet support some Java 8 features.
> > >
> > > I'd really go on with bcel6 and new GAV using Java 8 as minimum and
> > backport
> > > anything to 5.x that is required to let BCEL run on Java 8 runtime, but
> > > nothing else.
> > >
> > > I am normally also in the BC camp, but I realize that we stress it
> > sometimes
> > > too much and actually harm further development of a component. After
> > several
> > > years of (public) inactivity of a component, we should really take the
> > > advantage for a cut.
> > >
> > > The effort to release an additional 5.x after a major 6.0 is negligible
> >
> > Not sure I agree the effort is negligible.
> >
> > > compared to the constant annoyance by the limits of ancient JDKs
> working
> > on
> > > the interesting stuff for a component.
> >
> > The JDK required to run BCEL is orthogonal to compatibility.
> >
> > Indeed there was a proposal to use Java 8 default interface methods to
> > get round the issue with compatibility.
> >
> > Please let's not conflate the two issues.
> >
> > > Cheers,
> > > Jörg
> > >
> > >
> > > ---------------------------------------------------------------------
> > > 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
> >
> >
>



-- 
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

Re: [bcel] Deprecated InstructionConstants

[Benedikt Ritter <br...@apache.org>]

Okay, so were are we now?

- people are waiting for a new release
- package coords have changed - BC is broken
- sebb has put effort into making all changes compatible
- two interface changes remain

Is that correct? Then let's just get over with this two interfaces mach
make the API redesign afterwards. Let's create two extension interfaces
release this stuff with the old package and maven coord and we're done.

sebb <se...@gmail.com> schrieb am Do., 2. Juni 2016 um 14:19 Uhr:

> On 2 June 2016 at 12:35, Jörg Schaible <jo...@bpm-inspire.com>
> wrote:
> > Hi,
> >
> > sebb wrote:
> >
> >> Hang on please.
> >>
> >> There were plans to produce a new incompatible release with new Maven
> >> coords and new package names.
> >> However as I recall there was some pushback from users who wished to
> >> have a drop-in release.
> >> That is not possible unless the release is binary compatible.
> >
> > The question is, why does one want to have a BC release? If Oliver uses
> it
> > as drop-in replacement, he will not use any new stuff, i.e. he might be
> > interested to get simply a version working with Java 8 runtime.
> >
> >> So I spent quite a bit of effort reworking the changes so as to
> >> facilitate a binary compatible release.
> >> As far as I can recall, that effort was successful apart from changes
> >> to an interface (or two).
> >>
> >> There were some ideas as to how to resolve the interface
> >> incompatibilty, but no agreement was reached.
> >> I think the options were:
> >> - introduce new interface(s) extending the old one(s)
> >> - keep the interface(s) and handle any runtime errors
> >> - use the Java 8 (?) facility which allows an interface to contain a
> >> method implementation.
> >>
> >> Note that the code does not yet support some Java 8 features.
> >
> > I'd really go on with bcel6 and new GAV using Java 8 as minimum and
> backport
> > anything to 5.x that is required to let BCEL run on Java 8 runtime, but
> > nothing else.
> >
> > I am normally also in the BC camp, but I realize that we stress it
> sometimes
> > too much and actually harm further development of a component. After
> several
> > years of (public) inactivity of a component, we should really take the
> > advantage for a cut.
> >
> > The effort to release an additional 5.x after a major 6.0 is negligible
>
> Not sure I agree the effort is negligible.
>
> > compared to the constant annoyance by the limits of ancient JDKs working
> on
> > the interesting stuff for a component.
>
> The JDK required to run BCEL is orthogonal to compatibility.
>
> Indeed there was a proposal to use Java 8 default interface methods to
> get round the issue with compatibility.
>
> Please let's not conflate the two issues.
>
> > Cheers,
> > Jörg
> >
> >
> > ---------------------------------------------------------------------
> > 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
>
>

Re: [bcel] Deprecated InstructionConstants

[sebb <se...@gmail.com>]

On 2 June 2016 at 12:35, Jörg Schaible <jo...@bpm-inspire.com> wrote:
> Hi,
>
> sebb wrote:
>
>> Hang on please.
>>
>> There were plans to produce a new incompatible release with new Maven
>> coords and new package names.
>> However as I recall there was some pushback from users who wished to
>> have a drop-in release.
>> That is not possible unless the release is binary compatible.
>
> The question is, why does one want to have a BC release? If Oliver uses it
> as drop-in replacement, he will not use any new stuff, i.e. he might be
> interested to get simply a version working with Java 8 runtime.
>
>> So I spent quite a bit of effort reworking the changes so as to
>> facilitate a binary compatible release.
>> As far as I can recall, that effort was successful apart from changes
>> to an interface (or two).
>>
>> There were some ideas as to how to resolve the interface
>> incompatibilty, but no agreement was reached.
>> I think the options were:
>> - introduce new interface(s) extending the old one(s)
>> - keep the interface(s) and handle any runtime errors
>> - use the Java 8 (?) facility which allows an interface to contain a
>> method implementation.
>>
>> Note that the code does not yet support some Java 8 features.
>
> I'd really go on with bcel6 and new GAV using Java 8 as minimum and backport
> anything to 5.x that is required to let BCEL run on Java 8 runtime, but
> nothing else.
>
> I am normally also in the BC camp, but I realize that we stress it sometimes
> too much and actually harm further development of a component. After several
> years of (public) inactivity of a component, we should really take the
> advantage for a cut.
>
> The effort to release an additional 5.x after a major 6.0 is negligible

Not sure I agree the effort is negligible.

> compared to the constant annoyance by the limits of ancient JDKs working on
> the interesting stuff for a component.

The JDK required to run BCEL is orthogonal to compatibility.

Indeed there was a proposal to use Java 8 default interface methods to
get round the issue with compatibility.

Please let's not conflate the two issues.

> Cheers,
> Jörg
>
>
> ---------------------------------------------------------------------
> 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

Re: [bcel] Deprecated InstructionConstants

[Jörg Schaible <jo...@bpm-inspire.com>]

Hi,

sebb wrote:

> Hang on please.
> 
> There were plans to produce a new incompatible release with new Maven
> coords and new package names.
> However as I recall there was some pushback from users who wished to
> have a drop-in release.
> That is not possible unless the release is binary compatible.

The question is, why does one want to have a BC release? If Oliver uses it 
as drop-in replacement, he will not use any new stuff, i.e. he might be 
interested to get simply a version working with Java 8 runtime.

> So I spent quite a bit of effort reworking the changes so as to
> facilitate a binary compatible release.
> As far as I can recall, that effort was successful apart from changes
> to an interface (or two).
> 
> There were some ideas as to how to resolve the interface
> incompatibilty, but no agreement was reached.
> I think the options were:
> - introduce new interface(s) extending the old one(s)
> - keep the interface(s) and handle any runtime errors
> - use the Java 8 (?) facility which allows an interface to contain a
> method implementation.
> 
> Note that the code does not yet support some Java 8 features.

I'd really go on with bcel6 and new GAV using Java 8 as minimum and backport 
anything to 5.x that is required to let BCEL run on Java 8 runtime, but 
nothing else.

I am normally also in the BC camp, but I realize that we stress it sometimes 
too much and actually harm further development of a component. After several 
years of (public) inactivity of a component, we should really take the 
advantage for a cut.

The effort to release an additional 5.x after a major 6.0 is negligible 
compared to the constant annoyance by the limits of ancient JDKs working on 
the interesting stuff for a component.

Cheers,
J�rg


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

Re: [bcel] Deprecated InstructionConstants

[Benedikt Ritter <br...@apache.org>]

I would go with the first option.

sebb <se...@gmail.com> schrieb am Do., 2. Juni 2016 um 00:43:

> Hang on please.
>
> There were plans to produce a new incompatible release with new Maven
> coords and new package names.
> However as I recall there was some pushback from users who wished to
> have a drop-in release.
> That is not possible unless the release is binary compatible.
>
> So I spent quite a bit of effort reworking the changes so as to
> facilitate a binary compatible release.
> As far as I can recall, that effort was successful apart from changes
> to an interface (or two).
>
> There were some ideas as to how to resolve the interface
> incompatibilty, but no agreement was reached.
> I think the options were:
> - introduce new interface(s) extending the old one(s)
> - keep the interface(s) and handle any runtime errors
> - use the Java 8 (?) facility which allows an interface to contain a
> method implementation.
>
> Note that the code does not yet support some Java 8 features.
>
>
> On 1 June 2016 at 09:34, Jan Matèrne (jhm) <ap...@materne.de> wrote:
> >> It does not make sense though. All of the code in the bcel6 package is
> >> going to be released for the first time in the upcoming 6.0 release.
> >
> > Ok, didnt know that.
> > Then I'm fine :)
> >
> > Just wanted to give a hint.
> >
> >
> > Jan
> >
> >
> > ---------------------------------------------------------------------
> > 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
>
>

Re: [bcel] Deprecated InstructionConstants

[sebb <se...@gmail.com>]

On 2 June 2016 at 07:56, Benedikt Ritter <br...@apache.org> wrote:
> Gary Gregory <ga...@gmail.com> schrieb am Do., 2. Juni 2016 um
> 08:00 Uhr:
>
>> So trunk packages would be renamed _back_ from bcel6 to the 5.2 packages?
>>
>
> That's what I understood from sebb's last message.

Yes, that would need to happen to support BC.

>
>>
>> Gary
>>
>> On Wed, Jun 1, 2016 at 3:43 PM, sebb <se...@gmail.com> wrote:
>>
>> > Hang on please.
>> >
>> > There were plans to produce a new incompatible release with new Maven
>> > coords and new package names.
>> > However as I recall there was some pushback from users who wished to
>> > have a drop-in release.
>> > That is not possible unless the release is binary compatible.
>> >
>> > So I spent quite a bit of effort reworking the changes so as to
>> > facilitate a binary compatible release.
>> > As far as I can recall, that effort was successful apart from changes
>> > to an interface (or two).
>> >
>> > There were some ideas as to how to resolve the interface
>> > incompatibilty, but no agreement was reached.
>> > I think the options were:
>> > - introduce new interface(s) extending the old one(s)
>> > - keep the interface(s) and handle any runtime errors
>> > - use the Java 8 (?) facility which allows an interface to contain a
>> > method implementation.
>> >
>> > Note that the code does not yet support some Java 8 features.
>> >
>> >
>> > On 1 June 2016 at 09:34, Jan Matèrne (jhm) <ap...@materne.de> wrote:
>> > >> It does not make sense though. All of the code in the bcel6 package is
>> > >> going to be released for the first time in the upcoming 6.0 release.
>> > >
>> > > Ok, didnt know that.
>> > > Then I'm fine :)
>> > >
>> > > Just wanted to give a hint.
>> > >
>> > >
>> > > Jan
>> > >
>> > >
>> > > ---------------------------------------------------------------------
>> > > 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
>> >
>> >
>>
>>
>> --
>> 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

Re: [bcel] Deprecated InstructionConstants

[Benedikt Ritter <br...@apache.org>]

Gary Gregory <ga...@gmail.com> schrieb am Do., 2. Juni 2016 um
08:00 Uhr:

> So trunk packages would be renamed _back_ from bcel6 to the 5.2 packages?
>

That's what I understood from sebb's last message.


>
> Gary
>
> On Wed, Jun 1, 2016 at 3:43 PM, sebb <se...@gmail.com> wrote:
>
> > Hang on please.
> >
> > There were plans to produce a new incompatible release with new Maven
> > coords and new package names.
> > However as I recall there was some pushback from users who wished to
> > have a drop-in release.
> > That is not possible unless the release is binary compatible.
> >
> > So I spent quite a bit of effort reworking the changes so as to
> > facilitate a binary compatible release.
> > As far as I can recall, that effort was successful apart from changes
> > to an interface (or two).
> >
> > There were some ideas as to how to resolve the interface
> > incompatibilty, but no agreement was reached.
> > I think the options were:
> > - introduce new interface(s) extending the old one(s)
> > - keep the interface(s) and handle any runtime errors
> > - use the Java 8 (?) facility which allows an interface to contain a
> > method implementation.
> >
> > Note that the code does not yet support some Java 8 features.
> >
> >
> > On 1 June 2016 at 09:34, Jan Matèrne (jhm) <ap...@materne.de> wrote:
> > >> It does not make sense though. All of the code in the bcel6 package is
> > >> going to be released for the first time in the upcoming 6.0 release.
> > >
> > > Ok, didnt know that.
> > > Then I'm fine :)
> > >
> > > Just wanted to give a hint.
> > >
> > >
> > > Jan
> > >
> > >
> > > ---------------------------------------------------------------------
> > > 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
> >
> >
>
>
> --
> 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
>

Re: [bcel] Deprecated InstructionConstants

[Gary Gregory <ga...@gmail.com>]

So trunk packages would be renamed _back_ from bcel6 to the 5.2 packages?

Gary

On Wed, Jun 1, 2016 at 3:43 PM, sebb <se...@gmail.com> wrote:

> Hang on please.
>
> There were plans to produce a new incompatible release with new Maven
> coords and new package names.
> However as I recall there was some pushback from users who wished to
> have a drop-in release.
> That is not possible unless the release is binary compatible.
>
> So I spent quite a bit of effort reworking the changes so as to
> facilitate a binary compatible release.
> As far as I can recall, that effort was successful apart from changes
> to an interface (or two).
>
> There were some ideas as to how to resolve the interface
> incompatibilty, but no agreement was reached.
> I think the options were:
> - introduce new interface(s) extending the old one(s)
> - keep the interface(s) and handle any runtime errors
> - use the Java 8 (?) facility which allows an interface to contain a
> method implementation.
>
> Note that the code does not yet support some Java 8 features.
>
>
> On 1 June 2016 at 09:34, Jan Matèrne (jhm) <ap...@materne.de> wrote:
> >> It does not make sense though. All of the code in the bcel6 package is
> >> going to be released for the first time in the upcoming 6.0 release.
> >
> > Ok, didnt know that.
> > Then I'm fine :)
> >
> > Just wanted to give a hint.
> >
> >
> > Jan
> >
> >
> > ---------------------------------------------------------------------
> > 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
>
>


-- 
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

Re: [bcel] Deprecated InstructionConstants

[sebb <se...@gmail.com>]

Hang on please.

There were plans to produce a new incompatible release with new Maven
coords and new package names.
However as I recall there was some pushback from users who wished to
have a drop-in release.
That is not possible unless the release is binary compatible.

So I spent quite a bit of effort reworking the changes so as to
facilitate a binary compatible release.
As far as I can recall, that effort was successful apart from changes
to an interface (or two).

There were some ideas as to how to resolve the interface
incompatibilty, but no agreement was reached.
I think the options were:
- introduce new interface(s) extending the old one(s)
- keep the interface(s) and handle any runtime errors
- use the Java 8 (?) facility which allows an interface to contain a
method implementation.

Note that the code does not yet support some Java 8 features.


On 1 June 2016 at 09:34, Jan Matèrne (jhm) <ap...@materne.de> wrote:
>> It does not make sense though. All of the code in the bcel6 package is
>> going to be released for the first time in the upcoming 6.0 release.
>
> Ok, didnt know that.
> Then I'm fine :)
>
> Just wanted to give a hint.
>
>
> Jan
>
>
> ---------------------------------------------------------------------
> 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

AW: [bcel] Deprecated InstructionConstants

["Jan Matèrne (jhm)" <ap...@materne.de>]

> It does not make sense though. All of the code in the bcel6 package is
> going to be released for the first time in the upcoming 6.0 release.

Ok, didnt know that.
Then I'm fine :)

Just wanted to give a hint.


Jan


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

Re: [bcel] Deprecated InstructionConstants

[Gary Gregory <ga...@gmail.com>]

On Tue, May 31, 2016 at 11:36 PM, Jan Matèrne (jhm) <ap...@materne.de>
wrote:

> > The interface org.apache.commons.bcel6.generic.InstructionConstants is
> > deprecated in favor of a class. It seems OK to delete it since bcel6 is
> > a major new release.
> >
> > Check?
>
> Had a look at the source and history:
>
> Source [1]:
> @deprecated (since 6.0) Do not use. Use InstructionConst instead.
> ==> When deprecating with 6.0, deleting it in 6.0 as well would be too
> early in my opinion.
>

It does not make sense though. All of the code in the bcel6 package is
going to be released for the first time in the upcoming 6.0 release.

No one can have written code against these deprecated classes. What am I
missing. That these classes existed in version 5.x in a different package?
So what, a new version is the opportunity to drop old code. Other wise we
are adding new code, deprecating it right away, without an opportunity to
remove it until the _next_ major release, 7.0.

Gary


>
> History [2]:
> Javac-@Deprecated added in Sep 2015 [3]
> Javadoc-@Deprecatad is older. Havent found the initial commit.
>
>
> As I am not familiar with BCEL source, are you sure its deprecated long
> enough?
>
>
> Jan
>
>
> [1]
> https://github.com/apache/commons-bcel/blob/trunk/src/main/java/org/apache/commons/bcel6/generic/InstructionConstants.java
> [2]
> https://github.com/apache/commons-bcel/blame/trunk/src/main/java/org/apache/commons/bcel6/generic/InstructionConstants.java
> [3]
> https://github.com/apache/commons-bcel/commit/885b0a0a353275739c9b1658a8384fdbf6a9af2b
>
>
>
> ---------------------------------------------------------------------
> 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

AW: [bcel] Deprecated InstructionConstants

["Jan Matèrne (jhm)" <ap...@materne.de>]

> The interface org.apache.commons.bcel6.generic.InstructionConstants is
> deprecated in favor of a class. It seems OK to delete it since bcel6 is
> a major new release.
> 
> Check?

Had a look at the source and history:

Source [1]:
@deprecated (since 6.0) Do not use. Use InstructionConst instead.
==> When deprecating with 6.0, deleting it in 6.0 as well would be too early in my opinion.

History [2]:
Javac-@Deprecated added in Sep 2015 [3]
Javadoc-@Deprecatad is older. Havent found the initial commit.


As I am not familiar with BCEL source, are you sure its deprecated long enough?


Jan


[1] https://github.com/apache/commons-bcel/blob/trunk/src/main/java/org/apache/commons/bcel6/generic/InstructionConstants.java
[2] https://github.com/apache/commons-bcel/blame/trunk/src/main/java/org/apache/commons/bcel6/generic/InstructionConstants.java
[3] https://github.com/apache/commons-bcel/commit/885b0a0a353275739c9b1658a8384fdbf6a9af2b



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