[bcel] Deprecated InstructionConstants

classic Classic list List threaded Threaded
28 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[bcel] Deprecated InstructionConstants

garydgregory
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: [hidden email] | [hidden email]
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
Reply | Threaded
Open this post in threaded view
|

AW: [bcel] Deprecated InstructionConstants

Jan Matèrne (jhm)
> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [bcel] Deprecated InstructionConstants

garydgregory
On Tue, May 31, 2016 at 11:36 PM, Jan Matèrne (jhm) <[hidden email]>
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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
E-Mail: [hidden email] | [hidden email]
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
Reply | Threaded
Open this post in threaded view
|

AW: [bcel] Deprecated InstructionConstants

Jan Matèrne (jhm)
> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [bcel] Deprecated InstructionConstants

sebb-2-2
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) <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [bcel] Deprecated InstructionConstants

Benedikt Ritter-4
I would go with the first option.

sebb <[hidden email]> 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) <[hidden email]> 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: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [bcel] Deprecated InstructionConstants

garydgregory
In reply to this post by sebb-2-2
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 <[hidden email]> 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) <[hidden email]> 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: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
E-Mail: [hidden email] | [hidden email]
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
Reply | Threaded
Open this post in threaded view
|

Re: [bcel] Deprecated InstructionConstants

Benedikt Ritter-4
Gary Gregory <[hidden email]> 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 <[hidden email]> 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) <[hidden email]> 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: [hidden email]
> > > For additional commands, e-mail: [hidden email]
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>
>
> --
> E-Mail: [hidden email] | [hidden email]
> 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
>
Reply | Threaded
Open this post in threaded view
|

Re: [bcel] Deprecated InstructionConstants

sebb-2-2
On 2 June 2016 at 07:56, Benedikt Ritter <[hidden email]> wrote:
> Gary Gregory <[hidden email]> 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 <[hidden email]> 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) <[hidden email]> 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: [hidden email]
>> > > For additional commands, e-mail: [hidden email]
>> > >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: [hidden email]
>> > For additional commands, e-mail: [hidden email]
>> >
>> >
>>
>>
>> --
>> E-Mail: [hidden email] | [hidden email]
>> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [bcel] Deprecated InstructionConstants

dbrosIus
In reply to this post by garydgregory
This is the problem with Commons.  

-------- Original message --------
From: sebb <[hidden email]>
Date: 06/02/2016  5:15 AM  (GMT-05:00)
To: Commons Developers List <[hidden email]>
Subject: Re: [bcel] Deprecated InstructionConstants

On 2 June 2016 at 07:56, Benedikt Ritter <[hidden email]> wrote:
> Gary Gregory <[hidden email]> 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 <[hidden email]> 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) <[hidden email]> 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: [hidden email]
>> > > For additional commands, e-mail: [hidden email]
>> > >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: [hidden email]
>> > For additional commands, e-mail: [hidden email]
>> >
>> >
>>
>>
>> --
>> E-Mail: [hidden email] | [hidden email]
>> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [bcel] Deprecated InstructionConstants

sebb-2-2
No, it's a consequence of the way the Java classpath and Maven work.

If Commons wishes to release a compatible version of BCEL, it must use
the same Java package and Maven coordinates.
(as well as ensure that any changes to the public API are at least
binary-compatible)

If Commons is happy to ignore compatibility, it can release a new
version with different package and Maven coordinates.
However this means downstream users have to update and recompile their source.



On 2 June 2016 at 10:41, dbrosIus <[hidden email]> wrote:

> This is the problem with Commons.
>
> -------- Original message --------
> From: sebb <[hidden email]>
> Date: 06/02/2016  5:15 AM  (GMT-05:00)
> To: Commons Developers List <[hidden email]>
> Subject: Re: [bcel] Deprecated InstructionConstants
>
> On 2 June 2016 at 07:56, Benedikt Ritter <[hidden email]> wrote:
>> Gary Gregory <[hidden email]> 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 <[hidden email]> 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) <[hidden email]> 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: [hidden email]
>>> > > For additional commands, e-mail: [hidden email]
>>> > >
>>> >
>>> > ---------------------------------------------------------------------
>>> > To unsubscribe, e-mail: [hidden email]
>>> > For additional commands, e-mail: [hidden email]
>>> >
>>> >
>>>
>>>
>>> --
>>> E-Mail: [hidden email] | [hidden email]
>>> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [bcel] Deprecated InstructionConstants

