Frgaal (1) does seem an interesting beast. How would that work? Netbeans would be compiled using frgaal to support newer features to be still usable on Java 8? Would that in someway have to be targeted (i.e. compiled to a specific release target) which would adapter for use on java 8? Does that mean full later java features would have some kind of bridge layer? Would that impact performance in any way?
Is this maybe a matter relating to release/source/target/bootclasspath (2) aspects of things? Would multiple release jars (3) be needed as part of this? Then version specific items can be added in applicable namespace and compiled for given releases as needed (i.e. build steps for each supported java release version)? In theory it might bloat things a little but it would extend compatibility with older java for a little longer. Assume some of this would be considered during CI build pipeline as where somewhere. So from a higher level… * There is netbeans source code ** may/may not use newer java version APIs. ** If there are new java API features used (i.e. modules, block quotes, records, etc.) this adds a dependency on the given java version introduced during compile time ** If present but used on an older version would need to bridge between it (i.e. if supported use it if not then need to either have a wrapper, “adapter” [frgaal] means of leveraging new in an old environment, or multi release jar] * There is the java used to compile netbeans ** Used to compile to byte code of a specific version ** Possible to compile to older release versions ** May be impacting of release/source/target/bootclasspath build/run settings * There is the java used to run ** As long as compiled to be compatible with a specific release version it should run. ** If not compiled to be compatible, it doesn’t run (i.e. bytecode compatibility issue, unavailable APIs, etc.) ** My require “bridging”/“adapting” [frgaal] to run on * There is the java used to compile the [external] dependencies ** Each external dependency has its own java compatible version and may require updated dependencies (i.e. if using dependency not compiled it may work but if something calls from external back, there is a chance it may not be compatible due to conflicting java versions) Eric References (1) http://frgaal.org/ (2) https://stackoverflow.com/questions/43102787/what-is-the-release-flag-in-the-java-9-compiler (3) https://nipafx.dev/multi-release-jars-multiple-java-versions/ On Thu, Oct 7, 2021 at 12:58 AM Jaroslav Tulach <[email protected]> wrote: > Dne sobota 2. října 2021 1:38:20 CEST, Ernie Rael napsal(a): > > frgaal? > > > > How about allowing any/all jdk-11 language features and if a developer > > needs to run on jdk8 they must use frgaal to compile NB for jdk8? > > Frgaal, that'd be fantastic! As far as I know the latest version supports > all > JDK16 features including records. Fellow developers could code with the > newest > language features, while still target JDK8 APIs and bytecode version. > > Anyway, let's go step by step. Using JDK-11 to compile NetBeans seems to > have > overall support and seems to be moving in the right direction. > -jt > > PS: Ernie, if you decide to enable Frgaal compilation (see PR-2369 for > inspiration), you'll get my support. > > > On 9/30/2021 11:27 PM, Jaroslav Tulach wrote: > > > JDK17 is out and Geertjan told me the old request is going to appear > > > again. > > > Let me thus review an old thread from November/February... > > > > > > ---------- Forwarded message --------- > > > From: Jaroslav Tulach <[email protected]> > > > Date: Feb 9 2021 > > > > > > Hi. > > > I knew the time for a discussion like this is going to come when I > wrote > > > my > > > "Compile with JDK-11 javac --release flag" in November. I have just > been > > > trying > > > to find the email in archives, but no luck! I had to resend it. Here > is it > > > for > > > your reference: > > > > > > https://lists.apache.org/thread.html/ > > > r94d421ce16f609687c769125425b46f2322033879120b00afddbe17b%40% > > > 3Cdev.netbeans.apache.org%3E > > > > > > I guess I have to agree with Eric, we cannot stick with JDK8 forever. > We > > > have > > > to move on. On the other hand, as you know, I am not fan of [Big Bang > > > changes] > > > (http://wiki.apidesign.org/wiki/Big_Bang), as such I'd like to > propose to > > > move > > > forward step by step: > > > > > > Let's require JDK11 to build NetBeans sources. > > > > > > The switch to JDK11 compiler doesn't mean I suggest to drop running on > > > JDK8. > > > Me, my employer/gang, OracleLabs, still need to run VSNetBeans on JDK8. > > > However we can have it and still move our source code base forward > where > > > needed. > > > > > > Matthias wrote: > > >> I think Jaroslav, said, that in the old time, NetBeans was > > >> > > >> able to be run on JDK-1. I remember that also, but at some point in > the > > >> 8? cycle build requirements jumped to 8, while target version was > still > > >> 1.7. > > > > > > Yes, that used to be the policy. Even if we restrict the policy to LTS > > > versions of Java, JDK17 is near and we have to move forward. As such I > > > wanted > > > to discuss this issue in November, 2020. I am still puzzled to > understand > > > where did my email disappear... > > > > > > Btw. there is `nb-javac` for JDK8 - related work I am involved in: > > > > https://cwiki.apache.org/confluence/display/NETBEANS/Overview%3A+nb-javac > > > This week we managed to make the (automatic) conversion of JDK16's > javac > > > to > > > run on JDK8 and pass all the available tests. > > > > > > I really wish NetBeans to continue to run on JDK8, but I am ready to > do my > > > best to allow you to use the latest Java APIs and features where > needed. I > > > hope we find a balance between these two desires by going step by step. > > > > > > As such I repeat my suggestion: let's require JDK11 to build NetBeans: > > > https://lists.apache.org/thread.html/ > > > r94d421ce16f609687c769125425b46f2322033879120b00afddbe17b%40% > > > 3Cdev.netbeans.apache.org%3E > > > > > > > > > -jt > > > > > > Dne pátek 5. února 2021 16:12:10 CET, Eric Bresie napsal(a): > > >> Question on the Netbeans project's plan for moving forward towards > > >> introducing and utilizing features with newer Java versions. > > >> > > >> I understand the basic expectations at present are mainly build on > Java > > >> 8, > > >> while being possible to build (with applicable flags or jdk settings) > for > > >> newer java versions. > > >> > > >> At what point do we need to take the plunge and start actually using > some > > >> of the new features for Java 9 and beyond? > > >> > > >> When compiling with new java, I see > > >> > > >> 1. references to deprecated or removed interfaces so assume that > is > > >> one > > >> thing that would have to be addressed. > > >> 2. I see references to "source versions" (I saw one expecting > server > > >> version 1.4) which also show up. As I understand it, at some > point > > >> the > > >> general behavior in some of that will be to only support a few jdk > > >> > > >> version back so assume this might be a case for other needed changes > > >> [what > > >> makes it a specific version and is it as simple as changing the source > > >> version in the project details or build scripts]? > > >> > > >> Assume doing so would require changes like > > >> > > >> 1. Any "JDK" specific build details might have to be addressed > > >> 2. Address depreciation and source version differences > > >> 3. Find existing code which are candidates for refactoring with > newer > > >> java features involved > > >> 4. Maybe leverage some JDK tools or utilizing netbeans Java > > > > > > "refactoring > > > > > >> hints" for suggestions (i.e. changing loops to lambdas, utilized > > >> newer > > >> > > >> file interfaces, etc.) > > >> > > >> 5. Any dependency libraries would have to be updated with > compatible > > >> versions. This does have the added benefit of utilizing newer > > >> versions > > >> > > >> in these as well which may include performance, security, or bug fits > > >> benefits as well. > > >> > > >> 6. Update any documentation (i.e. build/runtime environments) > > >> > > >> Given the recent javadocs build issues requiring newer jdk, it may > mean > > > > > > the > > > > > >> time is coming sooner rather than later. > > >> > > >> I know this would be a major bit of work but I wanted to raise the > > > > > > question. > > > > > >> Eric Bresie > > >> [email protected] > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > For further information about the NetBeans mailing lists, visit: > > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > For further information about the NetBeans mailing lists, visit: > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists > > > > -- Eric Bresie [email protected]
