Building NetBeans on Mac

[Ryan Cuprak]

Hi,
 I am trying to build NetBeans on the Mac and have been running into an odd 
compiler error (bottom of email). 
  
 I am running with the following:
Graalvm 11 (Enterprise)
jenv managing Java versions
 
Command line:
ant -Dcluster.config=basic -Dpermit.jdk9.builds=true

I build the exact same code base on a Linux VM no problem with the only 
difference being I am using AdoptOpenJDK 11 managed by sdkman.

Has anyone else had this problem? 

Interesting, when I do an ls:
ls /Volumes/Pendelton/open-source/netbeans/platform/applemenu/build
classes classes-generated   depcache
notice-temp

 There is no "desktop-classes-classes” - it also does not exist on Linux when I 
build there but the compiler there doesn’t fail.

Thanks,
-Ryan

Build Output:
 -javac-init-nbjdk:
Trying to override old definition of task custom-javac

-javac-init-bootclasspath-prepend:

-javac-init-no-bootclasspath-prepend:

-javac-init:

-init-proxy:

init:

-prepare-mandatory-files-for-module:
[createlicensesummary] All tests passed

up-to-date:

-pre-compile:

-do-compile:
 [nb-javac] Compiling 7 source files to 
/Volumes/Pendelton/open-source/netbeans/platform/applemenu/build/classes
   [repeat] warning: [path] bad path element 
"/Volumes/Pendelton/open-source/netbeans/platform/applemenu/build/desktop-classes-classes":
 no such file or directory
   [repeat] error: Source option 6 is no longer supported. Use 7 or later.
   [repeat] error: Target option 6 is no longer supported. Use 7 or later.
  [nbmerge] Failed to build target: all-applemenu

Re: ? about C/C++ module

[Ernie Rael]

On 4/28/2020 3:58 PM, Brad Walker wrote:

I'm starting to wade into helping get the C/C++ module up and running on
Apache Netbeans. As a result, I have quick project question for the more
"senior" folks on this group. Or anyone else who cares to comment. 8-)

I would like to propose that we drop support for the SunStudio tools (i.e.
compiler and debugger, etc.). The reason is because it makes porting more
difficult. In addition, it doesn't really make sense for a project like
Apache Netbeans to carry all this technical debt that it incurs for which
no one really is going to support.

So what are the collective thoughts and opinions about dropping SunStudio
support in Apache Netbeans?

The assumption here is that GDB and friends would continue to work and be
supported.

-brad w.


There's this tantalizing message from Jan

http://mail-archives.apache.org/mod_mbox/netbeans-dev/202004.mbox/%3CCALd%3D3dH2vqLx8rrP2yDh76%3DDVKsok-g0Qeaf9zpeaVG2aeALhA%40mail.gmail.com%3E

which suggests

   alternative idea is to use a Language Server Protocol (LSP) server

You might find that thread interesting...

-ernie


-
To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org
For additional commands, e-mail: dev-h...@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

? about C/C++ module

[Brad Walker]

I'm starting to wade into helping get the C/C++ module up and running on
Apache Netbeans. As a result, I have quick project question for the more
"senior" folks on this group. Or anyone else who cares to comment. 8-)

I would like to propose that we drop support for the SunStudio tools (i.e.
compiler and debugger, etc.). The reason is because it makes porting more
difficult. In addition, it doesn't really make sense for a project like
Apache Netbeans to carry all this technical debt that it incurs for which
no one really is going to support.

So what are the collective thoughts and opinions about dropping SunStudio
support in Apache Netbeans?

The assumption here is that GDB and friends would continue to work and be
supported.

-brad w.

RE: nb-javac and the upcoming 12.0

[Eirik Bakke]

> But there is the UI for this, correct? I mean, when one activates the Java 
> support (in the default build), the UI will even refuse to activate it on JDK 
> 8 without installing nb-javac.

That's good. Sounds like there are plenty of barriers against users 
accidentally ending up in a suboptimal configuration without knowing why.

Thanks for the explanation!

(I'll continue to try to boil down and report examples that break the editor 
when I see exceptions... I suspect there's only a handful of cases that cause 
most of the problems.)

-- Eirik

-Original Message-
From: Jan Lahoda  
Sent: Tuesday, April 28, 2020 3:59 PM
To: Apache NetBeans 
Subject: Re: nb-javac and the upcoming 12.0

On Tue, Apr 28, 2020 at 7:50 PM Eirik Bakke  wrote:

> Sure. Though I think the user would be surprised if 
> editing/code-completion just silently doesn't work, when 
> building/running does. There needs to be a message of some sort, 
> recommending running the IDE on a later JDK.
>
> Otherwise we risk having users go "Well, I tried NetBeans once, and it 
> didn't work very well", or "but it doesn't do code completion like 
> Eclipse does", without knowing that there was a specific fixable problem.
>

But there is the UI for this, correct? I mean, when one activates the Java 
support (in the default build), the UI will even refuse to activate it on JDK 8 
without installing nb-javac. And even if it gets enabled (e.g. by using a 
non-default build), the user will get a dialog on the first start, and then a 
nag in the notification area on every subsequent start. We could add e.g. a 
warning to all Java editors, but does not feel necessary to me - I think the UI 
is pushing the user in the right direction fairly strongly.

On JDK 9+ (JDK 11+), the Java support can be enabled without nb-javac, and 
there is no dialog, but the nagging in the notification area is still there. 
(But the Java editor works, although not perfectly, even without nb-javac on 
JDK 11+.)

I believe the changes done and/or proposed for 12.0 are:
-in the activation dialog, if nb-javac is unchecked, and "Download and 
Activate" is selected (to download JavaFX), it used to download nb-javac 
unconditionally. I believe this is fixed by Jaroslav - if the checkbox is 
unchecked, nb-javac is not downloaded. Which is correct.
-when the runtime JDK is JDK 14+, do not nag the user to install nb-javac.
The reason is that nb-javac is still based on javac from JDK 13, and people are 
confused JDK 14 features are not working properly for them when running with 
nb-javac. This is https://github.com/apache/netbeans/pull/2108 Note that the 
user still can install nb-javac, just the IDE will not nag him on every start 
to do so.

(I think it is a little too late to do something more challenging for 12.0.)

The behavior of the NetBeans' Java editor without nb-javac is (I hope!) 
improving with every NetBeans and JDK release, it is somewhat difficult to keep 
track of individual changes (and some of the changes are just technical details 
which may e.g. sometimes lead to an exception being thrown from code 
completion, or something like that). AFAIK, there are currently four bigish 
differences in behavior of the Java editor with and without nb-javac (running 
on JDK 13/14):
-Compile on Save does not work without nb-javac. Solvable, but requires quite 
some work and testing.
-refactoring/find usages are much slower without nb-javac. Work on this is 
being done in https://github.com/apache/netbeans/pull/1890. (It includes some 
compromises, but hopefully acceptable. It will likely to be fast in most cases, 
but sometimes it may revert to being slow.) -code completion is slower (this is 
presumably mainly noticeable on big source files). This is because the code 
completion was sped up using "partial reparse" (if a file is parsed, then 
modified inside one method and then code completion is invoked, only the single 
method was reparsed, not the whole source). There is an implementation of that 
which does not need nb-javac, but is disabled by default, as I think it needs 
more testing.
Should be possible to enable using command line flag 
-J-Djava.enable.partial.reparse=true
-as the initial scan processes projects, processing of every project (more 
precisely source root) must fit into the memory at once when running without 
nb-javac. With nb-javac, the code may be processed in parts. So far, I think 
this is the only part that is not reasonably solvable. But I think the impact 
on users is likely to be low.

Then there is a set of issues related to error recovery and bugs, but I don't 
think I have a full list of those. This is e.g. Eirik's NETBEANS-4179
- an exception for erroneous code (this specific issue should be alleviated for 
JDK 15, see https://bugs.openjdk.java.net/browse/JDK-8243047). Again, I hope 
the situation is improving there, release after release, but I don't expect 
that we will deal with all such issues soon - some such issues exist even 

Re: nb-javac and the upcoming 12.0

[Geertjan Wielenga]

Absolutely true.

But at this point a new user is unlikely to get started by downloading JDK
8.

Gj

On Tue, 28 Apr 2020 at 19:50, Eirik Bakke  wrote:

> Sure. Though I think the user would be surprised if
> editing/code-completion just silently doesn't work, when building/running
> does. There needs to be a message of some sort, recommending running the
> IDE on a later JDK.
>
> Otherwise we risk having users go "Well, I tried NetBeans once, and it
> didn't work very well", or "but it doesn't do code completion like Eclipse
> does", without knowing that there was a specific fixable problem.
>
> -- Eirik
>
> -Original Message-
> From: Geertjan Wielenga 
> Sent: Tuesday, April 28, 2020 1:08 PM
> To: dev@netbeans.apache.org
> Subject: Re: nb-javac and the upcoming 12.0
>
> Well, it’s specifically about editing Java source files, in a project that
> uses any JDK, when NetBeans itself is running on JDK 8. Under these
> conditions, nb-javac is a requirement — specifically when editing Java
> source files, i.e., when using the Java editor. You can still build, test,
> run, etc.
>
> Gj
>
> On Tue, 28 Apr 2020 at 18:58, Eirik Bakke  wrote:
>
> > No, not at all!
> >
> > I just confused the "what JDK the IDE is running on" vs. "what JDK the
> > project is compiled with" when interpreting your proposed restriction.
> >
> > Ideally, a warning should be shown to a user if they try to use a JDK
> > 8 project while running the IDE on a JDK that does not support this.
> > It's a little unintuitive to have to juggle two JDKs here, but that
> > seems a reasonable price to pay if the user really wants to work with
> > a project that must compile with an old JDK.
> >
> > -- Eirik
> >
> > -Original Message-
> > From: Geertjan Wielenga 
> > Sent: Tuesday, April 28, 2020 12:53 PM
> > To: dev@netbeans.apache.org
> > Subject: Re: nb-javac and the upcoming 12.0
> >
> > Hopefully that’s not sarcasm. :-)
> >
> > Gj
> >
> > On Tue, 28 Apr 2020 at 18:43, Eirik Bakke  wrote:
> >
> > > Oh, now I get it. So you can still compile projects with JDK 8 and
> > > use the editor, but you must run the IDE itself on JDK 14, and with
> > > no nb-javac (to make JDK 8 projects work).
> > >
> > > That actually seems very reasonable!
> > >
> > > -- Eirik
> > >
> > > -Original Message-
> > > From: Geertjan Wielenga 
> > > Sent: Tuesday, April 28, 2020 12:29 PM
> > > To: dev@netbeans.apache.org
> > > Subject: Re: nb-javac and the upcoming 12.0
> > >
> > > Yes, the Java editor uses the JDK 14 javac if it runs on that JDK —
> > > even if the build of a particular project uses JDK 8 or anything else.
> > >
> > > Gj
> > >
> > > On Tue, 28 Apr 2020 at 18:25, Scott Palmer  wrote:
> > >
> > > > Just my 2 cents... I am all for NB having great first-class
> > > > support for development of projects that use Java 8, but I don’t
> > > > care if I’m forced to run NB itself with JDK-14.
> > > > I realize that some have projects  based on the NB platform that
> > > > they want to run on Java 8. I think if you are in that situation,
> > > > you have to decide to keep with an older version of the NB
> > > > platform because we can’t hold the platform back to Java 8
> > > > compatibility
> > forever.
> > > >
> > > > That being said, I would like to be able to change the default JDK
> > > > for projects so it is a different JDK than what NB is running on.
> > > > Having to go through most of my projects and explicitly flip them
> > > > to use JDK
> > > > 8 is a minor pain, and it also makes sharing the project with a
> > > > team a little more awkward as well. They need additional
> > > > configuration in NB so the right JDK can be found and we have to
> > > > share NB project files that otherwise don’t need to go into the
> project’s source repo.
> > > >
> > > > What is unclear to me, and it seems I’m not alone, is if NB is
> > > > running on
> > > > JDK-14 without nb-javac, what do we miss when working on a project
> > > > that builds with JDK-8? Can the NB editor not use JDK-14’s javac
> > > > even tough the build runs with JDK-8?
> > > >
> > > > Scott
> > > >
> > > > > On Apr 28, 2020, at 10:50 AM, Geertjan Wielenga
> > > > > 
> > > > wrote:
> > > > >
> > > > > You're not going to find me arguing against good support for Java
> 8.
> > > > > However, as stated above, we anticipate that nb-javac will not
> > > > > be ready
> > > > in
> > > > > time for the 12.0 release.
> > > > >
> > > > > Gj
> > > > >
> > > > > On Tue, Apr 28, 2020 at 4:46 PM Eirik Bakke 
> > wrote:
> > > > >
> > > > >>> A question is what about JDK 8. My bold suggestion would be
> > > > >>> that we
> > > > >> explicitly tell our users that they can’t use our Java Editor
> > > > >> if they’re running NetBeans on JDK 8.
> > > > >>
> > > > >> I think it's too early to drop first-class support for Java 8,
> > > > >> for the same reasons people listed in the earlier "Pull the
> > > > >> plug from Java 8 in 12.1?" thread.
> > > > >>
> > > > >> Good support for Java 8 is a feature, 

