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 <[email protected]> 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 <[email protected]> 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 <[email protected]> >> 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 <[email protected]> >>> wrote: >>> >>>> On Thu, Feb 19, 2026 at 8:32 AM Johann Sorel via dev >>>> <[email protected]> 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] >>>> >>>>
