On 10/30/22 11:40, Jaroslav Tulach wrote:
Dne úterý 25. října 2022 11:02:07 CET, Neil C Smith napsal(a):
On Tue, 25 Oct 2022 at 08:06, Jaroslav Tulach
wrote:
JDK `javac` drops support for old `-target` versions. E.g. version 11 can
no>
longer target 1.5 bytecode:
Doesn't that take
On Sun, 30 Oct 2022, 18:40 Jaroslav Tulach,
wrote:
> Dne úterý 25. října 2022 11:02:07 CET, Neil C Smith napsal(a):
> > On Tue, 25 Oct 2022 at 08:06, Jaroslav Tulach
>
> wrote:
> > > JDK `javac` drops support for old `-target` versions. E.g. version 11
> can
> > > no>
> > > longer target 1.5
> This would mean that NB_the_IDE (not the platform) would not be able to
> _run_ on JDK 8 anymore (thunder in the background), it would be locked
> to the current JDK release which is already conveniently synced with
> NB's release cycle.
Michael,
NetBeans Platform needs portability. We have to
Dne středa 26. října 2022 22:53:13 CET, Eric Bresie napsal(a):
> Sorry I’m not in the know here from a who developed what but…
>
> Since the below is forked from
>
> https://github.com/oracle/nb-javac
>
> Is that going to be a problem?
>
> Or is that the beauty of open source development (i.e.
Dne úterý 25. října 2022 11:02:07 CET, Neil C Smith napsal(a):
> On Tue, 25 Oct 2022 at 08:06, Jaroslav Tulach
wrote:
> > JDK `javac` drops support for old `-target` versions. E.g. version 11 can
> > no>
> > longer target 1.5 bytecode:
>
> Doesn't that take nb-javac beyond ever being just an
Dne středa 26. října 2022 5:48:28 CET, Laszlo Kishalmi napsal(a):
> I kind of like the idea let nb-javac go, not depend more on it.
Guys,
you are looking at the problem from an IDE perspective. However NetBeans is
also a platform!
When designing frameworks and libraries that shall be widely
On 27.10.22 16:58, Ernie Rael wrote:
On 22/10/27 2:59 AM, Neil C Smith wrote:
On Wed, 26 Oct 2022 at 21:12, Ernie Rael wrote:
NetBeans found
refuge in the powerful walled city state of Apache; where residents are
only allowed commerce with those within its walls or with some who it
On 22/10/27 2:59 AM, Neil C Smith wrote:
On Wed, 26 Oct 2022 at 21:12, Ernie Rael wrote:
NetBeans found
refuge in the powerful walled city state of Apache; where residents are
only allowed commerce with those within its walls or with some who it
explicitly approves.
Your text amused me,
At
On 27.10.22 12:05, Neil C Smith wrote:
On Thu, 27 Oct 2022 at 08:43, Anton V. Kirilchik wrote:
Is it possible, to do it like in Idea, which runs on jdk distributed with,
and each project in idea can be built and run on diferrent JDK?
Yes, this is exactly what the community installers do -
On Thu, 27 Oct 2022 at 08:43, Anton V. Kirilchik wrote:
> Is it possible, to do it like in Idea, which runs on jdk distributed with,
> and each project in idea can be built and run on diferrent JDK?
Yes, this is exactly what the community installers do -
On Wed, 26 Oct 2022 at 21:12, Ernie Rael wrote:
> NetBeans found
> refuge in the powerful walled city state of Apache; where residents are
> only allowed commerce with those within its walls or with some who it
> explicitly approves.
Your text amused me, but this statement I find ironic.
On Wed, 26 Oct 2022 at 21:18, Geertjan Wielenga
wrote:
> The direction is clear — we all work together on NetBeans and, since we’re
> all different people with different perspectives, we share our different
> ideas and perspectives, discuss them, and provide pull requests based on
> our ideas and
Indeed, as always, of course, you can run NetBeans on a JDK and run
your projects on any other JDK.
However, the place where nb-javac is used is within the Java editor
right now and, potentially, also when NetBeans is built (which is what
the discussion is about), which would mean that JDK would
I think we should divide JDK that NetBeans developed uder and run on, with
the JDKs under which projects are developed.
As example NB itself run on JDK 17, but i want use JDK from 8 to 17 for my
projects.
Is it possible, to do it like in Idea, which runs on jdk distributed with,
and each project
just to clarify:
I don't think anybody suggested to drop Java 8 support in the NetBeans
editor.
Imagine nb-javac as a dependency like any other artifact. If NB wants to
support Java X, it would have to get a javac which supports java X from
somewhere. If nb-javac would be gone, NB 16
JDK 8 is still supported by Oracle. Dropping it should happen when it makes
sense, after support has ended. If you need to work on Java versions prior to
8, first, I’m sorry, you have my sympathy, second, download an older version of
NetBeans that supports it - if you are living in the past
Just been looking into open source work done in the context of the
European Union and one of the key applications there requires JDK 8:
https://github.com/l-e-x/leos
I.e., we need to stop thinking that Java 8 is somehow dead or
ethically or otherwise problematic -- it's simply what a great deal
On 10/25/22 22:48, Laszlo Kishalmi wrote:
> I'm confused as well. Still not clear, what are we about to solve here.
> Use new lang spec with old runtimes? I do not have granny issues...
Also confused. If this is all so people can still code for Java 8 in
this day and age, I say drop support for
Sorry I’m not in the know here from a who developed what but…
Since the below is forked from
https://github.com/oracle/nb-javac
Is that going to be a problem?
Or is that the beauty of open source development (i.e. fork it, enhance it,
rebrand it [maybe nb-jc], etc. - license permitting)?
Eric
The direction is clear — we all work together on NetBeans and, since we’re
all different people with different perspectives, we share our different
ideas and perspectives, discuss them, and provide pull requests based on
our ideas and perspectives. Some are accepted and some not, depending on
how
On 22/10/24 9:42 AM, Neil C Smith wrote:
OTOH, I don't think this is all suited to technical discussion on
individual code changes either, as there are also questions of broad
direction of travel raised here that need to be reconciled.
In the before time, in the Kingdom of Java, NetBeans was in
en
Sent: Monday, October 24, 2022 4:27 PM
To: dev@netbeans.apache.org; Ernie Rael
Subject: Re: nb-javac for building NetBeans itself
On 24.10.22 22:15, Ernie Rael wrote:
On 22/10/24 8:58 AM, Michael Bien wrote:
On 24.10.22 17:27, Ernie Rael wrote:
The link to apache's guidelines for vo
etbeans.apache.org; Ernie Rael
Subject: Re: nb-javac for building NetBeans itself
On 24.10.22 22:15, Ernie Rael wrote:
On 22/10/24 8:58 AM, Michael Bien wrote:
On 24.10.22 17:27, Ernie Rael wrote:
The link to apache's guidelines for voting was clarifying for me.
I'd like to see a more technica
On Tue, 25 Oct 2022 at 08:06, Jaroslav Tulach wrote:
> JDK `javac` drops support for old `-target` versions. E.g. version 11 can no
> longer target 1.5 bytecode:
I'm confused! Wasn't the original proposal (and our existing usage of
it) about using nb-javac to support later source and target
e cycle where we can add it.
>
> Much better to keep NetBeans building with the standard JDK.
>
> -- Eirik
>
> -Original Message-
> From: Michael Bien
> Sent: Monday, October 24, 2022 4:27 PM
> To: dev@netbeans.apache.org; Ernie Rael
> Subject: Re: nb-
beans.apache.org; Ernie Rael
Subject: Re: nb-javac for building NetBeans itself
On 24.10.22 22:15, Ernie Rael wrote:
> On 22/10/24 8:58 AM, Michael Bien wrote:
>> On 24.10.22 17:27, Ernie Rael wrote:
>>> The link to apache's guidelines for voting was clarifying for me.
>>> I'
On 24.10.22 22:15, Ernie Rael wrote:
On 22/10/24 8:58 AM, Michael Bien wrote:
On 24.10.22 17:27, Ernie Rael wrote:
The link to apache's guidelines for voting was clarifying for me.
I'd like to see a more technical discussion.
for me too, I withdrew the -1 vote the moment I realized that this
On 22/10/24 9:42 AM, Neil C Smith wrote:
On Mon, 24 Oct 2022 at 17:02, Michael Bien wrote:
On 24.10.22 17:27, Ernie Rael wrote:
The link to apache's guidelines for voting was clarifying for me. I'd
like to see a more technical discussion.
for me too, I withdrew the -1 vote the moment I
On 22/10/24 8:58 AM, Michael Bien wrote:
On 24.10.22 17:27, Ernie Rael wrote:
The link to apache's guidelines for voting was clarifying for me. I'd
like to see a more technical discussion.
for me too, I withdrew the -1 vote the moment I realized that this
could qualify as veto since this
On 24.10.22 16:02, Michael Bien wrote:
Hi Geertjan,
replies inline
On 24.10.22 12:49, Geertjan Wielenga wrote:
Hi all,
Right now, when we build NetBeans, we’re using the javac from the JDK
that
we’re using to do the build — so that we’re dependent on the JDK team,
which can decide to drop
On Mon, 24 Oct 2022 at 17:02, Michael Bien wrote:
>
> On 24.10.22 17:27, Ernie Rael wrote:
> > The link to apache's guidelines for voting was clarifying for me. I'd
> > like to see a more technical discussion.
>
> for me too, I withdrew the -1 vote the moment I realized that this could
> qualify
On 24.10.22 17:27, Ernie Rael wrote:
The link to apache's guidelines for voting was clarifying for me. I'd
like to see a more technical discussion.
for me too, I withdrew the -1 vote the moment I realized that this could
qualify as veto since this discussion would fall into the code-change
On 22/10/24 4:50 AM, Neil C Smith wrote:
On Mon, 24 Oct 2022 at 12:31, Geertjan Wielenga
wrote:
On Mon, Oct 24, 2022 at 1:25 PM Neil C Smith wrote:
Multiple people have expressed massive reservations on this already.
Michael expressed a -0.99 already. Given code changes are really +1
or -1
On 24.10.22 16:14, Neil C Smith wrote:
On Mon, 24 Oct 2022 at 13:43, Geertjan Wielenga
wrote:
(But, of course, we already are dependent on nb-javac, nothing changes there.)
Not to the same extent.
On Mon, 24 Oct 2022 at 14:56, Geertjan Wielenga
wrote:
On Mon, 24 Oct 2022 at 13:43, Geertjan Wielenga
wrote:
> (But, of course, we already are dependent on nb-javac, nothing changes there.)
Not to the same extent.
On Mon, 24 Oct 2022 at 14:56, Geertjan Wielenga
wrote:
> https://github.com/JaroslavTulach/nb-javac/
>
> Where should it be, Neil? It
Hi Geertjan,
replies inline
On 24.10.22 12:49, Geertjan Wielenga wrote:
Hi all,
Right now, when we build NetBeans, we’re using the javac from the JDK that
we’re using to do the build — so that we’re dependent on the JDK team,
which can decide to drop features.
_If_ the JDK team decides to
I take the above back -- nb-javac is developed by Jaroslav Tulach, and
whoever contributes, e.g., Dusan Balek.
https://github.com/JaroslavTulach/nb-javac/
Where should it be, Neil? It can't be here at Apache because of its
licensing. Isn't it fine where it is and under active development via
(But, of course, we already are dependent on nb-javac, nothing changes there.)
Gj
On Mon, Oct 24, 2022 at 1:59 PM Geertjan Wielenga
wrote:
>
> I’d vote against at the moment, since we’d be dependent on nb-javac, the
> development and ownership of which is indeed a bit fuzzy.
>
> Gj
>
> On Mon,
I’d vote against at the moment, since we’d be dependent on nb-javac, the
development and ownership of which is indeed a bit fuzzy.
Gj
On Mon, 24 Oct 2022 at 13:51, Neil C Smith wrote:
> On Mon, 24 Oct 2022 at 12:31, Geertjan Wielenga
> wrote:
> >
> > On Mon, Oct 24, 2022 at 1:25 PM Neil C
On Mon, 24 Oct 2022 at 12:31, Geertjan Wielenga
wrote:
>
> On Mon, Oct 24, 2022 at 1:25 PM Neil C Smith wrote:
> >
> > Multiple people have expressed massive reservations on this already.
> > Michael expressed a -0.99 already. Given code changes are really +1
> > or -1 anyway, I'll lend the
On Mon, Oct 24, 2022 at 1:25 PM Neil C Smith wrote:
>
> Multiple people have expressed massive reservations on this already.
> Michael expressed a -0.99 already. Given code changes are really +1
> or -1 anyway, I'll lend the -0.01 until his and other reservations are
> adequately considered at
On Mon, 24 Oct 2022 at 11:50, Geertjan Wielenga wrote:
> Right now, when we build NetBeans, we’re using the javac from the JDK that
> we’re using to do the build — so that we’re dependent on the JDK team,
> which can decide to drop features.
>
> If, instead, we were to set the compiler in
Hi all,
Right now, when we build NetBeans, we’re using the javac from the JDK that
we’re using to do the build — so that we’re dependent on the JDK team,
which can decide to drop features.
If, instead, we were to set the compiler in NetBeans the build script, to
nb-javac, which is available on
43 matches
Mail list logo
