Re: [java runtime] Re: Jena next
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 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 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 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 > >>> > >> > > > > >
Re: [java runtime] Re: Jena next
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 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 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
Re: [java runtime] Re: Jena next
>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 Sent from Yahoo Mail on Android On Sun, 17 Nov 2019 at 10:41, Andy Seaborne 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 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 >> >
[java runtime] Re: Jena next
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 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