RE: nb-javac and the upcoming 12.0

[Eirik Bakke]

Sure. Though I think the user would be surprised if editing/code-completion 
just silently doesn't work, when building/running does. There needs to be a 
message of some sort, recommending running the IDE on a later JDK.

Otherwise we risk having users go "Well, I tried NetBeans once, and it didn't 
work very well", or "but it doesn't do code completion like Eclipse does", 
without knowing that there was a specific fixable problem.

-- Eirik

-Original Message-
From: Geertjan Wielenga  
Sent: Tuesday, April 28, 2020 1:08 PM
To: dev@netbeans.apache.org
Subject: Re: nb-javac and the upcoming 12.0

Well, it’s specifically about editing Java source files, in a project that uses 
any JDK, when NetBeans itself is running on JDK 8. Under these conditions, 
nb-javac is a requirement — specifically when editing Java source files, i.e., 
when using the Java editor. You can still build, test, run, etc.

Gj

On Tue, 28 Apr 2020 at 18:58, Eirik Bakke  wrote:

> No, not at all!
>
> I just confused the "what JDK the IDE is running on" vs. "what JDK the 
> project is compiled with" when interpreting your proposed restriction.
>
> Ideally, a warning should be shown to a user if they try to use a JDK 
> 8 project while running the IDE on a JDK that does not support this. 
> It's a little unintuitive to have to juggle two JDKs here, but that 
> seems a reasonable price to pay if the user really wants to work with 
> a project that must compile with an old JDK.
>
> -- Eirik
>
> -Original Message-
> From: Geertjan Wielenga 
> Sent: Tuesday, April 28, 2020 12:53 PM
> To: dev@netbeans.apache.org
> Subject: Re: nb-javac and the upcoming 12.0
>
> Hopefully that’s not sarcasm. :-)
>
> Gj
>
> On Tue, 28 Apr 2020 at 18:43, Eirik Bakke  wrote:
>
> > Oh, now I get it. So you can still compile projects with JDK 8 and 
> > use the editor, but you must run the IDE itself on JDK 14, and with 
> > no nb-javac (to make JDK 8 projects work).
> >
> > That actually seems very reasonable!
> >
> > -- Eirik
> >
> > -Original Message-
> > From: Geertjan Wielenga 
> > Sent: Tuesday, April 28, 2020 12:29 PM
> > To: dev@netbeans.apache.org
> > Subject: Re: nb-javac and the upcoming 12.0
> >
> > Yes, the Java editor uses the JDK 14 javac if it runs on that JDK — 
> > even if the build of a particular project uses JDK 8 or anything else.
> >
> > Gj
> >
> > On Tue, 28 Apr 2020 at 18:25, Scott Palmer  wrote:
> >
> > > Just my 2 cents... I am all for NB having great first-class 
> > > support for development of projects that use Java 8, but I don’t 
> > > care if I’m forced to run NB itself with JDK-14.
> > > I realize that some have projects  based on the NB platform that 
> > > they want to run on Java 8. I think if you are in that situation, 
> > > you have to decide to keep with an older version of the NB 
> > > platform because we can’t hold the platform back to Java 8 
> > > compatibility
> forever.
> > >
> > > That being said, I would like to be able to change the default JDK 
> > > for projects so it is a different JDK than what NB is running on.
> > > Having to go through most of my projects and explicitly flip them 
> > > to use JDK
> > > 8 is a minor pain, and it also makes sharing the project with a 
> > > team a little more awkward as well. They need additional 
> > > configuration in NB so the right JDK can be found and we have to 
> > > share NB project files that otherwise don’t need to go into the project’s 
> > > source repo.
> > >
> > > What is unclear to me, and it seems I’m not alone, is if NB is 
> > > running on
> > > JDK-14 without nb-javac, what do we miss when working on a project 
> > > that builds with JDK-8? Can the NB editor not use JDK-14’s javac 
> > > even tough the build runs with JDK-8?
> > >
> > > Scott
> > >
> > > > On Apr 28, 2020, at 10:50 AM, Geertjan Wielenga 
> > > > 
> > > wrote:
> > > >
> > > > You're not going to find me arguing against good support for Java 8.
> > > > However, as stated above, we anticipate that nb-javac will not 
> > > > be ready
> > > in
> > > > time for the 12.0 release.
> > > >
> > > > Gj
> > > >
> > > > On Tue, Apr 28, 2020 at 4:46 PM Eirik Bakke 
> wrote:
> > > >
> > > >>> A question is what about JDK 8. My bold suggestion would be 
> > > >>> that we
> > > >> explicitly tell our users that they can’t use our Java Editor 
> > > >> if they’re running NetBeans on JDK 8.
> > > >>
> > > >> I think it's too early to drop first-class support for Java 8, 
> > > >> for the same reasons people listed in the earlier "Pull the 
> > > >> plug from Java 8 in 12.1?" thread.
> > > >>
> > > >> Good support for Java 8 is a feature, and an important one for 
> > > >> an IDE
> > > that
> > > >> is primarily associated with the Java ecosystem.
> > > >>
> > > >> Eirik
> > > >>
> > > >> -Original Message-
> > > >> From: Geertjan Wielenga 
> > > >> Sent: Tuesday, April 28, 2020 2:47 AM
> > > >> To: dev 
> > > >> Subject: nb-javac and the upcoming 12.0
> > > >>
> > > >> Hi all,
> 

Re: nb-javac and the upcoming 12.0

[Geertjan Wielenga]

Well, it’s specifically about editing Java source files, in a project that
uses any JDK, when NetBeans itself is running on JDK 8. Under these
conditions, nb-javac is a requirement — specifically when editing Java
source files, i.e., when using the Java editor. You can still build, test,
run, etc.

Gj

On Tue, 28 Apr 2020 at 18:58, Eirik Bakke  wrote:

