[ALL] About binary compatibility

classic Classic list List threaded Threaded
58 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Re: [ALL] About binary compatibility

Ralph Goers

I should follow this up.  I don’t think the multi-release support would help in cases like what I have proposed for VFS (taking advantage of java.nio.file). In that case the changes would almost surely be too extensive to avoid compatibility issues.  

Ralph

> On Jun 6, 2016, at 11:44 AM, Ralph Goers <[hidden email]> wrote:
>
>
>> On Jun 6, 2016, at 11:38 AM, Gary Gregory <[hidden email]> wrote:
>>
>> On Mon, Jun 6, 2016 at 11:11 AM, Jochen Wiedmann <[hidden email] <mailto:[hidden email]>>
>> wrote:
>>
>>> ---------- Forwarded message ----------
>>> From: Ralph Goers <[hidden email]>
>>> Date: Mon, Jun 6, 2016 at 1:11 AM
>>> Subject: Re: [ALL] About binary compatibility
>>> To: Commons Developers List <[hidden email]>
>>>
>>>
>>> I think we should adopt Java 9’s multi-release jars [1] as standard
>>> practice.  While this won’t let us update our APIs without breaking
>>> compatibility (which may still be necessary), it will allow us to
>>> leverage some features in newer versions of Java without worrying
>>> about breaking backward compatibility.
>>>
>>> Strong disagreement. Java 9 is not even out, and I heard noone express
>>> any desire to *use* these beasts. In other words: We'd serve a
>>> non-existing demand. That can't help anyone,
>>> in particular not ourselves.
>>>
>>
>> Yeah, it seems a little early to jump on that bandwagon.
>>
>> I'd rather keep a mainline of development of new releases on a recent JRE
>> like Java 7 or 8 and let people who really want older JREs maintain
>> branches.
>>
>
> Gary, your response seems at odds with what I am saying. I’m not talking about supporting Java 6.  What I am suggesting is that this feature in Java 9 will let you take advantage of features in Java 8 or 9 while still being able to have the same jar run in Java 7.  In other words your can have a project where the Maven is told the target runtime is Java 7 but can take advantage of features in Java 8 or 9.  You don’t have to delay taking advantage of features just because you aren’t ready to abandon your Java 7 (or 8 when that is relevant) users.
>
> Ralph
>



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

Reply | Threaded
Open this post in threaded view
|

Re: [ALL] About binary compatibility

Ralph Goers
In reply to this post by James Carman
From what I have been reading on the core-libs-dev mailing list that feature is part of the Java 9 EA releases that are currently being delivered.  From this thread it appears you can build currently build multi-release jars with Maven [1[.

Ralph

[1] https://www.mail-archive.com/core-libs-dev%40openjdk.java.net/msg39514.html <https://www.mail-archive.com/core-libs-dev@.../msg39514.html>

> On Jun 6, 2016, at 11:50 AM, James Carman <[hidden email]> wrote:
>
> On Sun, Jun 5, 2016 at 7:12 PM Ralph Goers <[hidden email]>
> wrote:
>
>> I think we should adopt Java 9’s multi-release jars [1] as standard
>> practice.  While this won’t let us update our APIs without breaking
>> compatibility (which may still be necessary), it will allow us to leverage
>> some features in newer versions of Java without worrying about breaking
>> backward compatibility.
>>
>>
> When do you propose we adopt this new feature?  As of now, the issue is
> still listed as "Unresolved" in their issue tracking:
>
> https://bugs.openjdk.java.net/browse/JDK-8047305
>
> I'm not saying I'm against the idea (on the surface it sounds pretty
> interesting).  I'm just saying that it doesn't appear to be an option for
> us at present.  We could definitely be one of the early-adopters of this
> new feature (one a few select components first) and show folks how it's
> done, once it is available.  Common Lang seems like a likely candidate for
> such a feature.

Reply | Threaded
Open this post in threaded view
|

Re: [ALL] About binary compatibility

garydgregory
In reply to this post by Ralph Goers
On Mon, Jun 6, 2016 at 11:44 AM, Ralph Goers <[hidden email]>
wrote:

>
> > On Jun 6, 2016, at 11:38 AM, Gary Gregory <[hidden email]>
> wrote:
> >
> > On Mon, Jun 6, 2016 at 11:11 AM, Jochen Wiedmann <
> [hidden email] <mailto:[hidden email]>>
> > wrote:
> >
> >> ---------- Forwarded message ----------
> >> From: Ralph Goers <[hidden email]>
> >> Date: Mon, Jun 6, 2016 at 1:11 AM
> >> Subject: Re: [ALL] About binary compatibility
> >> To: Commons Developers List <[hidden email]>
> >>
> >>
> >> I think we should adopt Java 9’s multi-release jars [1] as standard
> >> practice.  While this won’t let us update our APIs without breaking
> >> compatibility (which may still be necessary), it will allow us to
> >> leverage some features in newer versions of Java without worrying
> >> about breaking backward compatibility.
> >>
> >> Strong disagreement. Java 9 is not even out, and I heard noone express
> >> any desire to *use* these beasts. In other words: We'd serve a
> >> non-existing demand. That can't help anyone,
> >> in particular not ourselves.
> >>
> >
> > Yeah, it seems a little early to jump on that bandwagon.
> >
> > I'd rather keep a mainline of development of new releases on a recent JRE
> > like Java 7 or 8 and let people who really want older JREs maintain
> > branches.
> >
>
> Gary, your response seems at odds with what I am saying. I’m not talking
> about supporting Java 6.  What I am suggesting is that this feature in Java
> 9 will let you take advantage of features in Java 8 or 9 while still being
> able to have the same jar run in Java 7.  In other words your can have a
> project where the Maven is told the target runtime is Java 7 but can take
> advantage of features in Java 8 or 9.  You don’t have to delay taking
> advantage of features just because you aren’t ready to abandon your Java 7
> (or 8 when that is relevant) users.
>

Howdy,

[These chats are fun, but we usually end up deciding nothing and delegating
Java platform decisions to individual components, so maybe we should make
_that_ a more visible Commons guideline if it is not already.]

I think what I am really saying (and not expressing it clearly!) is that I
am not looking forward to debugging these scenarios; I'd rather keep it
simple and say: we require Java X for release Y. Once a component jumps on
Java 7, I want to make it Java 7 all over (try-with-resources, diamond
notation, and so on.)

The argument I hear/read over and over is: Folks that are stuck on
maintaining a Java 6 (for example) stack are not going to want to change
anything in 3rd party dependencies beyond getting a security
or critical bug fix. So for me, if we release a new version of a component,
it can do whatever the "do-ers" want it to do. If someone says, "Hey! This
won't work on Java 6", I say "It will once you put in the work to backport
whatever you want in a branch!" ;-) Same argument for moving to Java 8. At
work, we are still stuck on Java 7, but I am not going to stop any Commons
component from going to Java 8, even though that would not be useful for me
today (at work.)

I hope that helps ;-)
Gary


>
> Ralph
>
>


--
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: [ALL] About binary compatibility

jochen-2
In reply to this post by Ralph Goers
On Mon, Jun 6, 2016 at 10:07 PM, Ralph Goers <[hidden email]> wrote:
> From what I have been reading on the core-libs-dev mailing list that feature is part of the
> Java 9 EA releases that are currently being delivered.  From this thread it appears
> you can build currently build multi-release jars with Maven [1].

I understand [1] to indicate that the Maven guys to prepare support
for multi release jars.
As far as I know, that stuff hasn't been released yet, and we don't
know what will be required
to use it. (New maven-jar-plugin? Maven? JDK9 for build?)

Without a stable Maven release that is intended to support these
things, I'd oppose us supporting
them.

Jochen


[1] https://www.mail-archive.com/core-libs-dev%40openjdk.java.net/msg39514.html
<https://www.mail-archive.com/core-libs-dev@.../msg39514.html>



--
The next time you hear: "Don't reinvent the wheel!"

http://www.keystonedevelopment.co.uk/wp-content/uploads/2014/10/evolution-of-the-wheel-300x85.jpg

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

Reply | Threaded
Open this post in threaded view
|

Re: [ALL] About binary compatibility

Benedikt Ritter-4
In reply to this post by garydgregory
Hi,

Gary Gregory <[hidden email]> schrieb am Mo., 6. Juni 2016 um
22:30 Uhr:

> On Mon, Jun 6, 2016 at 11:44 AM, Ralph Goers <[hidden email]>
> wrote:
>
> >
> > > On Jun 6, 2016, at 11:38 AM, Gary Gregory <[hidden email]>
> > wrote:
> > >
> > > On Mon, Jun 6, 2016 at 11:11 AM, Jochen Wiedmann <
> > [hidden email] <mailto:[hidden email]>>
> > > wrote:
> > >
> > >> ---------- Forwarded message ----------
> > >> From: Ralph Goers <[hidden email]>
> > >> Date: Mon, Jun 6, 2016 at 1:11 AM
> > >> Subject: Re: [ALL] About binary compatibility
> > >> To: Commons Developers List <[hidden email]>
> > >>
> > >>
> > >> I think we should adopt Java 9’s multi-release jars [1] as standard
> > >> practice.  While this won’t let us update our APIs without breaking
> > >> compatibility (which may still be necessary), it will allow us to
> > >> leverage some features in newer versions of Java without worrying
> > >> about breaking backward compatibility.
> > >>
> > >> Strong disagreement. Java 9 is not even out, and I heard noone express
> > >> any desire to *use* these beasts. In other words: We'd serve a
> > >> non-existing demand. That can't help anyone,
> > >> in particular not ourselves.
> > >>
> > >
> > > Yeah, it seems a little early to jump on that bandwagon.
> > >
> > > I'd rather keep a mainline of development of new releases on a recent
> JRE
> > > like Java 7 or 8 and let people who really want older JREs maintain
> > > branches.
> > >
> >
> > Gary, your response seems at odds with what I am saying. I’m not talking
> > about supporting Java 6.  What I am suggesting is that this feature in
> Java
> > 9 will let you take advantage of features in Java 8 or 9 while still
> being
> > able to have the same jar run in Java 7.  In other words your can have a
> > project where the Maven is told the target runtime is Java 7 but can take
> > advantage of features in Java 8 or 9.  You don’t have to delay taking
> > advantage of features just because you aren’t ready to abandon your Java
> 7
> > (or 8 when that is relevant) users.
> >
>
> Howdy,
>
> [These chats are fun, but we usually end up deciding nothing and delegating
> Java platform decisions to individual components, so maybe we should make
> _that_ a more visible Commons guideline if it is not already.]
>

Yes, this discussion started with "let's write something down". I haven't
seen any objections to my initial proposal so I'm going to document that on
our website soon.

Benedikt


>
> I think what I am really saying (and not expressing it clearly!) is that I
> am not looking forward to debugging these scenarios; I'd rather keep it
> simple and say: we require Java X for release Y. Once a component jumps on
> Java 7, I want to make it Java 7 all over (try-with-resources, diamond
> notation, and so on.)
>
> The argument I hear/read over and over is: Folks that are stuck on
> maintaining a Java 6 (for example) stack are not going to want to change
> anything in 3rd party dependencies beyond getting a security
> or critical bug fix. So for me, if we release a new version of a component,
> it can do whatever the "do-ers" want it to do. If someone says, "Hey! This
> won't work on Java 6", I say "It will once you put in the work to backport
> whatever you want in a branch!" ;-) Same argument for moving to Java 8. At
> work, we are still stuck on Java 7, but I am not going to stop any Commons
> component from going to Java 8, even though that would not be useful for me
> today (at work.)
>
> I hope that helps ;-)
> Gary
>
>
> >
> > Ralph
> >
> >
>
>
> --
> 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: [ALL] About binary compatibility