Dave Brosius-2
Commons should be happy to ignore compatibility, update to 1.8, change
package and maven coordinates, change interfaces to take advantage of
generics, become a modern code base. Staying in the 1.5 world, BCEL,
which is already dying, will die. No competent developer coming in from
the outside will look at BCEL and say, now _that_ is something i want to
work on.

This was the plan all along, and then someone came along and said, why
are we breaking backwards compatibility, and undid everything.

This is a major version, can we please move forward.



On 06/02/2016 06:07 AM, sebb wrote:

> No, it's a consequence of the way the Java classpath and Maven work.
>
> If Commons wishes to release a compatible version of BCEL, it must use
> the same Java package and Maven coordinates.
> (as well as ensure that any changes to the public API are at least
> binary-compatible)
>
> If Commons is happy to ignore compatibility, it can release a new
> version with different package and Maven coordinates.
> However this means downstream users have to update and recompile their source.
>
>
>
> On 2 June 2016 at 10:41, dbrosIus <[hidden email]> wrote:
>> This is the problem with Commons.
>>
>> -------- Original message --------
>> From: sebb <[hidden email]>
>> Date: 06/02/2016  5:15 AM  (GMT-05:00)
>> To: Commons Developers List <[hidden email]>
>> Subject: Re: [bcel] Deprecated InstructionConstants
>>
>> On 2 June 2016 at 07:56, Benedikt Ritter <[hidden email]> wrote:
>>> Gary Gregory <[hidden email]> 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 <[hidden email]> 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) <[hidden email]> 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: [hidden email]
>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: [hidden email]
>>>>> For additional commands, e-mail: [hidden email]
>>>>>
>>>>>
>>>>
>>>> --
>>>> E-Mail: [hidden email] | [hidden email]
>>>> 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: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [bcel] Deprecated InstructionConstants

sebb-2-2
On 2 June 2016 at 11:20, Dave Brosius <[hidden email]> wrote:

> Commons should be happy to ignore compatibility, update to 1.8, change
> package and maven coordinates, change interfaces to take advantage of
> generics, become a modern code base. Staying in the 1.5 world, BCEL, which
> is already dying, will die. No competent developer coming in from the
> outside will look at BCEL and say, now _that_ is something i want to work
> on.
>
> This was the plan all along, and then someone came along and said, why are
> we breaking backwards compatibility, and undid everything.
>
> This is a major version, can we please move forward.

Fine, provided that there is consensus to do so.

But I have yet to see agreement that breaking compatibility is acceptable.
There are several people who value compatibility over modernity.

Note that it would also be possible to release BCEL as two separate versions.
One which maintains compatibility, and the other which starts again
with a new design/package/coords.

>
>
>
> On 06/02/2016 06:07 AM, sebb wrote:
>>
>> No, it's a consequence of the way the Java classpath and Maven work.
>>
>> If Commons wishes to release a compatible version of BCEL, it must use
>> the same Java package and Maven coordinates.
>> (as well as ensure that any changes to the public API are at least
>> binary-compatible)
>>
>> If Commons is happy to ignore compatibility, it can release a new
>> version with different package and Maven coordinates.
>> However this means downstream users have to update and recompile their
>> source.
>>
>>
>>
>> On 2 June 2016 at 10:41, dbrosIus <[hidden email]> wrote:
>>>
>>> This is the problem with Commons.
>>>
>>> -------- Original message --------
>>> From: sebb <[hidden email]>
>>> Date: 06/02/2016  5:15 AM  (GMT-05:00)
>>> To: Commons Developers List <[hidden email]>
>>> Subject: Re: [bcel] Deprecated InstructionConstants
>>>
>>> On 2 June 2016 at 07:56, Benedikt Ritter <[hidden email]> wrote:
>>>>
>>>> Gary Gregory <[hidden email]> 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 <[hidden email]> 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) <[hidden email]> 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: [hidden email]
>>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: [hidden email]
>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> E-Mail: [hidden email] | [hidden email]
>>>>> 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: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [bcel] Deprecated InstructionConstants