> No, not at all!
>
> I just confused the "what JDK the IDE is running on" vs. "what JDK the
> project is compiled with" when interpreting your proposed restriction.
>
> Ideally, a warning should be shown to a user if they try to use a JDK 8
> project while running the IDE on a JDK that does not support this. It's a
> little unintuitive to have to juggle two JDKs here, but that seems a
> reasonable price to pay if the user really wants to work with a project
> that must compile with an old JDK.
>
> -- Eirik
>
> -Original Message-
> From: Geertjan Wielenga 
> Sent: Tuesday, April 28, 2020 12:53 PM
> To: dev@netbeans.apache.org
> Subject: Re: nb-javac and the upcoming 12.0
>
> Hopefully that’s not sarcasm. :-)
>
> Gj
>
> On Tue, 28 Apr 2020 at 18:43, Eirik Bakke  wrote:
>
> > Oh, now I get it. So you can still compile projects with JDK 8 and use
> > the editor, but you must run the IDE itself on JDK 14, and with no
> > nb-javac (to make JDK 8 projects work).
> >
> > That actually seems very reasonable!
> >
> > -- Eirik
> >
> > -Original Message-
> > From: Geertjan Wielenga 
> > Sent: Tuesday, April 28, 2020 12:29 PM
> > To: dev@netbeans.apache.org
> > Subject: Re: nb-javac and the upcoming 12.0
> >
> > Yes, the Java editor uses the JDK 14 javac if it runs on that JDK —
> > even if the build of a particular project uses JDK 8 or anything else.
> >
> > Gj
> >
> > On Tue, 28 Apr 2020 at 18:25, Scott Palmer  wrote:
> >
> > > Just my 2 cents... I am all for NB having great first-class support
> > > for development of projects that use Java 8, but I don’t care if I’m
> > > forced to run NB itself with JDK-14.
> > > I realize that some have projects  based on the NB platform that
> > > they want to run on Java 8. I think if you are in that situation,
> > > you have to decide to keep with an older version of the NB platform
> > > because we can’t hold the platform back to Java 8 compatibility
> forever.
> > >
> > > That being said, I would like to be able to change the default JDK
> > > for projects so it is a different JDK than what NB is running on.
> > > Having to go through most of my projects and explicitly flip them to
> > > use JDK
> > > 8 is a minor pain, and it also makes sharing the project with a team
> > > a little more awkward as well. They need additional configuration in
> > > NB so the right JDK can be found and we have to share NB project
> > > files that otherwise don’t need to go into the project’s source repo.
> > >
> > > What is unclear to me, and it seems I’m not alone, is if NB is
> > > running on
> > > JDK-14 without nb-javac, what do we miss when working on a project
> > > that builds with JDK-8? Can the NB editor not use JDK-14’s javac
> > > even tough the build runs with JDK-8?
> > >
> > > Scott
> > >
> > > > On Apr 28, 2020, at 10:50 AM, Geertjan Wielenga
> > > > 
> > > wrote:
> > > >
> > > > You're not going to find me arguing against good support for Java 8.
> > > > However, as stated above, we anticipate that nb-javac will not be
> > > > ready
> > > in
> > > > time for the 12.0 release.
> > > >
> > > > Gj
> > > >
> > > > On Tue, Apr 28, 2020 at 4:46 PM Eirik Bakke 
> wrote:
> > > >
> > > >>> A question is what about JDK 8. My bold suggestion would be that
> > > >>> we
> > > >> explicitly tell our users that they can’t use our Java Editor if
> > > >> they’re running NetBeans on JDK 8.
> > > >>
> > > >> I think it's too early to drop first-class support for Java 8,
> > > >> for the same reasons people listed in the earlier "Pull the plug
> > > >> from Java 8 in 12.1?" thread.
> > > >>
> > > >> Good support for Java 8 is a feature, and an important one for an
> > > >> IDE
> > > that
> > > >> is primarily associated with the Java ecosystem.
> > > >>
> > > >> Eirik
> > > >>
> > > >> -Original Message-
> > > >> From: Geertjan Wielenga 
> > > >> Sent: Tuesday, April 28, 2020 2:47 AM
> > > >> To: dev 
> > > >> Subject: nb-javac and the upcoming 12.0
> > > >>
> > > >> Hi all,
> > > >>
> > > >> We’re getting close to the 12.0 release and nb-javac won’t be
> > > >> available
> > > at
> > > >> the time of release. What nb-javac provides is detailed elsewhere
> > > >> but in summary it is a fork of the  javac finetuned to the Java
> > > >> Editor in NetBeans. It can’t be donated to Apache NetBeans
> > > >> because it is a javac
> > > fork
> > > >> and hence GPL licensed, so Oracle does not want to donate it and
> > > >> Apache projects can’t be released with it.
> > > >>
> > > >> Ultimately, we’d like to drop the need for nb-javac completely.
> > > >> That
> > > will
> > > >> simplify things a lot. Plus, that is increasingly 

RE: nb-javac and the upcoming 12.0

[Eirik Bakke]

No, not at all!

I just confused the "what JDK the IDE is running on" vs. "what JDK the project 
is compiled with" when interpreting your proposed restriction.

Ideally, a warning should be shown to a user if they try to use a JDK 8 project 
while running the IDE on a JDK that does not support this. It's a little 
unintuitive to have to juggle two JDKs here, but that seems a reasonable price 
to pay if the user really wants to work with a project that must compile with 
an old JDK.

-- Eirik

-Original Message-
From: Geertjan Wielenga  
Sent: Tuesday, April 28, 2020 12:53 PM
To: dev@netbeans.apache.org
Subject: Re: nb-javac and the upcoming 12.0

Hopefully that’s not sarcasm. :-)

Gj

On Tue, 28 Apr 2020 at 18:43, Eirik Bakke  wrote:

> Oh, now I get it. So you can still compile projects with JDK 8 and use 
> the editor, but you must run the IDE itself on JDK 14, and with no 
> nb-javac (to make JDK 8 projects work).
>
> That actually seems very reasonable!
>
> -- Eirik
>
> -Original Message-
> From: Geertjan Wielenga 
> Sent: Tuesday, April 28, 2020 12:29 PM
> To: dev@netbeans.apache.org
> Subject: Re: nb-javac and the upcoming 12.0
>
> Yes, the Java editor uses the JDK 14 javac if it runs on that JDK — 
> even if the build of a particular project uses JDK 8 or anything else.
>
> Gj
>
> On Tue, 28 Apr 2020 at 18:25, Scott Palmer  wrote:
>
> > Just my 2 cents... I am all for NB having great first-class support 
> > for development of projects that use Java 8, but I don’t care if I’m 
> > forced to run NB itself with JDK-14.
> > I realize that some have projects  based on the NB platform that 
> > they want to run on Java 8. I think if you are in that situation, 
> > you have to decide to keep with an older version of the NB platform 
> > because we can’t hold the platform back to Java 8 compatibility forever.
> >
> > That being said, I would like to be able to change the default JDK 
> > for projects so it is a different JDK than what NB is running on. 
> > Having to go through most of my projects and explicitly flip them to 
> > use JDK
> > 8 is a minor pain, and it also makes sharing the project with a team 
> > a little more awkward as well. They need additional configuration in 
> > NB so the right JDK can be found and we have to share NB project 
> > files that otherwise don’t need to go into the project’s source repo.
> >
> > What is unclear to me, and it seems I’m not alone, is if NB is 
> > running on
> > JDK-14 without nb-javac, what do we miss when working on a project 
> > that builds with JDK-8? Can the NB editor not use JDK-14’s javac 
> > even tough the build runs with JDK-8?
> >
> > Scott
> >
> > > On Apr 28, 2020, at 10:50 AM, Geertjan Wielenga 
> > > 
> > wrote:
> > >
> > > You're not going to find me arguing against good support for Java 8.
> > > However, as stated above, we anticipate that nb-javac will not be 
> > > ready
> > in
> > > time for the 12.0 release.
> > >
> > > Gj
> > >
> > > On Tue, Apr 28, 2020 at 4:46 PM Eirik Bakke  wrote:
> > >
> > >>> A question is what about JDK 8. My bold suggestion would be that 
> > >>> we
> > >> explicitly tell our users that they can’t use our Java Editor if 
> > >> they’re running NetBeans on JDK 8.
> > >>
> > >> I think it's too early to drop first-class support for Java 8, 
> > >> for the same reasons people listed in the earlier "Pull the plug 
> > >> from Java 8 in 12.1?" thread.
> > >>
> > >> Good support for Java 8 is a feature, and an important one for an 
> > >> IDE
> > that
> > >> is primarily associated with the Java ecosystem.
> > >>
> > >> Eirik
> > >>
> > >> -Original Message-
> > >> From: Geertjan Wielenga 
> > >> Sent: Tuesday, April 28, 2020 2:47 AM
> > >> To: dev 
> > >> Subject: nb-javac and the upcoming 12.0
> > >>
> > >> Hi all,
> > >>
> > >> We’re getting close to the 12.0 release and nb-javac won’t be 
> > >> available
> > at
> > >> the time of release. What nb-javac provides is detailed elsewhere 
> > >> but in summary it is a fork of the  javac finetuned to the Java 
> > >> Editor in NetBeans. It can’t be donated to Apache NetBeans 
> > >> because it is a javac
> > fork
> > >> and hence GPL licensed, so Oracle does not want to donate it and 
> > >> Apache projects can’t be released with it.
> > >>
> > >> Ultimately, we’d like to drop the need for nb-javac completely.
> > >> That
> > will
> > >> simplify things a lot. Plus, that is increasingly possible 
> > >> because from
> > JDK
> > >> 9 onwards we’re able to use the javac from the JDK that NetBeans 
> > >> runs on for the same purposes as nb-javac.
> > >>
> > >> And we’ve (especially Jan Lahoda) been enhancing Apache NetBeans 
> > >> over
> > the
> > >> past releases to enable the vanilla javac from the JDK on which 
> > >> NetBeans runs to be used increasingly better. And ultimately, of 
> > >> course, this
> > should
> > >> not be based on the JDK on which NetBeans runs, but on the JDK 
> > >> used by a particular project.
> > >>
> > >> 

Re: nb-javac and the upcoming 12.0

[Geertjan Wielenga]

Hopefully that’s not sarcasm. :-)

Gj

On Tue, 28 Apr 2020 at 18:43, Eirik Bakke  wrote:

