Re: [Dbutil] Java 8 -> 11

[Elliotte Rusty Harold]

There's no rule that you have to change the package name and Maven
coordinates with a major version bump. As long as the API is
compatible, it's OK to keep those. But breaking compatibility with
Java 8 is a pretty big step forward.

The goal is to allow people to produce and accept bug fixes in
libraries without being forced to upgrade to a JDK version they might
not actually need, or even be actively prohibited from using. JDK 8
--> 9+ is a huge shift, much bigger than 7 --> 8, that breaks a lot of
projects in unexpected ways.

On Sun, Oct 15, 2023 at 2:32 PM Gary Gregory  wrote:
>
> A major version bump is rather heavy handed when no one is asking for a
> "real" 2.0 with breaking changes. A major bump would imply a package name
> and Maven coordinate change. At least that's what we have done before for
> major version changes. We've also done major version changes without those
> types of changes BUT it would be nice to be consistent. For example, to
> update to Java 11 for Commons Lang without a package name change would mean
> calling it 4.0 while the package stays as lang3, confusing.
>
> Gary
>
> On Sun, Oct 15, 2023, 9:17 AM Elliotte Rusty Harold 
> wrote:
>
> > Not a library I use so I don't have a horse in the race. However, I do
> > recommend making this a major version bump to 2.0 so as not to close
> > off the possibility of critical fixes for folks still on older JDKs.
> >
> > On Sun, Oct 15, 2023 at 8:42 AM Gary Gregory 
> > wrote:
> > >
> > > We've recently released DBUtils after a long period of inactivity. Java
> > 21
> > > is also out. I plan on raising the floor for this component to Java 11
> > and
> > > GitHub builds will keep testing on Java LTS 11, 17, 21. I've not seen any
> > > Java 21 issues yet.
> > >
> > > Gary
> >
> >
> >
> > --
> > Elliotte Rusty Harold
> > elh...@ibiblio.org
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> >



-- 
Elliotte Rusty Harold
elh...@ibiblio.org

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

Re: [Text] Java 21 failure with a double

[Romain Manni-Bucau]

You can always test the java version and adjust the asserts but, without
being a [text] expert, I assume the toString usage will create more
troubles than helping so can need to be dropped or totally embraced in the
main impl.
Another option is to request if the JDK dev want to fix it since it as a
lot of side effects - thinking to API - so it can be something they come
back on.

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le dim. 15 oct. 2023 à 21:42, Gary Gregory  a
écrit :

> Good find Roman, that suspiciously looks like the culprit and causes a
> mismatch with the tests use of DecimalFormatter.
>
> Do you see a way to make the test take this into account?
>
> Ty,
> Gary
>
>
> On Sun, Oct 15, 2023, 2:13 PM Romain Manni-Bucau 
> wrote:
>
> > Hi Gary,
> >
> > Can't it be
> >
> >
> https://github.com/openjdk/jdk/commit/fb605944b5b734c8b47a9122e7ab3d3dcf55f71e
> > ?
> >
> > Long story short, commons-text uses Double.toString which changed due to
> > double (resp float) precision so it impacts tests.
> >
> > Romain Manni-Bucau
> > @rmannibucau  |  Blog
> >  | Old Blog
> >  | Github <
> > https://github.com/rmannibucau> |
> > LinkedIn  | Book
> > <
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > >
> >
> >
> > Le dim. 15 oct. 2023 à 19:57, Gary Gregory  a
> > écrit :
> >
> > > Hi all,
> > >
> > > Can someone explain the 1 test failure on Java 21 in DoubleFornatTest?
> A
> > > one digit difference?
> > >
> > > Gary
> > >
> >
>

Re: [Text] Java 21 failure with a double

[Gary Gregory]

Good find Roman, that suspiciously looks like the culprit and causes a
mismatch with the tests use of DecimalFormatter.

Do you see a way to make the test take this into account?

Ty,
Gary


On Sun, Oct 15, 2023, 2:13 PM Romain Manni-Bucau 
wrote:

> Hi Gary,
>
> Can't it be
>
> https://github.com/openjdk/jdk/commit/fb605944b5b734c8b47a9122e7ab3d3dcf55f71e
> ?
>
> Long story short, commons-text uses Double.toString which changed due to
> double (resp float) precision so it impacts tests.
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github <
> https://github.com/rmannibucau> |
> LinkedIn  | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> Le dim. 15 oct. 2023 à 19:57, Gary Gregory  a
> écrit :
>
> > Hi all,
> >
> > Can someone explain the 1 test failure on Java 21 in DoubleFornatTest? A
> > one digit difference?
> >
> > Gary
> >
>

Re: [Text] Java 21 failure with a double

[Romain Manni-Bucau]

Hi Gary,

Can't it be
https://github.com/openjdk/jdk/commit/fb605944b5b734c8b47a9122e7ab3d3dcf55f71e
?

Long story short, commons-text uses Double.toString which changed due to
double (resp float) precision so it impacts tests.

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le dim. 15 oct. 2023 à 19:57, Gary Gregory  a
écrit :

> Hi all,
>
> Can someone explain the 1 test failure on Java 21 in DoubleFornatTest? A
> one digit difference?
>
> Gary
>

[Text] Java 21 failure with a double

[Gary Gregory]

Hi all,

Can someone explain the 1 test failure on Java 21 in DoubleFornatTest? A
one digit difference?

Gary

Re: [Dbutil] Java 8 -> 11

[Gary Gregory]

Having a new major version for everything is not going to help I'm afraid.
A major new version does not imply a Java platform change. The Maven
tooling is missing a feature to the display dependency updates goal that
let's you specify a maximum Java version, or maybe that exists but i doubt
it.

Even with that imaginary feature, tooling would not be bullet-proof since a
jar can contain a mix of class files with different byte code version.

On top of that, you also have the mess Java made with multi-release jars
where jars, by design, contain classes file of different byte code versions.

All of that to say that you can't tool your way to building a dependency
tree automatically.

Gary

On Sun, Oct 15, 2023, 10:59 AM John Patrick  wrote:

> As a consumer, I would prefer all java version changes to be considered
> major breaking changes for all apache commons components.
> I've waste lots of hours trying to find the oldest released version that
> supports a specific java version as the project can't yet upgrade for
> various reasons.
>
>
> On Sun, 15 Oct 2023 at 15:49, sebb  wrote:
>
> > On Sun, 15 Oct 2023 at 15:37, Elric  wrote:
> > >
> > > On 15/10/2023 16:31, Gary Gregory wrote:
> > > > A major version bump is rather heavy handed when no one is asking
> for a
> > > > "real" 2.0 with breaking changes.
> > >
> > > Agreed. My 2 cents: a minor version and a clear release note is plenty.
> > > Critical bug fixes can still be made by bumping the patch version,
> >
> > Are you sure about that ?
> > Has that been tried?
> >
> > > though given that Java 8 is nearly ten years old, it's really time for
> > > folks to upgrade.
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > > For additional commands, e-mail: dev-h...@commons.apache.org
> > >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> >
>

Re: [Dbutil] Java 8 -> 11

[John Patrick]

As a consumer, I would prefer all java version changes to be considered
major breaking changes for all apache commons components.
I've waste lots of hours trying to find the oldest released version that
supports a specific java version as the project can't yet upgrade for
various reasons.


On Sun, 15 Oct 2023 at 15:49, sebb  wrote:

> On Sun, 15 Oct 2023 at 15:37, Elric  wrote:
> >
> > On 15/10/2023 16:31, Gary Gregory wrote:
> > > A major version bump is rather heavy handed when no one is asking for a
> > > "real" 2.0 with breaking changes.
> >
> > Agreed. My 2 cents: a minor version and a clear release note is plenty.
> > Critical bug fixes can still be made by bumping the patch version,
>
> Are you sure about that ?
> Has that been tried?
>
> > though given that Java 8 is nearly ten years old, it's really time for
> > folks to upgrade.
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [Dbutil] Java 8 -> 11

[sebb]

On Sun, 15 Oct 2023 at 15:37, Elric  wrote:
>
> On 15/10/2023 16:31, Gary Gregory wrote:
> > A major version bump is rather heavy handed when no one is asking for a
> > "real" 2.0 with breaking changes.
>
> Agreed. My 2 cents: a minor version and a clear release note is plenty.
> Critical bug fixes can still be made by bumping the patch version,

Are you sure about that ?
Has that been tried?

> though given that Java 8 is nearly ten years old, it's really time for
> folks to upgrade.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

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

Re: [Dbutil] Java 8 -> 11

[Elric]

On 15/10/2023 16:31, Gary Gregory wrote:

A major version bump is rather heavy handed when no one is asking for a
"real" 2.0 with breaking changes. 


Agreed. My 2 cents: a minor version and a clear release note is plenty. 
Critical bug fixes can still be made by bumping the patch version, 
though given that Java 8 is nearly ten years old, it's really time for 
folks to upgrade.


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

Re: [Dbutil] Java 8 -> 11

[Gary Gregory]

A major version bump is rather heavy handed when no one is asking for a
"real" 2.0 with breaking changes. A major bump would imply a package name
and Maven coordinate change. At least that's what we have done before for
major version changes. We've also done major version changes without those
types of changes BUT it would be nice to be consistent. For example, to
update to Java 11 for Commons Lang without a package name change would mean
calling it 4.0 while the package stays as lang3, confusing.

Gary

On Sun, Oct 15, 2023, 9:17 AM Elliotte Rusty Harold 
wrote:

> Not a library I use so I don't have a horse in the race. However, I do
> recommend making this a major version bump to 2.0 so as not to close
> off the possibility of critical fixes for folks still on older JDKs.
>
> On Sun, Oct 15, 2023 at 8:42 AM Gary Gregory 
> wrote:
> >
> > We've recently released DBUtils after a long period of inactivity. Java
> 21
> > is also out. I plan on raising the floor for this component to Java 11
> and
> > GitHub builds will keep testing on Java LTS 11, 17, 21. I've not seen any
> > Java 21 issues yet.
> >
> > Gary
>
>
>
> --
> Elliotte Rusty Harold
> elh...@ibiblio.org
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [Dbutil] Java 8 -> 11

[Elliotte Rusty Harold]

Not a library I use so I don't have a horse in the race. However, I do
recommend making this a major version bump to 2.0 so as not to close
off the possibility of critical fixes for folks still on older JDKs.

On Sun, Oct 15, 2023 at 8:42 AM Gary Gregory  wrote:
>
> We've recently released DBUtils after a long period of inactivity. Java 21
> is also out. I plan on raising the floor for this component to Java 11 and
> GitHub builds will keep testing on Java LTS 11, 17, 21. I've not seen any
> Java 21 issues yet.
>
> Gary



-- 
Elliotte Rusty Harold
elh...@ibiblio.org

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

[Dbutil] Java 8 -> 11

[Gary Gregory]

We've recently released DBUtils after a long period of inactivity. Java 21
is also out. I plan on raising the floor for this component to Java 11 and
GitHub builds will keep testing on Java LTS 11, 17, 21. I've not seen any
Java 21 issues yet.

Gary