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
<jaroslav.tul...@gmail.com>
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 <jaroslav.tul...@gmail.com>
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
ebre...@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org
For additional commands, e-mail: dev-h...@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org
For additional commands, e-mail: dev-h...@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
--
Eric Bresie
ebre...@gmail.com