> Oh, now I get it. So you can still compile projects with JDK 8 and use the
> editor, but you must run the IDE itself on JDK 14, and with no nb-javac (to
> make JDK 8 projects work).
>
> That actually seems very reasonable!
>
> -- Eirik
>
> -Original Message-
> From: Geertjan Wielenga 
> Sent: Tuesday, April 28, 2020 12:29 PM
> To: dev@netbeans.apache.org
> Subject: Re: nb-javac and the upcoming 12.0
>
> Yes, the Java editor uses the JDK 14 javac if it runs on that JDK — even
> if the build of a particular project uses JDK 8 or anything else.
>
> Gj
>
> On Tue, 28 Apr 2020 at 18:25, Scott Palmer  wrote:
>
> > Just my 2 cents... I am all for NB having great first-class support
> > for development of projects that use Java 8, but I don’t care if I’m
> > forced to run NB itself with JDK-14.
> > I realize that some have projects  based on the NB platform that they
> > want to run on Java 8. I think if you are in that situation, you have
> > to decide to keep with an older version of the NB platform because we
> > can’t hold the platform back to Java 8 compatibility forever.
> >
> > That being said, I would like to be able to change the default JDK for
> > projects so it is a different JDK than what NB is running on. Having
> > to go through most of my projects and explicitly flip them to use JDK
> > 8 is a minor pain, and it also makes sharing the project with a team a
> > little more awkward as well. They need additional configuration in NB
> > so the right JDK can be found and we have to share NB project files
> > that otherwise don’t need to go into the project’s source repo.
> >
> > What is unclear to me, and it seems I’m not alone, is if NB is running
> > on
> > JDK-14 without nb-javac, what do we miss when working on a project
> > that builds with JDK-8? Can the NB editor not use JDK-14’s javac even
> > tough the build runs with JDK-8?
> >
> > Scott
> >
> > > On Apr 28, 2020, at 10:50 AM, Geertjan Wielenga
> > > 
> > wrote:
> > >
> > > You're not going to find me arguing against good support for Java 8.
> > > However, as stated above, we anticipate that nb-javac will not be
> > > ready
> > in
> > > time for the 12.0 release.
> > >
> > > Gj
> > >
> > > On Tue, Apr 28, 2020 at 4:46 PM Eirik Bakke  wrote:
> > >
> > >>> A question is what about JDK 8. My bold suggestion would be that
> > >>> we
> > >> explicitly tell our users that they can’t use our Java Editor if
> > >> they’re running NetBeans on JDK 8.
> > >>
> > >> I think it's too early to drop first-class support for Java 8, for
> > >> the same reasons people listed in the earlier "Pull the plug from
> > >> Java 8 in 12.1?" thread.
> > >>
> > >> Good support for Java 8 is a feature, and an important one for an
> > >> IDE
> > that
> > >> is primarily associated with the Java ecosystem.
> > >>
> > >> Eirik
> > >>
> > >> -Original Message-
> > >> From: Geertjan Wielenga 
> > >> Sent: Tuesday, April 28, 2020 2:47 AM
> > >> To: dev 
> > >> Subject: nb-javac and the upcoming 12.0
> > >>
> > >> Hi all,
> > >>
> > >> We’re getting close to the 12.0 release and nb-javac won’t be
> > >> available
> > at
> > >> the time of release. What nb-javac provides is detailed elsewhere
> > >> but in summary it is a fork of the  javac finetuned to the Java
> > >> Editor in NetBeans. It can’t be donated to Apache NetBeans because
> > >> it is a javac
> > fork
> > >> and hence GPL licensed, so Oracle does not want to donate it and
> > >> Apache projects can’t be released with it.
> > >>
> > >> Ultimately, we’d like to drop the need for nb-javac completely.
> > >> That
> > will
> > >> simplify things a lot. Plus, that is increasingly possible because
> > >> from
> > JDK
> > >> 9 onwards we’re able to use the javac from the JDK that NetBeans
> > >> runs on for the same purposes as nb-javac.
> > >>
> > >> And we’ve (especially Jan Lahoda) been enhancing Apache NetBeans
> > >> over
> > the
> > >> past releases to enable the vanilla javac from the JDK on which
> > >> NetBeans runs to be used increasingly better. And ultimately, of
> > >> course, this
> > should
> > >> not be based on the JDK on which NetBeans runs, but on the JDK used
> > >> by a particular project.
> > >>
> > >> Anyway, there have been one or two pull requests around the above,
> > >> such
> > as
> > >> this one:
> > >>
> > >> https://github.com/apache/netbeans/pull/2108
> > >>
> > >> A question is what about JDK 8. My bold suggestion would be that we
> > >> explicitly tell our users that they can’t use our Java Editor if
> > >> they’re running NetBeans on JDK 8. I’m not saying that we should
> > >> drop support
> > for
> > >> JDK 8. I’m saying we should show a message that the user should
> > >> switch
> > to
> > >> the latest supported JDK for running NetBeans itself on (which of
> > >> course does not mean that a project can’t use any earlier JDK).
> > >>
> > >> Anyway, comments and thoughts welcome.
> 

RE: nb-javac and the upcoming 12.0

[Eirik Bakke]

Oh, now I get it. So you can still compile projects with JDK 8 and use the 
editor, but you must run the IDE itself on JDK 14, and with no nb-javac (to 
make JDK 8 projects work).

That actually seems very reasonable!

-- Eirik

-Original Message-
From: Geertjan Wielenga  
Sent: Tuesday, April 28, 2020 12:29 PM
To: dev@netbeans.apache.org
Subject: Re: nb-javac and the upcoming 12.0

Yes, the Java editor uses the JDK 14 javac if it runs on that JDK — even if the 
build of a particular project uses JDK 8 or anything else.

Gj

On Tue, 28 Apr 2020 at 18:25, Scott Palmer  wrote:

> Just my 2 cents... I am all for NB having great first-class support 
> for development of projects that use Java 8, but I don’t care if I’m 
> forced to run NB itself with JDK-14.
> I realize that some have projects  based on the NB platform that they 
> want to run on Java 8. I think if you are in that situation, you have 
> to decide to keep with an older version of the NB platform because we 
> can’t hold the platform back to Java 8 compatibility forever.
>
> That being said, I would like to be able to change the default JDK for 
> projects so it is a different JDK than what NB is running on. Having 
> to go through most of my projects and explicitly flip them to use JDK 
> 8 is a minor pain, and it also makes sharing the project with a team a 
> little more awkward as well. They need additional configuration in NB 
> so the right JDK can be found and we have to share NB project files 
> that otherwise don’t need to go into the project’s source repo.
>
> What is unclear to me, and it seems I’m not alone, is if NB is running 
> on
> JDK-14 without nb-javac, what do we miss when working on a project 
> that builds with JDK-8? Can the NB editor not use JDK-14’s javac even 
> tough the build runs with JDK-8?
>
> Scott
>
> > On Apr 28, 2020, at 10:50 AM, Geertjan Wielenga 
> > 
> wrote:
> >
> > You're not going to find me arguing against good support for Java 8.
> > However, as stated above, we anticipate that nb-javac will not be 
> > ready
> in
> > time for the 12.0 release.
> >
> > Gj
> >
> > On Tue, Apr 28, 2020 at 4:46 PM Eirik Bakke  wrote:
> >
> >>> A question is what about JDK 8. My bold suggestion would be that 
> >>> we
> >> explicitly tell our users that they can’t use our Java Editor if 
> >> they’re running NetBeans on JDK 8.
> >>
> >> I think it's too early to drop first-class support for Java 8, for 
> >> the same reasons people listed in the earlier "Pull the plug from 
> >> Java 8 in 12.1?" thread.
> >>
> >> Good support for Java 8 is a feature, and an important one for an 
> >> IDE
> that
> >> is primarily associated with the Java ecosystem.
> >>
> >> Eirik
> >>
> >> -Original Message-
> >> From: Geertjan Wielenga 
> >> Sent: Tuesday, April 28, 2020 2:47 AM
> >> To: dev 
> >> Subject: nb-javac and the upcoming 12.0
> >>
> >> Hi all,
> >>
> >> We’re getting close to the 12.0 release and nb-javac won’t be 
> >> available
> at
> >> the time of release. What nb-javac provides is detailed elsewhere 
> >> but in summary it is a fork of the  javac finetuned to the Java 
> >> Editor in NetBeans. It can’t be donated to Apache NetBeans because 
> >> it is a javac
> fork
> >> and hence GPL licensed, so Oracle does not want to donate it and 
> >> Apache projects can’t be released with it.
> >>
> >> Ultimately, we’d like to drop the need for nb-javac completely. 
> >> That
> will
> >> simplify things a lot. Plus, that is increasingly possible because 
> >> from
> JDK
> >> 9 onwards we’re able to use the javac from the JDK that NetBeans 
> >> runs on for the same purposes as nb-javac.
> >>
> >> And we’ve (especially Jan Lahoda) been enhancing Apache NetBeans 
> >> over
> the
> >> past releases to enable the vanilla javac from the JDK on which 
> >> NetBeans runs to be used increasingly better. And ultimately, of 
> >> course, this
> should
> >> not be based on the JDK on which NetBeans runs, but on the JDK used 
> >> by a particular project.
> >>
> >> Anyway, there have been one or two pull requests around the above, 
> >> such
> as
> >> this one:
> >>
> >> https://github.com/apache/netbeans/pull/2108
> >>
> >> A question is what about JDK 8. My bold suggestion would be that we 
> >> explicitly tell our users that they can’t use our Java Editor if 
> >> they’re running NetBeans on JDK 8. I’m not saying that we should 
> >> drop support
> for
> >> JDK 8. I’m saying we should show a message that the user should 
> >> switch
> to
> >> the latest supported JDK for running NetBeans itself on (which of 
> >> course does not mean that a project can’t use any earlier JDK).
> >>
> >> Anyway, comments and thoughts welcome.
> >>
> >> Gj
> >>
> >> ---
> >> -- To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org
> >> For additional commands, e-mail: dev-h...@netbeans.apache.org
> >>
> >> For further information about the NetBeans mailing lists, visit:
> >> 

Re: nb-javac and the upcoming 12.0

[Geertjan Wielenga]

Yes, the Java editor uses the JDK 14 javac if it runs on that JDK — even if
the build of a particular project uses JDK 8 or anything else.

Gj

On Tue, 28 Apr 2020 at 18:25, Scott Palmer  wrote:

> Just my 2 cents... I am all for NB having great first-class support for
> development of projects that use Java 8, but I don’t care if I’m forced to
> run NB itself with JDK-14.
> I realize that some have projects  based on the NB platform that they want
> to run on Java 8. I think if you are in that situation, you have to decide
> to keep with an older version of the NB platform because we can’t hold the
> platform back to Java 8 compatibility forever.
>
> That being said, I would like to be able to change the default JDK for
> projects so it is a different JDK than what NB is running on. Having to go
> through most of my projects and explicitly flip them to use JDK 8 is a
> minor pain, and it also makes sharing the project with a team a little more
> awkward as well. They need additional configuration in NB so the right JDK
> can be found and we have to share NB project files that otherwise don’t
> need to go into the project’s source repo.
>
> What is unclear to me, and it seems I’m not alone, is if NB is running on
> JDK-14 without nb-javac, what do we miss when working on a project that
> builds with JDK-8? Can the NB editor not use JDK-14’s javac even tough the
> build runs with JDK-8?
>
> Scott
>
> > On Apr 28, 2020, at 10:50 AM, Geertjan Wielenga 
> wrote:
> >
> > You're not going to find me arguing against good support for Java 8.
> > However, as stated above, we anticipate that nb-javac will not be ready
> in
> > time for the 12.0 release.
> >
> > Gj
> >
> > On Tue, Apr 28, 2020 at 4:46 PM Eirik Bakke  wrote:
> >
> >>> A question is what about JDK 8. My bold suggestion would be that we
> >> explicitly tell our users that they can’t use our Java Editor if they’re
> >> running NetBeans on JDK 8.
> >>
> >> I think it's too early to drop first-class support for Java 8, for the
> >> same reasons people listed in the earlier "Pull the plug from Java 8 in
> >> 12.1?" thread.
> >>
> >> Good support for Java 8 is a feature, and an important one for an IDE
> that
> >> is primarily associated with the Java ecosystem.
> >>
> >> Eirik
> >>
> >> -Original Message-
> >> From: Geertjan Wielenga 
> >> Sent: Tuesday, April 28, 2020 2:47 AM
> >> To: dev 
> >> Subject: nb-javac and the upcoming 12.0
> >>
> >> Hi all,
> >>
> >> We’re getting close to the 12.0 release and nb-javac won’t be available
> at
> >> the time of release. What nb-javac provides is detailed elsewhere but in
> >> summary it is a fork of the  javac finetuned to the Java Editor in
> >> NetBeans. It can’t be donated to Apache NetBeans because it is a javac
> fork
> >> and hence GPL licensed, so Oracle does not want to donate it and Apache
> >> projects can’t be released with it.
> >>
> >> Ultimately, we’d like to drop the need for nb-javac completely. That
> will
> >> simplify things a lot. Plus, that is increasingly possible because from
> JDK
> >> 9 onwards we’re able to use the javac from the JDK that NetBeans runs on
> >> for the same purposes as nb-javac.
> >>
> >> And we’ve (especially Jan Lahoda) been enhancing Apache NetBeans over
> the
> >> past releases to enable the vanilla javac from the JDK on which NetBeans
> >> runs to be used increasingly better. And ultimately, of course, this
> should
> >> not be based on the JDK on which NetBeans runs, but on the JDK used by a
> >> particular project.
> >>
> >> Anyway, there have been one or two pull requests around the above, such
> as
> >> this one:
> >>
> >> https://github.com/apache/netbeans/pull/2108
> >>
> >> A question is what about JDK 8. My bold suggestion would be that we
> >> explicitly tell our users that they can’t use our Java Editor if they’re
> >> running NetBeans on JDK 8. I’m not saying that we should drop support
> for
> >> JDK 8. I’m saying we should show a message that the user should switch
> to
> >> the latest supported JDK for running NetBeans itself on (which of course
> >> does not mean that a project can’t use any earlier JDK).
> >>
> >> Anyway, comments and thoughts welcome.
> >>
> >> Gj
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org
> >> For additional commands, e-mail: dev-h...@netbeans.apache.org
> >>
> >> For further information about the NetBeans mailing lists, visit:
> >> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
> >>
> >>
> >>
> >>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org
> For additional commands, e-mail: dev-h...@netbeans.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
>