Thomas Vandahl
In reply to this post by James Carman
On 05.06.16 20:33, James Carman wrote:
> Not quite. OSGi is a special case. It's much more restrictive than simple
> J2SE, because it can be. In the general case, the public API for OSGi is
> different from the public API for J2SE. Let's not confuse the two.

My intention was to use the OSGi meta data to define something that we
consider a public API. I agree to Sebastian that this might be difficult
for some components as they were not designed with a separation of
public and private API in mind. That's why I believe that suing
something a little more restrictive may help us to move forward and
improve the situation.

Bye, Thomas.


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

Reply | Threaded
Open this post in threaded view
|

Re: [ALL] About binary compatibility

jochen-2
On Mon, Jun 13, 2016 at 8:49 PM, Thomas Vandahl <[hidden email]> wrote:

> On 05.06.16 20:33, James Carman wrote:
>> Not quite. OSGi is a special case. It's much more restrictive than simple
>> J2SE, because it can be. In the general case, the public API for OSGi is
>> different from the public API for J2SE. Let's not confuse the two.
>
> My intention was to use the OSGi meta data to define something that we
> consider a public API. I agree to Sebastian that this might be difficult
> for some components as they were not designed with a separation of
> public and private API in mind. That's why I believe that suing
> something a little more restrictive may help us to move forward and
> improve the situation.

