I'm not sure how unusually slow Bruno's $work is. It's the same where I am and I know of plenty of other places in academia or government that look similar schedule-wise.
To be clear, I am not arguing for Java 8 beyond Jena 3-- instead (I think) I'm agreeing with Bruno that we might want to think about 11 as a good compromise between all the good new language features becoming available and getting solid uptake. That having been said, we're at the beginning of a long journey and things may well look different by the time we've actually scoped 4. ajs6f On Tue, Nov 19, 2019, 8:38 AM Andy Seaborne <a...@apache.org> wrote: > > > On 16/11/2019 23:55, Bruno P. Kinoshita wrote: > >> What perspectives do other people have on the landscape? > > My company is pretty slow in updating its stack. They have Java8 only > now (and an isolated pod with java 5 or 6 for a legacy app I think). Not > aware of any java9+ yet. > > I think for Jena 4 we could go with Java LTS os LTS-next (assuming Jena4 > may take a while to be ready)? > > Bruno > > So the real question is whether they would use a Java11 runtime - and > for security reasons updating the JVM is a good idea (tm) - even if its > running older code. > > That's what I am seeing - Java11 JVM for Java8 apps especially when > deploying a new installation. The standard IT dept recipe is for Java11 > so it just happens that way. > > Andy > > > > > Sent from Yahoo Mail on Android > > > > On Sun, 17 Nov 2019 at 10:41, Andy Seaborne<a...@apache.org> wrote: > > > > 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 > >>> > >> > > > > >