Re: nb-javac and the upcoming 12.0

[Scott Palmer]

Just my 2 cents... I am all for NB having great first-class support for 
development of projects that use Java 8, but I don’t care if I’m forced to run 
NB itself with JDK-14. 
I realize that some have projects  based on the NB platform that they want to 
run on Java 8. I think if you are in that situation, you have to decide to keep 
with an older version of the NB platform because we can’t hold the platform 
back to Java 8 compatibility forever. 

That being said, I would like to be able to change the default JDK for projects 
so it is a different JDK than what NB is running on. Having to go through most 
of my projects and explicitly flip them to use JDK 8 is a minor pain, and it 
also makes sharing the project with a team a little more awkward as well. They 
need additional configuration in NB so the right JDK can be found and we have 
to share NB project files that otherwise don’t need to go into the project’s 
source repo. 

What is unclear to me, and it seems I’m not alone, is if NB is running on 
JDK-14 without nb-javac, what do we miss when working on a project that builds 
with JDK-8? Can the NB editor not use JDK-14’s javac even tough the build runs 
with JDK-8?

Scott

> On Apr 28, 2020, at 10:50 AM, Geertjan Wielenga  wrote:
> 
> You're not going to find me arguing against good support for Java 8.
> However, as stated above, we anticipate that nb-javac will not be ready in
> time for the 12.0 release.
> 
> Gj
> 
> On Tue, Apr 28, 2020 at 4:46 PM Eirik Bakke  wrote:
> 
>>> A question is what about JDK 8. My bold suggestion would be that we
>> explicitly tell our users that they can’t use our Java Editor if they’re
>> running NetBeans on JDK 8.
>> 
>> I think it's too early to drop first-class support for Java 8, for the
>> same reasons people listed in the earlier "Pull the plug from Java 8 in
>> 12.1?" thread.
>> 
>> Good support for Java 8 is a feature, and an important one for an IDE that
>> is primarily associated with the Java ecosystem.
>> 
>> Eirik
>> 
>> -Original Message-
>> From: Geertjan Wielenga 
>> Sent: Tuesday, April 28, 2020 2:47 AM
>> To: dev 
>> Subject: nb-javac and the upcoming 12.0
>> 
>> Hi all,
>> 
>> We’re getting close to the 12.0 release and nb-javac won’t be available at
>> the time of release. What nb-javac provides is detailed elsewhere but in
>> summary it is a fork of the  javac finetuned to the Java Editor in
>> NetBeans. It can’t be donated to Apache NetBeans because it is a javac fork
>> and hence GPL licensed, so Oracle does not want to donate it and Apache
>> projects can’t be released with it.
>> 
>> Ultimately, we’d like to drop the need for nb-javac completely. That will
>> simplify things a lot. Plus, that is increasingly possible because from JDK
>> 9 onwards we’re able to use the javac from the JDK that NetBeans runs on
>> for the same purposes as nb-javac.
>> 
>> And we’ve (especially Jan Lahoda) been enhancing Apache NetBeans over the
>> past releases to enable the vanilla javac from the JDK on which NetBeans
>> runs to be used increasingly better. And ultimately, of course, this should
>> not be based on the JDK on which NetBeans runs, but on the JDK used by a
>> particular project.
>> 
>> Anyway, there have been one or two pull requests around the above, such as
>> this one:
>> 
>> https://github.com/apache/netbeans/pull/2108
>> 
>> A question is what about JDK 8. My bold suggestion would be that we
>> explicitly tell our users that they can’t use our Java Editor if they’re
>> running NetBeans on JDK 8. I’m not saying that we should drop support for
>> JDK 8. I’m saying we should show a message that the user should switch to
>> the latest supported JDK for running NetBeans itself on (which of course
>> does not mean that a project can’t use any earlier JDK).
>> 
>> Anyway, comments and thoughts welcome.
>> 
>> Gj
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org
>> For additional commands, e-mail: dev-h...@netbeans.apache.org
>> 
>> For further information about the NetBeans mailing lists, visit:
>> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>> 
>> 
>> 
>> 

-
To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org
For additional commands, e-mail: dev-h...@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: nb-javac and the upcoming 12.0

[Geertjan Wielenga]

You're not going to find me arguing against good support for Java 8.
However, as stated above, we anticipate that nb-javac will not be ready in
time for the 12.0 release.

Gj

On Tue, Apr 28, 2020 at 4:46 PM Eirik Bakke  wrote:

> > A question is what about JDK 8. My bold suggestion would be that we
> explicitly tell our users that they can’t use our Java Editor if they’re
> running NetBeans on JDK 8.
>
> I think it's too early to drop first-class support for Java 8, for the
> same reasons people listed in the earlier "Pull the plug from Java 8 in
> 12.1?" thread.
>
> Good support for Java 8 is a feature, and an important one for an IDE that
> is primarily associated with the Java ecosystem.
>
> Eirik
>
> -Original Message-
> From: Geertjan Wielenga 
> Sent: Tuesday, April 28, 2020 2:47 AM
> To: dev 
> Subject: nb-javac and the upcoming 12.0
>
> Hi all,
>
> We’re getting close to the 12.0 release and nb-javac won’t be available at
> the time of release. What nb-javac provides is detailed elsewhere but in
> summary it is a fork of the  javac finetuned to the Java Editor in
> NetBeans. It can’t be donated to Apache NetBeans because it is a javac fork
> and hence GPL licensed, so Oracle does not want to donate it and Apache
> projects can’t be released with it.
>
> Ultimately, we’d like to drop the need for nb-javac completely. That will
> simplify things a lot. Plus, that is increasingly possible because from JDK
> 9 onwards we’re able to use the javac from the JDK that NetBeans runs on
> for the same purposes as nb-javac.
>
> And we’ve (especially Jan Lahoda) been enhancing Apache NetBeans over the
> past releases to enable the vanilla javac from the JDK on which NetBeans
> runs to be used increasingly better. And ultimately, of course, this should
> not be based on the JDK on which NetBeans runs, but on the JDK used by a
> particular project.
>
> Anyway, there have been one or two pull requests around the above, such as
> this one:
>
> https://github.com/apache/netbeans/pull/2108
>
> A question is what about JDK 8. My bold suggestion would be that we
> explicitly tell our users that they can’t use our Java Editor if they’re
> running NetBeans on JDK 8. I’m not saying that we should drop support for
> JDK 8. I’m saying we should show a message that the user should switch to
> the latest supported JDK for running NetBeans itself on (which of course
> does not mean that a project can’t use any earlier JDK).
>
> Anyway, comments and thoughts welcome.
>
> Gj
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org
> For additional commands, e-mail: dev-h...@netbeans.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
>

RE: nb-javac and the upcoming 12.0

[Eirik Bakke]

> A question is what about JDK 8. My bold suggestion would be that we 
> explicitly tell our users that they can’t use our Java Editor if they’re 
> running NetBeans on JDK 8.

I think it's too early to drop first-class support for Java 8, for the same 
reasons people listed in the earlier "Pull the plug from Java 8 in 12.1?" 
thread.

Good support for Java 8 is a feature, and an important one for an IDE that is 
primarily associated with the Java ecosystem.

Eirik

-Original Message-
From: Geertjan Wielenga  
Sent: Tuesday, April 28, 2020 2:47 AM
To: dev 
Subject: nb-javac and the upcoming 12.0

Hi all,

We’re getting close to the 12.0 release and nb-javac won’t be available at the 
time of release. What nb-javac provides is detailed elsewhere but in summary it 
is a fork of the  javac finetuned to the Java Editor in NetBeans. It can’t be 
donated to Apache NetBeans because it is a javac fork and hence GPL licensed, 
so Oracle does not want to donate it and Apache projects can’t be released with 
it.

Ultimately, we’d like to drop the need for nb-javac completely. That will 
simplify things a lot. Plus, that is increasingly possible because from JDK
9 onwards we’re able to use the javac from the JDK that NetBeans runs on for 
the same purposes as nb-javac.

And we’ve (especially Jan Lahoda) been enhancing Apache NetBeans over the past 
releases to enable the vanilla javac from the JDK on which NetBeans runs to be 
used increasingly better. And ultimately, of course, this should not be based 
on the JDK on which NetBeans runs, but on the JDK used by a particular project.

Anyway, there have been one or two pull requests around the above, such as this 
one:

https://github.com/apache/netbeans/pull/2108

A question is what about JDK 8. My bold suggestion would be that we explicitly 
tell our users that they can’t use our Java Editor if they’re running NetBeans 
on JDK 8. I’m not saying that we should drop support for JDK 8. I’m saying we 
should show a message that the user should switch to the latest supported JDK 
for running NetBeans itself on (which of course does not mean that a project 
can’t use any earlier JDK).

