On 14/11/2019 20:08, Aaron Coburn wrote:
I would be very interested in discussing the high level Java API and how it
could be simplified.
Let's take API discussion to [API] and not loose the other points.
It might also be worthwhile to look into the overall package/jar structure.
This will help for both OSGi and JPMS support.
Yes. The package structure is a current impedance.
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?
Actually, I was thinking Java14 APIs (var type inference improvements;
Java9 has Http/2; Java12,13 Switch Expressions; java14 NVM
MappedByteBuffer improvemnts) and language changes - so a Java14 runtime
is required.
Modules would not be required of applications, and mixed JavaOld/Java14
code can be run on a Java14 JVM.
This is something we need to agree on first.
If we going to move from Java8, we might as well jump to Java14.
Jena3 remains for some overlap period.
I think the Java version factor is changed by the slow demise of
multi-application platforms (e.g. Tomcat + multiple WAR files).
Container and microservices isolate the Java choice.
Java8 EOL is September 2023 (End of free public updates by AdoptOpenJDK)
which is the same as Java11.
What perspectives do other people have on the landscape?
Andy
Cheers,
Aaron
On Wed, 13 Nov 2019 at 14:18, Andy Seaborne <a...@apache.org> 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
