Re: Current state of Apache Commons Math and Geometry
> On Feb 23, 2026, at 4:03 AM, Johann Sorel via dev > wrote: > > >> >> Hi. >> >>> Le ven. 20 févr. 2026 à 14:20, Elliotte Rusty Harold >>> a écrit : >>> On Fri, Feb 20, 2026 at 3:58 AM Gilles Sadowski >>> wrote: Le jeu. 19 févr. 2026 à 14:57, Johann Sorel via dev I agree: Collaboration on reusable code is a better way. >>> >>> I agree too. This has two prerequisites: >>> >>> 1. Reusable code >>> 2. Collaboration >>> >>> Neither of those is easy to satisfy nor should either be assumed. >>> Reusable code is probably the easier one to guarantee. You just need >>> to find at least three existing projects that already have code doing >>> the thing you're proposing to write a library for. You have one. There >>> could be others. >>> >>> Collaboration is much tougher. You need active developers who are >>> willing to contribute over the lifetime of the project. Even if you >>> have them today, you could lose them tomorrow. Code that you >>> contribute to a different project instead of your own will now be >>> blocked on the availability of reviewers and might not be released for >>> years, if ever. This is where Apache Xerces is currently stuck, for >>> example. >>> >>> Genuinely reusable code is helpful, but splitting your own work into >>> separate parts in separate projects owned by different teams, people, >>> and organizations is a very risky strategy. The presumption should be >>> not to do this. Good evidence of benefit is needed before I would >>> attempt that. >> These are all real questions which we should tackle. >> It's depressing that we've been asking them for years, without coming >> up with anything but "collaboration is too complicated", even between Woof, bold statements. Im doing my best to give what time I can to the project (commons generally) despite having lots of responsibilities. Are you? >> ASF projects. Even more frustrating is that AFAIK, the "Commons" >> project was originally started to do just that! For a long time, we've been >> totally open to committers from other ASF projects; yet no synergy has >> ever emerged (as far as I remember correctly). >> >> I hope that it will be different this time. [Thank you, Johann, for reaching >> out.] > > > No problem, but we are not there yet :). > > On my side I also have to make sure it would be okay with the other PMC and > with my boss. > And see how much regular time I can be allowed to work on this. > So don't get your hopes up to much, this is not something we planned to do > this year. > > My questions were to check the state of those libraries and if it would be > worth it. > > > Johann > > > >> >> Regards, >> Gilles >> >> - >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] > > - > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > - To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
Re: Current state of Apache Commons Math and Geometry
Johann, Sounds good. I did end up checking out the SIS code and it looks really interesting. I can definitely picture commons-geometry in there. It would be a good chance to introduce some cool new features in the library, such as vector buffers of some sort, new file format readers/writers, and new algorithms. I'd be willing to help out with that when you're ready. Regards, Matt J On Mon, Feb 23, 2026 at 4:03 AM Johann Sorel via dev wrote: > > Hi. > > > > Le ven. 20 févr. 2026 à 14:20, Elliotte Rusty Harold > > a écrit : > >> On Fri, Feb 20, 2026 at 3:58 AM Gilles Sadowski > wrote: > >>> Le jeu. 19 févr. 2026 à 14:57, Johann Sorel via dev > >>> I agree: Collaboration on reusable code is a better way. > >> > >> I agree too. This has two prerequisites: > >> > >> 1. Reusable code > >> 2. Collaboration > >> > >> Neither of those is easy to satisfy nor should either be assumed. > >> Reusable code is probably the easier one to guarantee. You just need > >> to find at least three existing projects that already have code doing > >> the thing you're proposing to write a library for. You have one. There > >> could be others. > >> > >> Collaboration is much tougher. You need active developers who are > >> willing to contribute over the lifetime of the project. Even if you > >> have them today, you could lose them tomorrow. Code that you > >> contribute to a different project instead of your own will now be > >> blocked on the availability of reviewers and might not be released for > >> years, if ever. This is where Apache Xerces is currently stuck, for > >> example. > >> > >> Genuinely reusable code is helpful, but splitting your own work into > >> separate parts in separate projects owned by different teams, people, > >> and organizations is a very risky strategy. The presumption should be > >> not to do this. Good evidence of benefit is needed before I would > >> attempt that. > > These are all real questions which we should tackle. > > It's depressing that we've been asking them for years, without coming > > up with anything but "collaboration is too complicated", even between > > ASF projects. Even more frustrating is that AFAIK, the "Commons" > > project was originally started to do just that! For a long time, we've > been > > totally open to committers from other ASF projects; yet no synergy has > > ever emerged (as far as I remember correctly). > > > > I hope that it will be different this time. [Thank you, Johann, for > reaching > > out.] > > > No problem, but we are not there yet :). > > On my side I also have to make sure it would be okay with the other PMC > and with my boss. > And see how much regular time I can be allowed to work on this. > So don't get your hopes up to much, this is not something we planned to > do this year. > > My questions were to check the state of those libraries and if it would > be worth it. > > > Johann > > > > > > > Regards, > > Gilles > > > > - > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > - > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
Re: Current state of Apache Commons Math and Geometry
Hi. Le ven. 20 févr. 2026 à 14:20, Elliotte Rusty Harold a écrit : On Fri, Feb 20, 2026 at 3:58 AM Gilles Sadowski wrote: Le jeu. 19 févr. 2026 à 14:57, Johann Sorel via dev I agree: Collaboration on reusable code is a better way. I agree too. This has two prerequisites: 1. Reusable code 2. Collaboration Neither of those is easy to satisfy nor should either be assumed. Reusable code is probably the easier one to guarantee. You just need to find at least three existing projects that already have code doing the thing you're proposing to write a library for. You have one. There could be others. Collaboration is much tougher. You need active developers who are willing to contribute over the lifetime of the project. Even if you have them today, you could lose them tomorrow. Code that you contribute to a different project instead of your own will now be blocked on the availability of reviewers and might not be released for years, if ever. This is where Apache Xerces is currently stuck, for example. Genuinely reusable code is helpful, but splitting your own work into separate parts in separate projects owned by different teams, people, and organizations is a very risky strategy. The presumption should be not to do this. Good evidence of benefit is needed before I would attempt that. These are all real questions which we should tackle. It's depressing that we've been asking them for years, without coming up with anything but "collaboration is too complicated", even between ASF projects. Even more frustrating is that AFAIK, the "Commons" project was originally started to do just that! For a long time, we've been totally open to committers from other ASF projects; yet no synergy has ever emerged (as far as I remember correctly). I hope that it will be different this time. [Thank you, Johann, for reaching out.] No problem, but we are not there yet :). On my side I also have to make sure it would be okay with the other PMC and with my boss. And see how much regular time I can be allowed to work on this. So don't get your hopes up to much, this is not something we planned to do this year. My questions were to check the state of those libraries and if it would be worth it. Johann Regards, Gilles - To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] - To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
Re: Current state of Apache Commons Math and Geometry
Le ven. 20 févr. 2026 à 15:22, Elliotte Rusty Harold a écrit : > > Not sure if by "modules" you mean JPMS modules or Maven artifacts. Both, I guess (not sure I understand the distinction which you tried to make). > Either way, keep in mind that commons geometry has already shipped 1.0 > so maintaining API compatibility is fairly important. Yes, and no. That is, we'll follow the usual (at "Commons") practice of maintaining BC, but if the actual contributors want to go on with a new API, it will be done towards a new major version. [In that case, the "top-level" Java package would become "o.a.c.geometry2", with a commensurate change of the Maven coordinates.] If Johann wants to experiment (e.g. to find out commonalities that could be merged into "Commons Geometry"), I'd even float the idea that we should readily do the "o.a.c.geometry2" change in a dedicated branch; for example, that would allow to easily compare (e.g. performance-wise) with the current API. [And if it turns out that a new major version is not required, we could relatively easily "back-port" into the "master" branch.] Best, Gilles >>> [...] - To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
Re: Current state of Apache Commons Math and Geometry
Hi Matt. Le ven. 20 févr. 2026 à 15:12, Matt Juntunen a écrit : > > For what it's worth, I plan on reviewing the code this weekend and trying > to answer the following as best I can: > 1. How much (and where) do the two libraries overlap in architecture and > design goals? > 2. How much effort would be required to modify each library to produce > reusable, shareable modules? > 3. Would this reusability have negative impacts on either library (e.g., > reduced performance, increased memory usage)? > > I'll report back with what I find. Thanks a lot; and welcome back. :-) >> [...] - To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
Re: Current state of Apache Commons Math and Geometry
Hi. Le ven. 20 févr. 2026 à 14:20, Elliotte Rusty Harold a écrit : > > On Fri, Feb 20, 2026 at 3:58 AM Gilles Sadowski wrote: > > > > Le jeu. 19 févr. 2026 à 14:57, Johann Sorel via dev > > > I agree: Collaboration on reusable code is a better way. > > > I agree too. This has two prerequisites: > > 1. Reusable code > 2. Collaboration > > Neither of those is easy to satisfy nor should either be assumed. > Reusable code is probably the easier one to guarantee. You just need > to find at least three existing projects that already have code doing > the thing you're proposing to write a library for. You have one. There > could be others. > > Collaboration is much tougher. You need active developers who are > willing to contribute over the lifetime of the project. Even if you > have them today, you could lose them tomorrow. Code that you > contribute to a different project instead of your own will now be > blocked on the availability of reviewers and might not be released for > years, if ever. This is where Apache Xerces is currently stuck, for > example. > > Genuinely reusable code is helpful, but splitting your own work into > separate parts in separate projects owned by different teams, people, > and organizations is a very risky strategy. The presumption should be > not to do this. Good evidence of benefit is needed before I would > attempt that. These are all real questions which we should tackle. It's depressing that we've been asking them for years, without coming up with anything but "collaboration is too complicated", even between ASF projects. Even more frustrating is that AFAIK, the "Commons" project was originally started to do just that! For a long time, we've been totally open to committers from other ASF projects; yet no synergy has ever emerged (as far as I remember correctly). I hope that it will be different this time. [Thank you, Johann, for reaching out.] Regards, Gilles - To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
Re: Current state of Apache Commons Math and Geometry
Not sure if by "modules" you mean JPMS modules or Maven artifacts. Either way, keep in mind that commons geometry has already shipped 1.0 so maintaining API compatibility is fairly important. On Fri, Feb 20, 2026 at 2:12 PM Matt Juntunen wrote: > > For what it's worth, I plan on reviewing the code this weekend and trying > to answer the following as best I can: > 1. How much (and where) do the two libraries overlap in architecture and > design goals? > 2. How much effort would be required to modify each library to produce > reusable, shareable modules? > 3. Would this reusability have negative impacts on either library (e.g., > reduced performance, increased memory usage)? > > I'll report back with what I find. > > Regards, > Matt J > > On Fri, Feb 20, 2026, 8:20 AM Elliotte Rusty Harold > wrote: > > > On Fri, Feb 20, 2026 at 3:58 AM Gilles Sadowski > > wrote: > > > > > > Le jeu. 19 févr. 2026 à 14:57, Johann Sorel via dev > > > > > I agree: Collaboration on reusable code is a better way. > > > > > > I agree too. This has two prerequisites: > > > > 1. Reusable code > > 2. Collaboration > > > > Neither of those is easy to satisfy nor should either be assumed. > > Reusable code is probably the easier one to guarantee. You just need > > to find at least three existing projects that already have code doing > > the thing you're proposing to write a library for. You have one. There > > could be others. > > > > Collaboration is much tougher. You need active developers who are > > willing to contribute over the lifetime of the project. Even if you > > have them today, you could lose them tomorrow. Code that you > > contribute to a different project instead of your own will now be > > blocked on the availability of reviewers and might not be released for > > years, if ever. This is where Apache Xerces is currently stuck, for > > example. > > > > Genuinely reusable code is helpful, but splitting your own work into > > separate parts in separate projects owned by different teams, people, > > and organizations is a very risky strategy. The presumption should be > > not to do this. Good evidence of benefit is needed before I would > > attempt that. > > > > -- > > Elliotte Rusty Harold > > [email protected] > > > > - > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > -- Elliotte Rusty Harold [email protected] - To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
Re: Current state of Apache Commons Math and Geometry
For what it's worth, I plan on reviewing the code this weekend and trying to answer the following as best I can: 1. How much (and where) do the two libraries overlap in architecture and design goals? 2. How much effort would be required to modify each library to produce reusable, shareable modules? 3. Would this reusability have negative impacts on either library (e.g., reduced performance, increased memory usage)? I'll report back with what I find. Regards, Matt J On Fri, Feb 20, 2026, 8:20 AM Elliotte Rusty Harold wrote: > On Fri, Feb 20, 2026 at 3:58 AM Gilles Sadowski > wrote: > > > > Le jeu. 19 févr. 2026 à 14:57, Johann Sorel via dev > > > I agree: Collaboration on reusable code is a better way. > > > I agree too. This has two prerequisites: > > 1. Reusable code > 2. Collaboration > > Neither of those is easy to satisfy nor should either be assumed. > Reusable code is probably the easier one to guarantee. You just need > to find at least three existing projects that already have code doing > the thing you're proposing to write a library for. You have one. There > could be others. > > Collaboration is much tougher. You need active developers who are > willing to contribute over the lifetime of the project. Even if you > have them today, you could lose them tomorrow. Code that you > contribute to a different project instead of your own will now be > blocked on the availability of reviewers and might not be released for > years, if ever. This is where Apache Xerces is currently stuck, for > example. > > Genuinely reusable code is helpful, but splitting your own work into > separate parts in separate projects owned by different teams, people, > and organizations is a very risky strategy. The presumption should be > not to do this. Good evidence of benefit is needed before I would > attempt that. > > -- > Elliotte Rusty Harold > [email protected] > > - > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
Re: Current state of Apache Commons Math and Geometry
On Fri, Feb 20, 2026 at 3:58 AM Gilles Sadowski wrote: > > Le jeu. 19 févr. 2026 à 14:57, Johann Sorel via dev > I agree: Collaboration on reusable code is a better way. I agree too. This has two prerequisites: 1. Reusable code 2. Collaboration Neither of those is easy to satisfy nor should either be assumed. Reusable code is probably the easier one to guarantee. You just need to find at least three existing projects that already have code doing the thing you're proposing to write a library for. You have one. There could be others. Collaboration is much tougher. You need active developers who are willing to contribute over the lifetime of the project. Even if you have them today, you could lose them tomorrow. Code that you contribute to a different project instead of your own will now be blocked on the availability of reviewers and might not be released for years, if ever. This is where Apache Xerces is currently stuck, for example. Genuinely reusable code is helpful, but splitting your own work into separate parts in separate projects owned by different teams, people, and organizations is a very risky strategy. The presumption should be not to do this. Good evidence of benefit is needed before I would attempt that. -- Elliotte Rusty Harold [email protected] - To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
Re: Current state of Apache Commons Math and Geometry
Le jeu. 19 févr. 2026 à 14:57, Johann Sorel via dev a écrit : > > > That's one way to see it. > Of course if no one else is interested or do not have time to get > involved then I'm better of continuing the work in Apache SIS. > Sure it's faster to do things on our own, without talking to anyone, > that's how we end up with a lot of different libs doing more or less the > same stuff. I agree: Collaboration on reusable code is a better way. > Our philosophy in Apache SIS is to follow the standards and formats if > they exist. > For Geometry that is ISO 19107, OGC Feature, the various Khronos specs > and some others like SVG, CSS... > A good geometry API should be able to map the existing. Matt Juntunen would be the one to discuss whether those things would be achievable within the current design, and scope, of Commons Geometry. > There is a good amount of overlapping, commons geometry is a rich library. I had a very brief look, and some of the basic functionality indeed overlaps (as would be expected). However, unless I'm mistaken, there is a divergence in fundamental design: Commons Geometry is based on immutable objects while SIS provides "setter" methods; see e.g. https://github.com/apache/sis/blob/geoapi-4.0/incubator/src/org.apache.sis.geometry/main/org/apache/sis/geometries/math/Vector3D.java vs https://commons.apache.org/proper/commons-geometry/commons-geometry-euclidean/apidocs/org/apache/commons/geometry/euclidean/threed/Vector3D.html > > For now I will continue the work in Apache SIS. > I'll see how it goes and perhaps start coming back to you if it can be > of mutual benefit. Performance features mentioned in your previous message are definitely very interesting; the question is whether all users can switch to the required Java version. Alternatively, perhaps we could define an interface to some functionality, with implementations provided in different modules (possibly with different Java version requirements). Gilles > Le 19/02/2026 à 14:27, Elliotte Rusty Harold a écrit : > > On Thu, Feb 19, 2026 at 8:32 AM Johann Sorel via dev > > wrote: > > part : > >> https://github.com/apache/sis/tree/geoapi-4.0/incubator/src/org.apache.sis.geometry/main/org/apache/sis/geometries > >> > >> Apache-commons-geometry contains a single kind of geometry : > >> Constructive Solid Geometry. which is really nice. > >> But what we are making is more like JavaTopologySuite, Esri-geometry, > >> SVG but with 3D (and more) support for PLY, GLTF, GPU... > > I'm not familiar with the math you're using, but it sounds like it's > > quite different from what's in commons geometry now and has limited > > overlap. If that's true, then I strongly recommend you make your own > > more targeted library and artifact rather than trying to shoehorn it > > into another library because the name sounds similar. Smaller, more > > focused libraries speed up development and enable you to build exactly > > what you need without trying to get consensus with another team. > > Frankenlibraries that include everything and the kitchen sink are > > already a problem for Apache Commons. I think you'll be much happier > > with your own library that you control and can tailor to your > > project's needs. - To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
Re: Current state of Apache Commons Math and Geometry
I am of the opinion that a library should use the lowest supported Java version unless its purpose absolutely cannot be delivered without higher JVM version features. That then leads to a debate on what the 'purpose' is. It could be high performance which is not available in lower JVM versions. It could be compatibility with other features of higher JVM versions. In this case an update to the minimum Java version would be warranted. IIUC the geometry component and other math components are meant to be functional libraries for all users. So leaving the Java version at 8 has always been the status quo. There are some features of higher Java levels that would increase performance and, in the case of FMA, numerical accuracy but these features are not required. There is also the possibility of releasing a module with a higher Java version, allowing the current functionality to use Java 8 and new features that require a higher Java level to be added. Alex On Thu, 19 Feb 2026 at 15:42, Gary Gregory wrote: > Hi Alex, > > Should the Java requirement be raised as some point and to what level in > your opinion? > > Gary > > On Thu, Feb 19, 2026, 10:19 Alex Herbert wrote: > >> One detail is that Commons geometry is Java 8. Some of the features from >> the OP seem to be more cutting edge and may require a higher JVM version. >> >> I think this would require some comparison of what is in the SIS project >> and how it overlaps the Commons Geometry (CG) component. I am not the best >> person to do this as I am not familiar with **all** the CG codebase. >> >> Alex >> >> >> On Thu, 19 Feb 2026 at 14:18, Gary Gregory >> wrote: >> >>> But Commons Geometry _is_ broken up in 6 smaller focused components. It >>> seems to me that CG should or could welcome new components, especially if >>> they come with a maintainer. Maybe Alex Herbert can shine a light here. >>> >>> Gary >>> >>> On Thu, Feb 19, 2026, 08:28 Elliotte Rusty Harold >>> wrote: >>> On Thu, Feb 19, 2026 at 8:32 AM Johann Sorel via dev wrote: part : > https://github.com/apache/sis/tree/geoapi-4.0/incubator/src/org.apache.sis.geometry/main/org/apache/sis/geometries > > Apache-commons-geometry contains a single kind of geometry : > Constructive Solid Geometry. which is really nice. > But what we are making is more like JavaTopologySuite, Esri-geometry, > SVG but with 3D (and more) support for PLY, GLTF, GPU... I'm not familiar with the math you're using, but it sounds like it's quite different from what's in commons geometry now and has limited overlap. If that's true, then I strongly recommend you make your own more targeted library and artifact rather than trying to shoehorn it into another library because the name sounds similar. Smaller, more focused libraries speed up development and enable you to build exactly what you need without trying to get consensus with another team. Frankenlibraries that include everything and the kitchen sink are already a problem for Apache Commons. I think you'll be much happier with your own library that you control and can tailor to your project's needs. -- Elliotte Rusty Harold [email protected] - To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
Re: Current state of Apache Commons Math and Geometry
Hi Alex, Should the Java requirement be raised as some point and to what level in your opinion? Gary On Thu, Feb 19, 2026, 10:19 Alex Herbert wrote: > One detail is that Commons geometry is Java 8. Some of the features from > the OP seem to be more cutting edge and may require a higher JVM version. > > I think this would require some comparison of what is in the SIS project > and how it overlaps the Commons Geometry (CG) component. I am not the best > person to do this as I am not familiar with **all** the CG codebase. > > Alex > > > On Thu, 19 Feb 2026 at 14:18, Gary Gregory wrote: > >> But Commons Geometry _is_ broken up in 6 smaller focused components. It >> seems to me that CG should or could welcome new components, especially if >> they come with a maintainer. Maybe Alex Herbert can shine a light here. >> >> Gary >> >> On Thu, Feb 19, 2026, 08:28 Elliotte Rusty Harold >> wrote: >> >>> On Thu, Feb 19, 2026 at 8:32 AM Johann Sorel via dev >>> wrote: >>> part : >>> > >>> https://github.com/apache/sis/tree/geoapi-4.0/incubator/src/org.apache.sis.geometry/main/org/apache/sis/geometries >>> > >>> > Apache-commons-geometry contains a single kind of geometry : >>> > Constructive Solid Geometry. which is really nice. >>> > But what we are making is more like JavaTopologySuite, Esri-geometry, >>> > SVG but with 3D (and more) support for PLY, GLTF, GPU... >>> >>> I'm not familiar with the math you're using, but it sounds like it's >>> quite different from what's in commons geometry now and has limited >>> overlap. If that's true, then I strongly recommend you make your own >>> more targeted library and artifact rather than trying to shoehorn it >>> into another library because the name sounds similar. Smaller, more >>> focused libraries speed up development and enable you to build exactly >>> what you need without trying to get consensus with another team. >>> Frankenlibraries that include everything and the kitchen sink are >>> already a problem for Apache Commons. I think you'll be much happier >>> with your own library that you control and can tailor to your >>> project's needs. >>> >>> -- >>> Elliotte Rusty Harold >>> [email protected] >>> >>> - >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >>>
Re: Current state of Apache Commons Math and Geometry
One detail is that Commons geometry is Java 8. Some of the features from the OP seem to be more cutting edge and may require a higher JVM version. I think this would require some comparison of what is in the SIS project and how it overlaps the Commons Geometry (CG) component. I am not the best person to do this as I am not familiar with **all** the CG codebase. Alex On Thu, 19 Feb 2026 at 14:18, Gary Gregory wrote: > But Commons Geometry _is_ broken up in 6 smaller focused components. It > seems to me that CG should or could welcome new components, especially if > they come with a maintainer. Maybe Alex Herbert can shine a light here. > > Gary > > On Thu, Feb 19, 2026, 08:28 Elliotte Rusty Harold > wrote: > >> On Thu, Feb 19, 2026 at 8:32 AM Johann Sorel via dev >> wrote: >> part : >> > >> https://github.com/apache/sis/tree/geoapi-4.0/incubator/src/org.apache.sis.geometry/main/org/apache/sis/geometries >> > >> > Apache-commons-geometry contains a single kind of geometry : >> > Constructive Solid Geometry. which is really nice. >> > But what we are making is more like JavaTopologySuite, Esri-geometry, >> > SVG but with 3D (and more) support for PLY, GLTF, GPU... >> >> I'm not familiar with the math you're using, but it sounds like it's >> quite different from what's in commons geometry now and has limited >> overlap. If that's true, then I strongly recommend you make your own >> more targeted library and artifact rather than trying to shoehorn it >> into another library because the name sounds similar. Smaller, more >> focused libraries speed up development and enable you to build exactly >> what you need without trying to get consensus with another team. >> Frankenlibraries that include everything and the kitchen sink are >> already a problem for Apache Commons. I think you'll be much happier >> with your own library that you control and can tailor to your >> project's needs. >> >> -- >> Elliotte Rusty Harold >> [email protected] >> >> - >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >>
Re: Current state of Apache Commons Math and Geometry
But Commons Geometry _is_ broken up in 6 smaller focused components. It seems to me that CG should or could welcome new components, especially if they come with a maintainer. Maybe Alex Herbert can shine a light here. Gary On Thu, Feb 19, 2026, 08:28 Elliotte Rusty Harold wrote: > On Thu, Feb 19, 2026 at 8:32 AM Johann Sorel via dev > wrote: > part : > > > https://github.com/apache/sis/tree/geoapi-4.0/incubator/src/org.apache.sis.geometry/main/org/apache/sis/geometries > > > > Apache-commons-geometry contains a single kind of geometry : > > Constructive Solid Geometry. which is really nice. > > But what we are making is more like JavaTopologySuite, Esri-geometry, > > SVG but with 3D (and more) support for PLY, GLTF, GPU... > > I'm not familiar with the math you're using, but it sounds like it's > quite different from what's in commons geometry now and has limited > overlap. If that's true, then I strongly recommend you make your own > more targeted library and artifact rather than trying to shoehorn it > into another library because the name sounds similar. Smaller, more > focused libraries speed up development and enable you to build exactly > what you need without trying to get consensus with another team. > Frankenlibraries that include everything and the kitchen sink are > already a problem for Apache Commons. I think you'll be much happier > with your own library that you control and can tailor to your > project's needs. > > -- > Elliotte Rusty Harold > [email protected] > > - > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
Re: Current state of Apache Commons Math and Geometry
That's one way to see it. Of course if no one else is interested or do not have time to get involved then I'm better of continuing the work in Apache SIS. Sure it's faster to do things on our own, without talking to anyone, that's how we end up with a lot of different libs doing more or less the same stuff. Our philosophy in Apache SIS is to follow the standards and formats if they exist. For Geometry that is ISO 19107, OGC Feature, the various Khronos specs and some others like SVG, CSS... A good geometry API should be able to map the existing. There is a good amount of overlapping, commons geometry is a rich library. For now I will continue the work in Apache SIS. I'll see how it goes and perhaps start coming back to you if it can be of mutual benefit. Johann Le 19/02/2026 à 14:27, Elliotte Rusty Harold a écrit : On Thu, Feb 19, 2026 at 8:32 AM Johann Sorel via dev wrote: part : https://github.com/apache/sis/tree/geoapi-4.0/incubator/src/org.apache.sis.geometry/main/org/apache/sis/geometries Apache-commons-geometry contains a single kind of geometry : Constructive Solid Geometry. which is really nice. But what we are making is more like JavaTopologySuite, Esri-geometry, SVG but with 3D (and more) support for PLY, GLTF, GPU... I'm not familiar with the math you're using, but it sounds like it's quite different from what's in commons geometry now and has limited overlap. If that's true, then I strongly recommend you make your own more targeted library and artifact rather than trying to shoehorn it into another library because the name sounds similar. Smaller, more focused libraries speed up development and enable you to build exactly what you need without trying to get consensus with another team. Frankenlibraries that include everything and the kitchen sink are already a problem for Apache Commons. I think you'll be much happier with your own library that you control and can tailor to your project's needs. - To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
Re: Current state of Apache Commons Math and Geometry
On Thu, Feb 19, 2026 at 8:32 AM Johann Sorel via dev wrote: part : > https://github.com/apache/sis/tree/geoapi-4.0/incubator/src/org.apache.sis.geometry/main/org/apache/sis/geometries > > Apache-commons-geometry contains a single kind of geometry : > Constructive Solid Geometry. which is really nice. > But what we are making is more like JavaTopologySuite, Esri-geometry, > SVG but with 3D (and more) support for PLY, GLTF, GPU... I'm not familiar with the math you're using, but it sounds like it's quite different from what's in commons geometry now and has limited overlap. If that's true, then I strongly recommend you make your own more targeted library and artifact rather than trying to shoehorn it into another library because the name sounds similar. Smaller, more focused libraries speed up development and enable you to build exactly what you need without trying to get consensus with another team. Frankenlibraries that include everything and the kitchen sink are already a problem for Apache Commons. I think you'll be much happier with your own library that you control and can tailor to your project's needs. -- Elliotte Rusty Harold [email protected] - To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
Re: Current state of Apache Commons Math and Geometry
Here are more informations : First as I said I am (one of the) PMC of Apache SIS, but not only, also of GeotoolKit and Examind-SDK. So I won't have the time to manage another project, if that's what you are hoping :). The Math code is here (most of it) : https://github.com/apache/sis/tree/geoapi-4.0/incubator/src/org.apache.sis.geometry/main/org/apache/sis/geometries/math To make it short it has : Tuple, Vector, Matrix, Quaternion, Array, ArrayND. Nothing fancy but we still made those, more modern, typed, metadata and aiming at being compatible with : - Large arrays (using Panama foreign memory) - Vector API (https://openjdk.org/jeps/426) - GPGPU / Babylon / HAT (https://www.youtube.com/watch?v=qkr3E27XYbY) to achieve somekind of Numpy API. The Geometry part : https://github.com/apache/sis/tree/geoapi-4.0/incubator/src/org.apache.sis.geometry/main/org/apache/sis/geometries Apache-commons-geometry contains a single kind of geometry : Constructive Solid Geometry. which is really nice. But what we are making is more like JavaTopologySuite, Esri-geometry, SVG but with 3D (and more) support for PLY, GLTF, GPU... More details here : https://github.com/apache/sis/blob/geoapi-4.0/incubator/src/org.apache.sis.geometry/main/org/apache/sis/geometries/package-info.java Your thoughts ? Johann Le 19/02/2026 à 04:35, Matt Juntunen a écrit : Hello, I did the 1.0.0 release of commons-geometry and some of the additional, unreleased functionality shortly afterward. My personal life changed quite a bit a few years ago and I haven't had the time or energy to keep pushing on it. I'd be happy to discuss the current functionality and see if any of it fits with what you're working on. Regards, Matt J On Wed, Feb 18, 2026 at 9:11 PM Gilles Sadowski wrote: Hi. Le mer. 18 févr. 2026 à 22:57, Johann Sorel via dev a écrit : Hello, I am Johann Sorel, working on the Apache SIS (Spatial Information System) project. In the project we have growing needs for advanced math, array, geometry, scene capabilities. Since we did not find what we need in other projects, we are developing them. The logical action would be to have those in the appropriate Apache project, such as Apache commons Math and Geometry. But those look abandoned. Neither "Commons Math" nor "Commons Geometry" are abandoned. The latter was spun off from the former, with enhanced performance and new features. - commons-math3 latest is from 2016 The 3.x line is not supported anymore. - commons-math4 beta is from 2022 Math v3.x (and earlier) was monolithic (and became bloated). Version 4 aimed at modularization, while several components were spun off (with improved design and for better maintenance): * Commons Geometry * Commons RNG * Commons Numbers * Commons Statistics The overhaul of the remaining "legacy" packages of "Math" is work-in-progress, but has stalled... - commons-geometry1 is from 2021 It has been stable since then. Are those replaced ? No. have they been merged in another project ? No. You are welcome to revive development. :-) Regards, Gilles - To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] - To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
Re: Current state of Apache Commons Math and Geometry
Hello, I did the 1.0.0 release of commons-geometry and some of the additional, unreleased functionality shortly afterward. My personal life changed quite a bit a few years ago and I haven't had the time or energy to keep pushing on it. I'd be happy to discuss the current functionality and see if any of it fits with what you're working on. Regards, Matt J On Wed, Feb 18, 2026 at 9:11 PM Gilles Sadowski wrote: > Hi. > > Le mer. 18 févr. 2026 à 22:57, Johann Sorel via dev > a écrit : > > > > Hello, > > > > I am Johann Sorel, working on the Apache SIS (Spatial Information > > System) project. > > > > In the project we have growing needs for advanced math, array, geometry, > > scene capabilities. > > Since we did not find what we need in other projects, we are developing > > them. > > > > The logical action would be to have those in the appropriate Apache > > project, such as Apache commons Math and Geometry. > > But those look abandoned. > > Neither "Commons Math" nor "Commons Geometry" are abandoned. > The latter was spun off from the former, with enhanced performance > and new features. > > > - commons-math3 latest is from 2016 > > The 3.x line is not supported anymore. > > > - commons-math4 beta is from 2022 > > Math v3.x (and earlier) was monolithic (and became bloated). > Version 4 aimed at modularization, while several components > were spun off (with improved design and for better maintenance): > * Commons Geometry > * Commons RNG > * Commons Numbers > * Commons Statistics > > The overhaul of the remaining "legacy" packages of "Math" is > work-in-progress, but has stalled... > > > - commons-geometry1 is from 2021 > > It has been stable since then. > > > > > Are those replaced ? > > No. > > > have they been merged in another project ? > > No. > > You are welcome to revive development. :-) > > Regards, > Gilles > > - > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
Re: Current state of Apache Commons Math and Geometry
Hi. Le mer. 18 févr. 2026 à 22:57, Johann Sorel via dev a écrit : > > Hello, > > I am Johann Sorel, working on the Apache SIS (Spatial Information > System) project. > > In the project we have growing needs for advanced math, array, geometry, > scene capabilities. > Since we did not find what we need in other projects, we are developing > them. > > The logical action would be to have those in the appropriate Apache > project, such as Apache commons Math and Geometry. > But those look abandoned. Neither "Commons Math" nor "Commons Geometry" are abandoned. The latter was spun off from the former, with enhanced performance and new features. > - commons-math3 latest is from 2016 The 3.x line is not supported anymore. > - commons-math4 beta is from 2022 Math v3.x (and earlier) was monolithic (and became bloated). Version 4 aimed at modularization, while several components were spun off (with improved design and for better maintenance): * Commons Geometry * Commons RNG * Commons Numbers * Commons Statistics The overhaul of the remaining "legacy" packages of "Math" is work-in-progress, but has stalled... > - commons-geometry1 is from 2021 It has been stable since then. > > Are those replaced ? No. > have they been merged in another project ? No. You are welcome to revive development. :-) Regards, Gilles - To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
Current state of Apache Commons Math and Geometry
Hello, I am Johann Sorel, working on the Apache SIS (Spatial Information System) project. In the project we have growing needs for advanced math, array, geometry, scene capabilities. Since we did not find what we need in other projects, we are developing them. The logical action would be to have those in the appropriate Apache project, such as Apache commons Math and Geometry. But those look abandoned. - commons-math3 latest is from 2016 - commons-math4 beta is from 2022 - commons-geometry1 is from 2021 Are those replaced ? have they been merged in another project ? Thanks Johann - To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