Anyway, comments and thoughts welcome.

Gj

-
To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org
For additional commands, e-mail: dev-h...@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: CA survey for Beta 3 or 4?

[Jiří Kovalský]

In such case let's include 
https://issues.apache.org/jira/browse/NETBEANS-4071 which is so far the 
only blocker identified by NetCAT team.


Eric?

-Jirka

Dne 28. 04. 20 v 14:44 Geertjan Wielenga napsal(a):

I think best to wait for Beta 4. That will basically be our release
candidate.

Gj


On Tue, 28 Apr 2020 at 14:40, Jiří Kovalský 
wrote:


Hi folks & Eric,

 according to the NetCAT plan [1] we should have started the
Community Acceptance (CA) survey yesterday. This research helps us to
gather feedback on the latest promoted build from the whole NetBeans
community and not only NetCAT participants before the final release voting.

 Are we planning to build Beta 4 or will Beta 3 become the voting
candidate? Or in other words, should I wait for Beta 4 or can I launch
the CA survey ASAP?

Thanks,
-Jirka

[1]
https://urldefense.com/v3/__https://cwiki.apache.org/confluence/display/NETBEANS/NetCAT*12.0*Schedule__;Kys!!GqivPVa7Brio!M9P_EJgH7l3cDw5VBdn31kT41rqkQ_fSStBI-majt3u51jgeOzKlnewZTbmDgBRNQW4$

-
To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org
For additional commands, e-mail: dev-h...@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://urldefense.com/v3/__https://cwiki.apache.org/confluence/display/NETBEANS/Mailing*lists__;Kw!!GqivPVa7Brio!M9P_EJgH7l3cDw5VBdn31kT41rqkQ_fSStBI-majt3u51jgeOzKlnewZTbmDIf2Og7k$








-
To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org
For additional commands, e-mail: dev-h...@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: CA survey for Beta 3 or 4?

[Geertjan Wielenga]

I think best to wait for Beta 4. That will basically be our release
candidate.

Gj


On Tue, 28 Apr 2020 at 14:40, Jiří Kovalský 
wrote:

> Hi folks & Eric,
>
> according to the NetCAT plan [1] we should have started the
> Community Acceptance (CA) survey yesterday. This research helps us to
> gather feedback on the latest promoted build from the whole NetBeans
> community and not only NetCAT participants before the final release voting.
>
> Are we planning to build Beta 4 or will Beta 3 become the voting
> candidate? Or in other words, should I wait for Beta 4 or can I launch
> the CA survey ASAP?
>
> Thanks,
> -Jirka
>
> [1]
> https://cwiki.apache.org/confluence/display/NETBEANS/NetCAT+12.0+Schedule
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org
> For additional commands, e-mail: dev-h...@netbeans.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
>

CA survey for Beta 3 or 4?

[Jiří Kovalský]

Hi folks & Eric,

   according to the NetCAT plan [1] we should have started the 
Community Acceptance (CA) survey yesterday. This research helps us to 
gather feedback on the latest promoted build from the whole NetBeans 
community and not only NetCAT participants before the final release voting.


   Are we planning to build Beta 4 or will Beta 3 become the voting 
candidate? Or in other words, should I wait for Beta 4 or can I launch 
the CA survey ASAP?


Thanks,
-Jirka

[1] 
https://cwiki.apache.org/confluence/display/NETBEANS/NetCAT+12.0+Schedule


-
To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org
For additional commands, e-mail: dev-h...@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: Future of nb-javac and vanilla javac

[Geertjan Wielenga]

Another way to look at it is via a search in our PRs, when you search on
javac, or similar, you should find all of them.

Gj

On Tue, 28 Apr 2020 at 13:35, Geertjan Wielenga  wrote:

>
>
>
> Sure, if you can put it together, I’ll be happy to contribute to it.
>
> Gj
>
> On Tue, 28 Apr 2020 at 13:13, Jean-Marc Borer  wrote:
>
>> IMHO this justifies even more to group the information about
>> nb-javac/javac in single place, no?
>>
>> JMB
>>
>> On Tue, Apr 28, 2020 at 12:25 PM Geertjan Wielenga 
>> wrote:
>>
>> > It’s changing all the time though. The enhancements that nb-javac brings
>> > are continually being reworked into our GitHub via interaction with
>> vanilla
>> > javac.
>> >
>> > Gj
>> >
>> > On Tue, 28 Apr 2020 at 12:22, Jean-Marc Borer 
>> wrote:
>> >
>> > > I have the feeling all the confusion about the nb-javac is due to fact
>> > >  that most of the information is scattered among different discussions
>> > and
>> > > (old?) wiki pages. As it is a hot topic, it would deserve a single and
>> > > up-to-date location about the evolution, don't you think?
>> > >
>> > > Best wishes,
>> > >
>> > > Jean-Marc
>> > >
>> > > On Tue, Apr 28, 2020 at 11:24 AM Neil C Smith 
>> > > wrote:
>> > >
>> > > > On Tue, 28 Apr 2020 at 10:06, Jean-Marc Borer 
>> > wrote:
>> > > > > Sure it would be good to code without it, but it seems that using
>> the
>> > > > plain
>> > > > > vanilla javac leads to some serious caveats according to
>> > > > >
>> > > >
>> > >
>> >
>> https://cwiki.apache.org/confluence/display/NETBEANS/Java+Editor+Using+JDK+javac
>> > > >
>> > > > That page is quite old now.  There are still caveats, but also Jan
>> and
>> > > > others have done a lot of work to make things better with vanilla
>> > > > javac.
>> > > >
>> > > > If we are dropping nb-javac as mooted elsewhere in 12.1, then that
>> > > > would be a decision to be made with the current caveats in mind.
>> > > >
>> > > > There are some serious caveats to keeping nb-javac too, as
>> Geertjan's
>> > > > thread today reveals! ;-)
>> > > >
>> > > > Best wishes,
>> > > >
>> > > > Neil
>> > > >
>> > > >
>> -
>> > > > To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org
>> > > > For additional commands, e-mail: dev-h...@netbeans.apache.org
>> > > >
>> > > > For further information about the NetBeans mailing lists, visit:
>> > > > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>> > > >
>> > > >
>> > > >
>> > > >
>> > >
>> >
>>
>

Re: Future of nb-javac and vanilla javac

[Geertjan Wielenga]

Sure, if you can put it together, I’ll be happy to contribute to it.

Gj

On Tue, 28 Apr 2020 at 13:13, Jean-Marc Borer  wrote:

> IMHO this justifies even more to group the information about
> nb-javac/javac in single place, no?
>
> JMB
>
> On Tue, Apr 28, 2020 at 12:25 PM Geertjan Wielenga 
> wrote:
>
> > It’s changing all the time though. The enhancements that nb-javac brings
> > are continually being reworked into our GitHub via interaction with
> vanilla
> > javac.
> >
> > Gj
> >
> > On Tue, 28 Apr 2020 at 12:22, Jean-Marc Borer  wrote:
> >
> > > I have the feeling all the confusion about the nb-javac is due to fact
> > >  that most of the information is scattered among different discussions
> > and
> > > (old?) wiki pages. As it is a hot topic, it would deserve a single and
> > > up-to-date location about the evolution, don't you think?
> > >
> > > Best wishes,
> > >
> > > Jean-Marc
> > >
> > > On Tue, Apr 28, 2020 at 11:24 AM Neil C Smith 
> > > wrote:
> > >
> > > > On Tue, 28 Apr 2020 at 10:06, Jean-Marc Borer 
> > wrote:
> > > > > Sure it would be good to code without it, but it seems that using
> the
> > > > plain
> > > > > vanilla javac leads to some serious caveats according to
> > > > >
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/NETBEANS/Java+Editor+Using+JDK+javac
> > > >
> > > > That page is quite old now.  There are still caveats, but also Jan
> and
> > > > others have done a lot of work to make things better with vanilla
> > > > javac.
> > > >
> > > > If we are dropping nb-javac as mooted elsewhere in 12.1, then that
> > > > would be a decision to be made with the current caveats in mind.
> > > >
> > > > There are some serious caveats to keeping nb-javac too, as Geertjan's
> > > > thread today reveals! ;-)
> > > >
> > > > Best wishes,
> > > >
> > > > Neil
> > > >
> > > > -
> > > > To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org
> > > > For additional commands, e-mail: dev-h...@netbeans.apache.org
> > > >
> > > > For further information about the NetBeans mailing lists, visit:
> > > > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
> > > >
> > > >
> > > >
> > > >
> > >
> >
>

Re: Future of nb-javac and vanilla javac

[Jean-Marc Borer]

IMHO this justifies even more to group the information about
nb-javac/javac in single place, no?

JMB

On Tue, Apr 28, 2020 at 12:25 PM Geertjan Wielenga 
wrote:

> It’s changing all the time though. The enhancements that nb-javac brings
> are continually being reworked into our GitHub via interaction with vanilla
> javac.
>
> Gj
>
> On Tue, 28 Apr 2020 at 12:22, Jean-Marc Borer  wrote:
>
> > I have the feeling all the confusion about the nb-javac is due to fact
> >  that most of the information is scattered among different discussions
> and
> > (old?) wiki pages. As it is a hot topic, it would deserve a single and
> > up-to-date location about the evolution, don't you think?
> >
> > Best wishes,
> >
> > Jean-Marc
> >
> > On Tue, Apr 28, 2020 at 11:24 AM Neil C Smith 
> > wrote:
> >
> > > On Tue, 28 Apr 2020 at 10:06, Jean-Marc Borer 
> wrote:
> > > > Sure it would be good to code without it, but it seems that using the
> > > plain
> > > > vanilla javac leads to some serious caveats according to
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/NETBEANS/Java+Editor+Using+JDK+javac
> > >
> > > That page is quite old now.  There are still caveats, but also Jan and
> > > others have done a lot of work to make things better with vanilla
> > > javac.
> > >
> > > If we are dropping nb-javac as mooted elsewhere in 12.1, then that
> > > would be a decision to be made with the current caveats in mind.
> > >
> > > There are some serious caveats to keeping nb-javac too, as Geertjan's
> > > thread today reveals! ;-)
> > >
> > > Best wishes,
> > >
> > > Neil
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org
> > > For additional commands, e-mail: dev-h...@netbeans.apache.org
> > >
> > > For further information about the NetBeans mailing lists, visit:
> > > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
> > >
> > >
> > >
> > >
> >
>

