You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@netbeans.apache.org by Michael Bien <mb...@gmail.com> on 2023/01/10 14:16:35 UTC
Lets talk about JDK 8 (new year edition)
Hello devs,
I hope everyone recovered from the last JDK 8 thread and is ready for
the first JDK 8 thread of 2023 :)
The commit validation job is currently testing on 8, 11, 17 and 20-ea.
It doesn't like NetBeans editor modules which require java 11 though
which blocks a Jakarta EE 10 PR atm (#4692).
This means we need either 1) a volunteer who would like to spend time
and fix JDK 8 tests, 2) we remove JDK 8 from the CV test matrix or 3) we
won't be able to merge this pr before freeze.
Given that NB doesn't really support running on JDK 11 since a while I
would simply opt for 2) and merge.
The problem is that I don't know the NB VSCode Extension situation very
well.
Have the NB VSCode Extension specific tests (which run on JDK 8)
sufficient coverage so that we can remove JDK 8 from the CV test matrix?
At what point will JDK 11 modules become a problem for VSCode? When will
the VSCode NB extension bump the runtime requirement to 11?
The next modules which would require JDK 11 are probably maven related
(#4999) but this wouldn't be for NB 17.
best regards,
michael
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Lets talk about JDK 8 (new year edition)
Posted by Neil C Smith <ne...@apache.org>.
On Tue, 10 Jan 2023 at 14:21, Michael Bien <mb...@gmail.com> wrote:
> The commit validation job is currently testing on 8, 11, 17 and 20-ea.
> It doesn't like NetBeans editor modules which require java 11 though
> which blocks a Jakarta EE 10 PR atm (#4692).
>
> This means we need either 1) a volunteer who would like to spend time
> and fix JDK 8 tests, 2) we remove JDK 8 from the CV test matrix or 3) we
> won't be able to merge this pr before freeze.
IMO, we could possibly disable the JDK 8 commit validation
temporarily. I think we might have a test issue here, that is not
specific to JDK 8, and will rear its head with higher Java
dependencies later anyway.
However, it's (more) likely the test failure is pointing out a valid
dependency misconfiguration in this PR given how it was agreed we'd
support higher Java versions, with optional enablement based on
OpenIDE-Module-Java-Dependencies. Why does this PR fail but existing
modules don't?!
Maybe my suggestion on the PR was wrong about using
OpenIDE-Module-Recommends, at least by itself - the existing modules
with higher than JDK 8 requirements all use OpenIDE-Module-Provides to
enable them I believe?
Best wishes,
Neil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Lets talk about JDK 8 (new year edition)
Posted by Eric Bresie <eb...@gmail.com>.
On Tue, Jan 10, 2023 at 8:21 AM Michael Bien <mb...@gmail.com> wrote:
>
> The commit validation job is currently testing on 8, 11, 17 and 20-ea.
> It doesn't like NetBeans editor modules which require java 11 though
> which blocks a Jakarta EE 10 PR atm (#4692).
>
> This means we need either 1) a volunteer who would like to spend time
> and fix JDK 8 tests,
Any further details on the failures?
Is there an issue to track this work should someone step up?
--
Eric Bresie
ebresie@gmail.com
Re: Lets talk about JDK 8 (new year edition)
Posted by Christian Oyarzun <co...@oyarzun.net>.
> Which Platform users need JDK 8 support and why can't they just stay on
> (for example) NetBeans 17?
I'm also a platform and IDE user. We moved our platform apps to JDK 11 back
in 2021.
As others have pointed out, if someone needs JDK 8 compatibility they can
use an older version of the platform.
Best regards,
Christian
Re: Lets talk about JDK 8 (new year edition)
Posted by Neil C Smith <ne...@apache.org>.
On Sun, 2 Apr 2023 at 15:49, Matthias Bläsing
<mb...@doppel-helix.eu.invalid> wrote:
> Am Sonntag, dem 02.04.2023 um 15:38 +0200 schrieb Jaroslav Tulach:
> > > It also becomes increasingly difficult to
> > > motivate myself to fix JDK 8 issues in my freetime.
> >
> > I can imagine that. However we are not coding NetBeans to please ourselves,
> > but to please our users.
>
> These users won't benefit from developers leaving NetBeans development,
> because they don't want to code for the past. That is the other side of
> the coin. At least I'm pondering if that might be a good idea.
This! We are not pleasing our users by making promises we cannot
maintain, or driving people away from contributing.
Yes, I'm in this to please myself as well as to please users. They're
both important reasons to me why I contribute to open source projects.
The vast majority of our users are IDE users. I'm not sure telling
them we cannot support features or fix issues because of the amount of
work required to maintain JDK 8 compatibility in an application that
no longer officially supports it actually counts as pleasing them!
> Which Platform users need JDK 8 support and why can't they just stay on
> (for example) NetBeans 17?
And this! I'm a platform user too, and quite focused on the needs of
platform developers in this process. I've reached out to a few others
on this and pointed them to this thread, and I hope others (Geertjan?)
might have too. I saw Rangi also commented here.
No-one else has yet mentioned a need to maintain ongoing JDK 8 support
for them, nor given any reason to.
Best wishes,
Neil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Lets talk about JDK 8 (new year edition)
Posted by Matthias Bläsing <mb...@doppel-helix.eu.INVALID>.
Hi Jaroslav,
Am Sonntag, dem 02.04.2023 um 15:38 +0200 schrieb Jaroslav Tulach:
> > It also becomes increasingly difficult to
> > motivate myself to fix JDK 8 issues in my freetime.
>
> I can imagine that. However we are not coding NetBeans to please ourselves,
> but to please our users.
These users won't benefit from developers leaving NetBeans development,
because they don't want to code for the past. That is the other side of
the coin. At least I'm pondering if that might be a good idea.
> NetBeans Platform users need JDK8 support. That's why
> I am volunteering to maintain and run the CI & tests on JDK8.
Which Platform users need JDK 8 support and why can't they just stay on
(for example) NetBeans 17? They are obviously not interested in
features, as they are already cut of from all developments in the JDK
area and thus I question why they would be interested in NB features.
What is more these users will have the same problem with other
libraries, which are also dropping support for old JDKs.
Fixing CI & tests is only part of the problem (which is already
enough), but our dependencies also can't be updated because of this and
that is a massive problem.
To give a different perspective: Running software on JDK 8 at my work
is a sign of problems and is faced with serious questions from OPs.
Even JDK 11 is beginning to becoming increasingly questionable and
quite frankly, once you over the JDK 8 barrier, it gets better.
Greetings
Matthias
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Lets talk about JDK 8 (new year edition)
Posted by Laszlo Kishalmi <la...@gmail.com>.
On 4/2/23 06:38, Jaroslav Tulach wrote:
> I can imagine that. However we are not coding NetBeans to please ourselves,
> but to please our users. NetBeans Platform users need JDK8 support. That's why
> I am volunteering to maintain and run the CI & tests on JDK8.
Well, that's not true. I'm in the game as NetBeans is my hobby and I
enjoy working with the community and creating something that's
fun/useful for me. I'm not really in this for the users, but if I
contribute something that they like it's a win-win. (I guess no-one
really needed ANTLR editing support besides of me.)
It's not that frequent, I do some coding besides of NetBeans usually on
JDK 17. While I still learns something new on Java 8 here from the
community. I started to feel that uncomfortable (I was missing
Map.of(...) the other day).
It would be good to have some new younger contributors as well, though
if we are looking like a bunch of old hippies still riding a flower
painted old Volkswagen hippie bus...
I think NetBeans Platform users have plenty of JDK8 support from
NetBeans 8.0 -> NetBeans 18. If anyone would like to keep that dream
alive and release occasional JDK8 releases within the Apache project of
forked, they are free to do that.
In some of our tests that fails on Java 11+ (probably Java 9+), happens
as the default GC behaves differently. It is solvable, though again it's
a burden.
We still do not know what is your very specific use case that requires
NetBeans JDK 8 compatible beyond NetBeans 18...
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Lets talk about JDK 8 (new year edition)
Posted by James Gosling <ja...@norquay.com>.
+1
>
> No, it's keeping ancient code that works kludged into a system that
> desperately wants to move on.
> The one line "if" isn't the problem, it's making sure the code in the body
> of that if and the code in the "else" coexisting without problems.
>
> Let's face it, the "code that already works" is NetBeans 17. The "if" is
> simple. IF you want to run on JDK 8, use NetBeans 17.
> There has yet to be any justification presented to keep future versions
> working on JDK 8. Why should we be writing software for over 6 years ago
> instead of software for today and tomorrow?
Re: Lets talk about JDK 8 (new year edition)
Posted by Scott Palmer <sw...@gmail.com>.
On Sun, Apr 2, 2023 at 9:38 AM Jaroslav Tulach <ja...@gmail.com>
wrote:
> > >> https://github.com/apache/netbeans/issues/4904
> > >>
> > >> see also 'priority:high' label for more,
> > >
> > > The issue says "Many tests fail on JDK 11" - how does that compare to
> JDK
> > > 8?
> > well. You mostly see this while trying to fix them. It always requires
> > extra work to keep supporting 8 too.
>
> The "extra work" is "keeping the code that already works"! We have code
> that
> works on JDK8 and there is no "extra work" to let it run on JDK8! Adding
> one
> additional `if (JDK11+)` check and writing new code is the "extra work",
> but
> it has nothing to do with supporting JDK8!
>
No, it's keeping ancient code that works kludged into a system that
desperately wants to move on.
The one line "if" isn't the problem, it's making sure the code in the body
of that if and the code in the "else" coexisting without problems.
Let's face it, the "code that already works" is NetBeans 17. The "if" is
simple. IF you want to run on JDK 8, use NetBeans 17.
There has yet to be any justification presented to keep future versions
working on JDK 8. Why should we be writing software for over 6 years ago
instead of software for today and tomorrow?
> > > I am a guy who cares about compatibility (of NetBeans): Please tell me
> if
> > > there is a test that doesn't work on JDK 8 and needs to be fixed.
>
> I am still willing to maintain JDK8 tests, CI & etc.
>
Okay. Then maintain your own branch that works on JDK 8 and let the main
NetBeans code move on.
> > With every new JDK release it will become more difficult to keep
> > supporting JDK 8 as runtime.
>
> No. That is not true. The code exists and works. You don't have to do
> anything
> special to continue support it.
>
No. That is not true. The burden to keep JDK 8 code working *while the
world around that code changes* is significant.
E.g if we chose to use a Record for something that needs to pass through a
JDK 8 compatible code path, what then?
>
> > It also becomes increasingly difficult to
> > motivate myself to fix JDK 8 issues in my freetime.
>
> I can imagine that. However we are not coding NetBeans to please
> ourselves,
> but to please our users. NetBeans Platform users need JDK8 support.
So far you are the only user that has spoken up about wanting (much less
needing) NetBeans to run on JDK 8.
Where are the other users? Why do they need *future* versions of NB on JDK
8 rather than what they are running now? (This has been asked multiple
times and I don't think we've ever got an answer, but I may have missed it.)
> That's why
> I am volunteering to maintain and run the CI & tests on JDK8.
>
And when the tests fail? Are you going to do all the fixes?
If so, how is it different from you personally maintaining a JDK 8
compatible branch of NetBeans?
Sorry, I'm with Mr. Gosling on this one. Let JDK 8 die, or rather, as he
put it, "kill it."
Scott
Re: Lets talk about JDK 8 (new year edition)
Posted by Jaroslav Tulach <ja...@gmail.com>.
> >> https://github.com/apache/netbeans/issues/4904
> >>
> >> see also 'priority:high' label for more,
> >
> > The issue says "Many tests fail on JDK 11" - how does that compare to JDK
> > 8?
> well. You mostly see this while trying to fix them. It always requires
> extra work to keep supporting 8 too.
The "extra work" is "keeping the code that already works"! We have code that
works on JDK8 and there is no "extra work" to let it run on JDK8! Adding one
additional `if (JDK11+)` check and writing new code is the "extra work", but
it has nothing to do with supporting JDK8!
> > I am a guy who cares about compatibility (of NetBeans): Please tell me if
> > there is a test that doesn't work on JDK 8 and needs to be fixed.
I am still willing to maintain JDK8 tests, CI & etc.
> With every new JDK release it will become more difficult to keep
> supporting JDK 8 as runtime.
No. That is not true. The code exists and works. You don't have to do anything
special to continue support it.
> It also becomes increasingly difficult to
> motivate myself to fix JDK 8 issues in my freetime.
I can imagine that. However we are not coding NetBeans to please ourselves,
but to please our users. NetBeans Platform users need JDK8 support. That's why
I am volunteering to maintain and run the CI & tests on JDK8.
-jt
> If I see PRs which
> fix edge cases in java-version parsing code which could be already
> solved by simply using the JDK 11 API for it, I am just asking myself:
> why are we doing this? It is not one thing which is the problem, its a
> million paper cuts.
>
> -mbien
>
>
> [1] https://www.eclipse.org/lists/jakartaee-platform-dev/msg03898.html
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Lets talk about JDK 8 (new year edition)
Posted by Neil C Smith <ne...@apache.org>.
On Fri, 31 Mar 2023 at 23:54, rangi.keen@siemens.com
<ra...@siemens.com> wrote:
> I am in favor of an LTS-1 policy. It allows us to adopt (somewhat) recent additions to the language while still supporting some older environments. Given that with the new release roadmap we will see a new LTS release every two years, an LTS-2 policy may make more sense while still allowing use of relatively recent language features. This would mean moving to Java 11 for NB 20 after the release of Java 21 in September.
Thanks Rangi for your input. The LTS-1 proposal I made above is
slightly different in that we would change the supported baseline with
the release of NB 22 rather than NB 20. As we're always aiming to
support the current JDK, it's actually with the release of Java 22
that we end up with a new LTS to add to the support matrix.
So, LTS-1 would always be officially supporting three JDKs concurrently -
NB 20 & 21 - JDK 11, 17 and 21
NB 22 - JDK 17, 21 and 22
An LTS-2 strategy might be to keep JDK 11 as the runtime minimum until
NB 30 in 2026, always supporting four JDKs concurrently. That might
be a capacity issue (people and CI)? Personally, I think we'd have to
then run a different policy for min build JDK than min runtime JDK
too.
It would be good in any way to align the platform with the IDE, which
has required JDK 11 for over a year now.
As mentioned earlier, I'm planning a lazy consensus and/or vote thread
on this from Monday. Have written up a fuller version of the above as
a draft, which might be amended if anyone has further comments that
can be addressed. The lazy consensus stage will also be a chance to
amend.
Best wishes,
Neil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Lets talk about JDK 8 (new year edition)
Posted by "rangi.keen@siemens.com" <ra...@siemens.com>.
I am in favor of an LTS-1 policy. It allows us to adopt (somewhat) recent additions to the language while still supporting some older environments. Given that with the new release roadmap <https://www.oracle.com/java/technologies/java-se-support-roadmap.html> we will see a new LTS release every two years, an LTS-2 policy may make more sense while still allowing use of relatively recent language features. This would mean moving to Java 11 for NB 20 after the release of Java 21 in September.
Rangi
> On Mar 24, 2023, at 3:10 PM, Neil C Smith <ne...@apache.org> wrote:
>
> On Tue, 14 Feb 2023 at 08:51, Michael Bien <mb...@gmail.com> wrote:
>> With every new JDK release it will become more difficult to keep
>> supporting JDK 8 as runtime. It also becomes increasingly difficult to
>> motivate myself to fix JDK 8 issues in my freetime. If I see PRs which
>> fix edge cases in java-version parsing code which could be already
>> solved by simply using the JDK 11 API for it, I am just asking myself:
>> why are we doing this? It is not one thing which is the problem, its a
>> million paper cuts.
>
> This thread has somewhat split into conversations elsewhere. But if
> we're going to save ourselves from the million paper cuts by nailing
> the coffin lid shut :-) we should probably move to vote on this soon.
>
> We're about to hit the branch point for NB18 in a few weeks. I swear
> this comes around quicker each time! If we're going to drop all
> support for running on JDK 8 in NetBeans 19, then it would be good to
> make that decision before NB18 branch and start of NB19 development.
> I'd be very happy if anyone else wants to propose a vote(!), but if
> nothing starts before week of April 3 I intend to initiate one so we
> can get a decision in time. I'd also prefer we did this via lazy
> consensus as we've done previously, but I get the feeling that won't
> work!
>
> Personally I'd also like us to link the decision on future JDK support
> to this too, so we could be clear to ourselves, platform developers,
> and users for how long we intend to commit to supporting particular
> JDKs. Various people, including me, have proposed an LTS-1 strategy.
> But the implication of that is only committing to supporting build and
> run of the IDE and platform on JDK 11 until the middle of 2024. Are
> the people not in favour of that in favour of an LTS-2 strategy, or
> something else entirely? What are the implications for us of that,
> etc.? I know Svata commented elsewhere about following up on this
> point - be good to understand the concerns and/or consider how to
> address within the capacity we have.
>
> We could of course separate the two things, if we really need to, but
> I'm not sure kicking the can further down the road is a good idea.
>
> Best wishes,
>
> Neil
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: dev-help@netbeans.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FNETBEANS%2FMailing%2Blists&data=05%7C01%7Crangi.keen%40siemens.com%7Cd7fb02c589424947056408db2c9ba388%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C638152819202129031%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=oxsbg4e0O7XutYjPCEklAb7s%2FHThQ1QjREiOq5eOHF0%3D&reserved=0
>
>
>
Re: Lets talk about JDK 8 (new year edition)
Posted by Neil C Smith <ne...@apache.org>.
On Tue, 14 Feb 2023 at 08:51, Michael Bien <mb...@gmail.com> wrote:
> With every new JDK release it will become more difficult to keep
> supporting JDK 8 as runtime. It also becomes increasingly difficult to
> motivate myself to fix JDK 8 issues in my freetime. If I see PRs which
> fix edge cases in java-version parsing code which could be already
> solved by simply using the JDK 11 API for it, I am just asking myself:
> why are we doing this? It is not one thing which is the problem, its a
> million paper cuts.
This thread has somewhat split into conversations elsewhere. But if
we're going to save ourselves from the million paper cuts by nailing
the coffin lid shut :-) we should probably move to vote on this soon.
We're about to hit the branch point for NB18 in a few weeks. I swear
this comes around quicker each time! If we're going to drop all
support for running on JDK 8 in NetBeans 19, then it would be good to
make that decision before NB18 branch and start of NB19 development.
I'd be very happy if anyone else wants to propose a vote(!), but if
nothing starts before week of April 3 I intend to initiate one so we
can get a decision in time. I'd also prefer we did this via lazy
consensus as we've done previously, but I get the feeling that won't
work!
Personally I'd also like us to link the decision on future JDK support
to this too, so we could be clear to ourselves, platform developers,
and users for how long we intend to commit to supporting particular
JDKs. Various people, including me, have proposed an LTS-1 strategy.
But the implication of that is only committing to supporting build and
run of the IDE and platform on JDK 11 until the middle of 2024. Are
the people not in favour of that in favour of an LTS-2 strategy, or
something else entirely? What are the implications for us of that,
etc.? I know Svata commented elsewhere about following up on this
point - be good to understand the concerns and/or consider how to
address within the capacity we have.
We could of course separate the two things, if we really need to, but
I'm not sure kicking the can further down the road is a good idea.
Best wishes,
Neil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Lets talk about JDK 8 (new year edition)
Posted by Michael Bien <mb...@gmail.com>.
On 13.02.23 20:06, Jaroslav Tulach wrote:
> Thank you for the pointers Michael.
>
>>>> This means we need either 1) a volunteer who would like to spend time
>>>> and fix JDK 8 tests,
>>> OK, tell me what to do.
>> as recap:
>>
>> this thread was started to notify that a JDK 8 issue was blocking a
>> fairly big Jakarta EE PR (#4692) which made only sense under JDK 11
>> anyway.
> Are you saying `enterprise` cluster requires JDK 11 and cannot run on JDK 8?
the Jakarta EE 10 modules require JDK 11, you can see it in Neil's commit:
https://github.com/apache/netbeans/pull/4692/commits/e6d965f2010d56ecc72f4b968b909bd88ccadefd
The next update of maven-indexer will require JDK 11 too, we can delay
this still a bit further but this gonna have to happen sooner or later.
It will also give us shiny features like parallel index extraction for free.
Another module which requires JDK 11 is "java.disco", the java
discovery/download service. The reason there too, was not because we
wanted to use Java-11-the-language, but because the dependencies were
only available on 11.
With Spring on 17, JEE on 21 next year (yey virtual threads!) and even
android is adding Java 11 APIs now (with sloth-speed), this will become
more common.
> I am not able to find the blocker...
blocker was that the CV tests failed on 8 and despite some module
manifest-fu, only Neil could find the right combination (with his magic
hands) of settings to make everything work - just in time for the deadline.
> "NetBeans Platform" - e.g. if you want to drop support for old JDKs in
> `enterprise` cluster - be it! It is (and always has been) a "user facing"
> cluster anyway.
yeah. Dependent on how the 'target' in "Jakarta EE 11 targets Java
21"[1] will be interpreted by vendors, the enterprise cluster might be
the cluster with the largest jump some time next year (although some of
it will already require 11, so the jump just became smaller).
>
>> we have some umbrella issues here for example where contributions are
>> welcome:
>>
>> https://github.com/apache/netbeans/issues/4904
>>
>> see also 'priority:high' label for more,
> The issue says "Many tests fail on JDK 11" - how does that compare to JDK 8?
well. You mostly see this while trying to fix them. It always requires
extra work to keep supporting 8 too.
JDK 9 also provides a replacement for the finalizer mechanism
(deprecated for removal) which we can't use #5440 - extra steps everywhere.
>
> I am a guy who cares about compatibility (of NetBeans): Please tell me if
> there is a test that doesn't work on JDK 8 and needs to be fixed.
>
> Summary: if you guys want to support JDK 11, then it is great. Do it!
With every new JDK release it will become more difficult to keep
supporting JDK 8 as runtime. It also becomes increasingly difficult to
motivate myself to fix JDK 8 issues in my freetime. If I see PRs which
fix edge cases in java-version parsing code which could be already
solved by simply using the JDK 11 API for it, I am just asking myself:
why are we doing this? It is not one thing which is the problem, its a
million paper cuts.
-mbien
[1] https://www.eclipse.org/lists/jakartaee-platform-dev/msg03898.html
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Lets talk about JDK 8 (new year edition)
Posted by Jaroslav Tulach <ja...@gmail.com>.
Thank you for the pointers Michael.
> >> This means we need either 1) a volunteer who would like to spend time
> >> and fix JDK 8 tests,
> >
> > OK, tell me what to do.
>
> as recap:
>
> this thread was started to notify that a JDK 8 issue was blocking a
> fairly big Jakarta EE PR (#4692) which made only sense under JDK 11
> anyway.
Are you saying `enterprise` cluster requires JDK 11 and cannot run on JDK 8?
It is a relatively huge PR and it is not easy to get my head around it.
Anyway, there is for example
https://github.com/apache/netbeans/pull/4692/files?file-filters%5B%5D=.properties&show-viewed-files=true#diff-6a741863ce06039216c34ea7e2d656c1c98044c11587a52b90fa82a6a9bc5097R19
which claims the module runs on JDK 8 - e.g. where is the problem? That's all
I am asking for: to run NetBeans on JDK 8 ;-)
I am not able to find the blocker...
> This was detected months ago and fixed less than a month ago by
> Neil - right before the NB 17 deadline as you can see in the discussion.
> That is why it had to be resolved quickly otherwise we would have
> another release with almost no Jakarta EE support.
Glad for NetBeans to support Jakarta EE. Anyway I have to admit, historically
the `enterprise` modules were always special - nobody really uses them as a
"NetBeans Platform" - e.g. if you want to drop support for old JDKs in
`enterprise` cluster - be it! It is (and always has been) a "user facing"
cluster anyway.
> Help is always appreciated but it is late in this particular case,
Honestly, `enterprise` cluster has always been a lost case. Let's try to save
the more important clusters!
> we have some umbrella issues here for example where contributions are
> welcome:
>
> https://github.com/apache/netbeans/issues/4904
>
> see also 'priority:high' label for more,
The issue says "Many tests fail on JDK 11" - how does that compare to JDK 8?
Because the problem of many tests failing on JDK 11 has always been that JDK
11 is incompatible with JDK 8. That's completely different problem - it is a
problem of the JDK!
I am a guy who cares about compatibility (of NetBeans): Please tell me if
there is a test that doesn't work on JDK 8 and needs to be fixed.
Summary: if you guys want to support JDK 11, then it is great. Do it! I am
willing to work as much as I can to **not drop** JDK 8 support. Tell me what
is blocking you with JDK 8 support and I fix it.
-jt
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Lets talk about JDK 8 (new year edition)
Posted by Michael Bien <mb...@gmail.com>.
On 10.02.23 03:30, Jaroslav Tulach wrote:
> Dne úterý 10. ledna 2023 15:16:35 CET, Michael Bien napsal(a):
>> Hello devs,
>>
>> I hope everyone recovered from the last JDK 8 thread and is ready for
>> the first JDK 8 thread of 2023 :)
> Nobody recovers from these threads with you guys without wounds.
>
> -1 (I mean veto) on dropping JDK 8 support.
this thread is no voting thread, see below.
>
>> The commit validation job is currently testing on 8, 11, 17 and 20-ea.
> Good.
>
>> This means we need either 1) a volunteer who would like to spend time
>> and fix JDK 8 tests,
> OK, tell me what to do.
as recap:
this thread was started to notify that a JDK 8 issue was blocking a
fairly big Jakarta EE PR (#4692) which made only sense under JDK 11
anyway. This was detected months ago and fixed less than a month ago by
Neil - right before the NB 17 deadline as you can see in the discussion.
That is why it had to be resolved quickly otherwise we would have
another release with almost no Jakarta EE support.
Help is always appreciated but it is late in this particular case,
we have some umbrella issues here for example where contributions are
welcome:
https://github.com/apache/netbeans/issues/4904
see also 'priority:high' label for more,
best regards,
michael
> -jt
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: dev-help@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-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Lets talk about JDK 8 (new year edition)
Posted by Kirk Pepperdine <ki...@kodewerk.com>.
> On Feb 13, 2023, at 7:38 PM, James Gosling <ja...@norquay.com> wrote:
>
> So…. In my opinion, JDK8 must die.
+1000, I cringe every time I see one of our VM engineers “back-port” a new feature!!! GCToolKit is at 11, pinned by users for the moment but I compile and test with 17 and 20.
> Anyone using Android is in their own special hell, so I tend to not worry about them much (mostly spoken as one who has emerged from being connected with a project that attempted to work with Android, but OMG…). If it were me, I’d skip forward to the latest LTS release, jdk17. I’m living there in my current project, and it’s lovely. Especially the GC.
>
> Stop the unholy contortions to coexist. Kill it. Nail its coffin closed. Do not look back.
>
>> On Feb 13, 2023, at 5:28 PM, Laszlo Kishalmi <la...@gmail.com> wrote:
>>
>> What is happening with people in 2023?
>>
>> Attempted bribery (another topic), threatening veto-s and supporters...
>>
>> With all my respect, Jarda, please don't act like this!
>>
>> We are talking and trying to find a solution to a problem:
>>
>> Java 8 is becoming a dead weight on this project.
>>
>> That's a fact, throwing a tantrum over it is not an adult way to handle the situation.
>>
>> Could you elaborate please, how would that affect your world, if for example. NetBeans 20 modules would be compiled with release 11 target?
>>
>> Using lookup and other core modules on Android? Since you are on JDK 8, what would happen if you would stick with your libraries on NetBeans 19? That's certainly possible. Any other use case?
>>
>> Previously you've offered on ideas to separate the language and the target JDK, so the target JDK can be level 8. There were no real use cases other than we can run on Java 8. By now it seems like an obsession.
>>
>> So reason, do not threat! Offer alternatives! The one, so far, it seems was not good enough.
>>
>> Help me understand, that those projects which are stuck on Java 8 for whatever reason, why can't stuck on a specific NetBeans version as well?
>>
>> Help me understand, what's wrong with maintaining a branch for NetBeans which kept on Java 8 and backport necessary stuff from master every now and then. That could be released, auto updated in need?
>>
>> Also, what would be of the scope of this "Java 8 Forever!" movement? The platform (with harness, core) cluster? The ide cluster? All we know, is that the enterprise cluster is a lost cause.
>>
>>
>> I feel, I've lost one of my heroes today...
>>
>> On 2/13/23 11:25, Jaroslav Tulach wrote:
>>> Thank you for your reply Neil.
>>>
>>>>>> I hope everyone recovered from the last JDK 8 thread and is ready for
>>>>>> the first JDK 8 thread of 2023 :)
>>>>> Nobody recovers from these threads with you guys without wounds.
>>>>>
>>>>> -1 (I mean veto) on dropping JDK 8 support.
>>>> If this were a lazy consensus thread, and we're not there yet, I'd
>>>> expect a -1
>>> As you probably know, I am not participating in day-to-day development of
>>> NetBeans. It may happen I miss the vote thread - technically it might be
>>> presented as my mistake, but in reality it would be an obstruction, because
>>> everyone of you shall know:
>>>
>>> I am voting against dropping support for JDK 8.
>>>
>>> At any vote you ever call - even if I miss it. Please be so nice and make sure
>>> I know that a vote is about to happen. Otherwise I will challenge that vote at
>>> Apache authorities.
>>>
>>>> to cover a lot more about an alternative way forward,
>>>> addressing the resource issues, testing capacity constraints, peoples'
>>>> time, priorities in supporting JDK 21+, release headaches, etc.
>>> That's what I have been providing to you for the last three years (at least).
>>> You were never listening to me. Whenever I tried to move NetBeans IDE forward,
>>> while keeping the wide usability of NetBeans Platform, you said no.
>>>
>>> Well, it is my turn now. I am saying no to "blind" dropping of JDK 8 support.
>>>
>>>> I hope we can find a consensus way forward on all that, but if not we
>>>> end up with a majority vote on the issue.
>>> I certainly hope we find a consensus. That was always the goal behind all my
>>> proposals in the last few years.
>>>
>>> Threatening with a "non-veto" vote on a code issue is a bit nasty, but I can
>>> live with it. Just keep me informed, so I can mobilize supporters.
>>>
>>>> And soon we'll end up with 8, 11, 17, 21 and 22-ea. That does not
>>>> feel sustainable.
>>> Why not? It is a machine doing the testing and it runs "for free". Anyway if
>>> you want to simplify the matrix - then drop 11 or 17 or 21 - they are all the
>>> same anyway. The the important thing is the bottom and then whether it shall
>>> be JDK8 or not!
>>>
>>> Let the negotiations begin!
>>> -jt
>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
>>> For additional commands, e-mail: dev-help@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-unsubscribe@netbeans.apache.org
>> For additional commands, e-mail: dev-help@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-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: dev-help@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-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Lets talk about JDK 8 (new year edition)
Posted by James Gosling <ja...@norquay.com>.
So…. In my opinion, JDK8 must die. Anyone using Android is in their own special hell, so I tend to not worry about them much (mostly spoken as one who has emerged from being connected with a project that attempted to work with Android, but OMG…). If it were me, I’d skip forward to the latest LTS release, jdk17. I’m living there in my current project, and it’s lovely. Especially the GC.
Stop the unholy contortions to coexist. Kill it. Nail its coffin closed. Do not look back.
> On Feb 13, 2023, at 5:28 PM, Laszlo Kishalmi <la...@gmail.com> wrote:
>
> What is happening with people in 2023?
>
> Attempted bribery (another topic), threatening veto-s and supporters...
>
> With all my respect, Jarda, please don't act like this!
>
> We are talking and trying to find a solution to a problem:
>
> Java 8 is becoming a dead weight on this project.
>
> That's a fact, throwing a tantrum over it is not an adult way to handle the situation.
>
> Could you elaborate please, how would that affect your world, if for example. NetBeans 20 modules would be compiled with release 11 target?
>
> Using lookup and other core modules on Android? Since you are on JDK 8, what would happen if you would stick with your libraries on NetBeans 19? That's certainly possible. Any other use case?
>
> Previously you've offered on ideas to separate the language and the target JDK, so the target JDK can be level 8. There were no real use cases other than we can run on Java 8. By now it seems like an obsession.
>
> So reason, do not threat! Offer alternatives! The one, so far, it seems was not good enough.
>
> Help me understand, that those projects which are stuck on Java 8 for whatever reason, why can't stuck on a specific NetBeans version as well?
>
> Help me understand, what's wrong with maintaining a branch for NetBeans which kept on Java 8 and backport necessary stuff from master every now and then. That could be released, auto updated in need?
>
> Also, what would be of the scope of this "Java 8 Forever!" movement? The platform (with harness, core) cluster? The ide cluster? All we know, is that the enterprise cluster is a lost cause.
>
>
> I feel, I've lost one of my heroes today...
>
> On 2/13/23 11:25, Jaroslav Tulach wrote:
>> Thank you for your reply Neil.
>>
>>>>> I hope everyone recovered from the last JDK 8 thread and is ready for
>>>>> the first JDK 8 thread of 2023 :)
>>>> Nobody recovers from these threads with you guys without wounds.
>>>>
>>>> -1 (I mean veto) on dropping JDK 8 support.
>>> If this were a lazy consensus thread, and we're not there yet, I'd
>>> expect a -1
>> As you probably know, I am not participating in day-to-day development of
>> NetBeans. It may happen I miss the vote thread - technically it might be
>> presented as my mistake, but in reality it would be an obstruction, because
>> everyone of you shall know:
>>
>> I am voting against dropping support for JDK 8.
>>
>> At any vote you ever call - even if I miss it. Please be so nice and make sure
>> I know that a vote is about to happen. Otherwise I will challenge that vote at
>> Apache authorities.
>>
>>> to cover a lot more about an alternative way forward,
>>> addressing the resource issues, testing capacity constraints, peoples'
>>> time, priorities in supporting JDK 21+, release headaches, etc.
>> That's what I have been providing to you for the last three years (at least).
>> You were never listening to me. Whenever I tried to move NetBeans IDE forward,
>> while keeping the wide usability of NetBeans Platform, you said no.
>>
>> Well, it is my turn now. I am saying no to "blind" dropping of JDK 8 support.
>>
>>> I hope we can find a consensus way forward on all that, but if not we
>>> end up with a majority vote on the issue.
>> I certainly hope we find a consensus. That was always the goal behind all my
>> proposals in the last few years.
>>
>> Threatening with a "non-veto" vote on a code issue is a bit nasty, but I can
>> live with it. Just keep me informed, so I can mobilize supporters.
>>
>>> And soon we'll end up with 8, 11, 17, 21 and 22-ea. That does not
>>> feel sustainable.
>> Why not? It is a machine doing the testing and it runs "for free". Anyway if
>> you want to simplify the matrix - then drop 11 or 17 or 21 - they are all the
>> same anyway. The the important thing is the bottom and then whether it shall
>> be JDK8 or not!
>>
>> Let the negotiations begin!
>> -jt
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
>> For additional commands, e-mail: dev-help@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-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: dev-help@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-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Lets talk about JDK 8 (new year edition)
Posted by Glenn Holmer <ce...@protonmail.com.INVALID>.
On 2/13/23 21:28, Laszlo Kishalmi wrote:
> Java 8 is becoming a dead weight on this project.
+1
> Help me understand, that those projects which are stuck on Java 8 for
> whatever reason, why can't stuck on a specific NetBeans version as well?
To me, that's the crux of the problem. If you need an old version of the
JDK, run an old version of NetBeans. Don't try and hold back the current
version.
--
Glenn Holmer (Linux registered user #16682)
"After the vintage season came the aftermath -- and Cenbe."
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Lets talk about JDK 8 (new year edition)
Posted by Laszlo Kishalmi <la...@gmail.com>.
What is happening with people in 2023?
Attempted bribery (another topic), threatening veto-s and supporters...
With all my respect, Jarda, please don't act like this!
We are talking and trying to find a solution to a problem:
Java 8 is becoming a dead weight on this project.
That's a fact, throwing a tantrum over it is not an adult way to handle
the situation.
Could you elaborate please, how would that affect your world, if for
example. NetBeans 20 modules would be compiled with release 11 target?
Using lookup and other core modules on Android? Since you are on JDK 8,
what would happen if you would stick with your libraries on NetBeans 19?
That's certainly possible. Any other use case?
Previously you've offered on ideas to separate the language and the
target JDK, so the target JDK can be level 8. There were no real use
cases other than we can run on Java 8. By now it seems like an obsession.
So reason, do not threat! Offer alternatives! The one, so far, it seems
was not good enough.
Help me understand, that those projects which are stuck on Java 8 for
whatever reason, why can't stuck on a specific NetBeans version as well?
Help me understand, what's wrong with maintaining a branch for NetBeans
which kept on Java 8 and backport necessary stuff from master every now
and then. That could be released, auto updated in need?
Also, what would be of the scope of this "Java 8 Forever!" movement? The
platform (with harness, core) cluster? The ide cluster? All we know, is
that the enterprise cluster is a lost cause.
I feel, I've lost one of my heroes today...
On 2/13/23 11:25, Jaroslav Tulach wrote:
> Thank you for your reply Neil.
>
>>>> I hope everyone recovered from the last JDK 8 thread and is ready for
>>>> the first JDK 8 thread of 2023 :)
>>> Nobody recovers from these threads with you guys without wounds.
>>>
>>> -1 (I mean veto) on dropping JDK 8 support.
>> If this were a lazy consensus thread, and we're not there yet, I'd
>> expect a -1
> As you probably know, I am not participating in day-to-day development of
> NetBeans. It may happen I miss the vote thread - technically it might be
> presented as my mistake, but in reality it would be an obstruction, because
> everyone of you shall know:
>
> I am voting against dropping support for JDK 8.
>
> At any vote you ever call - even if I miss it. Please be so nice and make sure
> I know that a vote is about to happen. Otherwise I will challenge that vote at
> Apache authorities.
>
>> to cover a lot more about an alternative way forward,
>> addressing the resource issues, testing capacity constraints, peoples'
>> time, priorities in supporting JDK 21+, release headaches, etc.
> That's what I have been providing to you for the last three years (at least).
> You were never listening to me. Whenever I tried to move NetBeans IDE forward,
> while keeping the wide usability of NetBeans Platform, you said no.
>
> Well, it is my turn now. I am saying no to "blind" dropping of JDK 8 support.
>
>> I hope we can find a consensus way forward on all that, but if not we
>> end up with a majority vote on the issue.
> I certainly hope we find a consensus. That was always the goal behind all my
> proposals in the last few years.
>
> Threatening with a "non-veto" vote on a code issue is a bit nasty, but I can
> live with it. Just keep me informed, so I can mobilize supporters.
>
>> And soon we'll end up with 8, 11, 17, 21 and 22-ea. That does not
>> feel sustainable.
> Why not? It is a machine doing the testing and it runs "for free". Anyway if
> you want to simplify the matrix - then drop 11 or 17 or 21 - they are all the
> same anyway. The the important thing is the bottom and then whether it shall
> be JDK8 or not!
>
> Let the negotiations begin!
> -jt
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: dev-help@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-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Lets talk about JDK 8 (new year edition)
Posted by Matthias Bläsing <mb...@doppel-helix.eu.INVALID>.
Hi,
Am Montag, dem 13.02.2023 um 20:25 +0100 schrieb Jaroslav Tulach:
> I am voting against dropping support for JDK 8.
I don't understand you: JDK 8 is a dead end. There will be no new
features. So why do you expect new features from your libraries? Just
use lookup/collections/whatever from ${last nb version compatible with
$ancient toolchain} and be done with it.
You would also to expect people to keep writing Windows 95 compatible
applications just because you refuse to update.
The question is: How long do you expect us to stay in the past?
> At any vote you ever call - even if I miss it. Please be so nice and make sure
> I know that a vote is about to happen. Otherwise I will challenge that vote at
> Apache authorities.
What do you expect them to do? A vote is called, there is a voting
period and later it is counted. This follows the procedures declared by
Apache. The only thing such a thread causes for me, to ensure, that hte
rules are literally followed.
> Why not? It is a machine doing the testing and it runs "for free".
Lie. Of course someone has to pay for the computing power and you might
not have noticed, but we already had to shift from travis to github
actions. Surely not because travis continued to provide the services
for free.
Greetings
Matthias
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Lets talk about JDK 8 (new year edition)
Posted by Neil C Smith <ne...@apache.org>.
On Mon, 13 Feb 2023 at 19:26, Jaroslav Tulach <ja...@gmail.com> wrote:
> As you probably know, I am not participating in day-to-day development of
> NetBeans.
And for those of use who are more involved day-to-day, it's causing
issues, and creating work (including the issue that kicked off this
thread). That one I argued we should fix and keep the validation
tests on JDK 8, and put time into fixing. I'm personally not prepared
to invest any more of my time into this in future though.
> At any vote you ever call - even if I miss it. Please be so nice and make sure
> I know that a vote is about to happen. Otherwise I will challenge that vote at
> Apache authorities.
Why are you directing this at me personally? Any PMC member could
call a vote on this. I'd quite like to get a consensus way forward,
and the framework aspect of NetBeans, and the needs of those users, is
really key for me as I've argued already in this thread.
> That's what I have been providing to you for the last three years (at least).
> You were never listening to me. Whenever I tried to move NetBeans IDE forward,
> while keeping the wide usability of NetBeans Platform, you said no.
Again, is this addressed at me personally? I'm not entirely sure what
you mean, but I've certainly listened to your proposals. I don't
believe they could have addressed many of the points that have been
raised though.
> Threatening with a "non-veto" vote on a code issue is a bit nasty, but I can
> live with it.
No-one is threatening anything, so please stop assuming bad faith. I
was pointing out the logical conclusion of where this ends up.
> Just keep me informed, so I can mobilize supporters.
As Matthias pointed out in his thread, what's needed is supporters who
are also willing to pick up the work required.
> > And soon we'll end up with 8, 11, 17, 21 and 22-ea. That does not
> > feel sustainable.
>
> Why not? It is a machine doing the testing and it runs "for free".
It's certainly not free. ASF has testing infrastructure sponsored by
GitHub, but it's not unlimited, and we're a fairly heavy user as it
is. The time taken for tests to run also has knock-on implications.
Best wishes,
Neil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Lets talk about JDK 8 (new year edition)
Posted by Jaroslav Tulach <ja...@gmail.com>.
Thank you for your reply Neil.
> > > I hope everyone recovered from the last JDK 8 thread and is ready for
> > > the first JDK 8 thread of 2023 :)
> >
> > Nobody recovers from these threads with you guys without wounds.
> >
> > -1 (I mean veto) on dropping JDK 8 support.
>
> If this were a lazy consensus thread, and we're not there yet, I'd
> expect a -1
As you probably know, I am not participating in day-to-day development of
NetBeans. It may happen I miss the vote thread - technically it might be
presented as my mistake, but in reality it would be an obstruction, because
everyone of you shall know:
I am voting against dropping support for JDK 8.
At any vote you ever call - even if I miss it. Please be so nice and make sure
I know that a vote is about to happen. Otherwise I will challenge that vote at
Apache authorities.
> to cover a lot more about an alternative way forward,
> addressing the resource issues, testing capacity constraints, peoples'
> time, priorities in supporting JDK 21+, release headaches, etc.
That's what I have been providing to you for the last three years (at least).
You were never listening to me. Whenever I tried to move NetBeans IDE forward,
while keeping the wide usability of NetBeans Platform, you said no.
Well, it is my turn now. I am saying no to "blind" dropping of JDK 8 support.
> I hope we can find a consensus way forward on all that, but if not we
> end up with a majority vote on the issue.
I certainly hope we find a consensus. That was always the goal behind all my
proposals in the last few years.
Threatening with a "non-veto" vote on a code issue is a bit nasty, but I can
live with it. Just keep me informed, so I can mobilize supporters.
> And soon we'll end up with 8, 11, 17, 21 and 22-ea. That does not
> feel sustainable.
Why not? It is a machine doing the testing and it runs "for free". Anyway if
you want to simplify the matrix - then drop 11 or 17 or 21 - they are all the
same anyway. The the important thing is the bottom and then whether it shall
be JDK8 or not!
Let the negotiations begin!
-jt
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Lets talk about JDK 8 (new year edition)
Posted by Neil C Smith <ne...@apache.org>.
On Fri, 10 Feb 2023 at 02:31, Jaroslav Tulach <ja...@gmail.com> wrote:
>
> Dne úterý 10. ledna 2023 15:16:35 CET, Michael Bien napsal(a):
> > Hello devs,
> >
> > I hope everyone recovered from the last JDK 8 thread and is ready for
> > the first JDK 8 thread of 2023 :)
>
> Nobody recovers from these threads with you guys without wounds.
>
> -1 (I mean veto) on dropping JDK 8 support.
If this were a lazy consensus thread, and we're not there yet, I'd
expect a -1 to cover a lot more about an alternative way forward,
addressing the resource issues, testing capacity constraints, peoples'
time, priorities in supporting JDK 21+, release headaches, etc.
I hope we can find a consensus way forward on all that, but if not we
end up with a majority vote on the issue.
> > The commit validation job is currently testing on 8, 11, 17 and 20-ea.
>
> Good.
And soon we'll end up with 8, 11, 17, 21 and 22-ea. That does not
feel sustainable.
Best wishes,
Neil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Lets talk about JDK 8 (new year edition)
Posted by Jaroslav Tulach <ja...@gmail.com>.
Dne úterý 10. ledna 2023 15:16:35 CET, Michael Bien napsal(a):
> Hello devs,
>
> I hope everyone recovered from the last JDK 8 thread and is ready for
> the first JDK 8 thread of 2023 :)
Nobody recovers from these threads with you guys without wounds.
-1 (I mean veto) on dropping JDK 8 support.
> The commit validation job is currently testing on 8, 11, 17 and 20-ea.
Good.
> This means we need either 1) a volunteer who would like to spend time
> and fix JDK 8 tests,
OK, tell me what to do.
-jt
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Compatibility with JDK 8: Shift work to people wanting it (was: Re: Lets talk about JDK 8 (new year edition))
Posted by Ernie Rael <er...@raelity.com>.
(Apologies if you see this twice. First sent this 3 hours ago. It was
not delivered to me; anyone?)
As Neil says
> The question is whether it is worth it?
And Scott
> An informed decision needs to be based on these details. Holding back
> for
> JDK 8 compatibility helps no one if there isn't actually any real
> demand to
> do so.
AFAICT, there's no stats on JDK version and NBP projects. Maybe the
closest is general
JDK usage, I don't know how well they relate, but it's the best we've got.
Last year, there were reports that JDK-8/JDK-11 were neck and neck at
somewhat under
50 percent, with JDK-11 and JDK-17 picking up steam.
So where's JDK-8 this year? An estimate might be 33%. If one third of
users are on
JDK-8, is that a real demand? Definitely JDK-8 usage is going down, how
steeply?
(Plenty of hand waving, but worth trying to base the discussion on fact.)
One question, what is the point below which there's no real demand and it's
not worth it?
-ernie
On 23/02/12 2:22 PM, Neil C Smith wrote:
> On Sun, 12 Feb 2023, 19:11 Matthias Bläsing,
> <mb...@doppel-helix.eu.invalid> wrote:
>
>> Hi,
>>
>> Am Freitag, dem 10.02.2023 um 10:12 +0000 schrieb Neil C Smith:
>>> On Thu, 9 Feb 2023 at 19:02, Matthias Bläsing<mb...@doppel-helix.eu.invalid>
>> wrote:
>>>> - commit to make NetBeans runnable on JDK LTS -1
>>>> - build with JDK LTS -1
>>>> - be able to be build with the current JDK
>>> +1 as long as that includes the platform.
>>>
>>> That is what I suggested in the other thread (I don't see why we need
>>> multiple threads incidentally!)
>>>
>>> An LTS-1 strategy seems closest to how NetBeans used to function -
>>> major-1, in a time when it also had more development resources?
>>>
>>> Let's also be clear, though, that adopting an LTS-1 strategy means
>>> dropping JDK 11 support either in our first release after JDK 21, or
>>> the first after JDK 22 - so latest May 2024.
>> why would we do that? I said _runnable_ and _buildable_. As long as the
>> current JDK support the target release I did not exclude that.
>>
> In which case I don't understand what you mean by committing to make
> NetBeans buildable and runnable on LTS-1? That to me means dropping the
> commitment to JDK 11 when it becomes LTS-2.
>
>
>
>>>> - keep as many modules as feasible compatible with release 8
>>> -1 : A number of things have come up recently about preparing for JDK
>>> 21+ that would involve increasing the bytecode level and APIs in some
>>> core parts of the NetBeans runtime container.
>> Could you elaborate what that is? Not using Thread#stop and dropping
>> finalizers is it not. That can be done (with some pain) with support
>> for 8. So what is the problem?
>>
> Yes, those and I think some others. My paragraph after the one you quoted
> was acknowledging we can do this for 8 with some pain (headache). The
> question is whether it is worth it?
>
> Best wishes,
>
> Neil
>
Re: Compatibility with JDK 8: Shift work to people wanting it (was: Re: Lets talk about JDK 8 (new year edition))
Posted by Neil C Smith <ne...@apache.org>.
On Thu, 16 Mar 2023 at 11:46, Svata Dedic <sv...@gmail.com> wrote:
> I see the rapid movement between
> JDK versions that is even increasing with increased frequency of JDK
> releases (with only limited features that make a real difference for NB
> development) as dangerous
But also a reality we don't control, and affects not just us but the
ecosystem we rely on.
> In my current state of mind / evaluation of the issue I'd give -0.5 to
> JDK8 drop and -infinity to JDK11 drop next year. I'll try to catch up
> with the conversation during till next week - the stated position needs
> more elaborate explanation, but I don't want to repeat others (too
> much). Thanks.
Fair enough. It would be good to link the -1's (or -0.5 to -infinity
:-) ) to alternative answers to the problems we face though.
On JDK 8, how would you envisage solving eg. the Maven indexer issues,
or other (currently) non-optional dependencies and modules needing
access to JDK 11+ APIs? Who is going to do the extra work that will
lead to?
On not dropping JDK 11 next year, what supported matrix of JDKs do you
think we should aim for with the platform and the IDE? Do you think
we should support and test across 4+ concurrent JDK's - JDK 11, 17 and
21 LTS as well as current? Where are the resources, CI, manpower and
release testing for that? Do you support an LTS-2 strategy, dropping
JDK 11 when JDK 25 is out? Or is the JDK LTS status irrelevant in
choosing our support matrix, and if so what should that be based on?
Best wishes,
Neil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Compatibility with JDK 8: Shift work to people wanting it (was: Re: Lets talk about JDK 8 (new year edition))
Posted by Svata Dedic <sv...@gmail.com>.
Speaking for myself personally:
I'd like to step in the discussion, as I see the rapid movement between
JDK versions that is even increasing with increased frequency of JDK
releases (with only limited features that make a real difference for NB
development) as dangerous - but I still lag behind as I am trying to
read the whole thread.
In my current state of mind / evaluation of the issue I'd give -0.5 to
JDK8 drop and -infinity to JDK11 drop next year. I'll try to catch up
with the conversation during till next week - the stated position needs
more elaborate explanation, but I don't want to repeat others (too
much). Thanks.
-Svata
On 16. 03. 23 12:23, Neil C Smith wrote:
> Hi Matthias,
>
> On Sun, 12 Feb 2023 at 22:22, Neil C Smith <ne...@apache.org> wrote:
>> On Sun, 12 Feb 2023, 19:11 Matthias Bläsing, <mb...@doppel-helix.eu.invalid> wrote:
>>>
>>> Hi,
>>>
>>> Am Freitag, dem 10.02.2023 um 10:12 +0000 schrieb Neil C Smith:
>>>> On Thu, 9 Feb 2023 at 19:02, Matthias Bläsing <mb...@doppel-helix.eu.invalid> wrote:
>>>>> - commit to make NetBeans runnable on JDK LTS -1
>>>>> - build with JDK LTS -1
>>>>> - be able to be build with the current JDK
>>>>
>>>> +1 as long as that includes the platform.
>>>>
>>>> That is what I suggested in the other thread (I don't see why we need
>>>> multiple threads incidentally!)
>>>>
>>>> An LTS-1 strategy seems closest to how NetBeans used to function -
>>>> major-1, in a time when it also had more development resources?
>>>>
>>>> Let's also be clear, though, that adopting an LTS-1 strategy means
>>>> dropping JDK 11 support either in our first release after JDK 21, or
>>>> the first after JDK 22 - so latest May 2024.
>>>
>>> why would we do that? I said _runnable_ and _buildable_. As long as the
>>> current JDK support the target release I did not exclude that.
>>
>>
>> In which case I don't understand what you mean by committing to make NetBeans buildable and runnable on LTS-1? That to me means dropping the commitment to JDK 11 when it becomes LTS-2.
>
> I'd still really like to see us make some movement here before the
> next release freeze in a month.
>
> I'd still like to understand whether we're saying the same or
> different things about adopting an LTS-1 strategy here?
>
> Thanks,
>
> Neil
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: dev-help@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-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Compatibility with JDK 8: Shift work to people wanting it (was: Re: Lets talk about JDK 8 (new year edition))
Posted by Scott Palmer <sw...@gmail.com>.
Some minimum JDK level needs to be specified. While this is basically
arbitrary based on the needs of the platform and work required to support
it, I think it makes sense that the minimum should be some LTS version. To
get the widest audience would suggest that version should be the oldest LTS
still supported at the time of release. That would mean any release prior
to September 2023 should have JDK 11 as the minimum and not anything more
recent.
If that minimum is considered too old for any reason then the next JDK to
consider should be the next LTS release after JDK 11.
Is there an argument for considering non-LTS releases? I suggest those
primarily because it seems they would be the JDKs most likely to be picked
in general for any arbitrary company, dependency, or whatever. Releases
between LTS releases are likely to be selected only when they contain a
particular needed feature.
I think it should go without saying that whatever JDK is selected as the
minimum, no incubating or preview features should be used. That just opens
another can of worms.
At the same time the expectation of users is that NetBeans will support the
current JDK for development. Ideally coding for EA releases should work on
a best-efforts basis. How are we to evaluate EA releases if our tools
won't support them? While NB must require some minimum version, it is not
unreasonable to require it to run on a more recent version in order to
support more recent JDKs. My point being that I don't see an issue if
running NB on JDK 11 means you can't properly work with a project that
needs JDK 19. If you need to run on JDK 19 to develop for JDK 19, that's
fair.
Personally, I think it is important to make the jump away from JDK 8. It
matters far less how far that jump is. JDK 11 would perhaps be the least
disruptive option in what is certainly going to be a disruptive transition
for some. But the difference from JDK 11 to JDK 17 is insignificant in
comparison to JDK 8 to 11. If you're going to break compatibility, why
drag your feet? Move forward as far as you can and sit there for a while
with a stable target JDK version, rather than tip-toeing one step at a time
trickling a few disruptions in at every release.
My 2c,
Scott
Re: Compatibility with JDK 8: Shift work to people wanting it (was: Re: Lets talk about JDK 8 (new year edition))
Posted by Matthias Bläsing <mb...@doppel-helix.eu.INVALID>.
Hi Neil,
Am Donnerstag, dem 16.03.2023 um 11:23 +0000 schrieb Neil C Smith:
> Hi Matthias,
>
> On Sun, 12 Feb 2023 at 22:22, Neil C Smith <ne...@apache.org> wrote:
> > On Sun, 12 Feb 2023, 19:11 Matthias Bläsing, <mb...@doppel-helix.eu.invalid> wrote:
> > >
> > > Hi,
> > >
> > > Am Freitag, dem 10.02.2023 um 10:12 +0000 schrieb Neil C Smith:
> > > > On Thu, 9 Feb 2023 at 19:02, Matthias Bläsing <mb...@doppel-helix.eu.invalid> wrote:
> > > > > - commit to make NetBeans runnable on JDK LTS -1
> > > > > - build with JDK LTS -1
> > > > > - be able to be build with the current JDK
> > > >
> > > > +1 as long as that includes the platform.
> > > >
> > > > That is what I suggested in the other thread (I don't see why we need
> > > > multiple threads incidentally!)
> > > >
> > > > An LTS-1 strategy seems closest to how NetBeans used to function -
> > > > major-1, in a time when it also had more development resources?
> > > >
> > > > Let's also be clear, though, that adopting an LTS-1 strategy means
> > > > dropping JDK 11 support either in our first release after JDK 21, or
> > > > the first after JDK 22 - so latest May 2024.
> > >
> > > why would we do that? I said _runnable_ and _buildable_. As long as the
> > > current JDK support the target release I did not exclude that.
> >
> >
> > In which case I don't understand what you mean by committing to make NetBeans buildable and runnable on LTS-1? That to me means dropping the commitment to JDK 11 when it becomes LTS-2.
>
> I'd still really like to see us make some movement here before the
> next release freeze in a month.
>
> I'd still like to understand whether we're saying the same or
> different things about adopting an LTS-1 strategy here?
what I think I wanted to say is, that we don't need to raise the
bytecode level for the whole codebase and could keep most modules on
language level 8, but give developers the option to raise it to LTS-1
if necessary. The definition of necessary might be a matter of
dicussion. This would give people who aim for compatibility with JDK 8
for some modules the handle to work with NetBeans and get their wishes.
External dependencies might cause us to be required to raise the Java
level over LTS - 1. Some libraries might evolve faster than we like and
we might not be able to work with the LTS - 1 compatbile version.
This then also means, that the build JDK would be required to be
current or current-1.
I think generally aiming for compatibilty with LTS - 1 would be a good
compromise.
Greetings
Matthias, not sure if this really helped to clear things up
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Compatibility with JDK 8: Shift work to people wanting it (was: Re: Lets talk about JDK 8 (new year edition))
Posted by Neil C Smith <ne...@apache.org>.
Hi Matthias,
On Sun, 12 Feb 2023 at 22:22, Neil C Smith <ne...@apache.org> wrote:
> On Sun, 12 Feb 2023, 19:11 Matthias Bläsing, <mb...@doppel-helix.eu.invalid> wrote:
>>
>> Hi,
>>
>> Am Freitag, dem 10.02.2023 um 10:12 +0000 schrieb Neil C Smith:
>> > On Thu, 9 Feb 2023 at 19:02, Matthias Bläsing <mb...@doppel-helix.eu.invalid> wrote:
>> > > - commit to make NetBeans runnable on JDK LTS -1
>> > > - build with JDK LTS -1
>> > > - be able to be build with the current JDK
>> >
>> > +1 as long as that includes the platform.
>> >
>> > That is what I suggested in the other thread (I don't see why we need
>> > multiple threads incidentally!)
>> >
>> > An LTS-1 strategy seems closest to how NetBeans used to function -
>> > major-1, in a time when it also had more development resources?
>> >
>> > Let's also be clear, though, that adopting an LTS-1 strategy means
>> > dropping JDK 11 support either in our first release after JDK 21, or
>> > the first after JDK 22 - so latest May 2024.
>>
>> why would we do that? I said _runnable_ and _buildable_. As long as the
>> current JDK support the target release I did not exclude that.
>
>
> In which case I don't understand what you mean by committing to make NetBeans buildable and runnable on LTS-1? That to me means dropping the commitment to JDK 11 when it becomes LTS-2.
I'd still really like to see us make some movement here before the
next release freeze in a month.
I'd still like to understand whether we're saying the same or
different things about adopting an LTS-1 strategy here?
Thanks,
Neil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Compatibility with JDK 8: Shift work to people wanting it (was: Re: Lets talk about JDK 8 (new year edition))
Posted by Scott Palmer <sw...@gmail.com>.
While I appreciate Jaroslav's point about libraries being compatible with a
wide variety of Java versions, we do have to balance that with keeping up
with recent developments and the extra effort it entails to avoid using
modern features that are otherwise available.
I personally don't see an issue in dropping Java 8 as a minimum platform
for building or running NetBeans. If you want to run on Java 8, you are
already accustomed to living in the past - you can deal with an older
version of NB or the NB platform that supports Java 8. I say that however,
having no stake in a NB platform app. It isn't going to affect me. My vote
shouldn't count for much.
But NB or the NB platform isn't the only library an application will use,
and many others are already starting to raise the bar as far as the minimum
supported JDK/JRE. You can only go back as far as all of your dependencies
will allow. If there is demand for it, a Java 8 compatible maintenance
branch can be made. One reason for running on JDK 8 mentioned running on
Android. Are there a significant number of NB platform apps that run on
Android now? Do they already build with the latest NB platform, or are
they already using an older version anyway - i.e. being on the lastest NB
platform may not be a big deal for them.
An informed decision needs to be based on these details. Holding back for
JDK 8 compatibility helps no one if there isn't actually any real demand to
do so.
Just my 2c,
Scott
On Sun, Feb 12, 2023 at 5:22 PM Neil C Smith <ne...@apache.org> wrote:
> On Sun, 12 Feb 2023, 19:11 Matthias Bläsing,
> <mb...@doppel-helix.eu.invalid> wrote:
>
> > Hi,
> >
> > Am Freitag, dem 10.02.2023 um 10:12 +0000 schrieb Neil C Smith:
> > > On Thu, 9 Feb 2023 at 19:02, Matthias Bläsing <
> mblaesing@doppel-helix.eu.invalid>
> > wrote:
> > > > - commit to make NetBeans runnable on JDK LTS -1
> > > > - build with JDK LTS -1
> > > > - be able to be build with the current JDK
> > >
> > > +1 as long as that includes the platform.
> > >
> > > That is what I suggested in the other thread (I don't see why we need
> > > multiple threads incidentally!)
> > >
> > > An LTS-1 strategy seems closest to how NetBeans used to function -
> > > major-1, in a time when it also had more development resources?
> > >
> > > Let's also be clear, though, that adopting an LTS-1 strategy means
> > > dropping JDK 11 support either in our first release after JDK 21, or
> > > the first after JDK 22 - so latest May 2024.
> >
> > why would we do that? I said _runnable_ and _buildable_. As long as the
> > current JDK support the target release I did not exclude that.
> >
>
> In which case I don't understand what you mean by committing to make
> NetBeans buildable and runnable on LTS-1? That to me means dropping the
> commitment to JDK 11 when it becomes LTS-2.
>
>
>
> > > > - keep as many modules as feasible compatible with release 8
> > >
> > > -1 : A number of things have come up recently about preparing for JDK
> > > 21+ that would involve increasing the bytecode level and APIs in some
> > > core parts of the NetBeans runtime container.
> >
> > Could you elaborate what that is? Not using Thread#stop and dropping
> > finalizers is it not. That can be done (with some pain) with support
> > for 8. So what is the problem?
> >
>
> Yes, those and I think some others. My paragraph after the one you quoted
> was acknowledging we can do this for 8 with some pain (headache). The
> question is whether it is worth it?
>
> Best wishes,
>
> Neil
>
Re: Compatibility with JDK 8: Shift work to people wanting it (was: Re: Lets talk about JDK 8 (new year edition))
Posted by Ernie Rael <er...@raelity.com>.
As Neil says
> The question is whether it is worth it?
And Scott
> An informed decision needs to be based on these details. Holding back for
> JDK 8 compatibility helps no one if there isn't actually any real demand to
> do so.
AFAICT, there's no stats on JDK version and NBP projects. Maybe the
closest is general
JDK usage, I don't know how well they relate, but it's the best we've got.
Last year, there were reports that JDK-8/JDK-11 were neck and neck at
somewhat under
50 percent, with JDK-11 and JDK-17 picking up steam.
So where's JDK-8 this year? An estimate might be 33%. If one third of
users are on
JDK-8, is that a real demand? Definitely JDK-8 usage is going down, how
steeply?
(Plenty of hand waving, but worth trying to base the discussion on fact.)
One question, what is the point below which there's no real demand and it's
not worth it?
-ernie
On 23/02/12 2:22 PM, Neil C Smith wrote:
> On Sun, 12 Feb 2023, 19:11 Matthias Bläsing,
> <mb...@doppel-helix.eu.invalid> wrote:
>
>> Hi,
>>
>> Am Freitag, dem 10.02.2023 um 10:12 +0000 schrieb Neil C Smith:
>>> On Thu, 9 Feb 2023 at 19:02, Matthias Bläsing <mb...@doppel-helix.eu.invalid>
>> wrote:
>>>> - commit to make NetBeans runnable on JDK LTS -1
>>>> - build with JDK LTS -1
>>>> - be able to be build with the current JDK
>>> +1 as long as that includes the platform.
>>>
>>> That is what I suggested in the other thread (I don't see why we need
>>> multiple threads incidentally!)
>>>
>>> An LTS-1 strategy seems closest to how NetBeans used to function -
>>> major-1, in a time when it also had more development resources?
>>>
>>> Let's also be clear, though, that adopting an LTS-1 strategy means
>>> dropping JDK 11 support either in our first release after JDK 21, or
>>> the first after JDK 22 - so latest May 2024.
>> why would we do that? I said _runnable_ and _buildable_. As long as the
>> current JDK support the target release I did not exclude that.
>>
> In which case I don't understand what you mean by committing to make
> NetBeans buildable and runnable on LTS-1? That to me means dropping the
> commitment to JDK 11 when it becomes LTS-2.
>
>
>
>>>> - keep as many modules as feasible compatible with release 8
>>> -1 : A number of things have come up recently about preparing for JDK
>>> 21+ that would involve increasing the bytecode level and APIs in some
>>> core parts of the NetBeans runtime container.
>> Could you elaborate what that is? Not using Thread#stop and dropping
>> finalizers is it not. That can be done (with some pain) with support
>> for 8. So what is the problem?
>>
> Yes, those and I think some others. My paragraph after the one you quoted
> was acknowledging we can do this for 8 with some pain (headache). The
> question is whether it is worth it?
>
> Best wishes,
>
> Neil
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Compatibility with JDK 8: Shift work to people wanting it (was: Re: Lets talk about JDK 8 (new year edition))
Posted by Neil C Smith <ne...@apache.org>.
On Sun, 12 Feb 2023, 19:11 Matthias Bläsing,
<mb...@doppel-helix.eu.invalid> wrote:
> Hi,
>
> Am Freitag, dem 10.02.2023 um 10:12 +0000 schrieb Neil C Smith:
> > On Thu, 9 Feb 2023 at 19:02, Matthias Bläsing <mb...@doppel-helix.eu.invalid>
> wrote:
> > > - commit to make NetBeans runnable on JDK LTS -1
> > > - build with JDK LTS -1
> > > - be able to be build with the current JDK
> >
> > +1 as long as that includes the platform.
> >
> > That is what I suggested in the other thread (I don't see why we need
> > multiple threads incidentally!)
> >
> > An LTS-1 strategy seems closest to how NetBeans used to function -
> > major-1, in a time when it also had more development resources?
> >
> > Let's also be clear, though, that adopting an LTS-1 strategy means
> > dropping JDK 11 support either in our first release after JDK 21, or
> > the first after JDK 22 - so latest May 2024.
>
> why would we do that? I said _runnable_ and _buildable_. As long as the
> current JDK support the target release I did not exclude that.
>
In which case I don't understand what you mean by committing to make
NetBeans buildable and runnable on LTS-1? That to me means dropping the
commitment to JDK 11 when it becomes LTS-2.
> > > - keep as many modules as feasible compatible with release 8
> >
> > -1 : A number of things have come up recently about preparing for JDK
> > 21+ that would involve increasing the bytecode level and APIs in some
> > core parts of the NetBeans runtime container.
>
> Could you elaborate what that is? Not using Thread#stop and dropping
> finalizers is it not. That can be done (with some pain) with support
> for 8. So what is the problem?
>
Yes, those and I think some others. My paragraph after the one you quoted
was acknowledging we can do this for 8 with some pain (headache). The
question is whether it is worth it?
Best wishes,
Neil
Re: Compatibility with JDK 8: Shift work to people wanting it (was: Re: Lets talk about JDK 8 (new year edition))
Posted by Matthias Bläsing <mb...@doppel-helix.eu.INVALID>.
Hi,
Am Freitag, dem 10.02.2023 um 10:12 +0000 schrieb Neil C Smith:
> On Thu, 9 Feb 2023 at 19:02, Matthias Bläsing <mb...@doppel-helix.eu.invalid> wrote:
> > - commit to make NetBeans runnable on JDK LTS -1
> > - build with JDK LTS -1
> > - be able to be build with the current JDK
>
> +1 as long as that includes the platform.
>
> That is what I suggested in the other thread (I don't see why we need
> multiple threads incidentally!)
>
> An LTS-1 strategy seems closest to how NetBeans used to function -
> major-1, in a time when it also had more development resources?
>
> Let's also be clear, though, that adopting an LTS-1 strategy means
> dropping JDK 11 support either in our first release after JDK 21, or
> the first after JDK 22 - so latest May 2024.
why would we do that? I said _runnable_ and _buildable_. As long as the
current JDK support the target release I did not exclude that.
> > - keep as many modules as feasible compatible with release 8
>
> -1 : A number of things have come up recently about preparing for JDK
> 21+ that would involve increasing the bytecode level and APIs in some
> core parts of the NetBeans runtime container.
Could you elaborate what that is? Not using Thread#stop and dropping
finalizers is it not. That can be done (with some pain) with support
for 8. So what is the problem?
> We could choose to keep release 8 for some modules that make sense as
> libraries outside of the runtime container - utilities, lookup, etc.?
> But surely it makes more sense to explicitly specify those, so that we
> and third-parties have clarity over which things still support JDK 8?
This might be part of a constructive counter proposal of the "JDK 8
will never die" fraction.
Greetings
Matthias
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Compatibility with JDK 8: Shift work to people wanting it (was: Re: Lets talk about JDK 8 (new year edition))
Posted by Neil C Smith <ne...@apache.org>.
On Thu, 9 Feb 2023 at 19:02, Matthias Bläsing
<mb...@doppel-helix.eu.invalid> wrote:
> - commit to make NetBeans runnable on JDK LTS -1
> - build with JDK LTS -1
> - be able to be build with the current JDK
+1 as long as that includes the platform.
That is what I suggested in the other thread (I don't see why we need
multiple threads incidentally!)
An LTS-1 strategy seems closest to how NetBeans used to function -
major-1, in a time when it also had more development resources?
Let's also be clear, though, that adopting an LTS-1 strategy means
dropping JDK 11 support either in our first release after JDK 21, or
the first after JDK 22 - so latest May 2024.
> - keep as many modules as feasible compatible with release 8
-1 : A number of things have come up recently about preparing for JDK
21+ that would involve increasing the bytecode level and APIs in some
core parts of the NetBeans runtime container.
Either we give ourselves more of a headache there to keep JDK 8, or we
do this cleanly, at which point raising the default to release 11
makes more sense?
We could choose to keep release 8 for some modules that make sense as
libraries outside of the runtime container - utilities, lookup, etc.?
But surely it makes more sense to explicitly specify those, so that we
and third-parties have clarity over which things still support JDK 8?
Best wishes,
Neil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Compatibility with JDK 8: Shift work to people wanting it (was: Re: Lets talk about JDK 8 (new year edition))
Posted by Matthias Bläsing <mb...@doppel-helix.eu.INVALID>.
Hi,
from my POV it is a fact, that NetBeans (the IDE) can't be required to
be runnable on JDK 8 and in fact it is not. So my idea:
- commit to make NetBeans runnable on JDK LTS -1
- build with JDK LTS -1
- be able to be build with the current JDK
- allow modules to depend on libraries, that require newer JDKs (see
new JakarataEE developments for example, OpenJFX)
- keep as many modules as feasible compatible with release 8
- if a module needs to break compatibility with java 8 it is the job of
people wanting it to stay compatible to do the necessary work
- the more to the core, the better the arguments for breaking
compatibitly should be
The idea here is, that I see Jaroslavs point that libraries should be
compatible and I'm willing to sacrifice syntactic sugar for
compatibility. What I won't accept is that we are stuck in the past.
OpenJFX has a webbrowser and thus quickly becomes a security component,
we must be able to update this.
This also introduces a baseline java version: The absolute lowest
support java version is the one still supported by the most current
JDK.
Greetings
Matthias
Am Dienstag, dem 10.01.2023 um 15:16 +0100 schrieb Michael Bien:
> Hello devs,
>
> I hope everyone recovered from the last JDK 8 thread and is ready for
> the first JDK 8 thread of 2023 :)
>
> The commit validation job is currently testing on 8, 11, 17 and 20-ea.
> It doesn't like NetBeans editor modules which require java 11 though
> which blocks a Jakarta EE 10 PR atm (#4692).
>
> This means we need either 1) a volunteer who would like to spend time
> and fix JDK 8 tests, 2) we remove JDK 8 from the CV test matrix or 3) we
> won't be able to merge this pr before freeze.
>
> Given that NB doesn't really support running on JDK 11 since a while I
> would simply opt for 2) and merge.
>
> The problem is that I don't know the NB VSCode Extension situation very
> well.
>
> Have the NB VSCode Extension specific tests (which run on JDK 8)
> sufficient coverage so that we can remove JDK 8 from the CV test matrix?
> At what point will JDK 11 modules become a problem for VSCode? When will
> the VSCode NB extension bump the runtime requirement to 11?
>
> The next modules which would require JDK 11 are probably maven related
> (#4999) but this wouldn't be for NB 17.
>
> best regards,
>
> michael
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Lets talk about JDK 8 (new year edition)
Posted by Martin Balin <mb...@apache.org>.
Hi,
Re VSNetBeans. It can be built and used on JDK11 and higher there is no problem with leaving JDK8 for VSIX.
Re tests it is as stated below, many NetBeans tests are still JDK8 and cannot be just turned off.
Martin
> On 11. 1. 2023, at 6:16, Michael Bien <mb...@gmail.com> wrote:
>
> Hi Laszlo,
>
> The platform tests have 90% of the testing done on JDK 8, there are only a few tests which are repeated again on 11 at the end of the jobs. Right now "Platform Modules batch1" is building platform-src.zip in isolation on JDK 11, not on 8, since 11 is currently the build requirement for NetBeans.
>
> Ideally we should be able to simply run the platform tests in a [8, 11] matrix, but we can't, see below.
>
> The other jobs which run on 8 and probably should stay on 8 are VSCode Ext and LSP. But would be good to have clarification on that one - I am sailing blind there.
>
> There are some more jobs additional to those above which still test on 8 since they can't run on 11 but potentially should, which is tracked with #4904.
>
> I have put the JDK version in the job title so its easy to inspect, here is a full run with all jobs enabled on master for a quick overview:
> https://github.com/apache/netbeans/actions/runs/3886947624/usage
>
> best regards,
> michael
>
>
> On 10.01.23 20:28, László Kishalmi wrote:
>> Well, I think we can remove the CV for Java 8.
>> Probably the only Java 8 thing we shall do is make sure that the platform
>> sources can be compiled and tested on Java 8.
>>
>>
>> On Tue, Jan 10, 2023 at 7:28 AM Michael Bien <mb...@gmail.com> wrote:
>>
>>> On 10.01.23 16:25, Ernie Rael wrote:
>>>> On 23/01/10 6:16 AM, Michael Bien wrote:
>>>>>
>>>>> Given that NB doesn't really support running on JDK 11 since a while
>>>>> I would simply opt for 2) and merge.
>>>>>
>>>>>
>>>> Typo? JDK-11 --> JDK-8
>>> yes, thanks for spotting this!
>>>
>>> -mbien
>>>
>>>> -ernie
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
>>>> For additional commands, e-mail: dev-help@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-unsubscribe@netbeans.apache.org
>>> For additional commands, e-mail: dev-help@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-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: dev-help@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-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Lets talk about JDK 8 (new year edition)
Posted by Michael Bien <mb...@gmail.com>.
Hi Laszlo,
The platform tests have 90% of the testing done on JDK 8, there are only
a few tests which are repeated again on 11 at the end of the jobs. Right
now "Platform Modules batch1" is building platform-src.zip in isolation
on JDK 11, not on 8, since 11 is currently the build requirement for
NetBeans.
Ideally we should be able to simply run the platform tests in a [8, 11]
matrix, but we can't, see below.
The other jobs which run on 8 and probably should stay on 8 are VSCode
Ext and LSP. But would be good to have clarification on that one - I am
sailing blind there.
There are some more jobs additional to those above which still test on 8
since they can't run on 11 but potentially should, which is tracked with
#4904.
I have put the JDK version in the job title so its easy to inspect, here
is a full run with all jobs enabled on master for a quick overview:
https://github.com/apache/netbeans/actions/runs/3886947624/usage
best regards,
michael
On 10.01.23 20:28, László Kishalmi wrote:
> Well, I think we can remove the CV for Java 8.
> Probably the only Java 8 thing we shall do is make sure that the platform
> sources can be compiled and tested on Java 8.
>
>
> On Tue, Jan 10, 2023 at 7:28 AM Michael Bien <mb...@gmail.com> wrote:
>
>> On 10.01.23 16:25, Ernie Rael wrote:
>>> On 23/01/10 6:16 AM, Michael Bien wrote:
>>>>
>>>> Given that NB doesn't really support running on JDK 11 since a while
>>>> I would simply opt for 2) and merge.
>>>>
>>>>
>>> Typo? JDK-11 --> JDK-8
>> yes, thanks for spotting this!
>>
>> -mbien
>>
>>> -ernie
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
>>> For additional commands, e-mail: dev-help@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-unsubscribe@netbeans.apache.org
>> For additional commands, e-mail: dev-help@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-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Lets talk about JDK 8 (new year edition)
Posted by Michael Bien <mb...@gmail.com>.
On 11.01.23 12:03, Neil C Smith wrote:
> On Tue, 10 Jan 2023 at 19:28, László Kishalmi <la...@gmail.com> wrote:
>> Well, I think we can remove the CV for Java 8.
>> Probably the only Java 8 thing we shall do is make sure that the platform
>> sources can be compiled and tested on Java 8.
> As and until we replace the (as we both said, conservative!) step
> forward agreed for NB13* then I'd prefer we only temporarily disable
> the CV test for JDK 8 to get this PR merged for freeze.
We could also leave it in the matrix and just skip ValidateModulesTest
on JDK 8.
Or we drop it from the matrix but run CV on JDK 8 in the NB VSCode job
(if at all possible) which isn't using the modules in question anyway
since they require JDK 11.
> If no-one
> else does, I'll try and look at fixing the way the dependencies are
> handled in the linked PR to get the test to pass before we move to
> release.
usually in threads like this someone is always asking if it takes any
extra dev time to maintain JDK 8 compatibility. Lets mark this point for
future reference :)
>
> Yes, the sooner we can update what was agreed for NB13, the better.
yep, the sooner the better, the current situation is not optimal.
-mbien
> But that requires notice (so not NB17, and possibly not NB18), a new
> lazy consensus proposal, and no vetoes!
>
> Best wishes,
>
> Neil
>
> * https://lists.apache.org/thread/rcfv7vgrz6byb2y1pjpv4894xh7p96d2
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: dev-help@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-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
RE: Lets talk about JDK 8 (new year edition)
Posted by Eirik Bakke <eb...@ultorg.com>.
> Platform applications are not limited to using the platform cluster.
> There are multiple platform applications I'm aware of that use modules from other clusters. Including one, possibly soon two, of my own.
Same here--my NetBeans Platform application ( https://www.ultorg.com/ ) uses most, but not all, of the modules in the "platform" cluster, as well as various hand-picked modules from the "ide" cluster (e.g. editor functionality and Database Explorer).
-- Eirik
-----Original Message-----
From: Neil C Smith <ne...@apache.org>
Sent: Wednesday, February 8, 2023 4:07 AM
To: Michael Bien <mb...@gmail.com>
Cc: dev <de...@netbeans.apache.org>
Subject: Re: Lets talk about JDK 8 (new year edition)
On Wed, 8 Feb 2023, 04:52 Michael Bien, <mb...@gmail.com> wrote:
> On 08.02.23 02:54, Neil C Smith wrote:
> > On Tue, 7 Feb 2023 at 21:39, Michael Bien <mb...@gmail.com> wrote:
> >> However, I got the feeling, sooner or later someone will want to
> >> have the platform again at a lower bytecode level than the rest of the IDE.
> >> I hope I am wrong and this never happens again. If this happens we
> >> can deal with this later, this isn't relevant for the immediate JDK
> >> 11 step since it is supposed to finally sync everything.
> > Again? That is not the situation now.
>
> now am confused...
>
> we have tests on 8 and 11. We build on 11 with bytecode level set to 8.
> Some modules set it to 11.
Yes. But there's nothing special about the platform cluster modules. All required modules (or dependencies of) across all clusters are built with max level 8. Optional modules, such as enhancing or overriding services, can specify 11. If running on 8 they should not enable and degrade cleanly.
IDE runtime requirements say JDK 11.
Well it is "officially supported" on JDK 11+. As we know it still technically runs on JDK 8, with a somewhat degraded experience. That was a requirement that led to the current arrangement - it wasn't platform vs rest of IDE.
What I hope from this discussion that there won't be any 8s in that
> paragraph above at some point in future. That is what I mean by "in sync".
>
Yes, me too! I'd like us to remove all 8s from that paragraph by NB19. And only commit to keeping any 11s in there until NB22.
Best wishes,
Neil
Re: Lets talk about JDK 8 (new year edition)
Posted by Neil C Smith <ne...@apache.org>.
On Wed, 8 Feb 2023, 04:52 Michael Bien, <mb...@gmail.com> wrote:
> On 08.02.23 02:54, Neil C Smith wrote:
> > On Tue, 7 Feb 2023 at 21:39, Michael Bien <mb...@gmail.com> wrote:
> >> However, I got the feeling, sooner or later someone will want to have
> >> the platform again at a lower bytecode level than the rest of the IDE.
> >> I hope I am wrong and this never happens again. If this happens we can
> >> deal with this later, this isn't relevant for the immediate JDK 11 step
> >> since it is supposed to finally sync everything.
> > Again? That is not the situation now.
>
> now am confused...
>
> we have tests on 8 and 11. We build on 11 with bytecode level set to 8.
> Some modules set it to 11.
Yes. But there's nothing special about the platform cluster modules. All
required modules (or dependencies of) across all clusters are built with
max level 8. Optional modules, such as enhancing or overriding services,
can specify 11. If running on 8 they should not enable and degrade cleanly.
IDE runtime requirements say JDK 11.
Well it is "officially supported" on JDK 11+. As we know it still
technically runs on JDK 8, with a somewhat degraded experience. That was a
requirement that led to the current arrangement - it wasn't platform vs
rest of IDE.
What I hope from this discussion that there won't be any 8s in that
> paragraph above at some point in future. That is what I mean by "in sync".
>
Yes, me too! I'd like us to remove all 8s from that paragraph by NB19. And
only commit to keeping any 11s in there until NB22.
Best wishes,
Neil
Re: Lets talk about JDK 8 (new year edition)
Posted by Michael Bien <mb...@gmail.com>.
On 08.02.23 02:54, Neil C Smith wrote:
> On Tue, 7 Feb 2023 at 21:39, Michael Bien <mb...@gmail.com> wrote:
>> However, I got the feeling, sooner or later someone will want to have
>> the platform again at a lower bytecode level than the rest of the IDE.
>> I hope I am wrong and this never happens again. If this happens we can
>> deal with this later, this isn't relevant for the immediate JDK 11 step
>> since it is supposed to finally sync everything.
> Again? That is not the situation now.
now am confused...
we have tests on 8 and 11. We build on 11 with bytecode level set to 8.
Some modules set it to 11. IDE runtime requirements say JDK 11. VSCodeEx
dl page says it runs on 8 and later (but this thread showed that 11
wouldn't be a problem - which is excellent).
What I hope from this discussion that there won't be any 8s in that
paragraph above at some point in future. That is what I mean by "in sync".
-mbien
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Lets talk about JDK 8 (new year edition)
Posted by Neil C Smith <ne...@apache.org>.
On Tue, 7 Feb 2023 at 21:39, Michael Bien <mb...@gmail.com> wrote:
> However, I got the feeling, sooner or later someone will want to have
> the platform again at a lower bytecode level than the rest of the IDE.
> I hope I am wrong and this never happens again. If this happens we can
> deal with this later, this isn't relevant for the immediate JDK 11 step
> since it is supposed to finally sync everything.
Again? That is not the situation now.
> platform to me is whatever comes out if you build:
> ant -Dcluster.config=platform
Platform applications are not limited to using the platform cluster.
There are multiple platform applications I'm aware of that use modules
from other clusters. Including one, possibly soon two, of my own.
The distinction of platform vs rest of the IDE doesn't make sense to
me, unless we decide to stop publishing the full range of modules as a
framework for third parties to consume.
> On 07.02.23 12:11, Neil C Smith wrote:
> > https://github.com/apache/netbeans/blob/master/nbbuild/default.xml#L126
>
> almost.
>
> once this is picked up everywhere and not every module sidelines it by
> defining it's own source/target it would be covered by a property like
> that yes.
True, I realise this is a little more complicated. It just makes
sense to me to concentrate module-specific settings for modules that
need to opt out of JDK 11 bytecode level than opt in to it.
> This has to be used for 'release' and not for source/target unless the
> boot cp is set for example. The custom compiler ant task handles some of
> it but not everything uses this task.
Yes. Definitely something that needs looking at.
Best wishes,
Neil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Lets talk about JDK 8 (new year edition)
Posted by Michael Bien <mb...@gmail.com>.
just to clarify:
- I am for moving to 11 asap, and once we are there, to the next LTS as
soon it makes sense (tests have to work etc).
- I am for keeping everything in sync if possible since I am a big fan
of keeping things simple.
However, I got the feeling, sooner or later someone will want to have
the platform again at a lower bytecode level than the rest of the IDE.
I hope I am wrong and this never happens again. If this happens we can
deal with this later, this isn't relevant for the immediate JDK 11 step
since it is supposed to finally sync everything.
platform to me is whatever comes out if you build:
ant -Dcluster.config=platform
On 07.02.23 12:11, Neil C Smith wrote:
> On Tue, 7 Feb 2023 at 00:46, Michael Bien <mb...@gmail.com> wrote:
>> there is no default configuration for source/target yet - that was just
>> an idea.
> I thought that was covered by this?
>
> https://github.com/apache/netbeans/blob/master/nbbuild/default.xml#L126
almost.
once this is picked up everywhere and not every module sidelines it by
defining it's own source/target it would be covered by a property like
that yes.
This has to be used for 'release' and not for source/target unless the
boot cp is set for example. The custom compiler ant task handles some of
it but not everything uses this task.
but NB will be probably there after 1-2 more PRs I hope.
best regards,
michael
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Lets talk about JDK 8 (new year edition)
Posted by Neil C Smith <ne...@apache.org>.
On Tue, 7 Feb 2023 at 00:46, Michael Bien <mb...@gmail.com> wrote:
> there is no default configuration for source/target yet - that was just
> an idea.
I thought that was covered by this?
https://github.com/apache/netbeans/blob/master/nbbuild/default.xml#L126
> again: if we can do everything in one go -> even better
+1 - we're saying the same thing here.
> Platform is a lib, the IDE is a tool/product. The distinction will
> likely always cause some friction in runtime requirements.
And platform is a cluster. Which is where some confusion is coming
from I think?
Additional consumers of our APIs, be it in RCP applications or other
usages of our Maven libraries, are not necessarily limited to just the
platform cluster.
The current policy we have on this didn't special case the platform
cluster as such, just that all modules requiring JDK 11 are optional
(and at the time not required by the VSCode support)
> Not a lot would prevent us to require JDK 21 for the IDE once it is out
> some time in future (assuming tests work). But I imagine there will be
> resistance to do the same for the platform.
That depends what you mean? Does this again mix definitions of
platform between the cluster and APIs consumed by others? We should
have one approach that covers all clusters. Which doesn't mean we
couldn't approach JDK 21 in a soft / optional modules way, like we're
currently doing with JDK 11.
There was a conversation a while back around the VSCode that included
something like NetBeans as a collection of tools built on a common
framework. I wonder whether we need different words here to describe
the collections of APIs (framework?) and the platform cluster?
> opt-ins can be trivially removed with search and replace once the
> default is bumped. This shouldn't be the reason to stop an IDE module
> from requiring JDK 11 for another year.
>
> We would have to do this anyway since there would be already opt-ins to
> remove once we add a default config due to already existing modules
> which require JDK 11.
>
> What is your concern?
Why another year? I'm actually suggesting we at least try to bump
everything to JDK 11 when NB 18 has branched, so in a couple of
months.
If anything I'm suggesting we consider bumping to JDK 17 in a year, or
at least give ourselves that option.
> >> No reason not to try. This is also one of the more time consuming tasks.
> >> Since you have to run a full build and then check via a script that none
> >> of the class files suddenly starts having their version set to 65.
> >>
> > Good job we have a test for that already then!here
>
> it is very rudimentary
>
> https://github.com/apache/netbeans/pull/5122#issuecomment-1359902237
I meant https://github.com/apache/netbeans/blob/master/platform/o.n.core/test/qa-functional/src/org/netbeans/core/validation/ValidateClassFilesTest.java
This runs as part of commit validation IIRC - I had to update it to
get our first JDK 11 compiled module PR (disco) to pass - it was
hardcoded to JDK 8 before then.
Best wishes,
Neil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Lets talk about JDK 8 (new year edition)
Posted by Michael Bien <mb...@gmail.com>.
On 07.02.23 00:43, Neil C Smith wrote:
> On Mon, 6 Feb 2023, 22:22 Michael Bien, <mb...@gmail.com> wrote:
>
>> What is needed is to communicate that it is ok to upgrade everything to
>> JDK11 - which would open the flood gates.
>>
> Maybe. But do we really want a flood of modules with non-default
> configuration?
there is no default configuration for source/target yet - that was just
an idea.
again: if we can do everything in one go -> even better
we can probably set the module manifest to JDK 11 in one go for example
which would be the easy part.
>> The policy was as far as I remember to be ok with new modules starting
>> out on JDK 11, old modules have to be discussed before move - that is
>> too much work since NB has ~450 sub-projects.
>>
>> Changing this will probably require a vote
>
> In my mind it requires a lazy consensus thread, like the previous one. ie.
> A proposal with no vetoes. Vetoes of course being based on technical
> arguments or alternative approaches to address the problem.
>
> I'm happy to write something up if no-one else does first. I restarted this
> discussion to try and work out what that should look like.
>
>
> this should be goal of course. Lets move everything to JDK 11 unless it
>> is used by the platform.
>>
> Why do you think the platform should be special cased?
I don't think it necessarily should. But it currently is.
Platform has to run on JDK 8+. IDE runs on JDK 11+ since NB 12.6.
you just wrote:
"a) support running the platform on JDK 8 until NetBeans 19"
-> special case in build, CI etc until NB 19 is out
after that we should sync everything 11. But there is no technical
reason to wait with IDE modules till that date, if someone wants to move
a module for NB 18 it shouldn't be a big deal.
Not a lot would prevent us to require JDK 21 for the IDE once it is out
some time in future (assuming tests work). But I imagine there will be
resistance to do the same for the platform. So the same situation will
likely repeat again.
Platform is a lib, the IDE is a tool/product. The distinction will
likely always cause some friction in runtime requirements.
>
>
> I don't think a forward looking statement regarding building
>> requirements of the IDE is needed tbh. If its left out we don't have to
>> define exceptions.
>>
> In many respects I agree. The important part of any statement is runtime
> compatibility. However ASF releases sources, so there are some arguments
> for good advance communication of build requirements too?
>
>
>> if it works we can do it all at once. I am just a bit skeptical that it
>> will "just work" given how many edge cases and custom javac calls the
>> build has to deal with.
>>
> True, but that's what I mean by opt-out vs opt-in. Why not keep the custom
> configuration for the edge cases?
opt-ins can be trivially removed with search and replace once the
default is bumped. This shouldn't be the reason to stop an IDE module
from requiring JDK 11 for another year.
We would have to do this anyway since there would be already opt-ins to
remove once we add a default config due to already existing modules
which require JDK 11.
What is your concern?
>> No reason not to try. This is also one of the more time consuming tasks.
>> Since you have to run a full build and then check via a script that none
>> of the class files suddenly starts having their version set to 65.
>>
> Good job we have a test for that already then!
it is very rudimentary
https://github.com/apache/netbeans/pull/5122#issuecomment-1359902237
-mbien
>
> Best wishes,
>
> Neil
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Lets talk about JDK 8 (new year edition)
Posted by Neil C Smith <ne...@apache.org>.
On Mon, 6 Feb 2023, 22:22 Michael Bien, <mb...@gmail.com> wrote:
> What is needed is to communicate that it is ok to upgrade everything to
> JDK11 - which would open the flood gates.
>
Maybe. But do we really want a flood of modules with non-default
configuration?
> The policy was as far as I remember to be ok with new modules starting
> out on JDK 11, old modules have to be discussed before move - that is
> too much work since NB has ~450 sub-projects.
>
> Changing this will probably require a vote
In my mind it requires a lazy consensus thread, like the previous one. ie.
A proposal with no vetoes. Vetoes of course being based on technical
arguments or alternative approaches to address the problem.
I'm happy to write something up if no-one else does first. I restarted this
discussion to try and work out what that should look like.
this should be goal of course. Lets move everything to JDK 11 unless it
> is used by the platform.
>
Why do you think the platform should be special cased?
I don't think a forward looking statement regarding building
> requirements of the IDE is needed tbh. If its left out we don't have to
> define exceptions.
>
In many respects I agree. The important part of any statement is runtime
compatibility. However ASF releases sources, so there are some arguments
for good advance communication of build requirements too?
>
> if it works we can do it all at once. I am just a bit skeptical that it
> will "just work" given how many edge cases and custom javac calls the
> build has to deal with.
>
True, but that's what I mean by opt-out vs opt-in. Why not keep the custom
configuration for the edge cases?
> No reason not to try. This is also one of the more time consuming tasks.
> Since you have to run a full build and then check via a script that none
> of the class files suddenly starts having their version set to 65.
>
Good job we have a test for that already then!
Best wishes,
Neil
Re: Lets talk about JDK 8 (new year edition)
Posted by Michael Bien <mb...@gmail.com>.
On 06.02.23 21:23, Neil C Smith wrote:
> On Sun, 5 Feb 2023 at 19:12, Michael Bien <mb...@gmail.com> wrote:
>> would be great. The JDK 8 -> 11 step is in many ways "special" since so
>> much changed between those two LTS releases.
> Well, yes, otherwise we might have done this some time ago! :-)
>
>> I don't think we have to move everything to JDK 11 at once -
> ...
>> We can move modules to JDK 11 incrementally until nothing is left on JDK
>> 8.
> Isn't that the status quo?
no it isn't. This is met by very high resistance. We have workarounds in
the maven-indexer space exclusively to keep JDK 8 compatibility and keep
using an EOL lucene lib.
Another (smaller) example was a bugfix i recently reviewed which fixed
java version number parsing and basically replicates an API which is
already in JDK 11 - there too we didn't bump the version.
What is needed is to communicate that it is ok to upgrade everything to
JDK11 - which would open the flood gates. Nobody sets release=8 for the
extra challenge :).
The policy was as far as I remember to be ok with new modules starting
out on JDK 11, old modules have to be discussed before move - that is
too much work since NB has ~450 sub-projects.
Changing this will probably require a vote - I don't know. Users already
know that they have to run on JDK 11+ since this is on the download page
since 12.6 I believe - nothing changes there.
> Having a few modules opting in to JDK 11
> seems a bit different to moving towards having everything opt-in and
> losing the benefits of a default configuration. At some point we
> surely need to move the default configuration up to JDK 11?
this should be goal of course. Lets move everything to JDK 11 unless it
is used by the platform.
>
>> We don't have to make this a hard rule. I would move to the next LTS as
>> soon it makes sense and we are actually able to do it. Once this works
>> we can make a rule out of it :)
> Who said "hard rule"? Our release schedule and process (which this
> ties into) was agreed to try and provide consistency and clarity for
> ourselves and users. But it's iterated multiple times since. Part of
> the thoughts on this are because OpenJDK iterated its release and
> support schedule. Having some principle that we can agree and can
> advertise to end users, particularly platform and plugin developers,
> has benefit.
>
> Let me reword the suggestion a little - the only two hard guarantees would be to
> - a) support running the platform on JDK 8 until NetBeans 19
> - b) to commit to supporting building and running on JDK 11 until (at
> least?) NetBeans 22 / May 2024
b) should leave room for exceptions though as long the modules are
optional and give convincing reasons to require JDKs >11. (gave an
example before, e.g: JakartaEE 11 targeting JDK 21)
I don't think a forward looking statement regarding building
requirements of the IDE is needed tbh. If its left out we don't have to
define exceptions.
>
> We don't need to commit to raising the bytecode version straight away,
> true, just it becomes an option at that point - we could also have a
> soft requirement as now.
right
>
>> i was hoping to be able to implement one 'release' property in the build
>> which would define the default bytecode level for everything and remove
>> the source/target properties everywhere. Modules would only define a
>> 'release' version if they want to break that convention.
> Yes, saw that and totally agree. Isn't that an argument for not
> taking the opt-in approach above though?
if it works we can do it all at once. I am just a bit skeptical that it
will "just work" given how many edge cases and custom javac calls the
build has to deal with.
No reason not to try. This is also one of the more time consuming tasks.
Since you have to run a full build and then check via a script that none
of the class files suddenly starts having their version set to 65.
The beauty of custom ant builds (I am kidding).
>
>> We should also consider a dialog for NB 18 which warns users if they try
>> to run NB on JDK 8 - we still don't have that dialog, I somehow keep
>> forgetting about it and only get reminded again while reading the issue
>> tracker during the RC phase.
> You and me both! :-) I'm almost thinking it might not be worth it -
> depends how we approach in future and whether it has re-use.
well. I have a demo somewhere which downloads a runtime JDK into the
netbeans folder if the version isn't right :)
best regards,
michael
>
> Best wishes,
>
> Neil
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: dev-help@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-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Lets talk about JDK 8 (new year edition)
Posted by Neil C Smith <ne...@apache.org>.
On Sun, 5 Feb 2023 at 19:12, Michael Bien <mb...@gmail.com> wrote:
> would be great. The JDK 8 -> 11 step is in many ways "special" since so
> much changed between those two LTS releases.
Well, yes, otherwise we might have done this some time ago! :-)
> I don't think we have to move everything to JDK 11 at once -
...
> We can move modules to JDK 11 incrementally until nothing is left on JDK
> 8.
Isn't that the status quo? Having a few modules opting in to JDK 11
seems a bit different to moving towards having everything opt-in and
losing the benefits of a default configuration. At some point we
surely need to move the default configuration up to JDK 11?
> I thought so far that the NB VSCode extension would still have a hard
> JDK 8 requirement - but I was wrong as this discussion showed, so there
> is nothing stopping us from doing this except the rule we set ourself in
> past.
Yes, so it's hopefully time to consider the next iteration of that rule ...
> We don't have to make this a hard rule. I would move to the next LTS as
> soon it makes sense and we are actually able to do it. Once this works
> we can make a rule out of it :)
Who said "hard rule"? Our release schedule and process (which this
ties into) was agreed to try and provide consistency and clarity for
ourselves and users. But it's iterated multiple times since. Part of
the thoughts on this are because OpenJDK iterated its release and
support schedule. Having some principle that we can agree and can
advertise to end users, particularly platform and plugin developers,
has benefit.
Let me reword the suggestion a little - the only two hard guarantees would be to
- a) support running the platform on JDK 8 until NetBeans 19
- b) to commit to supporting building and running on JDK 11 until (at
least?) NetBeans 22 / May 2024
We don't need to commit to raising the bytecode version straight away,
true, just it becomes an option at that point - we could also have a
soft requirement as now.
> i was hoping to be able to implement one 'release' property in the build
> which would define the default bytecode level for everything and remove
> the source/target properties everywhere. Modules would only define a
> 'release' version if they want to break that convention.
Yes, saw that and totally agree. Isn't that an argument for not
taking the opt-in approach above though?
> We should also consider a dialog for NB 18 which warns users if they try
> to run NB on JDK 8 - we still don't have that dialog, I somehow keep
> forgetting about it and only get reminded again while reading the issue
> tracker during the RC phase.
You and me both! :-) I'm almost thinking it might not be worth it -
depends how we approach in future and whether it has re-use.
Best wishes,
Neil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Lets talk about JDK 8 (new year edition)
Posted by Michael Bien <mb...@gmail.com>.
On 05.02.23 16:52, Neil C Smith wrote:
> On Wed, 11 Jan 2023 at 11:03, Neil C Smith <ne...@apache.org> wrote:
>> Yes, the sooner we can update what was agreed for NB13, the better.
>> But that requires notice (so not NB17, and possibly not NB18), a new
>> lazy consensus proposal, and no vetoes!
> Let's talk some more about JDK 8 ... and JDK 11 for that matter! :-)
>
> While the immediate NB17 issue was resolved, but given comments in
> other threads more recently, it would be good not to let the
> discussion on when and how to drop the rest of our JDK 8 support. In
> particular with JDK 21 (the next LTS) already on the horizon later
> this year.
>
> In the past I believe NetBeans supported current and previous Java
> releases? Now might be the time to consider what our long term plan
> with the new JDK release schedule should be too. Previously we've
> discussed LTS-1, LTS and current as perhaps the limit of our capacity,
> for both maintaining and testing infrastructure?
>
> Firstly, do we look to move to JDK 11 as the baseline release for
> compilation, and running of all modules from NetBeans 19 (Aug 2023)?
> That allows us to advertise the NetBeans 18 platform as the last
> release that will support JDK 8, as well as give us time to look at
> remaining problems with tests?
would be great. The JDK 8 -> 11 step is in many ways "special" since so
much changed between those two LTS releases.
I don't think we have to move everything to JDK 11 at once - so even if
we have the odd test left which requires JDK 8, it shouldn't hold
anything back IMO.
We can move modules to JDK 11 incrementally until nothing is left on JDK
8. NB already requires JDK 11 as runtime, what we should do next is to
communicate that the same rule applies for the platform.
I thought so far that the NB VSCode extension would still have a hard
JDK 8 requirement - but I was wrong as this discussion showed, so there
is nothing stopping us from doing this except the rule we set ourself in
past.
We should also consider a dialog for NB 18 which warns users if they try
to run NB on JDK 8 - we still don't have that dialog, I somehow keep
forgetting about it and only get reminded again while reading the issue
tracker during the RC phase.
>
> Secondly, should we at the same time advertise a plan for future JDK
> support so that IDE and platform users have something concrete to work
> with? This could be based on LTS-1, LTS and current. We could take
> the release of JDK 22, when JDK 21 stops being "current", as the point
> where we drop support for JDK 11. That would have NetBeans 22 (May
> 2024) requiring JDK 17 for build and run.
We don't have to make this a hard rule. I would move to the next LTS as
soon it makes sense and we are actually able to do it. Once this works
we can make a rule out of it :)
>
> We have required JDK 11 for build some time before dropping JDK 8
> support. Do we go back to min JDK for build and run being the same
> again, moving build and run min JDK 17 at the same time, or staggered?
i believe we should keep build and runtime requirements close to each
other when possible to simplify the whole process.
However, depending on how quick we update that minimum JDK requirement
in future, it might diverge again in rare situations.
example:
- Spring requires JDK 17 already
- Jakarta EE 11 will target JDK 21 (whatever "target" means, might be
vendor dependent, nobody could explain this to me so far)
So we might end up having modules wich require a more recent version
again. I would be always in favor to bump everything to the next LTS but
if we can't for whatever reason, this should not stop individual modules
from doing that IMO.
i was hoping to be able to implement one 'release' property in the build
which would define the default bytecode level for everything and remove
the source/target properties everywhere. Modules would only define a
'release' version if they want to break that convention.
we had some discussions about this here:
https://github.com/apache/netbeans/pull/5122
best regards,
michael
>
> Thoughts? Concerns? Alternatives?
>
> Best wishes,
>
> Neil
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: dev-help@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-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Lets talk about JDK 8 (new year edition)
Posted by Laszlo Kishalmi <la...@gmail.com>.
I have data on the Snap releases.
I know it is highly non representative and due to the auto update nature
of Snaps it is really in favor of latest stable so:
Rounding on hundreds: out of 33600 installs 32800 is using NetBeans 16,
200 NetBeans 15, 200 NetBeans 17-rc2, 200 NetBeans 12.0 and the rest are
just fragments.
On 2/6/23 17:57, Ernie Rael wrote:
> On 23/02/05 7:52 AM, Neil C Smith wrote:
>> On Wed, 11 Jan 2023 at 11:03, Neil C Smith <ne...@apache.org>
>> wrote:
>>> Yes, the sooner we can update what was agreed for NB13, the better.
>>> But that requires notice (so not NB17, and possibly not NB18), a new
>>> lazy consensus proposal, and no vetoes!
>> Let's talk some more about JDK 8 ... and JDK 11 for that matter! :-)
>
> Maybe somewhat off topic, but
>
> Is there any data on the distribution of NetBeans versions in use?
> In particular I'm wondering about how to set minimum supported
> NetBeans version for plugin
>
> -ernie
>
>>
>> While the immediate NB17 issue was resolved, but given comments in
>> other threads more recently, it would be good not to let the
>> discussion on when and how to drop the rest of our JDK 8 support. In
>> particular with JDK 21 (the next LTS) already on the horizon later
>> this year.
>>
>> In the past I believe NetBeans supported current and previous Java
>> releases? Now might be the time to consider what our long term plan
>> with the new JDK release schedule should be too. Previously we've
>> discussed LTS-1, LTS and current as perhaps the limit of our capacity,
>> for both maintaining and testing infrastructure?
>>
>> Firstly, do we look to move to JDK 11 as the baseline release for
>> compilation, and running of all modules from NetBeans 19 (Aug 2023)?
>> That allows us to advertise the NetBeans 18 platform as the last
>> release that will support JDK 8, as well as give us time to look at
>> remaining problems with tests?
>>
>> Secondly, should we at the same time advertise a plan for future JDK
>> support so that IDE and platform users have something concrete to work
>> with? This could be based on LTS-1, LTS and current. We could take
>> the release of JDK 22, when JDK 21 stops being "current", as the point
>> where we drop support for JDK 11. That would have NetBeans 22 (May
>> 2024) requiring JDK 17 for build and run.
>>
>> We have required JDK 11 for build some time before dropping JDK 8
>> support. Do we go back to min JDK for build and run being the same
>> again, moving build and run min JDK 17 at the same time, or staggered?
>>
>> Thoughts? Concerns? Alternatives?
>>
>> Best wishes,
>>
>> Neil
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
>> For additional commands, e-mail: dev-help@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-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: dev-help@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-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Lets talk about JDK 8 (new year edition)
Posted by Michael Bien <mb...@gmail.com>.
On 07.02.23 02:57, Ernie Rael wrote:
> On 23/02/05 7:52 AM, Neil C Smith wrote:
>> On Wed, 11 Jan 2023 at 11:03, Neil C Smith <ne...@apache.org>
>> wrote:
>>> Yes, the sooner we can update what was agreed for NB13, the better.
>>> But that requires notice (so not NB17, and possibly not NB18), a new
>>> lazy consensus proposal, and no vetoes!
>> Let's talk some more about JDK 8 ... and JDK 11 for that matter! :-)
>
> Maybe somewhat off topic, but
>
> Is there any data on the distribution of NetBeans versions in use?
NetBeans itself is collecting no data. Not sure if there are any metrics
from the plugin portal catalog queries.
> In particular I'm wondering about how to set minimum supported
> NetBeans version for plugin
I would simply pick a recent version and not worry about it. Maybe your
plugin encourages someone to upgrade NetBeans to a supported version :)
-mbien
>
> -ernie
>
>>
>> While the immediate NB17 issue was resolved, but given comments in
>> other threads more recently, it would be good not to let the
>> discussion on when and how to drop the rest of our JDK 8 support. In
>> particular with JDK 21 (the next LTS) already on the horizon later
>> this year.
>>
>> In the past I believe NetBeans supported current and previous Java
>> releases? Now might be the time to consider what our long term plan
>> with the new JDK release schedule should be too. Previously we've
>> discussed LTS-1, LTS and current as perhaps the limit of our capacity,
>> for both maintaining and testing infrastructure?
>>
>> Firstly, do we look to move to JDK 11 as the baseline release for
>> compilation, and running of all modules from NetBeans 19 (Aug 2023)?
>> That allows us to advertise the NetBeans 18 platform as the last
>> release that will support JDK 8, as well as give us time to look at
>> remaining problems with tests?
>>
>> Secondly, should we at the same time advertise a plan for future JDK
>> support so that IDE and platform users have something concrete to work
>> with? This could be based on LTS-1, LTS and current. We could take
>> the release of JDK 22, when JDK 21 stops being "current", as the point
>> where we drop support for JDK 11. That would have NetBeans 22 (May
>> 2024) requiring JDK 17 for build and run.
>>
>> We have required JDK 11 for build some time before dropping JDK 8
>> support. Do we go back to min JDK for build and run being the same
>> again, moving build and run min JDK 17 at the same time, or staggered?
>>
>> Thoughts? Concerns? Alternatives?
>>
>> Best wishes,
>>
>> Neil
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
>> For additional commands, e-mail: dev-help@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-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: dev-help@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-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Lets talk about JDK 8 (new year edition)
Posted by Ernie Rael <er...@raelity.com>.
On 23/02/05 7:52 AM, Neil C Smith wrote:
> On Wed, 11 Jan 2023 at 11:03, Neil C Smith <ne...@apache.org> wrote:
>> Yes, the sooner we can update what was agreed for NB13, the better.
>> But that requires notice (so not NB17, and possibly not NB18), a new
>> lazy consensus proposal, and no vetoes!
> Let's talk some more about JDK 8 ... and JDK 11 for that matter! :-)
Maybe somewhat off topic, but
Is there any data on the distribution of NetBeans versions in use?
In particular I'm wondering about how to set minimum supported
NetBeans version for plugin
-ernie
>
> While the immediate NB17 issue was resolved, but given comments in
> other threads more recently, it would be good not to let the
> discussion on when and how to drop the rest of our JDK 8 support. In
> particular with JDK 21 (the next LTS) already on the horizon later
> this year.
>
> In the past I believe NetBeans supported current and previous Java
> releases? Now might be the time to consider what our long term plan
> with the new JDK release schedule should be too. Previously we've
> discussed LTS-1, LTS and current as perhaps the limit of our capacity,
> for both maintaining and testing infrastructure?
>
> Firstly, do we look to move to JDK 11 as the baseline release for
> compilation, and running of all modules from NetBeans 19 (Aug 2023)?
> That allows us to advertise the NetBeans 18 platform as the last
> release that will support JDK 8, as well as give us time to look at
> remaining problems with tests?
>
> Secondly, should we at the same time advertise a plan for future JDK
> support so that IDE and platform users have something concrete to work
> with? This could be based on LTS-1, LTS and current. We could take
> the release of JDK 22, when JDK 21 stops being "current", as the point
> where we drop support for JDK 11. That would have NetBeans 22 (May
> 2024) requiring JDK 17 for build and run.
>
> We have required JDK 11 for build some time before dropping JDK 8
> support. Do we go back to min JDK for build and run being the same
> again, moving build and run min JDK 17 at the same time, or staggered?
>
> Thoughts? Concerns? Alternatives?
>
> Best wishes,
>
> Neil
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: dev-help@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-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Lets talk about JDK 8 (new year edition)
Posted by Michael Bien <mb...@gmail.com>.
On 14.02.23 05:11, Ernie Rael wrote:
> On 23/02/05 11:31 AM, Michael Bien wrote:
>>
>> NB 16/17 ships nb-javac which is based on JDK 19. Which means the
>> minimum bytecode level is 7 already. Once nb-javac updates to 20 that
>> number would be 8. (JDK 14 dropped support for 6, 20 dropped support
>> for 7,
>
> The link Neil gave
>
> https://www.oracle.com/java/technologies/java-se-support-roadmap.html
>
> may provide some insight into when JDK drops support (or it could be
> coincidence) for a bytecode level.
right. That is the reason I said I believed it to be highly unlikely
that javac would drop support for 8 before the LTS for 8 ends - so we
luckily don't have to worry about this aspect when updating nb-javac to
the current version which NB has to do periodically to support current
Java in the editor.
(which means nobody has to fear NB would have to drop support for Java 8
in-the-editor any time soon)
>
> That page indicates Extended Support for JDK-7 ended in 2022 and the
> first release of 2023, JDK-20, dropped support for JDK-7.
>
> Once thing curious is that Extended Support for JDK-8 ends in 2030,
> which is/after/ Extended Support ends for both JDK-11 and JDK-17.
yes this is intended. I don't think anyone will try the JDK 8 experiment
again. Java releases are more frequent, smaller and overlapping LTS
releases happen more often which makes migration much easier within a
project's lifetime.
JDK maintainers looked at python 3 and then looked back at JDK 8 and
probably thought: we nearly got hit by the same issue, we are just super
lucky that everyone valued compatibility so high.
There were some good blog posts about this from back when the new
release model got introduced, but I somehow can't find them right now -
search engines are either getting worse or I just get worse at using them.
It is also worth watching one of Mark Reinhold's older presentations
about the 11+ release model for more context (most will probably already
have seen it since he went on conference-world-tour with that :)).
-mbien
>
> -ernie
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Lets talk about JDK 8 (new year edition)
Posted by Ernie Rael <er...@raelity.com>.
On 23/02/05 11:31 AM, Michael Bien wrote:
>
> NB 16/17 ships nb-javac which is based on JDK 19. Which means the
> minimum bytecode level is 7 already. Once nb-javac updates to 20 that
> number would be 8. (JDK 14 dropped support for 6, 20 dropped support
> for 7,
The link Neil gave
https://www.oracle.com/java/technologies/java-se-support-roadmap.html
may provide some insight into when JDK drops support (or it could be coincidence) for a bytecode level.
That page indicates Extended Support for JDK-7 ended in 2022 and the first release of 2023, JDK-20, dropped support for JDK-7.
Once thing curious is that Extended Support for JDK-8 ends in 2030, which is/after/ Extended Support ends for both JDK-11 and JDK-17.
-ernie
> it is highly unlikely that the compiler will drop support for LTS
> releases like 8)
Re: Lets talk about JDK 8 (new year edition)
Posted by Michael Bien <mb...@gmail.com>.
On 05.02.23 20:31, Michael Bien wrote:
> On 05.02.23 18:28, Laszlo Kishalmi wrote:
>> Dear Neil,
>>
>> I've read this at least 4 times, now I hope I understand the most of
>> it. I'm one of the weaker minds...
>>
>> We are/can talking about different topics when we mention JDK Support.
>>
>> 1. Java IDE Source Editing Support, I know this is not what we are
>> talking about here, but when people reads on NetBeans JDK Support
>> this is what pops in their mind first. So any announcements we put
>> out should mention, that this won't change. (AFAIK, we are good from
>> Java 5 - Java 19/20?)
>
> NB 16/17 ships nb-javac which is based on JDK 19. Which means the
> minimum bytecode level is 7 already. Once nb-javac updates to 20 that
> number would be 8. (JDK 14 dropped support for 6, 20 dropped support
> for 7, it is highly unlikely that the compiler will drop support for
> LTS releases like 8)
>
> I never actually tested this before with Apache NetBeans (and it isn't
> tested in CI as far as I see). So if NB is still able to edit Java 5
> projects it is likely because it is running in some fallback mode or
> something similar and it pretends it's Java 8 which would probably
> work most of the time unless compile on safe is enabled which will
> break the build most likely.
>
> my opinion on this: as long NB supports editing the whole range of LTS
> versions (+ "current") it is all good. For retro programming it is
> probably better to use an older IDE anyway (I still keep a NB 6 around
> for situations like that).
>
> -mbien
>
i just quickly checked the jdk disco api via
https://foojay.io/download/
and 7 is the oldest version any registered vendor is still supporting.
So I don't even know where to get JDK 5 from except from old java one
CDs in my basement ;)
-mbien
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Lets talk about JDK 8 (new year edition)
Posted by Michael Bien <mb...@gmail.com>.
On 05.02.23 18:28, Laszlo Kishalmi wrote:
> Dear Neil,
>
> I've read this at least 4 times, now I hope I understand the most of
> it. I'm one of the weaker minds...
>
> We are/can talking about different topics when we mention JDK Support.
>
> 1. Java IDE Source Editing Support, I know this is not what we are
> talking about here, but when people reads on NetBeans JDK Support this
> is what pops in their mind first. So any announcements we put out
> should mention, that this won't change. (AFAIK, we are good from Java
> 5 - Java 19/20?)
NB 16/17 ships nb-javac which is based on JDK 19. Which means the
minimum bytecode level is 7 already. Once nb-javac updates to 20 that
number would be 8. (JDK 14 dropped support for 6, 20 dropped support for
7, it is highly unlikely that the compiler will drop support for LTS
releases like 8)
I never actually tested this before with Apache NetBeans (and it isn't
tested in CI as far as I see). So if NB is still able to edit Java 5
projects it is likely because it is running in some fallback mode or
something similar and it pretends it's Java 8 which would probably work
most of the time unless compile on safe is enabled which will break the
build most likely.
my opinion on this: as long NB supports editing the whole range of LTS
versions (+ "current") it is all good. For retro programming it is
probably better to use an older IDE anyway (I still keep a NB 6 around
for situations like that).
-mbien
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Lets talk about JDK 8 (new year edition)
Posted by Laszlo Kishalmi <la...@gmail.com>.
On 2/5/23 10:56, Neil C Smith wrote:
> On Sun, 5 Feb 2023 at 17:28, Laszlo Kishalmi <la...@gmail.com> wrote:
>> I've read this at least 4 times, now I hope I understand the most of it.
>> I'm one of the weaker minds...
> Or I'm one of the too verbose ones! :-)
>
> Thanks for your comments - some responses inline, mainly clarifications.
>
>> We are/can talking about different topics when we mention JDK Support.
>>
>> 1. Java IDE Source Editing Support, I know this is not what we are
>> talking about here, but when people reads on NetBeans JDK Support this
>> is what pops in their mind first. So any announcements we put out
>> should mention, that this won't change. (AFAIK, we are good from Java 5
>> - Java 19/20?)
> Agreed! We have that problem with reported issues now though. At
> least when the IDE *refuses* to run on JDK 8 this might get easier to
> explain.
>
> But, definitely good communication needed here that project JDK
> support is not directly affected by this proposal. *However*, we may
> need to consider the lowest JDK supported by nb-javac too.
>
>> 2. NetBeans Platform Source and Runtime JDK compatibility. If I remember
>> well we kept that on Java 8
> ...
>> 2. NetBeans Platform Source and Runtime JDK, is planned to be increased
>> to Java 11 with NetBeans 19, that would be fine, and it would be good to
>> announce that with NetBeans 17 and 18, 19 releases.
> Yes, we kept the ability to run the platform, and most of the IDE, on
> JDK 8. Most modules are compiled against --release 8
>
> My thought is to bump up the default value of
> OpenIDE-Module-Java-Dependencies to JDK 11 from NetBeans 19, and
> compile by default against --release 11.
>
>> 3. NetBeans IDE Source and Runtime JDK. This is a more open ended here.
>> I think most of us won't have the problem raising the source/runtime
>> level mandatory all across the modules to Java 11. Though LTS-1 could be
>> a question as with Java 21 LTS (is that confirmed?), by NetBeans 19,
>> Java 11 would be LTS-2. Should that mean, that NetBeans 19 would be
>> compiled with Java 17, with mandatory source level of Java 11 and IDE
>> modules can opt-in Java 17? Or should that be NetBeans 20?
> JDK 21 is LTS according to eg.
> https://www.oracle.com/java/technologies/java-se-support-roadmap.html
> with new two year cadence.
>
> Our first release after JDK 21 will be NetBeans 20.
>
> I realise saying LTS-1, LTS and current might be confusing terminology
> there? Maybe current JDK plus last two LTS JDK? I'm suggesting we
> limit ourselves to only ever supporting 3 JDKs at a time.
>
> So -
>
> NetBeans 20 and 21 - JDK 11, JDK 17 and JDK 21.
> NetBeans 22 - JDK 17, JDK 21 and JDK 22.
>
> That makes NetBeans 22 where we would next bump the base JDK for build
> and runtime for all modules - default OpenIDE-Module-Java-Dependencies
> is JDK 17, --release 17.
>
> We could require compiling on JDK 17 before then, to allow opt-in
> modules, but do we need the extra complexity? Is there a known
> requirement or is it hypothetical?
I do not think that there would be a requirement for using Java 17, at
least not a hard one.
Though after Java 8, Java 11 is just came out of the woods, many
language goodies are in Java 17.
What I'm thinking of is many swing stuff got a few constructors
protected, that could affect us (I hope not). Though that would happen
when we switch to --release 17.
> Best wishes,
>
> Neil
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: dev-help@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-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Lets talk about JDK 8 (new year edition)
Posted by Neil C Smith <ne...@apache.org>.
On Sun, 5 Feb 2023 at 17:28, Laszlo Kishalmi <la...@gmail.com> wrote:
> I've read this at least 4 times, now I hope I understand the most of it.
> I'm one of the weaker minds...
Or I'm one of the too verbose ones! :-)
Thanks for your comments - some responses inline, mainly clarifications.
> We are/can talking about different topics when we mention JDK Support.
>
> 1. Java IDE Source Editing Support, I know this is not what we are
> talking about here, but when people reads on NetBeans JDK Support this
> is what pops in their mind first. So any announcements we put out
> should mention, that this won't change. (AFAIK, we are good from Java 5
> - Java 19/20?)
Agreed! We have that problem with reported issues now though. At
least when the IDE *refuses* to run on JDK 8 this might get easier to
explain.
But, definitely good communication needed here that project JDK
support is not directly affected by this proposal. *However*, we may
need to consider the lowest JDK supported by nb-javac too.
> 2. NetBeans Platform Source and Runtime JDK compatibility. If I remember
> well we kept that on Java 8
...
> 2. NetBeans Platform Source and Runtime JDK, is planned to be increased
> to Java 11 with NetBeans 19, that would be fine, and it would be good to
> announce that with NetBeans 17 and 18, 19 releases.
Yes, we kept the ability to run the platform, and most of the IDE, on
JDK 8. Most modules are compiled against --release 8
My thought is to bump up the default value of
OpenIDE-Module-Java-Dependencies to JDK 11 from NetBeans 19, and
compile by default against --release 11.
> 3. NetBeans IDE Source and Runtime JDK. This is a more open ended here.
> I think most of us won't have the problem raising the source/runtime
> level mandatory all across the modules to Java 11. Though LTS-1 could be
> a question as with Java 21 LTS (is that confirmed?), by NetBeans 19,
> Java 11 would be LTS-2. Should that mean, that NetBeans 19 would be
> compiled with Java 17, with mandatory source level of Java 11 and IDE
> modules can opt-in Java 17? Or should that be NetBeans 20?
JDK 21 is LTS according to eg.
https://www.oracle.com/java/technologies/java-se-support-roadmap.html
with new two year cadence.
Our first release after JDK 21 will be NetBeans 20.
I realise saying LTS-1, LTS and current might be confusing terminology
there? Maybe current JDK plus last two LTS JDK? I'm suggesting we
limit ourselves to only ever supporting 3 JDKs at a time.
So -
NetBeans 20 and 21 - JDK 11, JDK 17 and JDK 21.
NetBeans 22 - JDK 17, JDK 21 and JDK 22.
That makes NetBeans 22 where we would next bump the base JDK for build
and runtime for all modules - default OpenIDE-Module-Java-Dependencies
is JDK 17, --release 17.
We could require compiling on JDK 17 before then, to allow opt-in
modules, but do we need the extra complexity? Is there a known
requirement or is it hypothetical?
Best wishes,
Neil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Lets talk about JDK 8 (new year edition)
Posted by Laszlo Kishalmi <la...@gmail.com>.
Dear Neil,
I've read this at least 4 times, now I hope I understand the most of it.
I'm one of the weaker minds...
We are/can talking about different topics when we mention JDK Support.
1. Java IDE Source Editing Support, I know this is not what we are
talking about here, but when people reads on NetBeans JDK Support this
is what pops in their mind first. So any announcements we put out
should mention, that this won't change. (AFAIK, we are good from Java 5
- Java 19/20?)
2. NetBeans Platform Source and Runtime JDK compatibility. If I remember
well we kept that on Java 8
3. NetBeans IDE Source and Runtime JDK compatibility. Again if I
remember well, from NetBeans 13, when we lifted the official supported
minimal runtime JDK version to JDK 11. We just allowed IDE modules to
opt-in JDK 11, upon their wish, requiring that through the module manifest.
So we need to plan from here.
1. Are we planning to drop some pre-Java 8 support from our Java Support
modules? I do not thinks so, though someone would see the need... (We
have a bunch native code for Java 5 profiling, though...)
2. NetBeans Platform Source and Runtime JDK, is planned to be increased
to Java 11 with NetBeans 19, that would be fine, and it would be good to
announce that with NetBeans 17 and 18, 19 releases.
3. NetBeans IDE Source and Runtime JDK. This is a more open ended here.
I think most of us won't have the problem raising the source/runtime
level mandatory all across the modules to Java 11. Though LTS-1 could be
a question as with Java 21 LTS (is that confirmed?), by NetBeans 19,
Java 11 would be LTS-2. Should that mean, that NetBeans 19 would be
compiled with Java 17, with mandatory source level of Java 11 and IDE
modules can opt-in Java 17? Or should that be NetBeans 20?
I'd say let's figure these out for this year, in these three planes
(Java Support, Platform, IDE), then we could extrapolate that to LTS-n
style for the future.
On 2/5/23 07:52, Neil C Smith wrote:
> On Wed, 11 Jan 2023 at 11:03, Neil C Smith <ne...@apache.org> wrote:
>> Yes, the sooner we can update what was agreed for NB13, the better.
>> But that requires notice (so not NB17, and possibly not NB18), a new
>> lazy consensus proposal, and no vetoes!
> Let's talk some more about JDK 8 ... and JDK 11 for that matter! :-)
>
> While the immediate NB17 issue was resolved, but given comments in
> other threads more recently, it would be good not to let the
> discussion on when and how to drop the rest of our JDK 8 support. In
> particular with JDK 21 (the next LTS) already on the horizon later
> this year.
>
> In the past I believe NetBeans supported current and previous Java
> releases? Now might be the time to consider what our long term plan
> with the new JDK release schedule should be too. Previously we've
> discussed LTS-1, LTS and current as perhaps the limit of our capacity,
> for both maintaining and testing infrastructure?
>
> Firstly, do we look to move to JDK 11 as the baseline release for
> compilation, and running of all modules from NetBeans 19 (Aug 2023)?
> That allows us to advertise the NetBeans 18 platform as the last
> release that will support JDK 8, as well as give us time to look at
> remaining problems with tests?
>
> Secondly, should we at the same time advertise a plan for future JDK
> support so that IDE and platform users have something concrete to work
> with? This could be based on LTS-1, LTS and current. We could take
> the release of JDK 22, when JDK 21 stops being "current", as the point
> where we drop support for JDK 11. That would have NetBeans 22 (May
> 2024) requiring JDK 17 for build and run.
>
> We have required JDK 11 for build some time before dropping JDK 8
> support. Do we go back to min JDK for build and run being the same
> again, moving build and run min JDK 17 at the same time, or staggered?
>
> Thoughts? Concerns? Alternatives?
>
> Best wishes,
>
> Neil
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: dev-help@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-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Lets talk about JDK 8 (new year edition)
Posted by Neil C Smith <ne...@apache.org>.
On Wed, 11 Jan 2023 at 11:03, Neil C Smith <ne...@apache.org> wrote:
> Yes, the sooner we can update what was agreed for NB13, the better.
> But that requires notice (so not NB17, and possibly not NB18), a new
> lazy consensus proposal, and no vetoes!
Let's talk some more about JDK 8 ... and JDK 11 for that matter! :-)
While the immediate NB17 issue was resolved, but given comments in
other threads more recently, it would be good not to let the
discussion on when and how to drop the rest of our JDK 8 support. In
particular with JDK 21 (the next LTS) already on the horizon later
this year.
In the past I believe NetBeans supported current and previous Java
releases? Now might be the time to consider what our long term plan
with the new JDK release schedule should be too. Previously we've
discussed LTS-1, LTS and current as perhaps the limit of our capacity,
for both maintaining and testing infrastructure?
Firstly, do we look to move to JDK 11 as the baseline release for
compilation, and running of all modules from NetBeans 19 (Aug 2023)?
That allows us to advertise the NetBeans 18 platform as the last
release that will support JDK 8, as well as give us time to look at
remaining problems with tests?
Secondly, should we at the same time advertise a plan for future JDK
support so that IDE and platform users have something concrete to work
with? This could be based on LTS-1, LTS and current. We could take
the release of JDK 22, when JDK 21 stops being "current", as the point
where we drop support for JDK 11. That would have NetBeans 22 (May
2024) requiring JDK 17 for build and run.
We have required JDK 11 for build some time before dropping JDK 8
support. Do we go back to min JDK for build and run being the same
again, moving build and run min JDK 17 at the same time, or staggered?
Thoughts? Concerns? Alternatives?
Best wishes,
Neil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Lets talk about JDK 8 (new year edition)
Posted by Neil C Smith <ne...@apache.org>.
On Tue, 10 Jan 2023 at 19:28, László Kishalmi <la...@gmail.com> wrote:
> Well, I think we can remove the CV for Java 8.
> Probably the only Java 8 thing we shall do is make sure that the platform
> sources can be compiled and tested on Java 8.
As and until we replace the (as we both said, conservative!) step
forward agreed for NB13* then I'd prefer we only temporarily disable
the CV test for JDK 8 to get this PR merged for freeze. If no-one
else does, I'll try and look at fixing the way the dependencies are
handled in the linked PR to get the test to pass before we move to
release.
Yes, the sooner we can update what was agreed for NB13, the better.
But that requires notice (so not NB17, and possibly not NB18), a new
lazy consensus proposal, and no vetoes!
Best wishes,
Neil
* https://lists.apache.org/thread/rcfv7vgrz6byb2y1pjpv4894xh7p96d2
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Lets talk about JDK 8 (new year edition)
Posted by László Kishalmi <la...@gmail.com>.
Well, I think we can remove the CV for Java 8.
Probably the only Java 8 thing we shall do is make sure that the platform
sources can be compiled and tested on Java 8.
On Tue, Jan 10, 2023 at 7:28 AM Michael Bien <mb...@gmail.com> wrote:
> On 10.01.23 16:25, Ernie Rael wrote:
> > On 23/01/10 6:16 AM, Michael Bien wrote:
> >>
> >>
> >> Given that NB doesn't really support running on JDK 11 since a while
> >> I would simply opt for 2) and merge.
> >>
> >>
> > Typo? JDK-11 --> JDK-8
>
> yes, thanks for spotting this!
>
> -mbien
>
> >
> > -ernie
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
> > For additional commands, e-mail: dev-help@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-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: dev-help@netbeans.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
>
Re: Lets talk about JDK 8 (new year edition)
Posted by Michael Bien <mb...@gmail.com>.
On 10.01.23 16:25, Ernie Rael wrote:
> On 23/01/10 6:16 AM, Michael Bien wrote:
>>
>>
>> Given that NB doesn't really support running on JDK 11 since a while
>> I would simply opt for 2) and merge.
>>
>>
> Typo? JDK-11 --> JDK-8
yes, thanks for spotting this!
-mbien
>
> -ernie
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: dev-help@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-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Lets talk about JDK 8 (new year edition)
Posted by Ernie Rael <er...@raelity.com>.
On 23/01/10 6:16 AM, Michael Bien wrote:
>
>
> Given that NB doesn't really support running on JDK 11 since a while I
> would simply opt for 2) and merge.
>
>
Typo? JDK-11 --> JDK-8
-ernie
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: NetBeans is a framework was: Lets talk about JDK 8 (new year edition)
Posted by Jaroslav Tulach <ja...@gmail.com>.
Late reply, sorry Antonio. I've just found your message.
Dne úterý 14. února 2023 20:52:28 CEST, Antonio napsal(a):
> Hi all,
>
> I'm afraid I don't have time to read the whole thread. That's a pity,
> because it looks fun!
>
> So I'll ask just a single queston to try to understand the situation.
>
> On 9/2/23 5:38, Jaroslav Tulach wrote:
> > I was my NetBeans libraries to be as portable as possible and also run on
> > Android. I want to use `Lookup` & co.
> > -jt
>
> I understand that you want to run Lookup & Co in Android, but I imagine
> you don't want to run the Enterprise cluster in Android, right? Either
> that or you sport a huge Android tablet/phone!
Right, I don't care about the "clearly IDE" clusters like `enterprise`.On the
other hand I do care about VSCode integration and I do care about Jackpot. I
want Jackpot to continue to run on JDK8 for many years to come.
> Question is: since NetBeans is modular and we now have a powerful Github
> action powered build system that compiles in thousands of different Java
> versions (and more to come by next year)...
>
> ...Wouldn't it be possible to try to keep Lookup & Co (i.e. the platform
> cluster and probably a few others) binary compatible with JDK8 (with a
> specific Github action or something), and let the rest of clusters
> evolve with the times?
Yes, that sounds like a plan. However there is no need to draw the JDK8 vs.
JDK11+ line along the clusters - we can use JDK11+ API in platform thanks to
the modular NetBeans runtime system. I wrote a blog post about it:
http://wiki.apidesign.org/wiki/AlternativeImplementation
E.g. I am for focusing on modern JDKs, but the (platform/core) code has to be
compiled to run on JDK8 and appropriate unit tests must pass on JDK8.
-jt
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: NetBeans is a framework was: Lets talk about JDK 8 (new year edition)
Posted by Antonio <an...@vieiro.net.INVALID>.
Hi all,
I'm afraid I don't have time to read the whole thread. That's a pity,
because it looks fun!
So I'll ask just a single queston to try to understand the situation.
On 9/2/23 5:38, Jaroslav Tulach wrote:
> I was my NetBeans libraries to be as portable as possible and also run on
> Android. I want to use `Lookup` & co.
> -jt
I understand that you want to run Lookup & Co in Android, but I imagine
you don't want to run the Enterprise cluster in Android, right? Either
that or you sport a huge Android tablet/phone!
Question is: since NetBeans is modular and we now have a powerful Github
action powered build system that compiles in thousands of different Java
versions (and more to come by next year)...
...Wouldn't it be possible to try to keep Lookup & Co (i.e. the platform
cluster and probably a few others) binary compatible with JDK8 (with a
specific Github action or something), and let the rest of clusters
evolve with the times?
Thanks,
Antonio
P.S.: Apologies if this has been asked before.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: NetBeans is a framework was: Lets talk about JDK 8 (new year edition)
Posted by Laszlo Kishalmi <la...@gmail.com>.
Well,
These are respectable things, on the other hand the "Java 8 Forever" T-Shirt
is getting more and more uncomfortable.
Fortunately, NetBeans is free and open source, many versions are available,
which are supporting JDK 8. If somebody would like to keep it that way, it's
still possible to keep a branch for it or even create a fork.
It seems someone has to pay the price. Either the active community, to keep
the Java 8 Runtime compatibility. Or someone has to step up and say, that
he/she would take care of some necessary backporting and releasing for
Java 8
every now and then.
And again, there is nothing wrong with using and build on an older
version of the
framework. Like, there is nothing wrong to use Java 8. It just has
consequences...
On 2/8/23 20:38, Jaroslav Tulach wrote:
> NetBeans isn't just an IDE, but it is a framework!
>
> When designing frameworks and libraries that shall be widely adopted it is
> important to increase portability as much as possible. If an API can be used
> on different systems, different configurations, the amount of users including
> such API in their applications grows.
>
> The best way to hurt portability is to depend on a 3rd party API that isn't
> portable. Depending on Win32 API is one such example. Of course, writing in
> Java (a language designed to write once and run everywhere) greatly increases
> portability. However there is another axis hurting portability - the supported
> JDK version. Of course, should a library be widely used, it has to support as
> oldest JDK as possible. These days it is JDK8 - the primary reason being that
> Android supports JDK8 - as such, should a library be aspire to be used on
> Android (as well as regular Java), it needs to stick to version eight. Btw.
> not that many years ago, Android only supported JDK6 and many libraries had to
> stay with JDK6 APIs and language.
>
>
> Supporting the ancient JDK gives the application writers using such library or
> framework a freedom to choose their JDK. The application writers can then run
> on oldest or newest JDK. That's the kind of freedom they want. However there's
> transitivity of non-portability - the portability of the final application
> cannot be bigger than portability of the least portable library used. This
> applies also to 3rd party dependencies a framework or library has: again their
> non-portability may negatively affect portability of such framework or library.
>
> I was my NetBeans libraries to be as portable as possible and also run on
> Android. I want to use `Lookup` & co.
> -jt
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: dev-help@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-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: NetBeans is a framework was: Lets talk about JDK 8 (new year edition)
Posted by Michael Bien <mb...@gmail.com>.
On 09.02.23 05:38, Jaroslav Tulach wrote:
> I was my NetBeans libraries to be as portable as possible and also run on
> Android. I want to use `Lookup` & co.
what percentage of NetBeans can run on android? Are users simply hoping
that it works or are they running our tests on android? Since we aren't
running any on it.
-mbien
> -jt
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: dev-help@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-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: NetBeans is a framework was: Lets talk about JDK 8 (new year edition)
Posted by Ernie Rael <er...@raelity.com>.
It's too bad there are no NetBeans specific statistics, both IDE and
platform.
It sure would be nice if there were some reference to stats on jdk
version usage
in these deliberations.
What I've seen in reports, the most recent I've found from mid 2022,
> even though Java 11 had been available for more than a year. Since
> then, the balance has shifted between these two LTS release versions.
> More than 48% of applications are now using Java 11 in production (up
> from 11.11% in 2020) with Java 8 a close second, capturing 46.45% of
> applications using the version in production.
>
> Java 17 has not climbed the charts, but in the handful of months since
> its release, it has already surpassed the Java 6, Java 10, and Java 16
> releases. [3]
Most reports show 8/11 neck and neck, with expectations that 11/17 continue
to increase share. [2], [3], [4]. Are there more recent reports around?
Something that seems to be missing from the conversation is an /Apache/
/NetBeans Mission Statement/ (or I just haven't seen it). That would include
who are the target users and with what priorities? Professionals,
Hobbyists,
Educators? A more detailed breakdown might be appropriate. And of course
IDE vs Platform considerations.
-ernie
[1]
https://www.stackchief.com/blog/Which%20Version%20of%20Java%20Should%20You%20Use%3F
[2]
https://sdtimes.com/java/report-percentage-of-oracle-jdk-distributions-in-java-ecosystem-drops-significantly/
[3] https://newrelic.com/resources/report/2022-state-of-java-ecosystem
[4]
https://www.infoworld.com/article/3652408/java-8-still-dominates-but-java-17-wave-is-coming-survey.html
On 23/02/08 8:38 PM, Jaroslav Tulach wrote:
> NetBeans isn't just an IDE, but it is a framework!
>
> When designing frameworks and libraries that shall be widely adopted it is
> important to increase portability as much as possible. If an API can be used
> on different systems, different configurations, the amount of users including
> such API in their applications grows.
>
> The best way to hurt portability is to depend on a 3rd party API that isn't
> portable. Depending on Win32 API is one such example. Of course, writing in
> Java (a language designed to write once and run everywhere) greatly increases
> portability. However there is another axis hurting portability - the supported
> JDK version. Of course, should a library be widely used, it has to support as
> oldest JDK as possible. These days it is JDK8 - the primary reason being that
> Android supports JDK8 - as such, should a library be aspire to be used on
> Android (as well as regular Java), it needs to stick to version eight. Btw.
> not that many years ago, Android only supported JDK6 and many libraries had to
> stay with JDK6 APIs and language.
>
>
> Supporting the ancient JDK gives the application writers using such library or
> framework a freedom to choose their JDK. The application writers can then run
> on oldest or newest JDK. That's the kind of freedom they want. However there's
> transitivity of non-portability - the portability of the final application
> cannot be bigger than portability of the least portable library used. This
> applies also to 3rd party dependencies a framework or library has: again their
> non-portability may negatively affect portability of such framework or library.
>
> I was my NetBeans libraries to be as portable as possible and also run on
> Android. I want to use `Lookup` & co.
> -jt
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:dev-unsubscribe@netbeans.apache.org
> For additional commands, e-mail:dev-help@netbeans.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
Re: NetBeans is a framework was: Lets talk about JDK 8 (new year edition)
Posted by John Neffenger <jo...@status6.com>.
On 2/8/23 8:38 PM, Jaroslav Tulach wrote:
> These days it is JDK8 - the primary reason being that
> Android supports JDK8 - as such, should a library be aspire to be used on
> Android (as well as regular Java), it needs to stick to version eight.
There are some benefits to that strategy, but there's also a cost, and
I'm not sure it's worth it.
I played that compatibility game with the Microsoft Virtual Machine in
Internet Explorer, which was stuck at Java 1.1 for years. By the time
the Microsoft VM was discontinued, I never managed to catch up to the
then-current Java versions 1.4 and 5, and my software became irrelevant.
People can move away from old technology very quickly. When they do, it
can leave you far, far behind. I'll never let one company (with an
agenda) hold me back again.
In fact, even the LTS releases mean little unless you're a paying
customer. Ron Pressler, author of the JDK Virtual Threads API, has been
trying to get that message out for a long time. Below is a small sample
(see comments from user "pron"):
https://news.ycombinator.com/item?id=33028988
"Anyway, the mention of the perennially misunderstood Java LTS is a pet
peeve of mine, ..."
"There's absolutely nothing special about them [LTS releases], and the
development of the JDK ignores the availability of such offerings."
https://news.ycombinator.com/item?id=22610237
"All OpenJDK versions are created equal."
John
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: NetBeans is a framework was: Lets talk about JDK 8 (new year edition)
Posted by Arafat BOUCHAFRA <ar...@gmail.com>.
Hi Jaroslav,
In your article about java framework portability, I agree with you a 100%,
and I'll add an important point, that sometimes we deal with low-level
code, by using JNI/JNA, and this precise point makes java portability in
front of a wall, I have learnt that from Limewire source code, in which we
can notice that its really difficult to make a 100% java portable
framework, due that each operating system had its own philosophy, and its
own underlaying low-level librairies.
At the end, to have a fully portable framework, in front of eyes, this one
should care on low-level code, because it's the only thing that will assure
to us a higher portability of this framework.
Regards
Le jeu. 9 févr. 2023 à 05:39, Jaroslav Tulach <ja...@gmail.com> a
écrit :
> NetBeans isn't just an IDE, but it is a framework!
>
> When designing frameworks and libraries that shall be widely adopted it is
> important to increase portability as much as possible. If an API can be
> used
> on different systems, different configurations, the amount of users
> including
> such API in their applications grows.
>
> The best way to hurt portability is to depend on a 3rd party API that
> isn't
> portable. Depending on Win32 API is one such example. Of course, writing
> in
> Java (a language designed to write once and run everywhere) greatly
> increases
> portability. However there is another axis hurting portability - the
> supported
> JDK version. Of course, should a library be widely used, it has to support
> as
> oldest JDK as possible. These days it is JDK8 - the primary reason being
> that
> Android supports JDK8 - as such, should a library be aspire to be used on
> Android (as well as regular Java), it needs to stick to version eight.
> Btw.
> not that many years ago, Android only supported JDK6 and many libraries
> had to
> stay with JDK6 APIs and language.
>
>
> Supporting the ancient JDK gives the application writers using such
> library or
> framework a freedom to choose their JDK. The application writers can then
> run
> on oldest or newest JDK. That's the kind of freedom they want. However
> there's
> transitivity of non-portability - the portability of the final application
> cannot be bigger than portability of the least portable library used. This
> applies also to 3rd party dependencies a framework or library has: again
> their
> non-portability may negatively affect portability of such framework or
> library.
>
> I was my NetBeans libraries to be as portable as possible and also run on
> Android. I want to use `Lookup` & co.
> -jt
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: dev-help@netbeans.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
>
NetBeans is a framework was: Lets talk about JDK 8 (new year edition)
Posted by Jaroslav Tulach <ja...@gmail.com>.
NetBeans isn't just an IDE, but it is a framework!
When designing frameworks and libraries that shall be widely adopted it is
important to increase portability as much as possible. If an API can be used
on different systems, different configurations, the amount of users including
such API in their applications grows.
The best way to hurt portability is to depend on a 3rd party API that isn't
portable. Depending on Win32 API is one such example. Of course, writing in
Java (a language designed to write once and run everywhere) greatly increases
portability. However there is another axis hurting portability - the supported
JDK version. Of course, should a library be widely used, it has to support as
oldest JDK as possible. These days it is JDK8 - the primary reason being that
Android supports JDK8 - as such, should a library be aspire to be used on
Android (as well as regular Java), it needs to stick to version eight. Btw.
not that many years ago, Android only supported JDK6 and many libraries had to
stay with JDK6 APIs and language.
Supporting the ancient JDK gives the application writers using such library or
framework a freedom to choose their JDK. The application writers can then run
on oldest or newest JDK. That's the kind of freedom they want. However there's
transitivity of non-portability - the portability of the final application
cannot be bigger than portability of the least portable library used. This
applies also to 3rd party dependencies a framework or library has: again their
non-portability may negatively affect portability of such framework or library.
I was my NetBeans libraries to be as portable as possible and also run on
Android. I want to use `Lookup` & co.
-jt
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists