I would be very interested in discussing the high level Java API and how it could be simplified. It might also be worthwhile to look into the overall package/jar structure. This will help for both OSGi and JPMS support.
Regarding the Java14/JPMS target, I assume this means that the Jena code can be compiled and run on a Java14 environment and/or used on the module path in a JPMS-enabled application (and *not* that all downstream applications must use one of the newer Java runtimes). That is, would the compiler target and source still be Java8? Cheers, Aaron On Wed, 13 Nov 2019 at 14:18, Andy Seaborne <[email protected]> wrote: > I'd like to start a discussion on where the project might go longer term. > > This can be specific areas, overall design, about project processes, > anything. > > If we are going to do a major change, Jena4, what preparation for that > can be done? (e.g. deprecation and signalling in Jena3, before the > change happens). > > Realistically, Jena4 means having Jena3 and Jena4 in parallel. Jena4 > need not be that big - we can have Jena5 etc. > > I'll put some technical points in a separate email. > > I would put on the list: > > * How has the world changed? What should the project produce? > * Target audience: for developers of Jena, while Jena3 is for users. > * Target: Java14, JPMS. > * Clear-up not easily done with perfect compatibility. > * Simpler. There are APIs and packages entangled due to history. > > To the lurkers :-) > > Feedback and specific feature requests are welcome. But before you "go > shopping", you may wish to factor in that every feature needs effort to > do it. The better place to be is that an application can get what it > needs to do, not whether the Jena system has every feature built-in. > > Andy >