Re: Future of nb-javac and vanilla javac

[Geertjan Wielenga]

It’s changing all the time though. The enhancements that nb-javac brings
are continually being reworked into our GitHub via interaction with vanilla
javac.

Gj

On Tue, 28 Apr 2020 at 12:22, Jean-Marc Borer  wrote:

> I have the feeling all the confusion about the nb-javac is due to fact
>  that most of the information is scattered among different discussions and
> (old?) wiki pages. As it is a hot topic, it would deserve a single and
> up-to-date location about the evolution, don't you think?
>
> Best wishes,
>
> Jean-Marc
>
> On Tue, Apr 28, 2020 at 11:24 AM Neil C Smith 
> wrote:
>
> > On Tue, 28 Apr 2020 at 10:06, Jean-Marc Borer  wrote:
> > > Sure it would be good to code without it, but it seems that using the
> > plain
> > > vanilla javac leads to some serious caveats according to
> > >
> >
> https://cwiki.apache.org/confluence/display/NETBEANS/Java+Editor+Using+JDK+javac
> >
> > That page is quite old now.  There are still caveats, but also Jan and
> > others have done a lot of work to make things better with vanilla
> > javac.
> >
> > If we are dropping nb-javac as mooted elsewhere in 12.1, then that
> > would be a decision to be made with the current caveats in mind.
> >
> > There are some serious caveats to keeping nb-javac too, as Geertjan's
> > thread today reveals! ;-)
> >
> > Best wishes,
> >
> > Neil
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org
> > For additional commands, e-mail: dev-h...@netbeans.apache.org
> >
> > For further information about the NetBeans mailing lists, visit:
> > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
> >
> >
> >
> >
>

Re: Future of nb-javac and vanilla javac

[Jean-Marc Borer]

I have the feeling all the confusion about the nb-javac is due to fact
 that most of the information is scattered among different discussions and
(old?) wiki pages. As it is a hot topic, it would deserve a single and
up-to-date location about the evolution, don't you think?

Best wishes,

Jean-Marc

On Tue, Apr 28, 2020 at 11:24 AM Neil C Smith  wrote:

> On Tue, 28 Apr 2020 at 10:06, Jean-Marc Borer  wrote:
> > Sure it would be good to code without it, but it seems that using the
> plain
> > vanilla javac leads to some serious caveats according to
> >
> https://cwiki.apache.org/confluence/display/NETBEANS/Java+Editor+Using+JDK+javac
>
> That page is quite old now.  There are still caveats, but also Jan and
> others have done a lot of work to make things better with vanilla
> javac.
>
> If we are dropping nb-javac as mooted elsewhere in 12.1, then that
> would be a decision to be made with the current caveats in mind.
>
> There are some serious caveats to keeping nb-javac too, as Geertjan's
> thread today reveals! ;-)
>
> Best wishes,
>
> Neil
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org
> For additional commands, e-mail: dev-h...@netbeans.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
>

Re: Future of nb-javac and vanilla javac

[Neil C Smith]

On Tue, 28 Apr 2020 at 10:06, Jean-Marc Borer  wrote:
> Sure it would be good to code without it, but it seems that using the plain
> vanilla javac leads to some serious caveats according to
> https://cwiki.apache.org/confluence/display/NETBEANS/Java+Editor+Using+JDK+javac

That page is quite old now.  There are still caveats, but also Jan and
others have done a lot of work to make things better with vanilla
javac.

If we are dropping nb-javac as mooted elsewhere in 12.1, then that
would be a decision to be made with the current caveats in mind.

There are some serious caveats to keeping nb-javac too, as Geertjan's
thread today reveals! ;-)

Best wishes,

Neil

-
To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org
For additional commands, e-mail: dev-h...@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: Future of nb-javac and vanilla javac

[Jean-Marc Borer]

Hi Geertjan,

Sure it would be good to code without it, but it seems that using the plain
vanilla javac leads to some serious caveats according to
https://cwiki.apache.org/confluence/display/NETBEANS/Java+Editor+Using+JDK+javac


So we can't reasonabily recommend to people not using the nb-javac, don't
you think?

Best wishes,

Jean-Marc

On Mon, Apr 27, 2020 at 9:51 PM Geertjan Wielenga 
wrote:

> There’s a related question to this pretty much every week. :-)
>
> It’s an ongoing process, we’re trying to move away from nb-javac, it
> requires some work still. In the meantime, if you can code without it,
> that would be great.
>
> Gj
>
>
> On Mon, 27 Apr 2020 at 21:19, Anthony Vanelverdinghe <
> anthonyv...@outlook.com> wrote:
>
> > My bad, I just noticed there was a related question just last week…
> >
> > From: Anthony Vanelverdinghe
> > Sent: Monday, 27 April 2020 21:16
> > To: dev@netbeans.apache.org
> > Subject: Future of nb-javac and vanilla javac
> >
> > Hi
> >
> > What is the future direction of NetBeans w.r.t. nb-javac and "vanilla"
> > javac?
> > NetBeans recommends nb-javac with a notification that says it “improves
> > Java editing experience and enables compile on save”.
> > But on the other hand it lags behind vanilla javac w.r.t. supporting new
> > language features (obviously), due to which I ran into the issue at [1]
> >
> > So I was wondering: how far is vanilla javac behind nb-javac in terms of
> > functionality? Are there plans to enhance it to the point where nb-javac
> > becomes obsolete? If so, what would be a rough estimate on when that
> would
> > be?
> >
> > Thanks in advance for any insights.
> >
> > Kind regards,
> > Anthony
> >
> > [1] https://issues.apache.org/jira/browse/NETBEANS-4263
> >
> >
>

Re: Netbeans Confluence

[Neil C Smith]

On Tue, 28 Apr 2020 at 09:44, Jean-Marc Borer  wrote:
> I wonder how the Netbeans confluence is or shall be used by our community.
> https://cwiki.apache.org/confluence/display/NETBEANS/Apache+NetBeans
>
> Moreover, I don't find (or could not find) any reference to it, either on
> GitHub or on the official site netbeans.apache.org.
>
> Am I missing something here?

Maybe best characterized as internal documentation vs external
documentation?  The wiki is generally about things relevant to people
on dev@ / committers / PMC specifically, rather than to the wider user
base.

It is linked in at a few places in the website, but to specific pages
like the release schedule (which probably deserves its own website
page at some point).

Best wishes,

Neil

-
To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org
For additional commands, e-mail: dev-h...@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: nb-javac and the upcoming 12.0

[Jean-Marc Borer]

I some answers here:
https://blogs.apache.org/netbeans/entry/what-s-nb-javac-in

But still, according to the blog entry, if you run NB on JDK9+ and use the
provided javac, you don't get all the benefits of nb-javac. I doesn't say
neither what those benefits are nor if you would benefit from them if you
use nb-javac with JDK9+ projects.


On Tue, Apr 28, 2020 at 10:38 AM Jean-Marc Borer  wrote:

> Now for my understanding: if you run Netbeans on JDK9+, but your projects
> are still using/running on JDK8, will you still need nb-javac for Java
> editing?
>
> Cheers,
>
> JM
>
> On Tue, Apr 28, 2020 at 8:59 AM Benjamin Graf 
> wrote:
>
>> Hi all together,
>>
>> what about code building. Netbeans is still build on JDK8. Some modules
>> need nb-javac for compilation and tests to work even if code is build
>> with JDK8 because code does use JDK9+ API. I think most time API from
>> javax.lang.model. You can increase min build JDK but it might not work
>> for users using Netbeans that need JDK8.
>>
>> Regards,
>>
>> Benjamin
>>
>> On 28.04.2020 08:47, Geertjan Wielenga wrote:
>> > Hi all,
>> >
>> > We’re getting close to the 12.0 release and nb-javac won’t be available
>> at
>> > the time of release. What nb-javac provides is detailed elsewhere but in
>> > summary it is a fork of the  javac finetuned to the Java Editor in
>> > NetBeans. It can’t be donated to Apache NetBeans because it is a javac
>> fork
>> > and hence GPL licensed, so Oracle does not want to donate it and Apache
>> > projects can’t be released with it.
>> >
>> > Ultimately, we’d like to drop the need for nb-javac completely. That
>> will
>> > simplify things a lot. Plus, that is increasingly possible because from
>> JDK
>> > 9 onwards we’re able to use the javac from the JDK that NetBeans runs on
>> > for the same purposes as nb-javac.
>> >
>> > And we’ve (especially Jan Lahoda) been enhancing Apache NetBeans over
>> the
>> > past releases to enable the vanilla javac from the JDK on which NetBeans
>> > runs to be used increasingly better. And ultimately, of course, this
>> should
>> > not be based on the JDK on which NetBeans runs, but on the JDK used by a
>> > particular project.
>> >
>> > Anyway, there have been one or two pull requests around the above, such
>> as
>> > this one:
>> >
>> > https://github.com/apache/netbeans/pull/2108
>> >
>> > A question is what about JDK 8. My bold suggestion would be that we
>> > explicitly tell our users that they can’t use our Java Editor if they’re
>> > running NetBeans on JDK 8. I’m not saying that we should drop support
>> for
>> > JDK 8. I’m saying we should show a message that the user should switch
>> to
>> > the latest supported JDK for running NetBeans itself on (which of course
>> > does not mean that a project can’t use any earlier JDK).
>> >
>> > Anyway, comments and thoughts welcome.
>> >
>> > Gj
>> >
>>
>>

Re: nb-javac and the upcoming 12.0

[Neil C Smith]

Hi,

Thanks for kicking this off! :-)

On Tue, 28 Apr 2020 at 07:47, Geertjan Wielenga  wrote:
> We’re getting close to the 12.0 release and nb-javac won’t be available at
> the time of release.

For clarity, we have the older nb-javac with support for JDK 13 that
we've had since 11.2 updates.  But we don't have an nb-javac with JDK
14 support.  That should have been available by feature freeze - that
was *a* reason we shifted the schedule back.  As it is it looks like
we might just have it by the planned release date, so even if linked
into 12.0 final, it would have missed all of NetCAT.

Having had the "fun" of a similar problem with 11.2, which broke some
key things and required a quick 11.2 update, I for one would -1
linking it in that late.

We could still push that link to nb-javac for JDK 14 after the 12.0
release, and after additional testing.  That will require a fix for
the third-party update centre to make it trusted and remove the
internal signing - I'll test and do a PR for that in the next couple
of days if no-one else gets around to it.