Jörg Schaible-5
In reply to this post by sebb-2-2
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [bcel] Deprecated InstructionConstants

sebb-2-2
On 2 June 2016 at 12:35, Jörg Schaible <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [bcel] Deprecated InstructionConstants

Benedikt Ritter-4
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 <[hidden email]> schrieb am Do., 2. Juni 2016 um 14:19 Uhr:

> On 2 June 2016 at 12:35, Jörg Schaible <[hidden email]>
> 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: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [bcel] Deprecated InstructionConstants

garydgregory
On Thu, Jun 2, 2016 at 1:22 PM, Benedikt Ritter <[hidden email]> 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 <[hidden email]> schrieb am Do., 2. Juni 2016 um 14:19 Uhr:
>
> > On 2 June 2016 at 12:35, Jörg Schaible <[hidden email]>
> > 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: [hidden email]
> > > For additional commands, e-mail: [hidden email]
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>



--
E-Mail: [hidden email] | [hidden email]
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
Reply | Threaded
Open this post in threaded view
|

Re: [bcel] Deprecated InstructionConstants

dbrosIus
In reply to this post by garydgregory
It is still not functionally compatible.  People parsing UNKNOWN annotations looking for generics (as was the right way before)  will now fail.   Better rip the generic support out too. 

-------- Original message --------
From: Benedikt Ritter <[hidden email]>
Date: 06/02/2016  4:22 PM  (GMT-05:00)
To: Commons Developers List <[hidden email]>
Subject: Re: [bcel] Deprecated InstructionConstants

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 <[hidden email]> schrieb am Do., 2. Juni 2016 um 14:19 Uhr:

> On 2 June 2016 at 12:35, Jörg Schaible <[hidden email]>
> 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: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [bcel] Deprecated InstructionConstants

Benedikt Ritter-3
dbrosIus <[hidden email]> schrieb am Do., 2. Juni 2016 um
22:32 Uhr:

> It is still not functionally compatible.  People parsing UNKNOWN
> annotations looking for generics (as was the right way before)  will now
> fail.   Better rip the generic support out too.
>

Okay, if this is the case I haven't understood the situation correctly. If
our plan is to make a release that covers Java 8, we should go all the way.


>
> -------- Original message --------
> From: Benedikt Ritter <[hidden email]>
> Date: 06/02/2016  4:22 PM  (GMT-05:00)
> To: Commons Developers List <[hidden email]>
> Subject: Re: [bcel] Deprecated InstructionConstants
>
> 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 <[hidden email]> schrieb am Do., 2. Juni 2016 um 14:19 Uhr:
>
> > On 2 June 2016 at 12:35, Jörg Schaible <[hidden email]>
> > 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: [hidden email]
> > > For additional commands, e-mail: [hidden email]
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: [bcel] Deprecated InstructionConstants

garydgregory
On Thu, Jun 2, 2016 at 1:34 PM, Benedikt Ritter <[hidden email]>
wrote:

> dbrosIus <[hidden email]> schrieb am Do., 2. Juni 2016 um
> 22:32 Uhr:
>
> > It is still not functionally compatible.  People parsing UNKNOWN
> > annotations looking for generics (as was the right way before)  will now
> > fail.   Better rip the generic support out too.
> >
>
> Okay, if this is the case I haven't understood the situation correctly. If
> our plan is to make a release that covers Java 8, we should go all the way.
>

I think the immediate need is to avoid blowing up on Java 8. I see this as
a 5.x BC release needed ASAP that the Maven plugin(s) can pick up, also
ASAP.

Gary


>
> >
> > -------- Original message --------
> > From: Benedikt Ritter <[hidden email]>
> > Date: 06/02/2016  4:22 PM  (GMT-05:00)
> > To: Commons Developers List <[hidden email]>
> > Subject: Re: [bcel] Deprecated InstructionConstants
> >
> > 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 <[hidden email]> schrieb am Do., 2. Juni 2016 um 14:19 Uhr:
> >
> > > On 2 June 2016 at 12:35, Jörg Schaible <[hidden email]
> >
> > > 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: [hidden email]
> > > > For additional commands, e-mail: [hidden email]
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [hidden email]
> > > For additional commands, e-mail: [hidden email]
> > >
> > >
> >
>



--
E-Mail: [hidden email] | [hidden email]
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
12