IMO, we are only complicating the situation, because that would only
make the situation less clear. Right now, we suggest that the project
retains binary compatibility, unless explicitly documented (via
package name, and Maven coordinates). Give

--
The next time you hear: "Don't reinvent the wheel!"

http://www.keystonedevelopment.co.uk/wp-content/uploads/2014/10/evolution-of-the-wheel-300x85.jpg

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

Reply | Threaded
Open this post in threaded view
|

Re: [ALL] About binary compatibility

James Carman
In reply to this post by Thomas Vandahl
I'd rather not make it (the OSGi metadata) the "source of truth".

On Mon, Jun 13, 2016 at 2:49 PM Thomas Vandahl <[hidden email]> wrote:

> On 05.06.16 20:33, James Carman wrote:
> > Not quite. OSGi is a special case. It's much more restrictive than simple
> > J2SE, because it can be. In the general case, the public API for OSGi is
> > different from the public API for J2SE. Let's not confuse the two.
>
> My intention was to use the OSGi meta data to define something that we
> consider a public API. I agree to Sebastian that this might be difficult
> for some components as they were not designed with a separation of
> public and private API in mind. That's why I believe that suing
> something a little more restrictive may help us to move forward and
> improve the situation.
>
> Bye, Thomas.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [ALL] About binary compatibility

Thomas Vandahl
In reply to this post by jochen-2
On 13.06.16 20:54, Jochen Wiedmann wrote:

> On Mon, Jun 13, 2016 at 8:49 PM, Thomas Vandahl <[hidden email]> wrote:
>> On 05.06.16 20:33, James Carman wrote:
>>> Not quite. OSGi is a special case. It's much more restrictive than simple
>>> J2SE, because it can be. In the general case, the public API for OSGi is
>>> different from the public API for J2SE. Let's not confuse the two.
>>
>> My intention was to use the OSGi meta data to define something that we
>> consider a public API. I agree to Sebastian that this might be difficult
>> for some components as they were not designed with a separation of
>> public and private API in mind. That's why I believe that suing
>> something a little more restrictive may help us to move forward and
>> improve the situation.
>
> IMO, we are only complicating the situation, because that would only
> make the situation less clear. Right now, we suggest that the project
> retains binary compatibility, unless explicitly documented (via
> package name, and Maven coordinates). Give
>
But we gain flexibility. Take JCS. The "public API" is basically just
what CacheAccess and friends define. Everything else is
implementation-specific. So the public API could be stable for a long
time while everything under the hood can be redesigned. I have quite
some experience with this approach and would prefer it over the current
commons policy any time.

Bye, Thomas

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

Reply | Threaded
Open this post in threaded view
|

Re: [ALL] About binary compatibility

Thomas Vandahl
In reply to this post by James Carman
On 13.06.16 20:57, James Carman wrote:
> I'd rather not make it (the OSGi metadata) the "source of truth".

I'm not insisting on OSGi meta data but I strongly believe that one
(single) source of truth is required. Suggest something else.

Bye, Thomas.


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

Reply | Threaded
Open this post in threaded view
|

Re: [ALL] About binary compatibility

James Carman
Agree we should have a "source of truth". Is there something wrong with
using an "internal" or "impl" package name? The bundle plugin for OSGi
doesn't export these by default, which would be a nice side effect! :).

On Mon, Jun 13, 2016 at 3:05 PM Thomas Vandahl <[hidden email]> wrote:

> On 13.06.16 20:57, James Carman wrote:
> > I'd rather not make it (the OSGi metadata) the "source of truth".
>
> I'm not insisting on OSGi meta data but I strongly believe that one
> (single) source of truth is required. Suggest something else.
>
> Bye, Thomas.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [ALL] About binary compatibility

Mark Thomas
In reply to this post by James Carman
Tomcat does this with a simple text file in the root of the
distribution. Compare Tomcat 9 [1] (currently in development) with
Tomcat 8 [2] (stable release).

We actually don't guarantee very much but Tomcat is a very different
type of project. The idea, however, could be re-used.

Mark

[1]
http://svn.apache.org/viewvc/tomcat/trunk/RELEASE-NOTES?view=annotate#l44

[2]
http://svn.apache.org/viewvc/tomcat/tc8.0.x/trunk/RELEASE-NOTES?view=annotate#l44

On 13/06/2016 19:57, James Carman wrote:

> I'd rather not make it (the OSGi metadata) the "source of truth".
>
> On Mon, Jun 13, 2016 at 2:49 PM Thomas Vandahl <[hidden email]> wrote:
>
>> On 05.06.16 20:33, James Carman wrote:
>>> Not quite. OSGi is a special case. It's much more restrictive than simple
>>> J2SE, because it can be. In the general case, the public API for OSGi is
>>> different from the public API for J2SE. Let's not confuse the two.
>>
>> My intention was to use the OSGi meta data to define something that we
>> consider a public API. I agree to Sebastian that this might be difficult
>> for some components as they were not designed with a separation of
>> public and private API in mind. That's why I believe that suing
>> something a little more restrictive may help us to move forward and
>> improve the situation.
>>
>> Bye, Thomas.
>>
>>
>> ---------------------------------------------------------------------
>> 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: [ALL] About binary compatibility

Jörg Schaible-5
In reply to this post by James Carman
Hi,

James Carman wrote:

> Agree we should have a "source of truth". Is there something wrong with
> using an "internal" or "impl" package name? The bundle plugin for OSGi
> doesn't export these by default, which would be a nice side effect! :).

While it is a step in the right direction, a package scoped solution does
not solve the problem of a public interface that should not be implemented
directly (as we've seen with the BCEL visitor). Time for Java 8 and its
default implementations ...

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: Re: [ALL] About binary compatibility

Andrey Loskutov
I like the way Eclipse it does for years:

1) Everything inside **/internal/ packages is non API by definition
2) MANIFEST.MF to use OSGI "Export-Package" attribute for "published" packages
3) Javadoc @noextend tag for classes not intended to be extended
4) Javadoc @noimplement tag for interfaces

A bonus for libraries with correct MANIFEST.MF is that they can be directly used as bundles inside any OSGI container (also Eclipse).

Example:
/**
 * An observable value whose changes can be vetoed by listeners.
 *
 * @param <T>
 *            the type of value being observed
 *
 * @noextend This interface is not intended to be extended by clients.
 * @noimplement This interface is not intended to be implemented by clients.
 *              Clients should instead subclass one of the classes that
 *              implement this interface. Note that direct implementers of this
 *              interface outside of the framework will be broken in future
 *              releases when methods are added to this interface.
 *
 * @since 1.0
 *
 */