That means that at release nb-javac in 12.0 would be limited to Java
13, so Java 14 support would require running on JDK 14 and not
installing nb-javac (and us stopping the IDE nagging people about it).

> Ultimately, we’d like to drop the need for nb-javac completely. ... And 
> ultimately, of course, this should
> not be based on the JDK on which NetBeans runs, but on the JDK used by a
> particular project.

There was a thread about dropping nb-javac from 12.1 a little while
ago.  Maybe good to keep that conversation separate from the immediate
12.0 issue?  And we'd need to clarify whether the second part is what
we actually want to do?  At 12.0 release we'd get a picture of how
much people want to run on a JDK lower than they want to code against?

> A question is what about JDK 8. My bold suggestion would be that we
> explicitly tell our users that they can’t use our Java Editor if they’re
> running NetBeans on JDK 8.

Why?  This was discussed in that 12.1 thread too, and somewhat
controversial there, but we also discussed keeping the JDK 8 support
for 12.0.  I think we should - the only thing we can't do is support
coding against JDK 14 while running on JDK 8?  And that only,
potentially, until an update is available.

Best wishes,

Neil

-
To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org
For additional commands, e-mail: dev-h...@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: nb-javac and the upcoming 12.0

[Tomas Poledny]

Isn't it possible to use old versions nb-javac (the last supported) with
Java 8 (for example without support records and etc.) and otherwise (with
newer version of java) use vanilla javac?

On Tue, Apr 28, 2020 at 10:39 AM Jean-Marc Borer  wrote:

> Now for my understanding: if you run Netbeans on JDK9+, but your projects
> are still using/running on JDK8, will you still need nb-javac for Java
> editing?
>
> Cheers,
>
> JM
>
> On Tue, Apr 28, 2020 at 8:59 AM Benjamin Graf 
> wrote:
>
> > Hi all together,
> >
> > what about code building. Netbeans is still build on JDK8. Some modules
> > need nb-javac for compilation and tests to work even if code is build
> > with JDK8 because code does use JDK9+ API. I think most time API from
> > javax.lang.model. You can increase min build JDK but it might not work
> > for users using Netbeans that need JDK8.
> >
> > Regards,
> >
> > Benjamin
> >
> > On 28.04.2020 08:47, Geertjan Wielenga wrote:
> > > Hi all,
> > >
> > > We’re getting close to the 12.0 release and nb-javac won’t be available
> > at
> > > the time of release. What nb-javac provides is detailed elsewhere but
> in
> > > summary it is a fork of the  javac finetuned to the Java Editor in
> > > NetBeans. It can’t be donated to Apache NetBeans because it is a javac
> > fork
> > > and hence GPL licensed, so Oracle does not want to donate it and Apache
> > > projects can’t be released with it.
> > >
> > > Ultimately, we’d like to drop the need for nb-javac completely. That
> will
> > > simplify things a lot. Plus, that is increasingly possible because from
> > JDK
> > > 9 onwards we’re able to use the javac from the JDK that NetBeans runs
> on
> > > for the same purposes as nb-javac.
> > >
> > > And we’ve (especially Jan Lahoda) been enhancing Apache NetBeans over
> the
> > > past releases to enable the vanilla javac from the JDK on which
> NetBeans
> > > runs to be used increasingly better. And ultimately, of course, this
> > should
> > > not be based on the JDK on which NetBeans runs, but on the JDK used by
> a
> > > particular project.
> > >
> > > Anyway, there have been one or two pull requests around the above, such
> > as
> > > this one:
> > >
> > > https://github.com/apache/netbeans/pull/2108
> > >
> > > A question is what about JDK 8. My bold suggestion would be that we
> > > explicitly tell our users that they can’t use our Java Editor if
> they’re
> > > running NetBeans on JDK 8. I’m not saying that we should drop support
> for
> > > JDK 8. I’m saying we should show a message that the user should switch
> to
> > > the latest supported JDK for running NetBeans itself on (which of
> course
> > > does not mean that a project can’t use any earlier JDK).
> > >
> > > Anyway, comments and thoughts welcome.
> > >
> > > Gj
> > >
> >
> >
>

Netbeans Confluence

[Jean-Marc Borer]

Hi fellows,

I wonder how the Netbeans confluence is or shall be used by our community.
https://cwiki.apache.org/confluence/display/NETBEANS/Apache+NetBeans

Moreover, I don't find (or could not find) any reference to it, either on
GitHub or on the official site netbeans.apache.org.

Am I missing something here?

I am asking those questions, because I would like to have a wiki for the
other netbeans projects such as
https://github.com/apache/netbeans-mavenutils-nbm-maven-plugin

Cheers,

Jean-Marc

Re: nb-javac and the upcoming 12.0

[Jean-Marc Borer]

Now for my understanding: if you run Netbeans on JDK9+, but your projects
are still using/running on JDK8, will you still need nb-javac for Java
editing?

Cheers,

JM

On Tue, Apr 28, 2020 at 8:59 AM Benjamin Graf  wrote:

> Hi all together,
>
> what about code building. Netbeans is still build on JDK8. Some modules
> need nb-javac for compilation and tests to work even if code is build
> with JDK8 because code does use JDK9+ API. I think most time API from
> javax.lang.model. You can increase min build JDK but it might not work
> for users using Netbeans that need JDK8.
>
> Regards,
>
> Benjamin
>
> On 28.04.2020 08:47, Geertjan Wielenga wrote:
> > Hi all,
> >
> > We’re getting close to the 12.0 release and nb-javac won’t be available
> at
> > the time of release. What nb-javac provides is detailed elsewhere but in
> > summary it is a fork of the  javac finetuned to the Java Editor in
> > NetBeans. It can’t be donated to Apache NetBeans because it is a javac
> fork
> > and hence GPL licensed, so Oracle does not want to donate it and Apache
> > projects can’t be released with it.
> >
> > Ultimately, we’d like to drop the need for nb-javac completely. That will
> > simplify things a lot. Plus, that is increasingly possible because from
> JDK
> > 9 onwards we’re able to use the javac from the JDK that NetBeans runs on
> > for the same purposes as nb-javac.
> >
> > And we’ve (especially Jan Lahoda) been enhancing Apache NetBeans over the
> > past releases to enable the vanilla javac from the JDK on which NetBeans
> > runs to be used increasingly better. And ultimately, of course, this
> should
> > not be based on the JDK on which NetBeans runs, but on the JDK used by a
> > particular project.
> >
> > Anyway, there have been one or two pull requests around the above, such
> as
> > this one:
> >
> > https://github.com/apache/netbeans/pull/2108
> >
> > A question is what about JDK 8. My bold suggestion would be that we
> > explicitly tell our users that they can’t use our Java Editor if they’re
> > running NetBeans on JDK 8. I’m not saying that we should drop support for
> > JDK 8. I’m saying we should show a message that the user should switch to
> > the latest supported JDK for running NetBeans itself on (which of course
> > does not mean that a project can’t use any earlier JDK).
> >
> > Anyway, comments and thoughts welcome.
> >
> > Gj
> >
>
>

Re: nb-javac and the upcoming 12.0

[Benjamin Graf]

Hi all together,

what about code building. Netbeans is still build on JDK8. Some modules
need nb-javac for compilation and tests to work even if code is build
with JDK8 because code does use JDK9+ API. I think most time API from
javax.lang.model. You can increase min build JDK but it might not work
for users using Netbeans that need JDK8.

Regards,

Benjamin

On 28.04.2020 08:47, Geertjan Wielenga wrote:
> Hi all,
>
> We’re getting close to the 12.0 release and nb-javac won’t be available at
> the time of release. What nb-javac provides is detailed elsewhere but in
> summary it is a fork of the  javac finetuned to the Java Editor in
> NetBeans. It can’t be donated to Apache NetBeans because it is a javac fork
> and hence GPL licensed, so Oracle does not want to donate it and Apache
> projects can’t be released with it.
>
> Ultimately, we’d like to drop the need for nb-javac completely. That will
> simplify things a lot. Plus, that is increasingly possible because from JDK
> 9 onwards we’re able to use the javac from the JDK that NetBeans runs on
> for the same purposes as nb-javac.
>
> And we’ve (especially Jan Lahoda) been enhancing Apache NetBeans over the
> past releases to enable the vanilla javac from the JDK on which NetBeans
> runs to be used increasingly better. And ultimately, of course, this should
> not be based on the JDK on which NetBeans runs, but on the JDK used by a
> particular project.
>
> Anyway, there have been one or two pull requests around the above, such as
> this one:
>
> https://github.com/apache/netbeans/pull/2108
>
> A question is what about JDK 8. My bold suggestion would be that we
> explicitly tell our users that they can’t use our Java Editor if they’re
> running NetBeans on JDK 8. I’m not saying that we should drop support for
> JDK 8. I’m saying we should show a message that the user should switch to
> the latest supported JDK for running NetBeans itself on (which of course
> does not mean that a project can’t use any earlier JDK).
>
> Anyway, comments and thoughts welcome.
>
> Gj
>



signature.asc
Description: OpenPGP digital signature

nb-javac and the upcoming 12.0

[Geertjan Wielenga]

Hi all,

We’re getting close to the 12.0 release and nb-javac won’t be available at
the time of release. What nb-javac provides is detailed elsewhere but in
summary it is a fork of the  javac finetuned to the Java Editor in
NetBeans. It can’t be donated to Apache NetBeans because it is a javac fork
and hence GPL licensed, so Oracle does not want to donate it and Apache
projects can’t be released with it.

Ultimately, we’d like to drop the need for nb-javac completely. That will
simplify things a lot. Plus, that is increasingly possible because from JDK
9 onwards we’re able to use the javac from the JDK that NetBeans runs on
for the same purposes as nb-javac.

And we’ve (especially Jan Lahoda) been enhancing Apache NetBeans over the
past releases to enable the vanilla javac from the JDK on which NetBeans
runs to be used increasingly better. And ultimately, of course, this should
not be based on the JDK on which NetBeans runs, but on the JDK used by a
particular project.

Anyway, there have been one or two pull requests around the above, such as
this one:

https://github.com/apache/netbeans/pull/2108

A question is what about JDK 8. My bold suggestion would be that we
explicitly tell our users that they can’t use our Java Editor if they’re
running NetBeans on JDK 8. I’m not saying that we should drop support for
JDK 8. I’m saying we should show a message that the user should switch to
the latest supported JDK for running NetBeans itself on (which of course
does not mean that a project can’t use any earlier JDK).

Anyway, comments and thoughts welcome.

Gj