You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Stephen Colebourne <sc...@joda.org> on 2017/05/22 20:10:22 UTC

[lang] Java 9 module investigations

I took a stab at adding module-info.java to [lang]:
https://github.com/jodastephen/commons-lang/commit/5d5dd6809eeef90ea2b6245c0d0a488fb917e30a

Since the maven-bundle-plugin isn't working, I had to use antrun to
copy the module-info.class file out and back in again. A gross hack.

There are two key findings:

1) [lang] currently depends on java.desktop. ie. the whole of Swing
and AWT. This is because `AbstractCircuitBreaker` uses
`PropertyChangeListener`. This was a big problem for the JDK too, and
they removed 6 JDK methods in order to avoid dependencies like this.

My recommendation is to remove the change listener methods.
Potentially this needs to be done aggressively in 3.7, which implies
deprecation in v3.6.


2) The DateUtilsTest does not pass for me on JDK 9. There are 6 test
failures, something to do with time-zones causing the BASE_DATE to be
set incorrectly. These failures occur without the module-info code on
JDK 9, so they need fixing anyway. The test does pass on JDK 8, so it
is a JDK 9 issue (Idon't have the time to really figure out what is
wrong sadly).

thanks
Stephen

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

Re: [lang] Java 9 module investigations

Posted by Gary Gregory <ga...@gmail.com>.
On Mon, May 22, 2017 at 3:52 PM, Stephen Colebourne <sc...@joda.org>
wrote:

> On 22 May 2017 at 23:29, Gary Gregory <ga...@gmail.com> wrote:
> > Don't you mean 4.0 since changing:
> >
> > - AbstractCircuitBreaker.addChangeListener(PropertyChangeListener)
> > - AbstractCircuitBreaker.removeChangeListener(PropertyChangeListener)
> >
> > would break BC?
>
> No. I meant 3.7. [lang] has a problem with versioning because it is
> tied to JDK releases, so incompatible changes within a development
> stream are tricky. This may be a case where BC could be broken. Or it
> may not. (Up to the maintainers, not me)
>

IMO, this is 4.0 territory (we have another thread cooking about 4.0 ATM).
The simplest solution would be for [lang4] to provide its own
PropertyChangeListener kind of interface.

We could also and in addition add an AbstractCircuitBreaker to
[collections].

Thoughts?

Gary


>
> There needs to be a JDK 9 modular compatible release of each
> development stream given how low level it is within the ecosystem.
> Now, there is no requirement to remove the java.desktop dependency,
> but it will make [lang3] look rather odd, given what kind of library
> it is trying to be.
>
> One final option is to declare an optional dependency on java.desktop,
> such that the AbstractCircuitBreaker will fail to load unless the
> end-user manually chooses to add java.desktop. I don't like it, but it
> may be a compromise for compatibility.
>
> Stephen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>


-- 
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition
<https://www.amazon.com/gp/product/1617290459/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8>

<http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1617290459>
JUnit in Action, Second Edition
<https://www.amazon.com/gp/product/1935182021/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22>

<http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182021>
Spring Batch in Action
<https://www.amazon.com/gp/product/1935182951/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%7Blink_id%7D%7D%22%3ESpring+Batch+in+Action>
<http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182951>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: [lang] Java 9 module investigations

Posted by Benedikt Ritter <br...@apache.org>.
Hi,

> Am 23.05.2017 um 12:13 schrieb Emmanuel Bourg <eb...@apache.org>:
> 
> Le 23/05/2017 à 00:52, Stephen Colebourne a écrit :
> 
>> One final option is to declare an optional dependency on java.desktop,
>> such that the AbstractCircuitBreaker will fail to load unless the
>> end-user manually chooses to add java.desktop. I don't like it, but it
>> may be a compromise for compatibility.
> 
> Would it be possible to:
> 
> 1. deprecate add/removeChangeListener, keep only empty methods
> 2. remove the underlying PropertyChangeSupport
> 3. not declare a dependency on java.desktop, even optional
> 
> In this situation will Java 9 be able to load and use
> AbstractCircuitBreaker as long as the add/removeChangeListener methods
> are never used? Or will the runtime check the method signatures when
> loading the class?

