.
> This will probably require code changes, CMake changes, and test
> changes.
>
>
> From: Jean-Baptiste Onofré
> Date: Wednesday, December 13, 2023 at 11:45 AM
> To: dev@arrow.apache.org
> Subject: Re: [DISC][Java]: Migrate Arrow Java to JPMS Java Platform
> Module
-c-data/x86_64). This will probably
require code changes, CMake changes, and test changes.
From: Jean-Baptiste Onofré
Date: Wednesday, December 13, 2023 at 11:45 AM
To: dev@arrow.apache.org
Subject: Re: [DISC][Java]: Migrate Arrow Java to JPMS Java Platform Module
System
Agree with David on
rrow.flight.core=ALL-UNNAMED, but if they aren’t
> > using Flight, they’ll get a warning about an unrecognized module. Any
> > thoughts about the best way to present these command-line changes?
> >
> >
> > From: Jean-Baptiste Onofré
> > Date: Wednesday, Dec
t;
> From: Jean-Baptiste Onofré
> Date: Wednesday, December 13, 2023 at 6:58 AM
> To: dev@arrow.apache.org
> Subject: Re: [DISC][Java]: Migrate Arrow Java to JPMS Java Platform
> Module System
> Hi,
>
> We have a "split packages" between flight-core and flig
: Re: [DISC][Java]: Migrate Arrow Java to JPMS Java Platform Module
System
Hi,
We have a "split packages" between flight-core and flight-grpc. I
don't think anyone is using only flight-core to create a new
"transport".
I think it's acceptable to combine flight-c
flight-grpc reuse packages. I’d like to
> > combine flight-core and flight-grpc because of this (currently we only
> > have Flight using grpc in Java).
> >
> > After Flight I’d take a look at the modules that have native code:
> >
> > * arrow-c-data
> >
-dataset
> * arrow-gandiva
>
>
> From: James Duong
> Date: Tuesday, December 5, 2023 at 1:39 PM
> To: dev@arrow.apache.org
> Subject: Re: [DISC][Java]: Migrate Arrow Java to JPMS Java Platform
> Module System
> I expect that we’d still have to change CLI arguments in JDK17.
: Re: [DISC][Java]: Migrate Arrow Java to JPMS Java Platform Module
System
I expect that we’d still have to change CLI arguments in JDK17.
The need for changing the CLI arguments is due to memory-core now being a named
module while requiring access to Unsafe and using reflection for accessing
, 2023 at 9:28 AM
To: dev@arrow.apache.org
Subject: Re: [DISC][Java]: Migrate Arrow Java to JPMS Java Platform Module
System
I believe Spark 4.0 was mentioned before. It’ll require Java 17 and will be
released in a few months (June?).
Best regards,
Adam Lippai
On Tue, Dec 5, 2023 at 12:05 David Li
til the new memory module from Java 21 is
> > available?
> >
> > The module-info.java files are written fairly naively. I haven’t
> > inspected thoroughly to determine what packages users will need.
> >
> > We can continue modularizing more components in a sep
ponents in a separate PR. Ideally
> all the user breakage (class movement, new command-line argument
> requirements) happens within one major Arrow version.
>
> From: James Duong
> Date: Tuesday, November 21, 2023 at 1:16 PM
> To: dev@arrow.apache.org
> Subject: Re: [DISC][Java]:
requires refactoring much of the memory module code and implementing a module
using the foreign memory interface.
From: James Duong
Date: Tuesday, November 28, 2023 at 6:48 PM
To: dev@arrow.apache.org
Subject: Re: [DISC][Java]: Migrate Arrow Java to JPMS Java Platform Module
System
Hi,
I’ve
movement, new command-line argument requirements) happens
within one major Arrow version.
From: James Duong
Date: Tuesday, November 21, 2023 at 1:16 PM
To: dev@arrow.apache.org
Subject: Re: [DISC][Java]: Migrate Arrow Java to JPMS Java Platform Module
System
I’m following up on this topic
I’m following up on this topic.
David has a PR from last year that’s done much of the heavy lifting for
refactoring the codebase to be package-friendly.
https://github.com/apache/arrow/pull/13072
What’s changed since and what’s left:
* New components have been added (Flight SQL for example)
14 matches
Mail list logo