public interface IVetoableValue<T> extends IObservableValue<T> {

Kind regards,
Andrey Loskutov

http://google.com/+AndreyLoskutov


> Gesendet: Dienstag, 14. Juni 2016 um 09:03 Uhr
> Von: "Jörg Schaible" <[hidden email]>
> An: [hidden email]
> Betreff: Re: [ALL] About binary compatibility
>
> Hi,
>
> James Carman wrote:
>
> > Agree we should have a "source of truth". Is there something wrong with
> > using an "internal" or "impl" package name? The bundle plugin for OSGi
> > doesn't export these by default, which would be a nice side effect! :).
>
> While it is a step in the right direction, a package scoped solution does
> not solve the problem of a public interface that should not be implemented
> directly (as we've seen with the BCEL visitor). Time for Java 8 and its
> default implementations ...
>
> 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: Re: [ALL] About binary compatibility

Matt Benson-2
On Tue, Jun 14, 2016 at 2:14 AM, Andrey Loskutov <[hidden email]> wrote:

> I like the way Eclipse it does for years:
>
> 1) Everything inside **/internal/ packages is non API by definition
> 2) MANIFEST.MF to use OSGI "Export-Package" attribute for "published"
> packages
> 3) Javadoc @noextend tag for classes not intended to be extended
> 4) Javadoc @noimplement tag for interfaces
>
> If "real" annotations were used for points 3 and 4, they could live
alongside a Java (6) Processor that, if the user had annotation processing
enabled, could fail the build (pretty sure this is doable).

Matt


> A bonus for libraries with correct MANIFEST.MF is that they can be
> directly used as bundles inside any OSGI container (also Eclipse).
>
> Example:
> /**
>  * An observable value whose changes can be vetoed by listeners.
>  *
>  * @param <T>
>  *            the type of value being observed
>  *
>  * @noextend This interface is not intended to be extended by clients.
>  * @noimplement This interface is not intended to be implemented by
> clients.
>  *              Clients should instead subclass one of the classes that
>  *              implement this interface. Note that direct implementers of
> this
>  *              interface outside of the framework will be broken in future
>  *              releases when methods are added to this interface.
>  *
>  * @since 1.0
>  *
>  */
> public interface IVetoableValue<T> extends IObservableValue<T> {
>
> Kind regards,
> Andrey Loskutov
>
> http://google.com/+AndreyLoskutov
>
>
> > Gesendet: Dienstag, 14. Juni 2016 um 09:03 Uhr
> > Von: "Jörg Schaible" <[hidden email]>
> > An: [hidden email]
> > Betreff: Re: [ALL] About binary compatibility
> >
> > Hi,
> >
> > James Carman wrote:
> >
> > > Agree we should have a "source of truth". Is there something wrong with
> > > using an "internal" or "impl" package name? The bundle plugin for OSGi
> > > doesn't export these by default, which would be a nice side effect! :).
> >
> > While it is a step in the right direction, a package scoped solution does
> > not solve the problem of a public interface that should not be
> implemented
> > directly (as we've seen with the BCEL visitor). Time for Java 8 and its
> > default implementations ...
> >
> > 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: Re: [ALL] About binary compatibility

garydgregory
On Jun 14, 2016 7:45 AM, "Matt Benson" <[hidden email]> wrote:

>
> On Tue, Jun 14, 2016 at 2:14 AM, Andrey Loskutov <[hidden email]> wrote:
>
> > I like the way Eclipse it does for years:
> >
> > 1) Everything inside **/internal/ packages is non API by definition
> > 2) MANIFEST.MF to use OSGI "Export-Package" attribute for "published"
> > packages
> > 3) Javadoc @noextend tag for classes not intended to be extended
> > 4) Javadoc @noimplement tag for interfaces
> >
> > If "real" annotations were used for points 3 and 4, they could live
> alongside a Java (6) Processor that, if the user had annotation processing
> enabled, could fail the build (pretty sure this is doable).

But where do these annotations live? Does each Commons component duplicate
them?

Gary

>
> Matt
>
>
> > A bonus for libraries with correct MANIFEST.MF is that they can be
> > directly used as bundles inside any OSGI container (also Eclipse).
> >
> > Example:
> > /**
> >  * An observable value whose changes can be vetoed by listeners.
> >  *
> >  * @param <T>
> >  *            the type of value being observed
> >  *
> >  * @noextend This interface is not intended to be extended by clients.
> >  * @noimplement This interface is not intended to be implemented by
> > clients.
> >  *              Clients should instead subclass one of the classes that
> >  *              implement this interface. Note that direct implementers
of
> > this
> >  *              interface outside of the framework will be broken in
future

> >  *              releases when methods are added to this interface.
> >  *
> >  * @since 1.0
> >  *
> >  */
> > public interface IVetoableValue<T> extends IObservableValue<T> {
> >
> > Kind regards,
> > Andrey Loskutov
> >
> > http://google.com/+AndreyLoskutov
> >
> >
> > > Gesendet: Dienstag, 14. Juni 2016 um 09:03 Uhr
> > > Von: "Jörg Schaible" <[hidden email]>
> > > An: [hidden email]
> > > Betreff: Re: [ALL] About binary compatibility
> > >
> > > Hi,
> > >
> > > James Carman wrote:
> > >
> > > > Agree we should have a "source of truth". Is there something wrong
with
> > > > using an "internal" or "impl" package name? The bundle plugin for
OSGi
> > > > doesn't export these by default, which would be a nice side effect!
:).
> > >
> > > While it is a step in the right direction, a package scoped solution
does
> > > not solve the problem of a public interface that should not be
> > implemented
> > > directly (as we've seen with the BCEL visitor). Time for Java 8 and
its

> > > default implementations ...
> > >
> > > 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: Re: [ALL] About binary compatibility

Matt Benson-2
On Jun 14, 2016 9:55 AM, "Gary Gregory" <[hidden email]> wrote:
>
>
> On Jun 14, 2016 7:45 AM, "Matt Benson" <[hidden email]> wrote:
> >
> > On Tue, Jun 14, 2016 at 2:14 AM, Andrey Loskutov <[hidden email]>
wrote:

> >
> > > I like the way Eclipse it does for years:
> > >
> > > 1) Everything inside **/internal/ packages is non API by definition
> > > 2) MANIFEST.MF to use OSGI "Export-Package" attribute for "published"
> > > packages
> > > 3) Javadoc @noextend tag for classes not intended to be extended
> > > 4) Javadoc @noimplement tag for interfaces
> > >
> > > If "real" annotations were used for points 3 and 4, they could live
> > alongside a Java (6) Processor that, if the user had annotation
processing
> > enabled, could fail the build (pretty sure this is doable).
>
> But where do these annotations live? Does each Commons component
duplicate them?
>

I thought about that, and would conclude that they should live in a thin
compile-time-only dependency library (it may be the case that usable
versions of these annotations already exist someplace, but the processor
would still have to be provided in this manner, so it doesn't really change
anything). No reason this couldn't be used outside Commons either, actually.

Matt

> Gary
>
> >
> > Matt
> >
> >
> > > A bonus for libraries with correct MANIFEST.MF is that they can be
> > > directly used as bundles inside any OSGI container (also Eclipse).
> > >
> > > Example:
> > > /**
> > >  * An observable value whose changes can be vetoed by listeners.
> > >  *
> > >  * @param <T>
> > >  *            the type of value being observed
> > >  *
> > >  * @noextend This interface is not intended to be extended by clients.
> > >  * @noimplement This interface is not intended to be implemented by
> > > clients.
> > >  *              Clients should instead subclass one of the classes
that
> > >  *              implement this interface. Note that direct
implementers of
> > > this
> > >  *              interface outside of the framework will be broken in
future

> > >  *              releases when methods are added to this interface.
> > >  *
> > >  * @since 1.0
> > >  *
> > >  */
> > > public interface IVetoableValue<T> extends IObservableValue<T> {
> > >
> > > Kind regards,
> > > Andrey Loskutov
> > >
> > > http://google.com/+AndreyLoskutov
> > >
> > >
> > > > Gesendet: Dienstag, 14. Juni 2016 um 09:03 Uhr
> > > > Von: "Jörg Schaible" <[hidden email]>
> > > > An: [hidden email]
> > > > Betreff: Re: [ALL] About binary compatibility
> > > >
> > > > Hi,
> > > >
> > > > James Carman wrote:
> > > >
> > > > > Agree we should have a "source of truth". Is there something
wrong with
> > > > > using an "internal" or "impl" package name? The bundle plugin for
OSGi
> > > > > doesn't export these by default, which would be a nice side
effect! :).
> > > >
> > > > While it is a step in the right direction, a package scoped
solution does
> > > > not solve the problem of a public interface that should not be
> > > implemented
> > > > directly (as we've seen with the BCEL visitor). Time for Java 8 and
its

> > > > default implementations ...
> > > >
> > > > 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: Re: [ALL] About binary compatibility

James Carman
Perhaps the new ASM-based replacement for CLIRR could have those as one of
its "components" in its TLP?

On Tue, Jun 14, 2016 at 11:00 AM Matt Benson <[hidden email]> wrote:

> On Jun 14, 2016 9:55 AM, "Gary Gregory" <[hidden email]> wrote:
> >
> >
> > On Jun 14, 2016 7:45 AM, "Matt Benson" <[hidden email]> wrote:
> > >
> > > On Tue, Jun 14, 2016 at 2:14 AM, Andrey Loskutov <[hidden email]>
> wrote:
> > >
> > > > I like the way Eclipse it does for years:
> > > >
> > > > 1) Everything inside **/internal/ packages is non API by definition
> > > > 2) MANIFEST.MF to use OSGI "Export-Package" attribute for "published"
> > > > packages
> > > > 3) Javadoc @noextend tag for classes not intended to be extended
> > > > 4) Javadoc @noimplement tag for interfaces
> > > >
> > > > If "real" annotations were used for points 3 and 4, they could live
> > > alongside a Java (6) Processor that, if the user had annotation
> processing
> > > enabled, could fail the build (pretty sure this is doable).
> >
> > But where do these annotations live? Does each Commons component
> duplicate them?
> >
>
> I thought about that, and would conclude that they should live in a thin
> compile-time-only dependency library (it may be the case that usable
> versions of these annotations already exist someplace, but the processor
> would still have to be provided in this manner, so it doesn't really change
> anything). No reason this couldn't be used outside Commons either,
> actually.
>
> Matt
>
> > Gary
> >
> > >
> > > Matt
> > >
> > >
> > > > A bonus for libraries with correct MANIFEST.MF is that they can be
> > > > directly used as bundles inside any OSGI container (also Eclipse).
> > > >
> > > > Example:
> > > > /**
> > > >  * An observable value whose changes can be vetoed by listeners.
> > > >  *
> > > >  * @param <T>
> > > >  *            the type of value being observed
> > > >  *
> > > >  * @noextend This interface is not intended to be extended by
> clients.
> > > >  * @noimplement This interface is not intended to be implemented by
> > > > clients.
> > > >  *              Clients should instead subclass one of the classes
> that
> > > >  *              implement this interface. Note that direct
> implementers of
> > > > this
> > > >  *              interface outside of the framework will be broken in
> future
> > > >  *              releases when methods are added to this interface.
> > > >  *
> > > >  * @since 1.0
> > > >  *
> > > >  */
> > > > public interface IVetoableValue<T> extends IObservableValue<T> {
> > > >
> > > > Kind regards,
> > > > Andrey Loskutov
> > > >
> > > > http://google.com/+AndreyLoskutov
> > > >
> > > >
> > > > > Gesendet: Dienstag, 14. Juni 2016 um 09:03 Uhr
> > > > > Von: "Jörg Schaible" <[hidden email]>
> > > > > An: [hidden email]
> > > > > Betreff: Re: [ALL] About binary compatibility
> > > > >
> > > > > Hi,
> > > > >
> > > > > James Carman wrote:
> > > > >
> > > > > > Agree we should have a "source of truth". Is there something
> wrong with
> > > > > > using an "internal" or "impl" package name? The bundle plugin for
> OSGi
> > > > > > doesn't export these by default, which would be a nice side
> effect! :).
> > > > >
> > > > > While it is a step in the right direction, a package scoped
> solution does
> > > > > not solve the problem of a public interface that should not be
> > > > implemented
> > > > > directly (as we've seen with the BCEL visitor). Time for Java 8 and
> its
> > > > > default implementations ...
> > > > >
> > > > > Cheers,
> > > > > Jörg
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: [hidden email]
> > > > For additional commands, e-mail: [hidden email]
> > > >
> > > >
>
123