I have created https://issues.apache.org/jira/browse/LANG-1339 <https://issues.apache.org/jira/browse/LANG-1339> for this. Let’s discuss possible solutions to the problem there.

Benedikt

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

Re: [lang] Java 9 module investigations

Posted by Emmanuel Bourg <eb...@apache.org>.
Le 23/05/2017 à 00:52, Stephen Colebourne a écrit :

> One final option is to declare an optional dependency on java.desktop,
> such that the AbstractCircuitBreaker will fail to load unless the
> end-user manually chooses to add java.desktop. I don't like it, but it
> may be a compromise for compatibility.

Would it be possible to:

1. deprecate add/removeChangeListener, keep only empty methods
2. remove the underlying PropertyChangeSupport
3. not declare a dependency on java.desktop, even optional

In this situation will Java 9 be able to load and use
AbstractCircuitBreaker as long as the add/removeChangeListener methods
are never used? Or will the runtime check the method signatures when
loading the class?

Emmanuel Bourg


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

Re: [lang] Java 9 module investigations

Posted by Stephen Colebourne <sc...@joda.org>.
On 22 May 2017 at 23:29, Gary Gregory <ga...@gmail.com> wrote:
> Don't you mean 4.0 since changing:
>
> - AbstractCircuitBreaker.addChangeListener(PropertyChangeListener)
> - AbstractCircuitBreaker.removeChangeListener(PropertyChangeListener)
>
> would break BC?

No. I meant 3.7. [lang] has a problem with versioning because it is
tied to JDK releases, so incompatible changes within a development
stream are tricky. This may be a case where BC could be broken. Or it
may not. (Up to the maintainers, not me)

There needs to be a JDK 9 modular compatible release of each
development stream given how low level it is within the ecosystem.
Now, there is no requirement to remove the java.desktop dependency,
but it will make [lang3] look rather odd, given what kind of library
it is trying to be.

One final option is to declare an optional dependency on java.desktop,
such that the AbstractCircuitBreaker will fail to load unless the
end-user manually chooses to add java.desktop. I don't like it, but it
may be a compromise for compatibility.

Stephen

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

Re: [lang] Java 9 module investigations

Posted by Gary Gregory <ga...@gmail.com>.
On Mon, May 22, 2017 at 1:10 PM, Stephen Colebourne <sc...@joda.org>
wrote:

> I took a stab at adding module-info.java to [lang]:
> https://github.com/jodastephen/commons-lang/commit/
> 5d5dd6809eeef90ea2b6245c0d0a488fb917e30a
>
> Since the maven-bundle-plugin isn't working, I had to use antrun to
> copy the module-info.class file out and back in again. A gross hack.
>
> There are two key findings:
>
> 1) [lang] currently depends on java.desktop. ie. the whole of Swing
> and AWT. This is because `AbstractCircuitBreaker` uses
> `PropertyChangeListener`. This was a big problem for the JDK too, and
> they removed 6 JDK methods in order to avoid dependencies like this.
>
> My recommendation is to remove the change listener methods.
> Potentially this needs to be done aggressively in 3.7, which implies
> deprecation in v3.6.
>

Don't you mean 4.0 since changing:

- AbstractCircuitBreaker.addChangeListener(PropertyChangeListener)
- AbstractCircuitBreaker.removeChangeListener(PropertyChangeListener)

would break BC?

Gary

>
>
> 2) The DateUtilsTest does not pass for me on JDK 9. There are 6 test
> failures, something to do with time-zones causing the BASE_DATE to be
> set incorrectly. These failures occur without the module-info code on
> JDK 9, so they need fixing anyway. The test does pass on JDK 8, so it
> is a JDK 9 issue (Idon't have the time to really figure out what is
> wrong sadly).
>
> thanks
> Stephen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>


-- 
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition
<https://www.amazon.com/gp/product/1617290459/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8>

<http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1617290459>
JUnit in Action, Second Edition
<https://www.amazon.com/gp/product/1935182021/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22>

<http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182021>
Spring Batch in Action
<https://www.amazon.com/gp/product/1935182951/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%7Blink_id%7D%7D%22%3ESpring+Batch+in+Action>
<http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182951>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory