You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avro.apache.org by Chad Preisler <ch...@gmail.com> on 2024/01/06 15:39:15 UTC
Make Apache Avro a proper Java module.
Hello,
I'm wondering if there is any interest in making Apache Avro a proper Java
module? The following changes are required.
- Add or generate the module-info.java file.
- Change the POM file to build a multi-release jar.
- Replace xerial Snappy with Apache commons-compress Snappy (see additional
information below).
- Update dependencies (like slf4) to the current versions.
- Build with newer JDK. I'm using 21.
Regarding the Snappy compressor, the next version of Apache
commons-compress (1.25.1) can be swapped in for Xerial with no issues. All
of the existing unit tests will work without changes. Xerial is not a
proper Java module at this time, and it uses JNI which could make it tricky
(especially if the goal is to use jlink).
For me, the motivation here is to use Avro with modularized
applications and custom runtime images using jlink.
I currently have this working locally, and I can contribute my changes.
Please let me know what you think.
Thanks,
Chad
Re: Make Apache Avro a proper Java module.
Posted by Niels Basjes <Ni...@basjes.nl>.
Hi,
I have been working on this one over the holidays:
https://github.com/apache/avro/pull/2699
I'm now able to build with Java 21 and still maintain backwards
compatibility for the final artifact with Java 8.
This also includes running (almost all) tests for the main avro module
under all JDKs (8, 11, 17 and 21).
From what I see now this change set would allow updating a lot of things
(dependencies, adding multirelease, etc.) without losing Java 8 support.
There are however a few rough edges; I had to remove the usage Unsafe and I
found that some tests simply fail on newer JDKs because of changes in the
way Java does things (mainly regarding reflection, modules and security).
Note that if we put dropping Java 8 support up for a vote I would +1 it.
Niels Basjes
On Mon, Jan 8, 2024 at 8:39 PM Chad Preisler <ch...@gmail.com>
wrote:
> I can do both depending on the timeline for 1.12.0. If you are cutting a
> release this week, that probably won't work. I don't think it will take
> long to switch to JDK 11 as your default, but I'm not familiar with testing
> changes to the github actions. Basically there will be some learning curve
> for me. You may want to consider adding JDK 21 and updating maven to the
> latest also.
>
> I'm happy to help and will have a decent amount of time to work on it this
> month.
>
> Let me know.
>
> On Mon, Jan 8, 2024 at 11:51 AM Ismaël Mejía <ie...@gmail.com> wrote:
>
> > +1 to move to Java 11. Most of our downstream projects have moved out of
> > Java 8 and the fact that we are getting behind on our own dependencies
> is a
> > sign of the current state of the ecosystem. So good to move, and no need
> to
> > change the full version. 1.12.0 should be good.
> >
> > We should probably tackle this in two different issues/PRs (1) to change
> > the baseline for development/support to Java 11 (build system, docker
> > image, github actions, enforce plugin, etc) and (2) for the proper Java
> 11
> > modules. Would you be up to prepare also a PR for (1) if we all agree
> Chad?
> >
> >
> >
> > On Mon, Jan 8, 2024 at 6:08 PM Stephen Kittelson
> > <st...@qualtrics.com.invalid> wrote:
> >
> >> More and more libraries these days are dropping support for JDK 8 (at
> >> least
> >> Spring Boot 3, Jakarta EE 11, Mockito 5, among others), so I personally
> >> think it would be fine to drop support for JDK 8 in 1.12.0, or maybe
> even
> >> bump the Avro release to 2.0.0 with the removal of JDK 8 support?
> >>
> >> On Mon, Jan 8, 2024 at 2:38 AM Martin Grigorov <mg...@apache.org>
> >> wrote:
> >>
> >> > Hi,
> >> >
> >> > I think this is a good idea!
> >> >
> >> > Some PRs (mostly by dependabot) are not merged because Avro needs to
> be
> >> JDK
> >> > 8 compatible and the dependencies require a newer JDK...
> >> > I am not sure whether Avro 1.12.0 still needs to be JDK 8 compatible
> or
> >> > not.
> >> >
> >> > Martin
> >> >
> >> > On Sat, Jan 6, 2024 at 5:55 PM Chad Preisler <chad.preisler@gmail.com
> >
> >> > wrote:
> >> >
> >> > > Hello,
> >> > >
> >> > > I'm wondering if there is any interest in making Apache Avro a
> proper
> >> > Java
> >> > > module? The following changes are required.
> >> > >
> >> > > - Add or generate the module-info.java file.
> >> > > - Change the POM file to build a multi-release jar.
> >> > > - Replace xerial Snappy with Apache commons-compress Snappy (see
> >> > additional
> >> > > information below).
> >> > > - Update dependencies (like slf4) to the current versions.
> >> > > - Build with newer JDK. I'm using 21.
> >> > >
> >> > > Regarding the Snappy compressor, the next version of Apache
> >> > > commons-compress (1.25.1) can be swapped in for Xerial with no
> issues.
> >> > All
> >> > > of the existing unit tests will work without changes. Xerial is not
> a
> >> > > proper Java module at this time, and it uses JNI which could make it
> >> > tricky
> >> > > (especially if the goal is to use jlink).
> >> > >
> >> > > For me, the motivation here is to use Avro with modularized
> >> > > applications and custom runtime images using jlink.
> >> > >
> >> > > I currently have this working locally, and I can contribute my
> >> changes.
> >> > >
> >> > > Please let me know what you think.
> >> > >
> >> > > Thanks,
> >> > >
> >> > > Chad
> >> > >
> >> >
> >>
> >
>
--
Best regards / Met vriendelijke groeten,
Niels Basjes
Re: Make Apache Avro a proper Java module.
Posted by Chad Preisler <ch...@gmail.com>.
I can do both depending on the timeline for 1.12.0. If you are cutting a
release this week, that probably won't work. I don't think it will take
long to switch to JDK 11 as your default, but I'm not familiar with testing
changes to the github actions. Basically there will be some learning curve
for me. You may want to consider adding JDK 21 and updating maven to the
latest also.
I'm happy to help and will have a decent amount of time to work on it this
month.
Let me know.
On Mon, Jan 8, 2024 at 11:51 AM Ismaël Mejía <ie...@gmail.com> wrote:
> +1 to move to Java 11. Most of our downstream projects have moved out of
> Java 8 and the fact that we are getting behind on our own dependencies is a
> sign of the current state of the ecosystem. So good to move, and no need to
> change the full version. 1.12.0 should be good.
>
> We should probably tackle this in two different issues/PRs (1) to change
> the baseline for development/support to Java 11 (build system, docker
> image, github actions, enforce plugin, etc) and (2) for the proper Java 11
> modules. Would you be up to prepare also a PR for (1) if we all agree Chad?
>
>
>
> On Mon, Jan 8, 2024 at 6:08 PM Stephen Kittelson
> <st...@qualtrics.com.invalid> wrote:
>
>> More and more libraries these days are dropping support for JDK 8 (at
>> least
>> Spring Boot 3, Jakarta EE 11, Mockito 5, among others), so I personally
>> think it would be fine to drop support for JDK 8 in 1.12.0, or maybe even
>> bump the Avro release to 2.0.0 with the removal of JDK 8 support?
>>
>> On Mon, Jan 8, 2024 at 2:38 AM Martin Grigorov <mg...@apache.org>
>> wrote:
>>
>> > Hi,
>> >
>> > I think this is a good idea!
>> >
>> > Some PRs (mostly by dependabot) are not merged because Avro needs to be
>> JDK
>> > 8 compatible and the dependencies require a newer JDK...
>> > I am not sure whether Avro 1.12.0 still needs to be JDK 8 compatible or
>> > not.
>> >
>> > Martin
>> >
>> > On Sat, Jan 6, 2024 at 5:55 PM Chad Preisler <ch...@gmail.com>
>> > wrote:
>> >
>> > > Hello,
>> > >
>> > > I'm wondering if there is any interest in making Apache Avro a proper
>> > Java
>> > > module? The following changes are required.
>> > >
>> > > - Add or generate the module-info.java file.
>> > > - Change the POM file to build a multi-release jar.
>> > > - Replace xerial Snappy with Apache commons-compress Snappy (see
>> > additional
>> > > information below).
>> > > - Update dependencies (like slf4) to the current versions.
>> > > - Build with newer JDK. I'm using 21.
>> > >
>> > > Regarding the Snappy compressor, the next version of Apache
>> > > commons-compress (1.25.1) can be swapped in for Xerial with no issues.
>> > All
>> > > of the existing unit tests will work without changes. Xerial is not a
>> > > proper Java module at this time, and it uses JNI which could make it
>> > tricky
>> > > (especially if the goal is to use jlink).
>> > >
>> > > For me, the motivation here is to use Avro with modularized
>> > > applications and custom runtime images using jlink.
>> > >
>> > > I currently have this working locally, and I can contribute my
>> changes.
>> > >
>> > > Please let me know what you think.
>> > >
>> > > Thanks,
>> > >
>> > > Chad
>> > >
>> >
>>
>
Re: Make Apache Avro a proper Java module.
Posted by Ismaël Mejía <ie...@gmail.com>.
+1 to move to Java 11. Most of our downstream projects have moved out of
Java 8 and the fact that we are getting behind on our own dependencies is a
sign of the current state of the ecosystem. So good to move, and no need to
change the full version. 1.12.0 should be good.
We should probably tackle this in two different issues/PRs (1) to change
the baseline for development/support to Java 11 (build system, docker
image, github actions, enforce plugin, etc) and (2) for the proper Java 11
modules. Would you be up to prepare also a PR for (1) if we all agree Chad?
On Mon, Jan 8, 2024 at 6:08 PM Stephen Kittelson
<st...@qualtrics.com.invalid> wrote:
> More and more libraries these days are dropping support for JDK 8 (at least
> Spring Boot 3, Jakarta EE 11, Mockito 5, among others), so I personally
> think it would be fine to drop support for JDK 8 in 1.12.0, or maybe even
> bump the Avro release to 2.0.0 with the removal of JDK 8 support?
>
> On Mon, Jan 8, 2024 at 2:38 AM Martin Grigorov <mg...@apache.org>
> wrote:
>
> > Hi,
> >
> > I think this is a good idea!
> >
> > Some PRs (mostly by dependabot) are not merged because Avro needs to be
> JDK
> > 8 compatible and the dependencies require a newer JDK...
> > I am not sure whether Avro 1.12.0 still needs to be JDK 8 compatible or
> > not.
> >
> > Martin
> >
> > On Sat, Jan 6, 2024 at 5:55 PM Chad Preisler <ch...@gmail.com>
> > wrote:
> >
> > > Hello,
> > >
> > > I'm wondering if there is any interest in making Apache Avro a proper
> > Java
> > > module? The following changes are required.
> > >
> > > - Add or generate the module-info.java file.
> > > - Change the POM file to build a multi-release jar.
> > > - Replace xerial Snappy with Apache commons-compress Snappy (see
> > additional
> > > information below).
> > > - Update dependencies (like slf4) to the current versions.
> > > - Build with newer JDK. I'm using 21.
> > >
> > > Regarding the Snappy compressor, the next version of Apache
> > > commons-compress (1.25.1) can be swapped in for Xerial with no issues.
> > All
> > > of the existing unit tests will work without changes. Xerial is not a
> > > proper Java module at this time, and it uses JNI which could make it
> > tricky
> > > (especially if the goal is to use jlink).
> > >
> > > For me, the motivation here is to use Avro with modularized
> > > applications and custom runtime images using jlink.
> > >
> > > I currently have this working locally, and I can contribute my changes.
> > >
> > > Please let me know what you think.
> > >
> > > Thanks,
> > >
> > > Chad
> > >
> >
>
Re: Make Apache Avro a proper Java module.
Posted by Martin Grigorov <mg...@apache.org>.
Hi Chad,
Please open a Draft PR with your changes!
It will be easier to review and comment on it!
Thank you!
On Fri, Feb 2, 2024 at 10:20 PM Chad Preisler <ch...@gmail.com>
wrote:
> I created a fork and branch that removes JDK 8 from the build and makes 11
> default. The changes can be seen here:
>
> https://github.com/cpreisler/avro/tree/remove-jdk-8
>
> Let me know what if anything you want me to do with this.
>
>
> On Mon, Jan 29, 2024 at 4:19 AM Niels Basjes <Ni...@basjes.nl> wrote:
>
> > Yes, Dropping the runtime support for Java 8 is enough of a reason to
> bump
> > to AVRO 2.0.0 for me.
> >
> > On Mon, Jan 8, 2024 at 6:09 PM Stephen Kittelson
> > <st...@qualtrics.com.invalid> wrote:
> >
> >> More and more libraries these days are dropping support for JDK 8 (at
> >> least
> >> Spring Boot 3, Jakarta EE 11, Mockito 5, among others), so I personally
> >> think it would be fine to drop support for JDK 8 in 1.12.0, or maybe
> even
> >> bump the Avro release to 2.0.0 with the removal of JDK 8 support?
> >>
> >> On Mon, Jan 8, 2024 at 2:38 AM Martin Grigorov <mg...@apache.org>
> >> wrote:
> >>
> >> > Hi,
> >> >
> >> > I think this is a good idea!
> >> >
> >> > Some PRs (mostly by dependabot) are not merged because Avro needs to
> be
> >> JDK
> >> > 8 compatible and the dependencies require a newer JDK...
> >> > I am not sure whether Avro 1.12.0 still needs to be JDK 8 compatible
> or
> >> > not.
> >> >
> >> > Martin
> >> >
> >> > On Sat, Jan 6, 2024 at 5:55 PM Chad Preisler <chad.preisler@gmail.com
> >
> >> > wrote:
> >> >
> >> > > Hello,
> >> > >
> >> > > I'm wondering if there is any interest in making Apache Avro a
> proper
> >> > Java
> >> > > module? The following changes are required.
> >> > >
> >> > > - Add or generate the module-info.java file.
> >> > > - Change the POM file to build a multi-release jar.
> >> > > - Replace xerial Snappy with Apache commons-compress Snappy (see
> >> > additional
> >> > > information below).
> >> > > - Update dependencies (like slf4) to the current versions.
> >> > > - Build with newer JDK. I'm using 21.
> >> > >
> >> > > Regarding the Snappy compressor, the next version of Apache
> >> > > commons-compress (1.25.1) can be swapped in for Xerial with no
> issues.
> >> > All
> >> > > of the existing unit tests will work without changes. Xerial is not
> a
> >> > > proper Java module at this time, and it uses JNI which could make it
> >> > tricky
> >> > > (especially if the goal is to use jlink).
> >> > >
> >> > > For me, the motivation here is to use Avro with modularized
> >> > > applications and custom runtime images using jlink.
> >> > >
> >> > > I currently have this working locally, and I can contribute my
> >> changes.
> >> > >
> >> > > Please let me know what you think.
> >> > >
> >> > > Thanks,
> >> > >
> >> > > Chad
> >> > >
> >> >
> >>
> >
> >
> > --
> > Best regards / Met vriendelijke groeten,
> >
> > Niels Basjes
> >
>
Re: Make Apache Avro a proper Java module.
Posted by Martin Grigorov <mg...@apache.org>.
Hi Chad,
Yes!
Dropping support for Java 8 is in the talks!
We want to release 1.12 with the current changes in the 'main' branch
(hopefully in the next few weeks) and then we can drop Java 8 in 'main'
that will be Avro 2.0 most likely!
You can open a PR for discussion now! But it will be merged once 1.12 is
released.
Martin
On Sun, Feb 11, 2024 at 4:20 PM Chad Preisler <ch...@gmail.com>
wrote:
> Hello,
>
> Will Avro be moving ahead with the removal of JDK8?
>
> Thanks,
> Chad
>
>
> On Fri, Feb 2, 2024 at 2:12 PM Chad Preisler <ch...@gmail.com>
> wrote:
>
> > I created a fork and branch that removes JDK 8 from the build and makes
> 11
> > default. The changes can be seen here:
> >
> > https://github.com/cpreisler/avro/tree/remove-jdk-8
> >
> > Let me know what if anything you want me to do with this.
> >
> >
> > On Mon, Jan 29, 2024 at 4:19 AM Niels Basjes <Ni...@basjes.nl> wrote:
> >
> >> Yes, Dropping the runtime support for Java 8 is enough of a reason to
> >> bump to AVRO 2.0.0 for me.
> >>
> >> On Mon, Jan 8, 2024 at 6:09 PM Stephen Kittelson
> >> <st...@qualtrics.com.invalid> wrote:
> >>
> >>> More and more libraries these days are dropping support for JDK 8 (at
> >>> least
> >>> Spring Boot 3, Jakarta EE 11, Mockito 5, among others), so I personally
> >>> think it would be fine to drop support for JDK 8 in 1.12.0, or maybe
> even
> >>> bump the Avro release to 2.0.0 with the removal of JDK 8 support?
> >>>
> >>> On Mon, Jan 8, 2024 at 2:38 AM Martin Grigorov <mg...@apache.org>
> >>> wrote:
> >>>
> >>> > Hi,
> >>> >
> >>> > I think this is a good idea!
> >>> >
> >>> > Some PRs (mostly by dependabot) are not merged because Avro needs to
> >>> be JDK
> >>> > 8 compatible and the dependencies require a newer JDK...
> >>> > I am not sure whether Avro 1.12.0 still needs to be JDK 8 compatible
> or
> >>> > not.
> >>> >
> >>> > Martin
> >>> >
> >>> > On Sat, Jan 6, 2024 at 5:55 PM Chad Preisler <
> chad.preisler@gmail.com>
> >>> > wrote:
> >>> >
> >>> > > Hello,
> >>> > >
> >>> > > I'm wondering if there is any interest in making Apache Avro a
> proper
> >>> > Java
> >>> > > module? The following changes are required.
> >>> > >
> >>> > > - Add or generate the module-info.java file.
> >>> > > - Change the POM file to build a multi-release jar.
> >>> > > - Replace xerial Snappy with Apache commons-compress Snappy (see
> >>> > additional
> >>> > > information below).
> >>> > > - Update dependencies (like slf4) to the current versions.
> >>> > > - Build with newer JDK. I'm using 21.
> >>> > >
> >>> > > Regarding the Snappy compressor, the next version of Apache
> >>> > > commons-compress (1.25.1) can be swapped in for Xerial with no
> >>> issues.
> >>> > All
> >>> > > of the existing unit tests will work without changes. Xerial is
> not a
> >>> > > proper Java module at this time, and it uses JNI which could make
> it
> >>> > tricky
> >>> > > (especially if the goal is to use jlink).
> >>> > >
> >>> > > For me, the motivation here is to use Avro with modularized
> >>> > > applications and custom runtime images using jlink.
> >>> > >
> >>> > > I currently have this working locally, and I can contribute my
> >>> changes.
> >>> > >
> >>> > > Please let me know what you think.
> >>> > >
> >>> > > Thanks,
> >>> > >
> >>> > > Chad
> >>> > >
> >>> >
> >>>
> >>
> >>
> >> --
> >> Best regards / Met vriendelijke groeten,
> >>
> >> Niels Basjes
> >>
> >
>
Re: Make Apache Avro a proper Java module.
Posted by Chad Preisler <ch...@gmail.com>.
Hello,
Will Avro be moving ahead with the removal of JDK8?
Thanks,
Chad
On Fri, Feb 2, 2024 at 2:12 PM Chad Preisler <ch...@gmail.com>
wrote:
> I created a fork and branch that removes JDK 8 from the build and makes 11
> default. The changes can be seen here:
>
> https://github.com/cpreisler/avro/tree/remove-jdk-8
>
> Let me know what if anything you want me to do with this.
>
>
> On Mon, Jan 29, 2024 at 4:19 AM Niels Basjes <Ni...@basjes.nl> wrote:
>
>> Yes, Dropping the runtime support for Java 8 is enough of a reason to
>> bump to AVRO 2.0.0 for me.
>>
>> On Mon, Jan 8, 2024 at 6:09 PM Stephen Kittelson
>> <st...@qualtrics.com.invalid> wrote:
>>
>>> More and more libraries these days are dropping support for JDK 8 (at
>>> least
>>> Spring Boot 3, Jakarta EE 11, Mockito 5, among others), so I personally
>>> think it would be fine to drop support for JDK 8 in 1.12.0, or maybe even
>>> bump the Avro release to 2.0.0 with the removal of JDK 8 support?
>>>
>>> On Mon, Jan 8, 2024 at 2:38 AM Martin Grigorov <mg...@apache.org>
>>> wrote:
>>>
>>> > Hi,
>>> >
>>> > I think this is a good idea!
>>> >
>>> > Some PRs (mostly by dependabot) are not merged because Avro needs to
>>> be JDK
>>> > 8 compatible and the dependencies require a newer JDK...
>>> > I am not sure whether Avro 1.12.0 still needs to be JDK 8 compatible or
>>> > not.
>>> >
>>> > Martin
>>> >
>>> > On Sat, Jan 6, 2024 at 5:55 PM Chad Preisler <ch...@gmail.com>
>>> > wrote:
>>> >
>>> > > Hello,
>>> > >
>>> > > I'm wondering if there is any interest in making Apache Avro a proper
>>> > Java
>>> > > module? The following changes are required.
>>> > >
>>> > > - Add or generate the module-info.java file.
>>> > > - Change the POM file to build a multi-release jar.
>>> > > - Replace xerial Snappy with Apache commons-compress Snappy (see
>>> > additional
>>> > > information below).
>>> > > - Update dependencies (like slf4) to the current versions.
>>> > > - Build with newer JDK. I'm using 21.
>>> > >
>>> > > Regarding the Snappy compressor, the next version of Apache
>>> > > commons-compress (1.25.1) can be swapped in for Xerial with no
>>> issues.
>>> > All
>>> > > of the existing unit tests will work without changes. Xerial is not a
>>> > > proper Java module at this time, and it uses JNI which could make it
>>> > tricky
>>> > > (especially if the goal is to use jlink).
>>> > >
>>> > > For me, the motivation here is to use Avro with modularized
>>> > > applications and custom runtime images using jlink.
>>> > >
>>> > > I currently have this working locally, and I can contribute my
>>> changes.
>>> > >
>>> > > Please let me know what you think.
>>> > >
>>> > > Thanks,
>>> > >
>>> > > Chad
>>> > >
>>> >
>>>
>>
>>
>> --
>> Best regards / Met vriendelijke groeten,
>>
>> Niels Basjes
>>
>
Re: Make Apache Avro a proper Java module.
Posted by Chad Preisler <ch...@gmail.com>.
I created a fork and branch that removes JDK 8 from the build and makes 11
default. The changes can be seen here:
https://github.com/cpreisler/avro/tree/remove-jdk-8
Let me know what if anything you want me to do with this.
On Mon, Jan 29, 2024 at 4:19 AM Niels Basjes <Ni...@basjes.nl> wrote:
> Yes, Dropping the runtime support for Java 8 is enough of a reason to bump
> to AVRO 2.0.0 for me.
>
> On Mon, Jan 8, 2024 at 6:09 PM Stephen Kittelson
> <st...@qualtrics.com.invalid> wrote:
>
>> More and more libraries these days are dropping support for JDK 8 (at
>> least
>> Spring Boot 3, Jakarta EE 11, Mockito 5, among others), so I personally
>> think it would be fine to drop support for JDK 8 in 1.12.0, or maybe even
>> bump the Avro release to 2.0.0 with the removal of JDK 8 support?
>>
>> On Mon, Jan 8, 2024 at 2:38 AM Martin Grigorov <mg...@apache.org>
>> wrote:
>>
>> > Hi,
>> >
>> > I think this is a good idea!
>> >
>> > Some PRs (mostly by dependabot) are not merged because Avro needs to be
>> JDK
>> > 8 compatible and the dependencies require a newer JDK...
>> > I am not sure whether Avro 1.12.0 still needs to be JDK 8 compatible or
>> > not.
>> >
>> > Martin
>> >
>> > On Sat, Jan 6, 2024 at 5:55 PM Chad Preisler <ch...@gmail.com>
>> > wrote:
>> >
>> > > Hello,
>> > >
>> > > I'm wondering if there is any interest in making Apache Avro a proper
>> > Java
>> > > module? The following changes are required.
>> > >
>> > > - Add or generate the module-info.java file.
>> > > - Change the POM file to build a multi-release jar.
>> > > - Replace xerial Snappy with Apache commons-compress Snappy (see
>> > additional
>> > > information below).
>> > > - Update dependencies (like slf4) to the current versions.
>> > > - Build with newer JDK. I'm using 21.
>> > >
>> > > Regarding the Snappy compressor, the next version of Apache
>> > > commons-compress (1.25.1) can be swapped in for Xerial with no issues.
>> > All
>> > > of the existing unit tests will work without changes. Xerial is not a
>> > > proper Java module at this time, and it uses JNI which could make it
>> > tricky
>> > > (especially if the goal is to use jlink).
>> > >
>> > > For me, the motivation here is to use Avro with modularized
>> > > applications and custom runtime images using jlink.
>> > >
>> > > I currently have this working locally, and I can contribute my
>> changes.
>> > >
>> > > Please let me know what you think.
>> > >
>> > > Thanks,
>> > >
>> > > Chad
>> > >
>> >
>>
>
>
> --
> Best regards / Met vriendelijke groeten,
>
> Niels Basjes
>
Re: Make Apache Avro a proper Java module.
Posted by Niels Basjes <Ni...@basjes.nl>.
Yes, Dropping the runtime support for Java 8 is enough of a reason to bump
to AVRO 2.0.0 for me.
On Mon, Jan 8, 2024 at 6:09 PM Stephen Kittelson
<st...@qualtrics.com.invalid> wrote:
> More and more libraries these days are dropping support for JDK 8 (at least
> Spring Boot 3, Jakarta EE 11, Mockito 5, among others), so I personally
> think it would be fine to drop support for JDK 8 in 1.12.0, or maybe even
> bump the Avro release to 2.0.0 with the removal of JDK 8 support?
>
> On Mon, Jan 8, 2024 at 2:38 AM Martin Grigorov <mg...@apache.org>
> wrote:
>
> > Hi,
> >
> > I think this is a good idea!
> >
> > Some PRs (mostly by dependabot) are not merged because Avro needs to be
> JDK
> > 8 compatible and the dependencies require a newer JDK...
> > I am not sure whether Avro 1.12.0 still needs to be JDK 8 compatible or
> > not.
> >
> > Martin
> >
> > On Sat, Jan 6, 2024 at 5:55 PM Chad Preisler <ch...@gmail.com>
> > wrote:
> >
> > > Hello,
> > >
> > > I'm wondering if there is any interest in making Apache Avro a proper
> > Java
> > > module? The following changes are required.
> > >
> > > - Add or generate the module-info.java file.
> > > - Change the POM file to build a multi-release jar.
> > > - Replace xerial Snappy with Apache commons-compress Snappy (see
> > additional
> > > information below).
> > > - Update dependencies (like slf4) to the current versions.
> > > - Build with newer JDK. I'm using 21.
> > >
> > > Regarding the Snappy compressor, the next version of Apache
> > > commons-compress (1.25.1) can be swapped in for Xerial with no issues.
> > All
> > > of the existing unit tests will work without changes. Xerial is not a
> > > proper Java module at this time, and it uses JNI which could make it
> > tricky
> > > (especially if the goal is to use jlink).
> > >
> > > For me, the motivation here is to use Avro with modularized
> > > applications and custom runtime images using jlink.
> > >
> > > I currently have this working locally, and I can contribute my changes.
> > >
> > > Please let me know what you think.
> > >
> > > Thanks,
> > >
> > > Chad
> > >
> >
>
--
Best regards / Met vriendelijke groeten,
Niels Basjes
Re: Make Apache Avro a proper Java module.
Posted by Stephen Kittelson <st...@qualtrics.com.INVALID>.
More and more libraries these days are dropping support for JDK 8 (at least
Spring Boot 3, Jakarta EE 11, Mockito 5, among others), so I personally
think it would be fine to drop support for JDK 8 in 1.12.0, or maybe even
bump the Avro release to 2.0.0 with the removal of JDK 8 support?
On Mon, Jan 8, 2024 at 2:38 AM Martin Grigorov <mg...@apache.org> wrote:
> Hi,
>
> I think this is a good idea!
>
> Some PRs (mostly by dependabot) are not merged because Avro needs to be JDK
> 8 compatible and the dependencies require a newer JDK...
> I am not sure whether Avro 1.12.0 still needs to be JDK 8 compatible or
> not.
>
> Martin
>
> On Sat, Jan 6, 2024 at 5:55 PM Chad Preisler <ch...@gmail.com>
> wrote:
>
> > Hello,
> >
> > I'm wondering if there is any interest in making Apache Avro a proper
> Java
> > module? The following changes are required.
> >
> > - Add or generate the module-info.java file.
> > - Change the POM file to build a multi-release jar.
> > - Replace xerial Snappy with Apache commons-compress Snappy (see
> additional
> > information below).
> > - Update dependencies (like slf4) to the current versions.
> > - Build with newer JDK. I'm using 21.
> >
> > Regarding the Snappy compressor, the next version of Apache
> > commons-compress (1.25.1) can be swapped in for Xerial with no issues.
> All
> > of the existing unit tests will work without changes. Xerial is not a
> > proper Java module at this time, and it uses JNI which could make it
> tricky
> > (especially if the goal is to use jlink).
> >
> > For me, the motivation here is to use Avro with modularized
> > applications and custom runtime images using jlink.
> >
> > I currently have this working locally, and I can contribute my changes.
> >
> > Please let me know what you think.
> >
> > Thanks,
> >
> > Chad
> >
>
Re: Make Apache Avro a proper Java module.
Posted by Martin Grigorov <mg...@apache.org>.
Hi,
I think this is a good idea!
Some PRs (mostly by dependabot) are not merged because Avro needs to be JDK
8 compatible and the dependencies require a newer JDK...
I am not sure whether Avro 1.12.0 still needs to be JDK 8 compatible or not.
Martin
On Sat, Jan 6, 2024 at 5:55 PM Chad Preisler <ch...@gmail.com>
wrote:
> Hello,
>
> I'm wondering if there is any interest in making Apache Avro a proper Java
> module? The following changes are required.
>
> - Add or generate the module-info.java file.
> - Change the POM file to build a multi-release jar.
> - Replace xerial Snappy with Apache commons-compress Snappy (see additional
> information below).
> - Update dependencies (like slf4) to the current versions.
> - Build with newer JDK. I'm using 21.
>
> Regarding the Snappy compressor, the next version of Apache
> commons-compress (1.25.1) can be swapped in for Xerial with no issues. All
> of the existing unit tests will work without changes. Xerial is not a
> proper Java module at this time, and it uses JNI which could make it tricky
> (especially if the goal is to use jlink).
>
> For me, the motivation here is to use Avro with modularized
> applications and custom runtime images using jlink.
>
> I currently have this working locally, and I can contribute my changes.
>
> Please let me know what you think.
>
> Thanks,
>
> Chad
>